Hello, If there is any problems with certificates in cvmfs repository again ? voms-proxy-init -voms cms -valid 192:00 -debug with X509_CERT_DIR=/cvmfs/oasis.opensciencegrid.org/mis/osg-wn-client/3.2/3.2.26/el6-x86_64/etc/grid-security/certificates X509_VOMS_DIR=/cvmfs/oasis.opensciencegrid.org/mis/osg-wn-client/3.2/3.2.26/el6-x86_64/etc/grid-security/vomsdir Detected Globus version: 2.2 Unspecified proxy version, settling on Globus version: 2 Number of bits in key :1024 Files being used: CA certificate file: none Trusted certificates directory : /cvmfs/oasis.opensciencegrid.org/mis/osg-wn-client/3.2/3.2.26/el6-x86_64/etc/grid-security/certificates Proxy certificate file : /tmp/x509up_u0 User certificate file: /etc/grid-security/hostcert.pem User key file: /etc/grid-security/hostkey.pem Output to /tmp/x509up_u0 Your identity: /DC=com/DC=DigiCert-Grid/O=Open Science Grid/OU=Services/CN=earth.crc.nd.edu Using configuration file /cvmfs/oasis.opensciencegrid.org/mis/osg-wn-client/3.2/3.2.26/el6-x86_64/etc/vomses Creating temporary proxy to /tmp/tmp_x509up_u0_29211 ...++++++ ...++++++ Done Contacting voms2.cern.ch:15002 [/DC=ch/DC=cern/OU=computers/CN=voms2.cern.ch] "cms" Failed Error: Error during SSL handshake:error:80066405:lib(128):verify_callback:outdated CRL found, revoking all certs till you get new CRL:sslutils.c:2115 outdated CRL found, revoking all certs till you get new CRL Function: verify_callback error:80066411:lib(128):verify_callback:certificate failed verify::sslutils.c:2318 error =CRL has expired subject=/DC=ch/DC=cern/OU=computers/CN=voms2.cern.ch issuer =/DC=ch/DC=cern/CN=CERN Grid Certification Authority
I added Tim T to this ticket since he did the last update to the repo as far as I can see. He may know more. -Kyle
By the way, is it still recommended to use the OSG CVMFS certificates? X509_CERT_DIR=/cvmfs/oasis.opensciencegrid.org/mis/osg-wn-client/3.2/3.2.26/el6-x86_64/etc/grid-security/certificates X509_VOMS_DIR=/cvmfs/oasis.opensciencegrid.org/mis/osg-wn-client/3.2/3.2.26/el6-x86_64/etc/grid-security/vomsdir or is it better to use osg-ca-certs-updater-cron + fetch-crl daemons to keep the local ones up to date? What are the advantages/disanvantages for each option? Best, Kenyi by /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=khurtado/CN=764581/CN=Kenyi Paolo Hurtado Anampa
The mis vo hasn't done an osg-oasis-update since Monday. On oasis-login there's a process that's been stuck since then running under the ouser.mis login: python2 /home/ouser.mis/oasis-ca-updater I don't have root access on oasis-login so I don't know what it is stuck on. It doesn't have any subprocesses. Adding Scott as the administrator of oasis-login.
Killed the offending process, ran an osg-oasis-update and oasis-ca-updater as ouser.mis, all completed without intervention. Will observe next scheduled run in 43 minutes.
next update runs at 16:20, will check then. /cvmfs/oasis.opensciencegrid.org/mis/certificates shows content timestamped at the time of my forced update. Everything worked manually will wait for 16:20 to verify automated update completed properly.
I now see the updated CA package when accessing OASIS from xd-login. This should be fixed. We'll do an analysis of the problem on Tuesday.
I ran the updater manually through the weekend. It seems to be leaving behind a lockfile, handing this off to Tim T. Ops is, at this time, uninvolved. De-asssigning Kyle, I'll lurk in case I need to continue manual intervention.
Hello, We would like to know what source for CRLs is recommended to use ? I was told before that cvmfs is reliable but since I experienced the problems I switched to local. Do I have to switch back to cvmfs repository ? Thanks -Serguei by /DC=com/DC=DigiCert-Grid/O=Open Science Grid/OU=People/CN=Serguei Fedorov 787
The existence of the lockfile is perfectly normal -- the script uses flock to actually lock/unlock the file, instead of just checking for its existence. More worrying is that the script kept running - it's set to time out after 60 minutes. I'll crank up the debug level and see what I can find. -Mat
fetch-crl is supported, something else might be supported at some future date, this will be discussed soon.
Hello, access via cvmfs is now monitored, if the CRLs are not updated in 24 hrs, the service will go into a warning state, 48 hrs will go into a critical state. A problem will be addressed the next business day. Please note, this addresses updating of the CRLs. The CRLs are accessible via three redundant cvmfs replica located at IU, BNL and FNAL. It is extremely unlikely all three will fail simultaneously but such an event is considered of critical priority. There is no policy, at this time, stating which method is referred. I hope the above information is sufficient for you to choose which you prefer and understand there may be external constraints forcing you to choose the /cvmfs option. I'm resolving this ticket since the original problem has been addressed. Mat, if you'd like, create and track your work with a JIRA ticket. As always, if you encounter problems, please let us know as soon as possible and we will assist.
No similar tickets found.