When the host machine executed the script including pycurl on the python2 series of CentOS 6.X, pycurl.error: (35, 'SSL connect error') Was output. .. .. Ah, SSL access is an error. ..
The mystery that similar scripts are working in the staging environment ... I researched various things while wondering, "I don't really know the difference" or "Is it possible to use it before?"
Verify in interactive mode as follows
python
import pycurl
c = pycurl.Curl()
c.setopt(pycurl.URL, 'https://XXXX')
c.setopt(pycurl.VERBOSE, True)
c.perform()
Bad log in a bad environment (I decided this was the cause) ---- The following is an excerpt ----
* NSS error -5938
* Closing connection #0
* SSL connect error
OK-like log (I judged it OK because ↓ appeared)
----- The following is an excerpt -----
< HTTP/1.1 200 OK
here, Hmmm, I wonder if pycurl itself is bad, etc. It looks okay. (Forgot how to check)
I wonder if it's the curl version in the first place.
yum info libcurl
It's the same. .. ..
I didn't know what was wrong Finally here ↓ log
* NSS error -5938
Find out about.
What is NSS? ..
I'm ignorant, when I look up NSS, https://ja.wikipedia.org/wiki/Network_Security_Services It turns out that it is an SSL library.
Hmm? Is this something wrong? So if you look further http://www.at-link.ad.jp/topics/news/news-20151105.html To reach.
It seems that there is a vulnerability for the time being, so check the version.
rpm -q nss nss-util nspr
nss-3.16.2.3-3.el6_6.x86_64
nss-util-3.16.2.3-2.el6_6.x86_64
nspr-4.10.6-1.el6_5.x86_64
It's a vulnerable guy ...
I think that I will check in the same way in an environment where the script can be executed normally.
rpm -q nss nss-util nspr
nss-3.21.0-8.el6.x86_64
nss-util-3.21.0-2.el6.x86_64
nspr-4.11.0-1.el6.x86_64
The version is completely different. Both curl and pycurl look at the NSS of the execution environment (host machine), I'm sure. .. ..
By the way,
Production
cat /etc/redhat-release
CentOS release 6.6 (Final)
Staging
cat /etc/redhat-release
CentOS release 6.8 (Final)
The version of CentOS is also different.
Maybe CentOS 6.6 is bundled with vulnerable NSS from the beginning, 6.8 bundles vulnerable NSS, I guess there is a difference.
Execute ↓ for the time being
yum update nss nss-util nspr
After that, when the script that was not executable was executed again, it became executable without any error. (Event resolution) I feel that I have spent about 8 hours from the start of the survey so far. ..
If you can't run curl, try it. .. (There is no problem if the vulnerability is dealt with)