[v6r12] Removed use of shifter proxy (read-only operations)

[fstagni]

@atsareg @phicharp IIUC these agents would keep working in case of DFC. In case the file catalog is instead the LFC we need the machines to be trusted, and the agents/optimizers should run with CSEC_MECH=ID env variable

If accepted I will update the documentation.

Not using the proxy demonstrated speedup.

[atsareg]

I do not think it will work with DFC, DFC applies per user authentication, not per host. I would prefer using personal proxies ( shifter or ... ). Otherwise you might need to give special rights to a host which looks out of concept to me.

[fstagni]

It's not about writing data in the FC, it's about reading from it. And the DFC is just another DIRAC DB...

Anyway, I let you and Philippe (or Chris) decide, this is not fully my competence.

[phicharp]

Full authentication with a proxy for reading out of an FC is rather useless, and just a trusted relationship should be enough. This is what we do with the LFC. With the DFC or any Dirac service the applied concept is to use the server host certificate. I have no idea whether this is lighter or not, but obviously for other services it is clearly faster…
AFAIK the environment variable CSEC_MECH=ID is only used by the LFC, therefore is innocuous if we don’t use the LFC. My understanding was that useServerCertificate was the equivalent for Dirac services, i.e. for the DFC. Therefore we don’t need a proxy for agents that only read the DFC. Am I wrong?
Cheers,
Philippe

Le 8 déc. 2014 à 17:53, fstagni [email protected] a écrit :

It's not about writing data in the FC, it's about reading from it. And the DFC is just another DIRAC DB...

Anyway, I let you and Philippe (or Chris) decide, this is not fully my competence.

—
Reply to this email directly or view it on GitHub.

Dr Philippe Charpentier
J09210, Physics Department, CERN, CH-1211 Genève 23
LHCb Experiment Distributed Computing Coordinator
Office 2-R-007, Tel : +41 22 767 4244 , GSM : +41 76 487 0167
mailto:[email protected] http://cern.ch/Philippe.Charpentier

[graciani]

Hi,

the DFC, as any other DIRAC service will accept a connection from any known
host. By default services and agents will use their own host certificate to
establish the connection to other DIRAC services. The question here, and I
think this is what Andrei refers to, is what rights will this "client" have
when querying the catalog data. This will depend on the establish ACLs and
security in DFC. If "read all" policy is set any valid user will be able to
query the catalog, which is all we need for those components.

Ricardo

On 9 December 2014 at 14:12, Philippe Charpentier [email protected]
wrote:

Full authentication with a proxy for reading out of an FC is rather
useless, and just a trusted relationship should be enough. This is what we
do with the LFC. With the DFC or any Dirac service the applied concept is
to use the server host certificate. I have no idea whether this is lighter
or not, but obviously for other services it is clearly faster…
AFAIK the environment variable CSEC_MECH=ID is only used by the LFC,
therefore is innocuous if we don’t use the LFC. My understanding was that
useServerCertificate was the equivalent for Dirac services, i.e. for the
DFC. Therefore we don’t need a proxy for agents that only read the DFC. Am
I wrong?
Cheers,
Philippe

Le 8 déc. 2014 à 17:53, fstagni [email protected] a écrit :

It's not about writing data in the FC, it's about reading from it. And
the DFC is just another DIRAC DB...

Anyway, I let you and Philippe (or Chris) decide, this is not fully my
competence.

—
Reply to this email directly or view it on GitHub.

Dr Philippe Charpentier
J09210, Physics Department, CERN, CH-1211 Genève 23
LHCb Experiment Distributed Computing Coordinator
Office 2-R-007, Tel : +41 22 767 4244 , GSM : +41 76 487 0167
mailto:[email protected] http://cern.ch/Philippe.Charpentier

—
Reply to this email directly or view it on GitHub
#2199 (comment).

Ricardo Graciani Diaz

Dept. Estructura i Constituents de la Materia
Facultat de Fisica Tel: +34 93 403 9183
Universitat de Barcelona Fax: +34 93 402 1198

Diagonal, 645
E-08028 Barcelona

[atsareg]

This is my point - if everything is globally read available, then host identities can be used. But this is a limiting choice of LHCb and may be some other communities. Others can choose differently but will fail if using host identities will be hard coded.

[phicharp]

Then it is rather simple to set it as an operational option in the CS?
However I see no reason why a community would not be willing to trust one of its own machines????!!!!

Le 9 déc. 2014 à 16:43, Andrei Tsaregorodtsev [email protected] a écrit :

This is my point - if everything is globally read available, then host identities can be used. But this is a limiting choice of LHCb and may be some other communities. Others can choose differently but will fail if using host identities will be hard coded.

—
Reply to this email directly or view it on GitHub.

Dr Philippe Charpentier
J09210, Physics Department, CERN, CH-1211 Genève 23
LHCb Experiment Distributed Computing Coordinator
Office 2-R-007, Tel : +41 22 767 4244 , GSM : +41 76 487 0167
mailto:[email protected] http://cern.ch/Philippe.Charpentier

[fstagni]

Following the discussion, would you like that some pre-defined set of pre-defined rules are set in the ConfigTemplate? At the moment it is as simple as

Authorization
{
  Default = authenticated
}

[atsareg]

I think we can decide later. I mean that you are right saying that this affects only non-DIRAC services ( LFC ). When used with DFC we will tune the authorization more carefully

[fstagni]

Documentation updated: https://github.com/DIRACGrid/DIRAC/wiki/DIRAC-v6r12