Napaka check_hostname v pip za posredovalnim strežnikom: pip ali tunel?
Dve različni napaki izpišeta isto napako imena gostitelja v pip za posredovalnim strežnikom. Ločite zastarelega odjemalca od posredovalnega strežnika, ki znova podpisuje promet, in popravite pravo plast.
Dve različni napaki izpišeta isto sled pip, popravek, ki ustreza eni, pa drugo poslabša. Odjemalec, prestar, da bi poimenoval tuneliranega gostitelja, potrebuje nadgradnjo. Posredovalni strežnik, ki znova podpisuje promet, potrebuje zaupanja vreden korenski certifikat, ne znižanja različice. Ugotovite, katero od obeh imate, preden uredite spremenljivko posredovalnega strežnika, saj poti vodijo v nasprotne smeri.
Preberite zadnje okvire, preden se dotaknete nastavitev
Kje se sled konča, vam pove, katera plast je popustila. Če so zaključni okviri v kodi TLS knjižnice urllib3, ki je priložena pip, in se besedilo pritožuje zaradi imena gostitelja, odjemalska knjižnica ni mogla dokončati koraka preverjanja, in to je težava različice veliko pogosteje kot težava certifikata. Če besedilo namesto tega poroča o zavrnjeni povezavi, nerazrešenem imenu posredovalnega strežnika ali napaki HTTP 407, je kriva končna točka tunela in nobena nadgradnja tega ne bo spremenila.
Zabeležite različico pip in spremenljivke posredovalnega strežnika v isti lupini, ki odpove. Lupina, odprta preden se je tunel dvignil, nosi drugačne vrednosti kot tista, odprta pozneje, in razlika med njima je pogosto cela diagnoza.
python3 -m pip --version
env | grep -i -E 'proxy|no_proxy'
Ko je odjemalec starejši od tunela
Starejše izdaje pip so vključevale sklad HTTPS, ki je izgubil ciljno ime gostitelja, ko je bila vtičnica zavita v tunel. Sporočilo check_hostname je tisto, kar ta sklad izda, ko doseže preverjanje brez imena za primerjavo. Nadgradnja odpravi napako, ker novejši odjemalec ohrani ime med rokovanjem, in sprememba je dovolj poceni, da jo poskusite najprej, kadar koli zaključni okviri kažejo na priloženo kodo TLS.
Če indeks ni dosegljiv s stroja, ki odpoveduje, prenesite aktualni wheel na gostitelja, ki to zmore, in namestite iz datoteke. Uporabite ime datoteke, ki ste jo dejansko prenesli, ne različice, kopirane iz bloga.
python3 -m pip install --upgrade pip
python3 -m pip install ./pip-24.2-py3-none-any.whl
Ko posredovalni strežnik znova podpiše promet
Posredovalni strežnik, ki zaključi TLS in znova izda certifikate pod korporativnim korenom, ustvari drugo napako: certificate verify failed, ne pritožbe zaradi imena gostitelja. Ta razlika je namig, ker je odjemalec dosegel strežnik in nato zavrnil identiteto, ki mu je bila prikazana. Popravek je, da temu korenu izrecno zaupate, bodisi za en ukaz bodisi prek spremenljivke PIP_CERT, da lahko odjemalec zgradi verigo do tega, kar posredovalni strežnik predstavi. Dodajanje korena v sistemsko shrambo zaupanja prav tako deluje, vendar spreminja zaupanje za vsak program na stroju, in to je večja odločitev kot popravljanje ene namestitve paketa.
--trusted-host ohranite kot diagnostiko, nikoli kot trajno stanje. Izklopi preverjanje, ki ste ga poskušali ohraniti, zato je resnično napačen certifikat pozneje videti zdrav. Če ste ga uporabili za namestitev enega paketa, ga odstranite in popravite verigo pred naslednjo izdajo.
Vaša lastna koda Python popolnoma ignorira konfiguracijo pip. Klic requests potrebuje posredovalni strežnik in paket predana tja, kjer ju ta seja vidi, zato blok spodaj nastavi oboje na objektu seje.
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)
Ko sta končna točka ali vrata napačna
Odjemalec tunela pogosto prepiše sistemski posredovalni strežnik med povezovanjem, kar lahko pusti pip usmerjen na gostitelja, ki na teh vratih nikoli ne odgovori. Preizkusite končno točko z odjemalcem, ki ni pip, preden spremenite katero koli nastavitev pip. Če curl odpove z istim argumentom posredovalnega strežnika, je napaka nad pip in nobena konfiguracija znotraj pip ne bo pomagala.
Zastavica ukaza in okoljske spremenljivke povedo isto za različne obsege: zastavica velja za en klic, spremenljivke za vsak pozneje zagnan proces. Dodajte NO_PROXY za notranji indeks, da zasebni promet paketov preskoči ovinek skozi tunel.
curl -x http://proxy.corp.internal:8080 --head https://pypi.org/simple/
pip install --proxy http://proxy.corp.internal:8080 requests
Trajno shranite nastavitev in dokažite, da pot deluje
Posredovalni strežnik shranite v lastno konfiguracijo pip, kadar mora preživeti trenutno lupino, nato preberite, kaj bo pip res uporabil. Izhod debug poimenuje datoteko in spremenljivko za vsako vrednostjo, kar razreši spore o prednosti hitreje kot branje dokumentacije.
Preverjanje namerno uporablja dva odjemalca. Zahteva iz standardne knjižnice dokazuje pot in verigo zaupanja, medtem ko prenos dokazuje, da se lastna konfiguracija pip z njima strinja. Ko prva uspe in druga odpove, je razlika znotraj pip in ne v omrežju.
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 |