 |
 |
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