Error na check_hostname ng pip sa likod ng proxy: pip o ang tunnel?

Dalawang magkaibang pagkabigo ang naglilimbag ng parehong traceback ng pip, at ang pag-aayos na bagay sa isa ay nagpapalala sa isa. Kailangan ng upgrade ang client na masyadong luma para pangalanan ang isang host na dumaan sa tunnel. Kailangan ng pinagkakatiwalaang root certificate ang proxy na muling pumipirma ng trapiko, hindi ng downgrade. Alamin kung alin sa dalawa ang mayroon ka bago baguhin ang isang variable ng proxy, dahil magkasalungat ang direksyon ng mga landas.

Basahin ang huling mga frame bago hawakan ang mga setting

Sinasabi ng lugar kung saan nagtatapos ang traceback kung aling layer ang sumuko. Kung ang mga panghuling frame ay nasa loob ng TLS code ng urllib3 na kasama ng pip at nagrereklamo ang teksto tungkol sa hostname, hindi natapos ng client library ang isang hakbang ng pagpapatunay, at mas madalas na problemang bersyon ito kaysa problemang certificate. Kung ang teksto ay nag-uulat sa halip ng tinanggihang koneksyon, hindi nalutas na pangalan ng proxy o error na HTTP 407, ang dulo ng tunnel ang may kasalanan at walang upgrade na magbabago nito.

Kunin ang bersyon ng pip at ang mga variable ng proxy sa parehong shell na nabigo. Ang shell na binuksan bago umangat ang tunnel ay may ibang mga halaga kaysa sa binuksan pagkatapos, at ang pagkakaiba ng mga ito ay madalas ang buong diagnosis.

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

Kapag ang client ay mas luma kaysa tunnel

Ang mas lumang mga release ng pip ay may kasamang HTTPS stack na nawawalan ng hostname ng destinasyon kapag ang socket ay nabalot ng tunnel. Ang mensaheng check_hostname ang inilalabas ng stack na iyon kapag umabot ito sa pagpapatunay na walang pangalang maihahambing. Inaalis ng upgrade ang depekto dahil pinapanatili ng mas bagong client ang pangalan sa buong handshake, at ang pagbabago ay sapat na mura upang subukan muna sa tuwing ituturo ng mga panghuling frame ang kasamang TLS code.

Kung hindi maabot ang index mula sa bumabagsak na makina, kumuha ng kasalukuyang wheel sa host na makakaya at i-install mula sa file. Gamitin ang filename na aktwal mong na-download, hindi isang bersyong kinopya mula sa blog post.

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

Kapag ang proxy ay muling pumipirma ng trapiko

Ang proxy na nagtatapos ng TLS at muling naglalabas ng mga certificate sa ilalim ng corporate root ay gumagawa ng ibang error: certificate verify failed, hindi reklamo sa hostname. Ang pagkakaibang iyon ang palatandaan, dahil nakarating ang client sa isang server at pagkatapos ay tinanggihan ang identidad na ipinakita dito. Ang pag-aayos ay ang tahasang pagtitiwala sa root na iyon, para sa isang utos man o sa pamamagitan ng variable na PIP_CERT, upang makabuo ang client ng chain patungo sa ipinapakita ng proxy. Gumagana rin ang pagdaragdag ng root sa trust store ng system, ngunit binabago nito ang tiwala para sa bawat programa sa makina, at mas malaking desisyon iyon kaysa sa pag-aayos ng isang pag-install ng package.

Panatilihin ang --trusted-host bilang diagnostic, hindi kailanman bilang permanenteng estado. Pinapatay nito ang pagsusuring sinusubukan mong panatilihin, kaya ang tunay na maling certificate ay mukhang malusog pagkatapos. Kung ginamit mo ito upang mag-install ng isang package, alisin ito at ayusin ang chain bago ang susunod na release.

Ang sarili mong Python code ay ganap na binabalewala ang configuration ng pip. Ang isang tawag sa requests ay nangangailangan ng proxy at bundle na ipasa kung saan makikita ng session na iyon ang mga ito, kaya itinatakda ng bloke sa ibaba ang pareho sa session object.

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)

Kapag mali ang dulo o port

Ang client ng tunnel ay madalas na nagsusulat muli ng system proxy habang kumokonekta, na maaaring mag-iwan sa pip na nakaturo sa isang host na hindi kailanman sumasagot sa port na iyon. Subukan ang dulo gamit ang client na hindi pip bago baguhin ang anumang setting ng pip. Kung nabigo ang curl sa parehong argumento ng proxy, ang depekto ay nasa itaas ng pip at walang configuration sa loob ng pip ang makakatulong.

Ang flag ng utos at ang mga variable ng environment ay nagsasabi ng parehong bagay sa magkaibang saklaw: ang flag ay para sa isang invocation, ang mga variable ay para sa bawat prosesong sinimulan pagkatapos. Magdagdag ng NO_PROXY para sa isang panloob na index upang laktawan ng pribadong trapiko ng package ang pag-ikot sa tunnel.

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

Panatilihin ang setting at patunayan na gumagana ang landas

Itabi ang proxy sa sariling configuration ng pip kapag kailangan nitong mabuhay nang mas matagal kaysa kasalukuyang shell, pagkatapos basahin pabalik kung ano talaga ang gagamitin ng pip. Pinangalanan ng debug output ang file at variable sa likod ng bawat halaga, na mas mabilis na nagtatapos ng mga pagtatalo tungkol sa precedence kaysa pagbasa ng dokumentasyon.

Sinasadya ng pagpapatunay na gumamit ng dalawang client. Pinatutunayan ng kahilingan mula sa standard library ang ruta at ang chain ng tiwala, habang ang pag-download ay nagpapatunay na ang sariling configuration ng pip ay sumasang-ayon sa kanila. Kapag nagtagumpay ang una at nabigo ang pangalawa, ang pagkakaiba ay nasa loob ng pip at hindi sa network.

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