ホストマシンがCentOS6.Xのpython2系においてpycurlを含むスクリプトを実行したところ、
pycurl.error: (35, 'SSL connect error')
と出力されてしまっていた。。。
あー、SSLのアクセスがエラーなのね、と。。
尚、ステージング環境では同様のスクリプトは動いているという謎・・・
「差分マジ不明」、とか「そもそも前は使えてたんかな?」と疑問に思いつつ、色々と調べた。
以下の様に、インタラクティブモードで検証を行う
import pycurl
c = pycurl.Curl()
c.setopt(pycurl.URL, 'https://XXXX')
c.setopt(pycurl.VERBOSE, True)
c.perform()
ダメな環境のダメっぽいログ(これが原因かなと判断した)
----以下は抜粋----
* NSS error -5938
* Closing connection #0
* SSL connect error
OKっぽいログ(↓が出てたからOKと判断した)
-----以下は抜粋-----
< HTTP/1.1 200 OK
ここで、
んーー、pycurl自体が悪いのかなー、などと思案するも、
どうも大丈夫そう。(確認方法失念)
そもそものcurlのバージョンとかなのかな、と思案する。
yum info libcurl
それも同じ。。。
なにが悪いのか全然分からん、と思って
ここでようやく↓のログ
* NSS error -5938
について調べる。
※色々調べて3時間くらい無駄にしてる
NSSってなんや。。
無知なわたしはNSSを調べると、
https://ja.wikipedia.org/wiki/Network_Security_Services
SSLライブラリであるということが分かる。
ん?こいつがなんか悪い?
ということで更に調べると
http://www.at-link.ad.jp/topics/news/news-20151105.html
にたどり着く。
ひとまず脆弱性があるらしいということなので、バージョンを調べる。
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
脆弱性があるやつなのね・・・
と思ってスクリプトが正常実行できる環境で同様に確認してみる。
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
バージョン全然違うやんけ。
curlもpycurlも実行環境(ホストマシン)のNSS見るということなんですね、きっと、なるほど。。。
ちなみに、
cat /etc/redhat-release
CentOS release 6.6 (Final)
cat /etc/redhat-release
CentOS release 6.8 (Final)
CentOSのバージョンも違うやんけ。
たぶん、CentOS6.6は脆弱性持ってるNSSが最初っからバンドルされている、
6.8は脆弱性対応済みのNSSをバンドルしている、
という差分があるんだろうな、という推測。
ひとまず↓を実行する
yum update nss nss-util nspr
その後、実行不可となっていたスクリプトを再度実行するとエラーが無く実行可能となった。(事象解決)
ここまで調査開始から8時間くらい費やしてる気がする。。
curl実行出来ない方はお試しあれ。。
(脆弱性対応してあれば問題無いんですけどね)