 |
 |
Hi, I had the same reply. It can be switched off. however for xrootd it has to be replaced by vomsxrd. So sites need to make sure that is configured. Other more personal preferences like the WEB UI working is not a grid use case. cheers alessandra On 22/08/2018 14:25, Sam Skipsey wrote: > 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] > <mailto:[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 > -- Respect is a rational process. \\// For Ur-Fascism, disagreement is treason. (U. Eco) ######################################################################## To unsubscribe from the GRIDPP-STORAGE list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=GRIDPP-STORAGE&A=1