Lorsque la machine hôte a exécuté un script comprenant pycurl sur la série python2 de CentOS 6.X, pycurl.error: (35, 'SSL connect error') A été sortie. .. .. Ah, l'accès SSL est une erreur. ..
Le mystère que des scripts similaires fonctionnent dans l'environnement de préparation ... J'ai fait des recherches sur diverses choses en me demandant: «Je ne connais pas vraiment la différence» ou «Est-il possible de l'utiliser avant?»
Vérifiez en mode interactif comme suit
python
import pycurl
c = pycurl.Curl()
c.setopt(pycurl.URL, 'https://XXXX')
c.setopt(pycurl.VERBOSE, True)
c.perform()
Mauvais journal dans un mauvais environnement (j'ai décidé que c'était la cause) ---- Ce qui suit est un extrait ----
* NSS error -5938
* Closing connection #0
* SSL connect error
Journal de type OK (je l'ai jugé OK parce que ↓ est apparu)
----- Ce qui suit est un extrait -----
< HTTP/1.1 200 OK
ici, Hmmm, je me demande si pycurl lui-même est mauvais, etc. Ça a l'air bien. (J'ai oublié comment vérifier)
Je me demande si c'est la version curl en premier lieu.
yum info libcurl
C'est le même. .. ..
Je ne savais pas ce qui n'allait pas Enfin ici ↓ log
* NSS error -5938
Renseignez-vous.
Qu'est-ce que NSS? ..
Je suis ignorant, quand je regarde NSS, https://ja.wikipedia.org/wiki/Network_Security_Services Il s'avère que c'est une bibliothèque SSL.
Hmm? Est-ce que quelque chose ne va pas? Alors si tu regardes plus loin http://www.at-link.ad.jp/topics/news/news-20151105.html Atteindre.
Il semble qu'il existe une vulnérabilité pour le moment, alors vérifiez la 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
C'est un gars vulnérable ...
Je pense que je vais le vérifier de la même manière dans un environnement où le script peut être exécuté normalement.
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
La version est complètement différente. Les deux curl et pycurl regardent le NSS de l'environnement d'exécution (machine hôte), j'en suis sûr. .. ..
Au fait,
Production
cat /etc/redhat-release
CentOS release 6.6 (Final)
Mise en scène
cat /etc/redhat-release
CentOS release 6.8 (Final)
La version de CentOS est également différente.
Peut-être que CentOS 6.6 est fourni avec NSS vulnérable depuis le début, 6.8 faisceaux NSS vulnérables, Je suppose qu'il y a une différence.
Exécutez ↓ pour le moment
yum update nss nss-util nspr
Après cela, lorsque le script non exécutable a été de nouveau exécuté, il est devenu exécutable sans aucune erreur. (Résolution d'événement) Je pense avoir passé environ 8 heures depuis le début de l'enquête jusqu'à présent. ..
Si vous ne pouvez pas exécuter curl, essayez-le. .. (Il n'y a pas de problème si la vulnérabilité est corrigée)
Recommended Posts