 |
 |
hi Ste, So, I've been double-checking with the DPM dev team (as I said in the Storage meeting, I couldn't think of any services which *should* need a gridmapfile - as, for example, xrootd with vomsxrd doesn't)... The state of play is this, via Fabrizio and Maarten: *if* you contact any of the services on a modern DPM with a X509 proxy with a valid VOMS extension, the VOMS extension will be used directly (no gridmapfile needed). *if* you contact any of the services on a modern DPM with a bare X509 proxy, then the gridmapfile will be used. [This is used to, for example, allow access to the HTTP interface via web browsers, which are uniformly not VOMS-aware.] So, if DUNE (and other FNAL VOs) will only be using VOMS-aware clients, then there should be no issue with the VOMS Server admin interface going away. Sam On Wed, Aug 22, 2018 at 1:59 PM sjones <[log in to unmask]> wrote: > Hi all, > > (Note: For the avoidance of confusion, I'll be "Ste", and Steven Timm > will be "Steven"!) > > Sorry in advance for any repetition. These are my thoughts on the > gridmapfile problem before us. > > About gridmapfiles: A gridmapfile is a dictionary that translates some > identifier from a VO member's proxy (such as a DN or a VOMs Attribute) > to (e.g.) a local login name. There are at least two types of > gridmapfile. > > One type of gridmapfile translates a VOMS attribute from the proxy to a > local login name. This is the type used in our ARGUS server. There is > no contact with the VOMS Admin Port on any VOMS Server to get the list > of members. Instead, the VOMS-attribute based gridmapfile is created > from the VOMS Attributes (listed in, say, the VOID cards.) This is (I > think) what Steven is referring to when he says "CERN ... say that > anything which uses Argus for authentication should be able to operate > in the mode where it just looks at the voms-proxy". > > > Another type of gridmapfile translates a user's DN into a local login > name. This is the type used on our DPM disk servers. Periodic contact > is made with the VOMS Server Admin port (by cronjob) to create a > DN-based gridmapfile: > > # head /etc/lcgdm-mapfile > "/C=AM/O=ArmeSFo/O=ArmeSFo CA Department/CN=Mariam Pilikyan" alice > "/C=AR/O=e-Ciencia/OU=UNLP/L=CeSPI/CN=Gonzalo Enrique Orellana" atlas > "/C=AR/O=e-Ciencia/OU=UNLP/L=CeSPI/CN=Hernan Pablo Wahlberg" atlas > "/C=AR/O=e-Ciencia/OU=UNLP/L=CeSPI/CN=Maria Josefina Alconada Verzini" > atlas > > > Steven Timm (DUNE) tells us that Fermilab is to drop the VOMS Admin > Server interface on or after 17 Sept. All US VOs are doing it (because > they can no longer get maintenance of the software!) They will retain > the underlying voms servers. voms-proxy-init, voms-proxy-info and so > forth will work as they did. Steven also mentions a rumour that CERN > will turn off public access to their VOMS-Admin server (singular?) as > well within the next year or so. > > As I say above, this VOMS Admin interface is used to make DN-based > gridmapfiles. Since some services (TBD) use DN-based gridmapfiles, > Steven plans to distribute the DNs with some scripted process, and sites > can make their DN-based gridmapfiles from that. (DPM, specifically > creates this file with a cronjob: /etc/lcgdm-mapfile - that might have > to change.) > > Steven Timm was aware that the Echo SE at RAL and the EOS storage at > CERN do not know about VOMS proxies and need the list of DNs. But > Steven was surprised when he saw lots of contacts from DPMs in other UK > sites, as well as from the GridPP Dirac server. > > The question I think is: do we need to keep an up-to-date DN-based > gridmapfile on our DPM head and disk nodes (residing in > /etc/lcgdm-mapfile)? If not, we can just let it fail. Else, we need to > do something. How can we answer that? > > Cheers, > > Ste > > ######################################################################## > > To unsubscribe from the GRIDPP-STORAGE list, click the following link: > https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=GRIDPP-STORAGE&A=1 > ######################################################################## To unsubscribe from the GRIDPP-STORAGE list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=GRIDPP-STORAGE&A=1