pip-en check_hostname errorea proxy baten atzean: pip edo tunela?
Bi hutsegitek pip host-izen errore bera inprimatzen dute proxy baten atzean. Bereizi bezero zaharkitua trafikoa berriz sinatzen duen proxy batetik, eta konpondu geruza zuzena.
Bi hutsegite desberdinek pip-en aztarna bera inprimatzen dute, eta bati dagokion konponketak bestea okertzen du. Tunelatutako host bat izendatzeko zaharkituta dagoen bezero batek eguneraketa behar du. Trafikoa berriz sinatzen duen proxy batek erro-sertifikatu fidagarria behar du, ez bertsio-jaitsiera. Ebatzi bi horietatik zein duzun proxy aldagai bat editatu aurretik, bideak kontrako norabideetan doaz eta.
Irakurri azken markoak ezarpenak ukitu aurretik
Aztarna amaitzen den lekuak esaten dizu zein geruzak eman zuen amore. Amaierako markoak pip-ekin batera datorren urllib3 TLS kodearen barruan badaude eta testuak host-izen baten kexa egiten badu, bezero-liburutegiak ezin izan zuen egiaztapen-pausoa amaitu, eta hori bertsio-arazo bat da askoz sarriago ziurtagiri-arazo bat baino. Testuak, horren ordez, ukatutako konexio bat, konpondu gabeko proxy-izen bat edo HTTP 407 bat badu, tunelaren amaierako puntua da erruduna eta inolako eguneraketak ez du hori aldatuko.
Hartu pip bertsioa eta proxy aldagaiak huts egiten duen shell berean. Tunela altxatu aurretik irekitako shell batek ondoren irekitakoak ez bezalako balioak daramatza, eta bien arteko aldea da, sarritan, diagnostiko osoa.
python3 -m pip --version
env | grep -i -E 'proxy|no_proxy'
Bezeroa tunela baino zaharragoa denean
pip-en bertsio zaharrek socket-a tunel batez bildu ondoren helburuko host-izena galtzen zuen HTTPS pilak zekartzaten. check_hostname mezua pila horrek igortzen duena da, konparatzeko izenik gabe egiaztapenera iristen denean. Eguneraketak akatsa kentzen du, bezero berriagoak izena esku-emate osoan zehar gordetzen duelako, eta aldaketa nahikoa merkea da lehenengo probatzeko amaierako markoek TLS kode bateratuari seinalatzen dioten bakoitzean.
Indizera huts egiten duen makinatik iristen ez bada, deskargatu uneko wheel bat lor dezakeen host batean eta instalatu fitxategitik. Erabili benetan deskargatu duzun fitxategi-izena, blogeko bidalketa batetik kopiatutako bertsio bat erabili beharrean.
python3 -m pip install --upgrade pip
python3 -m pip install ./pip-24.2-py3-none-any.whl
Proxyak trafikoa berriz sinatzen duenean
TLS amaitzen duen eta enpresa-erro baten pean ziurtagiriak berriz igortzen dituen proxy batek beste errore bat sortzen du: certificate verify failed, ez host-izen baten kexa. Aldea hori da arrastoa, bezeroa zerbitzari batera iritsi eta gero erakutsi zioten identitatea baztertu zuelako. Konponketa erro hori berariaz fidatzea da, bai agindu bakarrerako bai PIP_CERT aldagaiaren bidez, bezeroak proxyak aurkezten duenera katea eraiki dezan. Erroa sistemaren konfiantza-biltegian gehitzeak ere funtzionatzen du, baina makinako programa guztien konfiantza aldatzen du, eta hori pakete-instalazio bat konpontzea baino erabaki handiagoa da.
Eduki --trusted-host diagnostiko gisa, inoiz ez egoera iraunkor gisa. Atxiki nahi zenuen egiaztapena itzaltzen du, eta, beraz, benetan okerra den ziurtagiri bat osasuntsu dagoela dirudi gero. Pakete bat instalatzeko erabili bazenuen, kendu eta konpondu katea hurrengo bertsioaren aurretik.
Zure Python kodea erabat arduratzen ez da pip-en konfigurazioaz. requests dei batek proxy-a eta sorta sesio horrek ikus ditzakeen tokian pasatu behar ditu, horregatik beheko blokeak biak jartzen ditu sesio-objektuan.
pip install --cert /usr/local/share/ca-certificates/corp-root.crt requests
export PIP_CERT=/usr/local/share/ca-certificates/corp-root.crt
s = requests.Session()
s.proxies = {"https": "http://10.20.30.40:8080"}
s.verify = "/usr/local/share/ca-certificates/corp-root.crt"
s.get("https://pypi.org/simple/", timeout=15)
Amaierako puntua edo ataka okerra denean
Tunelaren bezero batek sarritan sistema-proxy-a berridazten du konektatzen ari denean, eta horrek pip ataka horretan inoiz erantzuten ez duen host batera zuzenduta utz dezake. Probatu amaierako puntua pip ez den bezero batekin, pip-en edozein ezarpen aldatu aurretik. curl-ek proxy argumentu berarekin huts egiten badu, akatsa pip-en gainetik dago eta pip barruko konfigurazioak ez du lagunduko.
Komandoaren banderak eta ingurune-aldagaiek gauza bera esaten diete esparru desberdinei: bandera deialdi bakarrerako da, aldagaiak ondoren abiatutako prozesu bakoitzerako. Gehitu NO_PROXY barne-indize baterako, pakete-trafiko pribatuak tunelaren ingurubidea saihes dezan.
curl -x http://proxy.corp.internal:8080 --head https://pypi.org/simple/
pip install --proxy http://proxy.corp.internal:8080 requests
Iraunarazi ezarpena eta frogatu bideak funtzionatzen duela
Gorde proxy-a pip-en konfigurazioan, uneko shell-a gainditu behar duenean, eta gero irakurri pip-ek benetan zer erabiliko duen. Debug irteerak balio bakoitzaren atzeko fitxategia eta aldagaia izendatzen ditu, eta horrek lehentasunari buruzko eztabaidak dokumentazioa irakurtzea baino azkarrago konpontzen ditu.
Egiaztapenak bi bezero erabiltzen ditu nahita. Liburutegi estandarraren eskaerak bidea eta konfiantza-katea frogatzen ditu, deskargak berriz pip-en konfigurazioak haiekin ados dagoela frogatzen du. Lehenak arrakasta duenean eta bigarrenak huts egiten duenean, aldea pip-en barruan dago, ez sarean.
pip config set global.proxy http://proxy.corp.internal:8080
pip config debug
python3 -c "import urllib.request as r; print(r.urlopen('https://pypi.org/simple/').status)"
pip download --no-deps -d /tmp/wheelcheck requests
| What you see | First command | Repair |
|---|---|---|
| hostname message inside vendored TLS frames | python3 -m pip --version | upgrade the client |
| certificate verify failed after the tunnel | curl -x http://proxy.corp.internal:8080 --head https://pypi.org/simple/ | trust the corporate root |
| connection refused or HTTP 407 | env | grep -i -E 'proxy|no_proxy' | correct host, port or credentials |