check_hostname-feil i pip bak ein proxy: pip eller tunnelen?

To ulike feil skriv ut den same pip-spora, og reparasjonen som passar den eine gjer den andre verre. Ein klient som er for gammal til å namngje ein tunnelert vert, treng ei oppgradering. Ein proxy som signerer trafikken på nytt, treng eit klarert rotsertifikat, ikkje ei nedgradering. Finn ut kva av dei to du har før du redigerer ein proxyvariabel, fordi stiane går i motsette retningar.

Les dei siste rammene før du rører innstillingane

Der spora sluttar, fortel deg kva lag som gav opp. Viss dei avsluttande rammene ligg i pip sin medfølgjande urllib3-TLS-kode og teksten klagar på eit vertsnamn, kunne klientbiblioteket ikkje fullføre eit verifiseringstrinn, og det er eit versjonsproblem langt oftare enn eit sertifikatproblem. Viss teksten i staden rapporterer ei avvist tilkopling, eit uløyst proxynamn eller ein HTTP 407, er tunneleendepunktet skulda, og inga oppgradering vil endre det.

Fang pip-versjonen og proxyvariablane i den same skala som feilar. Eit skal som vart opna før tunnelen kom opp, ber andre verdiar enn eit som vart opna etterpå, og skilnaden mellom dei er ofte heile diagnosen.

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

Når klienten er eldre enn tunnelen

Eldre pip-utgåver inkluderte ein HTTPS-stakk som miste målvertenamnet når sockelen vart pakka inn av ein tunnel. check_hostname-meldinga er det den stakken sender ut når han når verifiseringa utan eit namn å samanlikne med. Ei oppgradering fjernar feilen fordi den nyare klienten held på namnet gjennom handtrykket, og endringa er billeg nok til å prøve først når dei avsluttande rammene peikar på medfølgjande TLS-kode.

Viss indeksen ikkje kan nåast frå maskinen som feilar, hent ein gjeldande wheel på ein vert som kan, og installer frå fila. Bruk filnamnet du faktisk lasta ned, ikkje ein versjon kopiert frå eit blogginnlegg.

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

Når proxyen signerer trafikken på nytt

Ein proxy som avsluttar TLS og gjev ut sertifikat på nytt under ei bedriftsrot, produserer ein annan feil: certificate verify failed, ikkje ei klage på vertsnamn. Den skilnaden er leiartråden, fordi klienten nådde ein tenar og avviste deretter identiteten han vart vist. Reparasjonen er å stole på den rota eksplisitt, anten for éin kommando eller via PIP_CERT-variabelen, slik at klienten kan byggje ei kjede til det proxyen presenterer. Å leggje rota til systemets tillitslager fungerer òg, men det endrar tillit for kvart program på maskinen, og det er ei større avgjerd enn å fikse éin pakkeinstallasjon.

Hald --trusted-host som diagnose, aldri som ein varig tilstand. Det slår av sjekken du prøvde å halde, så eit verkeleg feil sertifikat ser friskt ut etterpå. Viss du brukte det for å installere éin pakke, fjern det og reparer kjeda før neste utgåve.

Din eigen Python-kode ignorerer pip-konfigurasjonen heilt. Eit requests-kall treng at proxyen og pakken vert sende dit den økta kan sjå dei, og difor set blokka nedanfor begge på sesjonsobjektet.

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)

Når endepunktet eller porten er feil

Ein tunnelklient skriv ofte om systemproxyen medan han koplar til, noko som kan la pip peike på ein vert som aldri svarar på den porten. Test endepunktet med ein klient som ikkje er pip, før du endrar noka pip-innstilling. Viss curl feilar med det same proxyargumentet, sit feilen over pip, og ingen konfigurasjon inne i pip vil hjelpe.

Kommandoflagget og miljøvariablane seier det same til ulike omfang: flagget gjeld for eitt kall, variablane for kvar prosess som vert starta etterpå. Legg til NO_PROXY for ein intern indeks, slik at privat pakketrafikk hoppar over omvegen gjennom tunnelen.

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

Gjer innstillinga varig og vis at stien fungerer

Lagre proxyen i pips eigen konfigurasjon når han skal overleve den gjeldande skala, og les deretter tilbake kva pip faktisk vil bruke. Debug-utdataa namngjev fila og variabelen bak kvar verdi, noko som avgjer diskusjonar om forrang raskare enn å lese dokumentasjonen.

Verifiseringa brukar medvite to klientar. Førespurnaden frå standardbiblioteket provar ruta og tillitskjeda, medan nedlastinga provar at pips eigen konfigurasjon er samd med dei. Når den første lukkast og den andre feilar, ligg skilnaden inne i pip og ikkje i nettet.

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