pip check_hostname-fout agter 'n proxy: pip of die tonnel?

Twee verskillende foute druk dieselfde pip-terugsporing, en die herstel wat by die een pas, maak die ander erger. 'n Kliënt wat te oud is om 'n tonnelde gasheernaam te noem, het 'n opgradering nodig. 'n Proxy wat verkeer her-onderteken, het 'n vertroude wortelsertifikaat nodig, nie 'n afgradering nie. Bepaal watter van die twee jy het voordat jy 'n proxy-veranderlike wysig, want die paaie loop in teenoorgestelde rigtings.

Lees die laaste raamwerke voordat jy instellings aanraak

Waar die terugsporing eindig, sê vir jou watter laag opgegee het. As die slotraamwerke binne pip se ingeboude urllib3-TLS-kode sit en die teks kla oor 'n gasheernaam, kon die kliëntbiblioteek nie 'n verifikasiestap voltooi nie, en dit is veel vaker 'n weergawe probleem as 'n sertifikaatprobleem. As die teks eerder 'n geweierde verbinding, 'n onopgeloste proxy-naam of 'n HTTP 407 rapporteer, is die tonnel-eindpunt skuld en geen opgradering sal dit verander nie.

Vang die pip-weergawe en die proxy-veranderlikes in dieselfde shell wat misluk. 'n Shell wat oopgemaak is voordat die tonnel opgekom het, dra ander waardes as een wat daarna oopgemaak is, en die verskil tussen hulle is dikwels die hele diagnose.

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

Wanneer die kliënt ouer is as die tonnel

Ouer pip-vrystellings het 'n HTTPS-stapel ingesluit wat die bestemmingsgasheernaam verloor het sodra die socket deur 'n tonnel omhul is. Die check_hostname-boodskap is wat daardie stapel uitstuur wanneer dit verifikasie bereik sonder 'n naam om teen te vergelyk. 'n Opgradering verwyder die fout omdat die nuwer kliënt die naam deur die handshake hou, en die verandering is goedkoop genoeg om eerste te probeer wanneer die slotraamwerke na ingeboude TLS-kode wys.

As die indeks nie vanaf die mislukte masjien bereik kan word nie, haal 'n huidige wheel op 'n gasheer wat dit kan en installeer uit die lêer. Gebruik die lêernaam wat jy werklik afgelaai het eerder as 'n weergawe wat uit 'n blogpos gekopieer is.

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

Wanneer die proxy verkeer her-onderteken

’n Proxy wat TLS termineer en sertifikate onder 'n korporatiewe wortel heruitreik, produseer 'n ander fout: certificate verify failed, nie 'n gasheernaam-klag nie. Daardie verskil is die leidraad, want die kliënt het 'n bediener bereik en toe die identiteit wat aan hom gewys is, verwerp. Die herstel is om daardie wortel eksplisiet te vertrou, hetsy vir een opdrag of deur die PIP_CERT-veranderlike, sodat die kliënt 'n ketting kan bou na wat die proxy bied. Om die wortel by die stelsel se vertroude stoor te voeg werk ook, maar dit verander vertroue vir elke program op die masjien, wat 'n groter besluit is as om een pakketinstallasie reg te maak.

Hou --trusted-host as 'n diagnostiese middel, nooit as 'n russtand nie. Dit skakel die kontrole af wat jy wou behou, so 'n werklik verkeerde sertifikaat lyk daarna gesond. As jy dit gebruik het om een pakket te installeer, verwyder dit en herstel die ketting voor die volgende vrystelling.

Jou eie Python-kode ignoreer pip se konfigurasie heeltemal. 'n requests-oproep benodig die proxy en die bundel waar daardie sessie hulle kan sien, en daarom stel die blok hieronder albei op die sessie-objek.

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)

Wanneer die eindpunt of poort verkeerd is

'n Tonnelkliënt herskryf dikwels die stelselproxy terwyl dit verbind, wat pip kan laat wys na 'n gasheer wat nooit op daardie poort antwoord nie. Toets die eindpunt met 'n kliënt wat nie pip is nie voordat jy enige pip-instelling verander. As curl met dieselfde proxy-argument misluk, sit die fout bo pip en geen hoeveelheid konfigurasie binne pip sal help nie.

Die opdragvlag en die omgewingsveranderlikes sê dieselfde ding vir verskillende omvange: die vlag geld vir een aanroeping, die veranderlikes vir elke proses wat daarna begin. Voeg NO_PROXY by vir 'n interne indeks sodat private pakketverkeer die ompad deur die tonnel oorslaan.

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

Hou die instelling en bewys die pad werk

Stoor die proxy in pip se eie konfigurasie wanneer dit die huidige shell moet oorleef, en lees dan terug wat pip werklik gaan gebruik. Die debug-uitset noem die lêer en die veranderlike agter elke waarde, wat argumente oor voorrang vinniger besleg as om die dokumentasie te lees.

Verifikasie gebruik doelbewus twee kliënte. Die standaardbiblioteek-versoek bewys die roete en die vertrouensketting, terwyl die aflaai bewys dat pip se eie konfigurasie met hulle saamstem. Wanneer die eerste slaag en die tweede misluk, is die verskil binne pip eerder as in die netwerk.

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