check_hostname-villa pip bak við milliþjón: pip eða göngin?
Tvær bilanir prenta sömu pip-villu um hýsilheiti bak við milliþjón. Greindu gamlan biðlara frá milliþjóni sem endurskrifar undir umferðina og lagaðu rétta lagið.
Tvær ólíkar bilanir prenta sama pip-rakninguna, og viðgerðin sem hentar annarri gerir hina verri. Biðlari sem er of gamall til að nefna göngulegan hýsil þarf uppfærslu. Milliþjónn sem endurskrifar undir umferðina þarf traustan rótarvottorð, ekki niðurfærslu. Finndu út hvor þessara tveggja er til staðar áður en þú breytir milliþjónsbreytu, því slóðirnar liggja í gagnstæðar áttir.
Lestu síðustu rammana áður en þú snertir stillingar
Þar sem rakningin endar segir þér hvaða lag gafst upp. Ef lokarammana er að finna í TLS-kóða urllib3 sem fylgir pip og textinn kvartar um hýsilheiti, gat biðlarasafnið ekki klárað sannprófunarþrep, og það er útgáfuvandamál miklu oftar en vottorðsvandamál. Ef textinn greinir hins vegar frá hafnaðri tengingu, óleystu milliþjónsnafni eða HTTP 407, er endapunktur ganganna sekur og engin uppfærsla mun breyta því.
Skráðu pip-útgáfuna og milliþjónsbreyturnar í sama skelinni sem bregst. Skel sem opnuð var áður en göngin komu upp ber önnur gildi en sú sem opnuð var eftir, og munurinn á þeim er oft öll greiningin.
python3 -m pip --version
env | grep -i -E 'proxy|no_proxy'
Þegar biðlarinn er eldri en göngin
Eldri pip-útgáfur báru HTTPS-stafa sem missti áfangahýsilheitið þegar göngin vöfðu sokkinn. check_hostname-skilaboðin eru það sem sá stafi sendir frá sér þegar hann nær sannprófun án nafns til að bera saman. Uppfærsla fjarlægir bilunina því nýrri biðlarinn heldur nafninu í gegnum handabandið, og breytingin er nógu ódýr til að prófa fyrst hvenær sem lokarammana vísa á meðfylgjandi TLS-kóða.
Ef ekki er hægt að ná í skráasafnið frá biluðu vélinni, sæktu ferskan wheel á hýsil sem getur það og settu upp úr skránni. Notaðu skráarheitið sem þú sóttir í raun, ekki útgáfu sem afrituð var af bloggfærslu.
python3 -m pip install --upgrade pip
python3 -m pip install ./pip-24.2-py3-none-any.whl
Þegar milliþjónninn endurskrifar undir umferðina
Milliþjónn sem lýkur TLS og gefur út vottorð að nýju undir fyrirtækisrót framleiðir aðra villu: certificate verify failed, ekki kvörtun um hýsilheiti. Sá munur er vísbendingin, því biðlarinn náði í þjón og hafnaði síðan auðkenninu sem sýnt var. Viðgerðin er að treysta þeirri rót sérstaklega, annaðhvort fyrir eina skipun eða í gegnum PIP_CERT-breytuna, svo biðlarinn geti byggt keðju að því sem milliþjónninn sýnir. Að bæta rótinni við traustageymslu kerfisins virkar líka, en það breytir trausti fyrir hvert forrit á vélinni, og það er stærri ákvörðun en að laga eina pakkauppsetningu.
Haltu --trusted-host sem greiningartæki, aldrei sem varanlegu ástandi. Það slekkur á þeirri athugun sem þú reyndir að halda, svo virkilega rangt vottorð lítur heilbrigt út eftir. Ef þú notaðir það til að setja upp eitt pakka, fjarlægðu það og lagaðu keðjuna fyrir næstu útgáfu.
Þinn eigin Python-kóði hunsar stillingar pip algjörlega. requests-kall þarf milliþjóninn og búntið sent þangað sem sú lota getur séð þau, þess vegna setur blokkin hér fyrir neðan bæði á lotu-hlutinn.
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)
Þegar endapunkturinn eða gáttin er röng
Milliþjónsbiðlari endurskrifar oft kerfismilliþjóninn meðan hann tengist, sem getur skilið pip eftir að vísa á hýsil sem svarar aldrei á þeirri gátt. Prófaðu endapunktinn með biðlara sem er ekki pip áður en þú breytir einhverri pip-stillingu. Ef curl bregst með sama milliþjónsargumentinu liggur bilunin ofan við pip og engin uppsetning inni í pip mun hjálpa.
Skipunarflagg og umhverfisbreytur segja það sama fyrir ólík svið: flaggið gildir fyrir eitt kall, breyturnar fyrir hvert ferli sem ræst er á eftir. Bættu NO_PROXY við fyrir innra skráasafn svo einkafarmur pakka sleppi króknum í gegnum göngin.
curl -x http://proxy.corp.internal:8080 --head https://pypi.org/simple/
pip install --proxy http://proxy.corp.internal:8080 requests
Geymdu stillinguna og sannaðu að slóðin virki
Geymdu milliþjóninn í eigin stillingum pip þegar hann á að lifa skelina af, lestu síðan hvað pip mun í raun nota. debug-úttakið nefnir skrána og breytuna bak við hvert gildi, sem leysir deilur um forgang hraðar en að lesa skjölunina.
Sannprófunin notar tvo biðlara viljandi. Beiðni úr staðalsafninu sannar slóðina og traustakeðjuna, en niðurhalið sannar að eigin stillingar pip séu sammála þeim. Þegar fyrri virkar og seinni bregst er munurinn inni í pip en ekki í netinu.
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 |