Firewall entrypoint or proxy for federation

Site Administrators
1

Hi EOS community,

We’re preparing an EOS deployment for a grid site in Vienna. We have a minimal setup running 3 mgm nodes (with quarkdb) + 2 fst nodes. This base setup is working, we can read/write files with GSI authentication.

We do not want to expose the whole storage system publicly, therefore we are considering a “proxy” setup. We’ve investigated both xroot pss (https://xrootd.slac.stanford.edu/doc/dev410/pss_config.htm) and EOS firewall-entrypoints (following this http://eos-docs.web.cern.ch/eos-docs/configuration/proxys.html). Unfortunately we have not been successful with either approach.

xroot pss
We did not manage to get authentication working properly. GSI auth works against the xroot proxy instance, but credentials/identity is not forwarded correctly to the FSTs. As far as I understand this is to be expected for the xroot pss setup?

eos proxygroups
We’ve configured the fwep as FST without an export. It has joined the EOS cluster, and the node is added to the proxygroup “myproxy1”. A client with a “foreign” geotag “ASDF” contacting the mgm gets a network error, with the error in the mgm log “could not find the requested proxy group myproxy1 in the map”.

We think this tells us, that mgm knows it should redirect it to the proxy (i.e. geosched is setup correctly). But it is unclear, why it cannot be located. We’ve only added the fwep host to the proxygroup, not the target FSTs.

We’ve traced the error to the source (https://github.com/cern-eos/eos/blob/master/mgm/GeoTreeEngine.cc#L1525) but were unable to determine the cause of it.
This is the log on the mgm:

200301 23:22:15 time=1583101335.912210 func=open                     level=INFO  logid=1b35a1a6-5c0b-11ea-8101-0050568df328 unit=mgm@test-eos-mgm-1.vbc.ac.at:1094 tid=00007fb61e3f6700 source=XrdMgmOfsFile:825              tident=erich.bi.3680:338@grid-ui-0.grid.staging.clip sec=gsi   uid=10661 gid=1999 name=erich.birngruber geo="ASDF" acl=0 r=0 w=0 wo=0 egroup=0 shared=0 mutable=1
200301 23:22:15 time=1583101335.912360 func=findProxy                level=ERROR logid=d1d4013a-5a73-11ea-81a2-0050568df328 unit=mgm@test-eos-mgm-1.vbc.ac.at:1094 tid=00007fb61e3f6700 source=GeoTreeEngine:1525             tident=<service> sec=      uid=0 gid=0 name= geo="" could not find the requested proxy group myproxy1 in the map
200301 23:22:15 time=1583101335.912437 func=Emsg                     level=ERROR logid=1b35a1a6-5c0b-11ea-8101-0050568df328 unit=mgm@test-eos-mgm-1.vbc.ac.at:1094 tid=00007fb61e3f6700 source=XrdMgmOfsFile:2933             tident=erich.bi.3680:338@grid-ui-0.grid.staging.clip sec=gsi   uid=10661 gid=1999 name=erich.birngruber geo="ASDF" Unable to open file  /eos/user/erich.birngruber/hello56; Network is unreachable
  • what are the reasons to not find the proxy node?
  • we also noticed: individual proxygroups can be removed from a node, but “node proxygroupclear” command gives an error, also using the value “< none>” gives the same error.
  • Which one is the recommended approach: should we go with xrood pss or EOS proxy groups?
  • We want to participate in the grid storage federation, is this even the correct approach or do we need to go with the EOS fed service? (if so, does this work with the forwarding of credentials to EOS?)

Please help!
Greeting from Vienna,
Erich

2

Hi Erich,
the problem with pss is, that there is no implemtation for a working GSI delegation.

Considering the firewall proxy groups, we probably need to setup this ourselfs. I think, we never have tried this ourselfs, only the person who developed it, which has left some years ago. We should also add this to a test case.

If you have only few FSTs , I don’t really see a good point to use a proxy in front.

If you talk about GRID storage federation, for which experiment you need to do that?

3

Hi Andreas,
Thanks for the response. True, it would be only 9 FSTs on our end. One consideration was to also have this as IPv6 “gateway”. At the moment we have no v6 deployed on our campus - it would have been an option to get v6 in the DMZ first and then use the proxies there also for v6-to-v4 translation.
What we’ve tried with the proxies, we’ve hit that error as mentioned above, but could not identify the root cause, as that proxy group was setup. But then we should probably consider not going with proxies at all.

As far as experiments go, we have 3: CMS, Alice and Belle2.
We’re aware of the difference in authentication with the Alice tokens (haven’t tried it yet though). For all 3 we will require grid federation - both storage and compute - but I guess this is the forum for the former :slight_smile:.

Best,
Erich

4

Hi Erich,
at least for ALICE it is easy to setup a proxy, because the proxy does only pass the token on without authentication. You can just setup a native PSS xrootd proxy without authentication and map the gateway machine to the alice account.

It is also easy to setup a proxy if you can map all people from one VO to a single identity. If you need to delegate individuals, that is currently not working.

Cheers Andreas.

5

Hi Andreas,
Thanks again and please excuse my late reply. We got a little distracted here with recent events.
I think we will move forward without proxies for the time being, as we have to integrate multiple VOs, not so many FSTs - and the redirector(s) has to be reachable anyways.

Thanks for the advice and stay healthy,
Best
Erich