Hi,
automatically updated rpms would solve this problem and you would have
only one place to update without these repeated threads. Can we discuss
next Tuesday to make it a deployment policy in gridpp?
cheers
alessandra
On 03/03/2020 13:29, sjones wrote:
> 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
--
Inference: a conclusion reached on the basis of evidence and reasoning
Respect is a rational process. \\//
For Ur-Fascism, disagreement is treason. (U. Eco)
########################################################################
To unsubscribe from the TB-SUPPORT list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=TB-SUPPORT&A=1
|