Hi all,

It would be a Sysiphusian task (incessant but futile) to update the 
Approved VOs document before, continuously and after the changes to the 
DNs of the voms1.fnal.gov and voms2.fnal.gov VOMS server occurring 
between ~ now and 8th April.  So, instead, I'm publishing the analysis 
below (which I have shared with Chris and Daniela for comments). 
Basically, from an operational point of view, it's every man/woman for 
him/her self to devise a way at your site to support DUNE (and other 
Fermilab VOs) for the duration of this change.

The basic principle is simple enough; between tomorrow and 8th April, 
the DNs of the servers will, in turn, change from having /ST=IL to 
having /ST=Illinois instead. And the impact analysis below shows that 
the changes must be made at the sites more or less simultaneously with 
the changes on the servers.

Obviously, I'll put the documentation straight once the whole phase is 
done and dusted. Please let me know if there is anything more I can 
do....

Cheers,

Ste
Liverpool

===== ANALYSIS =====

Hi Chris, Daniela,

Note: All the below applies to any VO that uses voms*.fnal.gov, not just 
DUNE. But I use DUNE as an example.

I'm trying to figure something out for this. See below; you're quite 
right; I think two changes are necessary, one on 4th March, another on 
8th April. And maybe one in between, for the /etc/vomes/*

In short, tomorrow, sites need a new 
/etc/grid-security/vomsdir/dune/voms1.fnal.gov.lsc, with the new DN, and 
on the 8th April, sites will need a new 
/etc/grid-security/vomsdir/dune/voms2.fnal.gov.lsc. It's a pest, but 
there's no way around it AFAICS.

Of course, a perfect match (timewise) is impossible, so there will be 
some chaos whatever we do. So, is this right? I'm going to give guidance 
on TB_SUPPORT on this, so I need to be sure....

Please review and comment if you have time. Cheers,

Ste


---- Show the changes will break DUNE jobs unless two changes are done 
------

SteveT will turn off (has turned off?) voms1.fnal.gov, so no proxies 
will come from that until its new certificate is put on. DUNE users will 
only make proxies from voms2.fnal.gov. I expect he'll turn 
voms1.fnal.gov back on tomorrow, Wed, 4th Mar, with its new DN. And DUNE 
users will start getting proxies from (potentially) either VOMS server, 
again. The whole process will repeat in reverse for voms2.fnal.gov 
around Wed, 8th Apr.

DUNE USERS
**********
With respect to DUNE users. At various points in this timeline, users 
with /etc/vomses entries inconsistent with the servers can not use those 
servers to create proxies. But, since at least one VOMS server will be 
up, running and consistent with at least one of the users' config files 
at all times, they can continue to just make proxies. We have to (at 
least) ensure that /etc/vomses/dune-voms* for users is updated at some 
time between 4th Mar and 8th Apr.

DUNE GRID SERVICES
******************

ARGUS policies that control the way a job is allocated/mapped to a user 
don't use DNs, at my site at least, so that won't change.

Today (3rd Mar)  there will be no impact, since voms1.fnal.gov is off, 
and all jobs will come with proxies from the unchanged voms2.fnal.gov. 
When voms1.fnal.gov comes back, we will start getting jobs from that. 
They will have proxies containing the new DN of the voms1.fnal.gov VOMS 
server. My security system will try to test those proxies. The files in 
/etc/grid-security/vomsdir/dune/ are used for this purpose, e.g. 
presently:

# cat voms1.fnal.gov.lsc
/DC=org/DC=incommon/C=US/ST=IL/L=Batavia/O=Fermi Research 
Alliance/OU=Fermilab/CN=voms1.fnal.gov
/C=US/O=Internet2/OU=InCommon/CN=InCommon IGTF Server CA

# cat voms2.fnal.gov.lsc
/DC=org/DC=incommon/C=US/ST=IL/L=Batavia/O=Fermi Research 
Alliance/OU=Fermilab/CN=voms2.fnal.gov
/C=US/O=Internet2/OU=InCommon/CN=InCommon IGTF Server CA

Basically, it's saying that if a proxy comes with a certain DN signed by 
a certain CADN, I'll trust it. Hence after voms1.fnal.gov comes back on, 
its DN won't match the one in the LSC file and that (I think) is the end 
of it. Jobs with proxies from that  fail.

Hence two changes needed at each end, and one (/etc/vomes) in the 
middle.

-------- Original Message --------
Subject: DUNE VOMS cert changing next week
Date: 2020-02-28 15:11
 From: Steven C Timm <[log in to unmask]>
To: Stephen Jones <[log in to unmask]>, Andrew Mcnab 
<[log in to unmask]>

  WHAT ARE WE DOING?

We are making a configuration change to the Fermilab VOMS servers
voms1.fnal.gov and voms2.fnal.gov.  This will result in the
Distinguished Name of these servers being changed.  A new client
configuration file will be necessary to obtain VO credentials

(voms-proxy) after these configuration changes.  This impacts the
Fermilab VO (FIFE Users), the DES VO, and the DUNE VO.

WHEN WILL THIS OCCUR?

voms2.fnal.gov will change on Wednesday, March 4.

voms1.fnal.gov will change on Wednesday, April 8.

Each of these servers will be turned off two days before its respective
change so we do not have any stale credentials in the system.

WHAT IS THE IMPACT TO THOSE RECEIVING THIS EMAIL?

You may see voms-proxy-init requests fail temporarily and retry on the
other voms server.  This is an expected behavior.

WHAT DO THOSE RECEIVING THIS EMAIL NEED TO DO?

Need to be sure that a new version of the vo-client is installed.  On
SCD-managed interactive nodes (gpvm) this will be done by the managers
of these nodes.  On user managed desktops you will need to have the
latest version of the vo-client package, which is scheduled to be
released immediately before the respective change dates. The next
version of the vo-client package will be release 100.  After the
configuration change is complete there will be a notice and users will
be asked to verify that the new configuration is working for them.

The actual new Distinguished Names will be:

/DC=org/DC=incommon/C=US/ST=Illinois/L=Batavia/O=Fermi Research
Alliance/OU=Fermilab/CN=voms1.fnal.gov

and /DC=org/DC=incommon/C=US/ST=Illinois/L=Batavia/O=Fermi Research
Alliance/OU=Fermilab/CN=voms2.fnal.gov

They differ from the previous ones only by having /ST=Illinois instead
of /ST=IL
Message 1 of 6801

########################################################################

To unsubscribe from the TB-SUPPORT list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=TB-SUPPORT&A=1