Gabim check_hostname i pip pas një proxy: pip apo tuneli?

Dy dështime të ndryshme shtypin të njëjtin gjurmë të pip, dhe riparimi që i shkon njërit e përkeqëson tjetrin. Një klient shumë i vjetër për të emërtuar një host të tunelizuar kërkon një përditësim. Një proxy që rinënshkruan trafikun kërkon një certifikatë rrënjësore të besuar, jo një ulje versioni. Përcaktoni cilin nga të dy keni përpara se të ndryshoni një variabël proxy, sepse rrugët shkojnë në drejtime të kundërta.

Lexoni kuadrot e fundit përpara se të prekni cilësimet

Ku përfundon gjurma ju tregon cila shtresë u dorëzua. Nëse kuadrot mbyllëse ndodhen brenda kodit TLS të urllib3 që vjen me pip dhe teksti ankohet për një emër hosti, biblioteka kliente nuk arriti të përfundojë një hap verifikimi, dhe ky është një problem versioni shumë më shpesh sesa një problem certifikate. Nëse teksti në vend të kësaj raporton një lidhje të refuzuar, një emër proxy të pazgjidhur ose një gabim HTTP 407, pika fundore e tunelit është fajtore dhe asnjë përditësim nuk do ta ndryshojë atë.

Kapni versionin e pip dhe variablat e proxy në të njëjtën shell që dështon. Një shell i hapur përpara se tuneli të ngrihej mban vlera të ndryshme nga një i hapur më pas, dhe ndryshimi midis tyre është shpesh i gjithë diagnostikimi.

python3 -m pip --version
env | grep -i -E 'proxy|no_proxy'

Kur klienti është më i vjetër se tuneli

Versionet më të vjetra të pip përfshinin një stack HTTPS që humbiste emrin e hostit të destinacionit sapo soketi mbështillej nga një tunel. Mesazhi check_hostname është ai që lëshon ky stack kur arrin verifikimin pa një emër për të krahasuar. Një përditësim e heq defektin sepse klienti më i ri e ruan emrin gjatë shtrëngimit të duarve, dhe ndryshimi është mjaft i lirë për t'u provuar i pari sa herë kuadrot mbyllëse tregojnë kodin TLS që vjen me pip.

Nëse indeksi nuk arrihet nga makina që dështon, merrni një wheel të përditësuar në një host që mundet dhe instalojeni nga skedari. Përdorni emrin e skedarit që keni shkarkuar vërtet, jo një version të kopjuar nga një postim blogu.

python3 -m pip install --upgrade pip
python3 -m pip install ./pip-24.2-py3-none-any.whl

Kur proxy rinënshkruan trafikun

Një proxy që përfundon TLS dhe riemeton certifikata nën një rrënjë korporative prodhon një gabim tjetër: certificate verify failed, jo një ankesë për emrin e hostit. Ai dallim është indicja, sepse klienti arriti te një server dhe pastaj refuzoi identitetin që iu tregua. Riparimi është t'i besosh në mënyrë të qartë asaj rrënje, qoftë për një komandë qoftë përmes variablës PIP_CERT, që klienti të mund të ndërtojë një zinxhir deri te ajo që paraqet proxy. Shtimi i rrënjës në depon e besimit të sistemit funksionon gjithashtu, por ndryshon besimin për çdo program në makinë, dhe ky është një vendim më i madh sesa rregullimi i një instalimi pakete.

Mbajeni --trusted-host si diagnostikim, kurrë si gjendje e përhershme. Ai fik kontrollin që po përpiqeshit të mbanit, kështu që një certifikatë vërtet e gabuar duket e shëndetshme më pas. Nëse e përdorët për të instaluar një paketë, hiqeni dhe riparoni zinxhirin përpara versionit të ardhshëm.

Kodi juaj Python e injoron plotësisht konfigurimin e pip. Një thirrje requests ka nevojë që proxy dhe paketa të kalohen atje ku ajo sesion mund t'i shohë, prandaj blloku më poshtë i vendos të dyja në objektin e sesionit.

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)

Kur pika fundore ose porta janë gabim

Një klient tuneli shpesh rishkruan proxy-n e sistemit ndërsa lidhet, gjë që mund ta lërë pip të drejtuar nga një host që nuk përgjigjet kurrë në atë portë. Testoni pikën fundore me një klient që nuk është pip përpara se të ndryshoni çdo cilësim të pip. Nëse curl dështon me të njëjtin argument proxy, defekti është mbi pip dhe asnjë konfigurim brenda pip nuk do të ndihmojë.

Flamuri i komandës dhe variablat e mjedisit thonë të njëjtën gjë për fusha të ndryshme: flamuri vlen për një thirrje, variablat për çdo proces të nisur më pas. Shtoni NO_PROXY për një indeks të brendshëm, që trafiku privat i paketave të anashkalojë rrugën rreth e qark përmes tunelit.

curl -x http://proxy.corp.internal:8080 --head https://pypi.org/simple/
pip install --proxy http://proxy.corp.internal:8080 requests

Bëjeni të përhershme cilësimin dhe provoni se rruga funksionon

Ruajeni proxy-n në konfigurimin e vetë pip kur duhet t'i mbijetojë shell-it aktual, pastaj lexoni çfarë do të përdorë vërtet pip. Dalja e debug emërton skedarin dhe variablën pas çdo vlere, gjë që i zgjidh më shpejt debatet për përparësinë sesa leximi i dokumentacionit.

Verifikimi përdor qëllimisht dy klientë. Kërkesa nga biblioteka standarde provon rrugën dhe zinxhirin e besimit, ndërsa shkarkimi provon se konfigurimi i vetë pip është në pajtim me to. Kur i pari ka sukses dhe i dyti dështon, dallimi është brenda pip dhe jo në rrjet.

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