You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I immediately ran into a problem that is not obvious to solve. This happened on the cluster here and my imac. The ./manage_externals/checkout_externals script hangs with very little indication about what to do. Turns out when it gets to installing ww3 if has an issue with validating a certificate. Is there a way to fix this certificate or at least pre-validate this certificate before managing externals, so the script does not hang. I managed to get around this by blindly hitting p to permanently accept the certificate. Then wiping everything and doing a fresh install (the certificate then was OK). A student is not going to know to try this and it will lead to lots of frustration if they cannot even get the model. The error is below.
The command will continue to run, but you may want to abort
manage_externals with ^C and investigate. A possible cause of hangs is
when svn or git require authentication to access a private
repository. On some systems, svn and git requests for authentication
information will not be displayed to the user. In this case, the program
will appear to hang. Ensure you can run svn and git manually and access
all repositories without entering your authentication information.
p
ERROR:root:Command '[u'svn', u'checkout', u'--quiet', u'https://svn-ccsm-models.cgd.ucar.edu/ww3/release_tags/ww3_cesm2_1_rel_01', u'/home/home01/phydrm/release_cesm2_1_0/components/ww3']' returned non-zero exit status 1
ERROR:root:Failed with output:
Error validating server certificate for 'https://svn-ccsm-models.cgd.ucar.edu:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
Certificate information:
- Hostname: *.cgd.ucar.edu
- Valid: from Wed, 28 Dec 2016 00:00:00 GMT until Sat, 28 Dec 2019 23:59:59 GMT
- Issuer: InCommon, Internet2, Ann Arbor, MI, US
- Fingerprint: 39:f1:46:85:a2:2a:86:e5:d4:b8:8b:0b:c0:f8:28:d6:71:74:1d:22
(R)eject, accept (t)emporarily or accept (p)ermanently? svn: E175002: Unable to connect to a repository at URL 'https://svn-ccsm-models.cgd.ucar.edu/ww3/release_tags/ww3_cesm2_1_rel_01'
svn: E175002: OPTIONS of 'https://svn-ccsm-models.cgd.ucar.edu/ww3/release_tags/ww3_cesm2_1_rel_01': Could not read status line: Secure connection truncated (https://svn-ccsm-models.cgd.ucar.edu)
He said this was with svn version 1.7.14 (on a cluster) and 1.10.0 on his mac.
I am not able to reproduce this problem exactly (I tried with 1.8.10 on cheyenne and 1.10.2 on my mac, after moving away my ~/.subversion directory): For me, if I haven't yet accepted the certificate, I get a very obvious prompt in the midst of running manage_externals:
[~/temporary/cesm]$ ./manage_externals/checkout_externals
Processing externals description file : Externals.cfg
Checking status of externals: clm, mosart, ww3, cime, cice, pop, cism, rtm, cam,
Checking out externals: clm, mosart, ww3, Error validating server certificate for 'https://svn-ccsm-models.cgd.ucar.edu:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
Certificate information:
- Hostname: *.cgd.ucar.edu
- Valid: from Dec 28 00:00:00 2016 GMT until Dec 28 23:59:59 2019 GMT
- Issuer: InCommon RSA Server CA, InCommon, Internet2, Ann Arbor, MI, US
- Fingerprint: 39:F1:46:85:A2:2A:86:E5:D4:B8:8B:0B:C0:F8:28:D6:71:74:1D:22
(R)eject, accept (t)emporarily or accept (p)ermanently? p
cime,
I did find that I need to accept the certificate fairly quickly for it to work: if I take more than a minute or so to respond, the process errors out (the same thing happens if I do an svn checkout directly: this is not specific to manage_externals).
Mark Moore said that the error arises because UCAR has switched to a certificate authority that gives this issue, and it would be a lot of work to put in place all new certificates for everything. He suggested adding --trust-server-cert in the svn checkout command. This also required adding --non-interactive. When I added both of those, the certificate indeed seems to be accepted without any need for a prompt, but it causes another problem if the svn repo is private and so requires authentication (the --non-interactive interferes with that: rather than prompting for a password, the process immediately exits). Also, it appears that it wouldn't necessarily fix all certificate-related problems – e.g., if a certificate has expired (and again, adding --non-interactive would make this problem worse for users (like me) who currently can see the prompt but with that option the process would immediately fail). (Newer versions of svn support --trust-server-cert-failures, which can accept a wider class of certificate problems, but that option is only available for newer versions of svn - e.g., it doesn't seem to be available for 1.8.10.)
The text was updated successfully, but these errors were encountered:
Dan Marsh reported the following:
He said this was with svn version 1.7.14 (on a cluster) and 1.10.0 on his mac.
I am not able to reproduce this problem exactly (I tried with 1.8.10 on cheyenne and 1.10.2 on my mac, after moving away my ~/.subversion directory): For me, if I haven't yet accepted the certificate, I get a very obvious prompt in the midst of running manage_externals:
I did find that I need to accept the certificate fairly quickly for it to work: if I take more than a minute or so to respond, the process errors out (the same thing happens if I do an svn checkout directly: this is not specific to manage_externals).
Mark Moore said that the error arises because UCAR has switched to a certificate authority that gives this issue, and it would be a lot of work to put in place all new certificates for everything. He suggested adding
--trust-server-cert
in the svn checkout command. This also required adding--non-interactive
. When I added both of those, the certificate indeed seems to be accepted without any need for a prompt, but it causes another problem if the svn repo is private and so requires authentication (the--non-interactive
interferes with that: rather than prompting for a password, the process immediately exits). Also, it appears that it wouldn't necessarily fix all certificate-related problems – e.g., if a certificate has expired (and again, adding--non-interactive
would make this problem worse for users (like me) who currently can see the prompt but with that option the process would immediately fail). (Newer versions of svn support--trust-server-cert-failures
, which can accept a wider class of certificate problems, but that option is only available for newer versions of svn - e.g., it doesn't seem to be available for 1.8.10.)The text was updated successfully, but these errors were encountered: