pip check_hostname klaida už tarpinio serverio: pip ar tunelis?

Dvi skirtingos gedimai išveda tą pačią pip pėdsaką, o taisymas, tinkantis vienam, pablogina kitą. Klientas, per senas įvardyti tuneliuojamą prieglobą, reikalauja atnaujinimo. Tarpinis serveris, kuris iš naujo pasirašo srautą, reikalauja patikimo šakninio sertifikato, o ne versijos sumažinimo. Nustatykite, kuris iš dviejų pas jus yra, prieš redaguodami tarpinio serverio kintamąjį, nes keliai veda priešingomis kryptimis.

Perskaitykite paskutinius kadrus prieš liesdami nustatymus

Vieta, kurioje baigiasi pėdsakas, pasako, kuris sluoksnis pasidavė. Jei baigiamieji kadrai yra pip pridedamame urllib3 TLS kode, o tekstas skundžiasi prieglobos vardu, kliento biblioteka negalėjo užbaigti tikrinimo žingsnio, ir tai yra versijos problema daug dažniau nei sertifikato problema. Jei tekstas vietoj to praneša apie atmestą ryšį, neišspręstą tarpinio serverio vardą arba HTTP 407 klaidą, kalta tunelio galinė dalis ir joks atnaujinimas to nepakeis.

Užfiksuokite pip versiją ir tarpinio serverio kintamuosius toje pačioje aplinkoje, kuri nepavyksta. Aplinka, atidaryta prieš pakylant tuneliui, turi kitas reikšmes nei atidaryta po to, ir skirtumas tarp jų dažnai yra visa diagnozė.

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

Kai klientas senesnis už tunelį

Senesni pip leidiniai turėjo HTTPS krūvą, kuri prarasdavo paskirties prieglobos vardą, kai lizdas būdavo apvyniojamas tuneliu. check_hostname pranešimas yra tai, ką ta krūva išleidžia pasiekusi tikrinimą be vardo palyginimui. Atnaujinimas pašalina gedimą, nes naujesnis klientas išsaugo vardą per rankos paspaudimą, ir pakeitimas yra pakankamai pigus, kad būtų bandomas pirmas, kai baigiamieji kadrai rodo į pridedamą TLS kodą.

Jei indeksas nepasiekiamas iš nepavykstančios mašinos, atsisiųskite naują wheel tame prieglobos serveryje, kuris gali, ir įdiekite iš failo. Naudokite failo vardą, kurį iš tikrųjų atsisiuntėte, o ne versiją, nukopijuotą iš tinklaraščio įrašo.

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

Kai tarpinis serveris iš naujo pasirašo srautą

Tarpinis serveris, kuris užbaigia TLS ir iš naujo išduoda sertifikatus pagal įmonės šaknį, sukuria kitą klaidą: certificate verify failed, o ne prieglobos vardo skundą. Tas skirtumas yra užuomina, nes klientas pasiekė serverį ir tada atmetė parodytą tapatybę. Taisymas yra aiškiai pasitikėti ta šaknimi, arba vienai komandai, arba per PIP_CERT kintamąjį, kad klientas galėtų sukurti grandinę iki to, ką pateikia tarpinis serveris. Šaknies pridėjimas prie sistemos patikėjimo saugyklos taip pat veikia, bet tai keičia pasitikėjimą kiekvienai mašinos programai, ir tai didesnis sprendimas nei sutaisyti vieną paketo diegimą.

Laikykite --trusted-host diagnostika, niekada ne nuolatine būsena. Jis išjungia patikrą, kurią bandėte išsaugoti, todėl tikrai neteisingas sertifikatas po to atrodo sveikas. Jei naudojote jį vienam paketui įdiegti, pašalinkite ir sutaisykite grandinę prieš kitą leidimą.

Jūsų pačių Python kodas visiškai nepaiso pip konfigūracijos. requests iškvietimui reikia perduoti tarpinį serverį ir rinkinį ten, kur ta sesija juos mato, todėl žemiau esantis blokas nustato abu sesijos objekte.

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)

Kai galinė dalis ar prievadas neteisingi

Tunelio klientas dažnai perrašo sistemos tarpinį serverį jungdamasis, o tai gali palikti pip nukreiptą į prieglobą, kuri tame prievade niekada neatsako. Išbandykite galinę dalį klientu, kuris nėra pip, prieš keisdami bet kurį pip nustatymą. Jei curl nepavyksta su tuo pačiu tarpinio serverio argumentu, gedimas yra aukščiau pip ir jokia konfigūracija pip viduje nepadės.

Komandos vėliavėlė ir aplinkos kintamieji sako tą patį skirtingoms apimtims: vėliavėlė galioja vienam iškvietimui, kintamieji kiekvienam po to paleistam procesui. Pridėkite NO_PROXY vidiniam indeksui, kad privatus paketų srautas apeitų aplinkkelį per tunelį.

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

Išsaugokite nustatymą ir įrodykite, kad kelias veikia

Laikykite tarpinį serverį pačioje pip konfigūracijoje, kai jis turi pergyventi dabartinę aplinką, tada perskaitykite, ką pip iš tikrųjų naudos. debug išvestis įvardija failą ir kintamąjį už kiekvienos reikšmės, o tai ginčus dėl pirmenybės išsprendžia greičiau nei dokumentacijos skaitymas.

Tikrinimas sąmoningai naudoja du klientus. Standartinės bibliotekos užklausa įrodo maršrutą ir pasitikėjimo grandinę, o atsisiuntimas įrodo, kad pip pati konfigūracija su jais sutinka. Kai pirmasis pavyksta, o antrasis nepavyksta, skirtumas yra pip viduje, o ne tinkle.

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