Eraro check_hostname de pip malantaŭ prokurilo: pip aŭ la tunelo?

Du malsamaj fiaskoj presas la saman spuron de pip, kaj la riparo taŭga por unu plimalbonigas la alian. Kliento tro malnova por nomi tunelitan gastiganton bezonas ĝisdatigon. Prokurilo, kiu resubskribas trafikon, bezonas fidindan radikan atestilon, ne malaltigon de versio. Eltrovu, kiun el la du vi havas, antaŭ ol redakti prokurilan variablon, ĉar la vojoj kondukas en kontraŭajn direktojn.

Legu la lastajn kadrojn antaŭ ol tuŝi agordojn

La loko, kie la spuro finiĝas, diras al vi, kiu tavolo rezignis. Se la fermaj kadroj sidas ene de la TLS-kodo de urllib3 enkonstruita en pip kaj la teksto plendas pri gastigantnomo, la klienta biblioteko ne povis fini validigan paŝon, kaj tio estas versioproblemo multe pli ofte ol atestilproblemo. Se la teksto anstataŭe raportas rifuzitan konekton, nesolvitan prokurilan nomon aŭ eraron HTTP 407, la tunela finpunkto kulpas kaj neniu ĝisdatigo tion ŝanĝos.

Kaptu la version de pip kaj la prokurilajn variablojn en la sama ŝelo, kiu fiaskas. Ŝelo malfermita antaŭ ol la tunelo supreniris portas aliajn valorojn ol unu malfermita poste, kaj la diferenco inter ili ofte estas la tuta diagnozo.

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

Kiam la kliento estas pli malnova ol la tunelo

Pli malnovaj eldonoj de pip kunportis HTTPS-stakon, kiu perdis la celan gastigantnomon post kiam la ingo estis volvita de tunelo. La mesaĝo check_hostname estas tio, kion tiu stako eligas kiam ĝi atingas validigon sen nomo por kompari. Ĝisdatigo forigas la difekton ĉar la pli nova kliento konservas la nomon tra la manpremo, kaj la ŝanĝo estas sufiĉe malmultekosta por provi unue kiam la fermaj kadroj montras al enkonstruita TLS-kodo.

Se la indekso neatingeblas de la fiaskanta maŝino, elŝutu aktualan wheel sur gastiganto, kiu povas, kaj instalun el la dosiero. Uzu la dosiernomon, kiun vi efektive elŝutis, anstataŭ version kopiitan el blogaĵo.

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

Kiam la prokurilo resubskribas trafikon

Prokurilo, kiu finas TLS kaj reeldonas atestilojn sub kompania radiko, produktas alian eraron: certificate verify failed, ne plendon pri gastigantnomo. Tiu diferenco estas la indiko, ĉar la kliento atingis servilon kaj poste malakceptis la identecon montritan al ĝi. La riparo estas fidi tiun radikon eksplicite, ĉu por unu komando ĉu per la variablo PIP_CERT, por ke la kliento povu konstrui ĉenon al tio, kion la prokurilo prezentas. Aldoni la radikon al la sistema fida konservejo ankaŭ funkcias, sed ĝi ŝanĝas fidon por ĉiu programo sur la maŝino, kio estas pli granda decido ol ripari unu pakaĵan instalon.

Tenu --trusted-host kiel diagnozilon, neniam kiel restan staton. Ĝi malŝaltas la kontrolon, kiun vi provis konservi, do vere malĝusta atestilo aspektas sana poste. Se vi uzis ĝin por instali unu pakaĵon, forigu ĝin kaj riparu la ĉenon antaŭ la sekva eldono.

Via propra Python-kodo tute ignoras la agordon de pip. Voko de requests bezonas la prokurilon kaj la faskon transdonitajn tie, kie tiu sesio povas vidi ilin, kaj tial la suba bloko starigas ambaŭ sur la sesia objekto.

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)

Kiam la finpunkto aŭ pordo estas malĝusta

Tunela kliento ofte reskribas la sisteman prokurilon dum ĝi konektiĝas, kio povas lasi pip direktitan al gastiganto, kiu neniam respondas sur tiu pordo. Testu la finpunkton per kliento, kiu ne estas pip, antaŭ ol ŝanĝi ajnan agordon de pip. Se curl fiaskas kun la sama prokurila argumento, la difekto sidas super pip kaj nenia kvanto da agordo ene de pip helpos.

La komanda flago kaj la mediaj variabloj diras la samon al malsamaj sferoj: la flago validas por unu alvoko, la variabloj por ĉiu procezo startigita poste. Aldonu NO_PROXY por interna indekso, por ke privata pakaĵa trafiko preterlasu la ĉirkaŭvojon tra la tunelo.

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

Persistigu la agordon kaj pruvu, ke la vojo funkcias

Konservu la prokurilon en la propra agordo de pip kiam ĝi devas postvivi la nunan ŝelon, poste relegu, kion pip vere uzos. La eligo de debug nomas la dosieron kaj la variablon malantaŭ ĉiu valoro, kio solvas disputojn pri prioritato pli rapide ol legado de la dokumentaro.

La validigo intence uzas du klientojn. La peto el la norma biblioteko pruvas la itineron kaj la fidan ĉenon, dum la elŝuto pruvas, ke la propra agordo de pip konsentas kun ili. Kiam la unua sukcesas kaj la dua fiaskas, la diferenco estas ene de pip, ne en la reto.

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