Hi All,
I've dumped all the emails into one file, see below.
Ste
-----------------------------------------------
VOMS Admin Interface Emails
--- Steve Timm (DUNE) ---
Fermilab is in the process of transitioning away from a web-based
VOMS-Admin server for the DUNE and Fermilab VO's. This is likely to
happen on or after September 17. Once the VOMS-Admin server is turned
off, we will then distribute the list of Distinguished Names to the
sites that need it via a manual script that can be pushed to your
storage element and picked up from there.
The only GridPP site that we currently are aware that needs the list of
DN's, is RAL's Echo SE. This list of DN's was generated manually when we
onboarded that site and we have not added anything to it.
However I see that almost all the UK sites are still contacting our
VOMS-Admin server on a regular basis. So I want to understand what is
causing that, and if any authentication is likely to break once it does
go away. The host names we see:
<log list of se, and the dirac server at ICL>
--- Reply from Daniela (GridPP Dirac) ---
Hi Steven, Given that the voms interface is a standard voms component, I
don't understand why FNAL wants to turn it off. (Even CERN still
maintains this.) It's just going to make integration with the rest of
the world harder, because you'll be the only VO out there that does
this, but you probably know this :-S @Raja: Do you know if DPM webdav
will be affected ?
--- Reply from Steven Timm ---
The CERN security people keep telling us that they will turn off public
access to their VOMS-Admin server as well within the next year or so.
The people who run the actual VOMS servers at CERN know nothing about
that plan. There are allegedly problems that VOMS-Admin is not
compatible with GDPR regulations, it lets too much info out.
All US VO's are ditching VOMS-Admin (Against my strong protestations)
because they can no longer get maintenance for the branch of the
software they are on. We will still keep the underlying voms server and
have voms-proxy-init, voms-proxy-info and so forth work as they did
before.
The people at CERN who have a very similar setup say that anything which
uses Argus for authentication should be able to operate in the mode
where it just looks at the voms-proxy as presented to it, and they claim
that the CERN compute side is operating in this mode at the moment. The
storage side at cern, which is EOS, doesn't know anything about VOMS
proxies and just needs the list of DN's. It is my understanding that we
are in a similar situation with RAL which just needs the list of DN's..
the question is, what are all the DPM SE's doing. Steve
--- Reply from Daniela ---
This is actually worse than I first thought.
When I said dirac01 would disappear because we won't need to support
DUNE any longer on the GridPP DIRAC server I had forgotten that LSST
also uses the FNAL voms server. LSST is just doing a major production
run in the UK *right now* using the GridPP DIRAC instance and a
subset of the storage elements mentioned here, e.g. Manchester and
QMUL. If this causes access problems to their data this will be a
major set back.
In DIRAC we use the voms admin interface to automatically register
users if they belong to a VO we support. Until we wrote (and some
people on this mailing list might remember) this automated sync tool
we had to register people by hand which was just not scalable - we
support about 15 VOs of various sizes. Now LSST won't stop working on
day one on DIRAC obviously, but not being able to access a list of VO
members would require a major rewrite of the DIRAC software (unless
Raja tells me LHCb has an alternative solution that does not involve
direct access to a database at CERN).
@Steven Timm: Is that script you were talking about earlier available
somewhere so we can have a look at how we would actually receive the
information and maybe getting a head start ?
It should be noted that EOS/Echo are the exception in the UK and the
voms aware implementations of storage are by far the majority. (The
'only works at CERN/RAL type solutions' are a bit of a sore spot among
the lower ranks here, or maybe it's just me.) I don't really believe
the GRDP hype, most commercial organisations seem to be able to work
around it perfectly fine, but that's beyond the point here.
Regards, Daniela
--- Reply from Steven Timm
Some of my colleagues talked to LSST people and they say that LSST has
agreed to move their VOMS-Admin server away from Fermilab entirely. As
far as I know the new location has not yet been named, nor has that new
site yet contacted me to get the existing information of the VO. (We
will verify all of this before we turn the "off" switch at this end).
--- Steven Timm, this time to Alessandra ---
Hi Alessandra-- Jobs will still arrive with valid coms-proxies signed by
the VOMS server.
What will not be available are any of the things that require querying
the voms-admin servers for the list of members.
I am not familiar enough with the guts of the DPM storage element and
how it does its authorization but it appears that most of the SE's that
are calling the dune
voms-admin servers are doing the VomsCompatibilityService
/getGridmapUsers
call for each of the groups in dune. Is that correct?
Does DPM make a grid-mapfile or is it done by some other means?
I need the technical details so I can correctly make the argument to
management as to what needs to be done. Steve
--- Ste Jones copies in Sam ---
Hi Steve (Timm), We're trying to find out why an SE queries the admin
port on your voms server. We'll let you know when we find out. Copying
in Sam ... Sam, our DPM storage nodes call out to the VOMS port on the
DUNE/FNAL VOMs Server. Any idea what that's all about? This is
happening at a bunch of sites that support DUNE. What does DPM need a
list of users for? Does it still need to make a gridmapfile? What do you
think?
--- Reply from Alessandra ---
It (DPM) does (use a gridmapfile)
--- Reply from Daniela ---
I almost suspect some of these warnings actually come from lsst rather
than dune. @Steven T: Would you mind generating a complete list of UK
services
accessing the voms interface ? I'm just worried that there are other
surprises waiting. Daniela
--- Reply from STeve Timm---
I am attaching three files--these show respectively all the accesses to
https://voms.fnal.gov:8443/voms/dune,
https://voms.fnal.gov:8443/voms/fermilab,
and https://voms.fnal.gov:8443/voms/lsst
This time period is today in UTC time stamps starting from 05:00 UTC =
00:00 local time at Fermilab.
(SJ Note: the files contained logs of accesses by many storage elements
at the sites that support Dune, LSST... and also the Dirac requests)
########################################################################
To unsubscribe from the GRIDPP-STORAGE list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=GRIDPP-STORAGE&A=1
|
