pip check_hostname hiba proxy mögött: a pip vagy az alagút?

Két különböző hiba ugyanazt a pip-nyomkövetést írja ki, és az egyikhez illő javítás a másikat rontja. Egy túl régi kliens, amely nem tudja megnevezni az alagutazott gazdagépet, frissítést igényel. Az újra-aláíró proxy megbízható gyökértanúsítványt igényel, nem visszalépést. Állapítsa meg, melyikük van Önnél, mielőtt proxyváltozót szerkeszt, mert az utak ellentétes irányba vezetnek.

Olvassa el az utolsó kereteket, mielőtt a beállításokhoz nyúl

A nyomkövetés vége megmondja, melyik réteg adta fel. Ha a záró keretek a piphez csomagolt urllib3 TLS-kódjában vannak, és a szöveg gazdanévre panaszkodik, a kliens könyvtár nem tudott befejezni egy ellenőrzési lépést, és ez sokkal gyakrabban verzióprobléma, mint tanúsítványprobléma. Ha a szöveg ehelyett elutasított kapcsolatot, fel nem oldott proxynevet vagy HTTP 407 hibát jelez, az alagút végpontja a hibás, és semmilyen frissítés nem változtat ezen.

Rögzítse a pip verzióját és a proxyváltozókat ugyanabban a shellben, amelyik hibázik. Az alagút feljövetele előtt megnyitott shell más értékeket hordoz, mint az utána megnyitott, és a kettő közötti különbség gyakran a teljes diagnózis.

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

Amikor a kliens régebbi az alagútnál

A régebbi pip-kiadások olyan HTTPS-vermet tartalmaztak, amely elveszítette a cél gazdanevet, amint az alagút körbevette a socketet. A check_hostname üzenet az, amit ez a vermet kibocsát, amikor összehasonlításra alkalmas név nélkül eléri az ellenőrzést. A frissítés megszünteti a hibát, mert az újabb kliens megtartja a nevet a kézfogás során, és a változtatás elég olcsó ahhoz, hogy először próbáljuk ki, valahányszor a záró keretek a csomagolt TLS-kódra mutatnak.

Ha az index nem érhető el a hibázó gépről, töltsön le egy friss wheel-t egy olyan gazdagépen, amely képes rá, és telepítsen a fájlból. A ténylegesen letöltött fájlnevet használja, ne egy blogbejegyzésből másolt verziót.

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

Amikor a proxy újra-aláírja a forgalmat

Az a proxy, amely lezárja a TLS-t és vállalati gyökér alatt újra kiállítja a tanúsítványokat, más hibát produkál: certificate verify failed, nem gazdanév-panaszt. Ez a különbség a nyom, mert a kliens elért egy szervert, majd elutasította a megmutatott identitást. A javítás az, hogy explicit módon megbízzunk ebben a gyökérben, akár egy parancshoz, akár a PIP_CERT változón keresztül, hogy a kliens láncot építhessen ahhoz, amit a proxy bemutat. A gyökér hozzáadása a rendszer megbízhatósági tárolójához is működik, de ez minden program megbízhatóságát megváltoztatja a gépen, és ez nagyobb döntés, mint egy csomagtelepítés javítása.

A --trusted-host maradjon diagnosztika, soha ne állandó állapot. Kikapcsolja azt az ellenőrzést, amelyet meg akart tartani, így egy valóban rossz tanúsítvány utána egészségesnek látszik. Ha egy csomag telepítésére használta, távolítsa el, és a következő kiadás előtt javítsa a láncot.

A saját Python-kódja teljesen figyelmen kívül hagyja a pip konfigurációját. Egy requests-hívásnak a proxyt és a csomagot ott kell átadni, ahol az a munkamenet látja őket, ezért a lenti blokk mindkettőt a munkamenet-objektumra állítja.

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)

Amikor a végpont vagy a port rossz

Az alagút kliens gyakran átírja a rendszerproxyt, miközben csatlakozik, ami a pipet olyan gazdagépre irányíthatja, amely soha nem válaszol azon a porton. Tesztelje a végpontot egy nem pip klienssel, mielőtt bármilyen pip-beállítást megváltoztat. Ha a curl ugyanazzal a proxyargumentummal hibázik, a hiba a pip felett van, és semmilyen pipen belüli konfiguráció nem segít.

A parancsjelző és a környezeti változók ugyanazt mondják különböző hatóköröknek: a jelző egyetlen hívásra érvényes, a változók minden utána indított folyamatra. Adjon hozzá NO_PROXY-t egy belső indexhez, hogy a privát csomagforgalom kihagyja az alagúton át vezető kitérőt.

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

Tegye tartóssá a beállítást, és bizonyítsa, hogy az útvonal működik

Amikor túl kell élnie az aktuális shellt, tárolja a proxyt a pip saját konfigurációjában, majd olvassa vissza, mit fog a pip valóban használni. A debug kimenet megnevezi az egyes értékek mögötti fájlt és változót, ami gyorsabban rendezi az elsőbbségi vitákat, mint a dokumentáció olvasása.

Az ellenőrzés szándékosan két klienst használ. A szabványos könyvtár kérése bizonyítja az útvonalat és a bizalmi láncot, míg a letöltés azt bizonyítja, hogy a pip saját konfigurációja egyetért velük. Amikor az első sikerül és a második hibázik, a különbség a pipen belül van, nem a hálózatban.

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