pip check_hostname kļūda aiz starpniekservera: pip vai tunelis?

Divas dažādas kļūdas izdrukā vienu un to pašu pip izsekojumu, un labojums, kas der vienai, padara otru sliktāku. Klientam, kas ir pārāk vecs, lai nosauktu tunelētu resursdatoru, nepieciešama atjaunināšana. Starpniekserverim, kas paraksta trafiku no jauna, nepieciešams uzticams saknes sertifikāts, nevis versijas pazemināšana. Noskaidrojiet, kura no abām jums ir, pirms rediģējat starpniekservera mainīgo, jo ceļi ved pretējos virzienos.

Izlasiet pēdējos kadrus pirms iestatījumu aiztikšanas

Vieta, kur izsekojums beidzas, pasaka, kurš slānis padevās. Ja noslēdzošie kadri atrodas pip pievienotajā urllib3 TLS kodā un teksts sūdzas par resursdatora nosaukumu, klienta bibliotēka nevarēja pabeigt pārbaudes soli, un tā ir versijas problēma daudz biežāk nekā sertifikāta problēma. Ja teksts tā vietā ziņo par noraidītu savienojumu, neatrisinātu starpniekservera nosaukumu vai HTTP 407 kļūdu, vainīgs ir tuneļa galapunkts, un neviena atjaunināšana to nemainīs.

Ierakstiet pip versiju un starpniekservera mainīgos tajā pašā čaulā, kas neizdodas. Čaula, kas atvērta pirms tuneļa pacelšanas, satur citas vērtības nekā tā, kas atvērta pēc tam, un atšķirība starp tām bieži ir visa diagnoze.

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

Kad klients ir vecāks par tuneli

Vecākas pip versijas ietvēra HTTPS steku, kas zaudēja galamērķa resursdatora nosaukumu, tiklīdz ligzda tika ietīta tunelī. check_hostname ziņojums ir tas, ko šī steka izdod, kad tas sasniedz pārbaudi bez nosaukuma salīdzināšanai. Atjaunināšana novērš kļūdu, jo jaunākais klients saglabā nosaukumu visā rokasspiedienā, un izmaiņas ir pietiekami lētas, lai tās mēģinātu vispirms, kad noslēdzošie kadri norāda uz pievienoto TLS kodu.

Ja indeksam nevar piekļūt no neizdevušās mašīnas, lejupielādējiet aktuālu wheel uz resursdatoru, kas to spēj, un instalējiet no faila. Izmantojiet faila nosaukumu, ko tiešām lejupielādējāt, nevis versiju, kas nokopēta no emuāra ieraksta.

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

Kad starpniekserveris paraksta trafiku no jauna

Starpniekserveris, kas izbeidz TLS un atkārtoti izdod sertifikātus uzņēmuma saknes ietvaros, rada citu kļūdu: certificate verify failed, nevis sūdzību par resursdatora nosaukumu. Šī atšķirība ir pavediens, jo klients sasniedza serveri un pēc tam noraidīja parādīto identitāti. Labojums ir nepārprotami uzticēties šai saknei, vai nu vienai komandai, vai arī caur PIP_CERT mainīgo, lai klients varētu izveidot ķēdi līdz tam, ko uzrāda starpniekserveris. Saknes pievienošana sistēmas uzticības krātuvē arī darbojas, taču tā maina uzticību katrai programmai mašīnā, un tas ir lielāks lēmums nekā vienas pakotnes instalācijas salabošana.

Paturiet --trusted-host kā diagnostiku, nekad kā pastāvīgu stāvokli. Tas izslēdz pārbaudi, ko jūs centāties saglabāt, tāpēc patiesi nepareizs sertifikāts pēc tam izskatās vesels. Ja izmantojāt to vienas pakotnes instalēšanai, noņemiet to un salabojiet ķēdi pirms nākamā laidiena.

Jūsu paša Python kods pilnībā ignorē pip konfigurāciju. requests izsaukumam ir nepieciešams nodot starpniekserveri un komplektu tur, kur šī sesija tos redz, tāpēc tālāk esošais bloks iestata abus sesijas objektā.

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)

Kad galapunkts vai ports ir nepareizs

Tuneļa klients bieži pārraksta sistēmas starpniekserveri, kamēr izveido savienojumu, kas var atstāt pip vērstu uz resursdatoru, kas šajā portā nekad neatbild. Pārbaudiet galapunktu ar klientu, kas nav pip, pirms maināt jebkuru pip iestatījumu. Ja curl neizdodas ar to pašu starpniekservera argumentu, kļūda ir virs pip, un nekāda konfigurācija pip iekšienē nepalīdzēs.

Komandas karodziņš un vides mainīgie saka vienu un to pašu dažādiem tvērumiem: karodziņš attiecas uz vienu izsaukumu, mainīgie uz katru pēc tam palaisto procesu. Pievienojiet NO_PROXY iekšējam indeksam, lai privātais pakotņu trafiks apietu apkārtceļu caur tuneli.

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

Saglabājiet iestatījumu un pierādiet, ka ceļš darbojas

Glabājiet starpniekserveri pip paša konfigurācijā, kad tam jāpārdzīvo pašreizējā čaula, pēc tam nolasiet, ko pip patiešām izmantos. debug izvade nosauc failu un mainīgo aiz katras vērtības, kas strīdus par prioritāti atrisina ātrāk nekā dokumentācijas lasīšana.

Pārbaude apzināti izmanto divus klientus. Standarta bibliotēkas pieprasījums pierāda maršrutu un uzticības ķēdi, bet lejupielāde pierāda, ka pip paša konfigurācija tiem piekrīt. Kad pirmais izdodas un otrais neizdodas, atšķirība ir pip iekšienē, nevis tīklā.

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