JISCMail - GRIDPP-STORAGE Archives

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