Прокси артындагы pip check_hostname катасы: pip же туннель?
Прокси артында эки башка бузулуу бирдей pip хост аталышынын катасын басып чыгарат. Эскирген кардарды трафикке кайра кол койгон проксиден айырмалап, туура катмарды оңдоңуз.
Эки башка бузулуу бирдей pip изин басып чыгарат, ал эми бирине ылайыктуу оңдоо экинчисин начарлатат. Туннелден өткөн хостту атоо үчүн өтө эски кардарга жаңыртуу керек. Трафикке кайра кол койгон проксиге ишеничтүү тамыр сертификаты керек, версияны төмөндөтүү эмес. Прокси өзгөрмөсүн түзөтүүдөн мурун бул экөөнүн кимиси сизде экенин аныктаңыз, анткени жолдор карама-каршы багыттарга баратат.
Жөндөөлөргө тийүүдөн мурун акыркы кадрларды окуңуз
Издин кайда бүтөөрү кайсы катмар багынганын айтат. Эгер жабылуучу кадрлар pip менен келген urllib3 TLS кодунун ичинде болсо жана текст хост атына нааразы болсо, кардар китепканасы текшерүү кадамын бүтүрө алган эмес, жана бул сертификат маселесине караганда версия маселеси алда канча көп. Эгер текст анын ордуна четке кагылган байланыш, чечилбеген прокси аты же HTTP 407 катасы жөнүндө билдирсе, туннелдин акыркы чекити күнөөлүү жана эч кандай жаңыртуу аны өзгөртпөйт.
pip версиясын жана прокси өзгөрмөлөрүн ийгиликсиз болгон ошол эле кабыкта жазып алыңыз. Туннель көтөрүлө электе ачылган кабык андан кийин ачылгандан башка маанилерди алып жүрөт, жана алардын ортосундагы айырма көбүнчө бүткүл диагностика.
python3 -m pip --version
env | grep -i -E 'proxy|no_proxy'
Кардар туннелден эски болгондо
pip-дин эски чыгарылыштары сокет туннел менен капталгандан кийин барар хосттун атын жоготкон HTTPS стекти камтыган. check_hostname билдирүүсү — бул стек салыштырууга ат жок текшерүүгө жеткенде чыгарган билдирүү. Жаңыртуу бузулууну жоёт, анткени жаңы кардар кол алышуу бою атын сактайт, жана жабылуучу кадрлар коштолгон TLS кодуна көрсөткөндө бул өзгөртүүнү биринчи сынап көрүүгө татыктуу арзан.
Эгер индекске ийгиликсиз машинадан жетүү мүмкүн болбосо, мүмкүнчүлүгү бар хосттон учурдагы wheel алып, файлдан орнотуңуз. Блог жазуусунан көчүрүлгөн версиянын ордуна чындап жүктөгөн файл атын колдонуңуз.
python3 -m pip install --upgrade pip
python3 -m pip install ./pip-24.2-py3-none-any.whl
Прокси трафикке кайра кол койгондо
TLSти бүтүргөн жана сертификаттарды корпоративдик тамырдын астында кайра чыгарган прокси башка катаны пайда кылат: certificate verify failed, хост атына нааразычылык эмес. Ушул айырма белги, анткени кардар серверге жетип, анан өзүнө көрсөтүлгөн инсандыкты четке каккан. Оңдоо — ошол тамырга ачык ишенүү, же бир буйрук үчүн, же PIP_CERT өзгөрмөсү аркылуу, ошондо кардар прокси сунуштаган нерсеге чынжыр кура алат. Тамырды системанын ишеним кампасына кошуу да иштейт, бирок бул машинадагы ар бир программанын ишенимин өзгөртөт, жана бул бир пакет орнотууну оңдоодон чоңураак чечим.
--trusted-hostту диагностика катары кармаңыз, эч качан туруктуу абал катары эмес. Ал сиз сактагыңыз келген текшерүүнү өчүрөт, ошондуктан чынында туура эмес сертификат андан кийин соо көрүнөт. Эгер аны бир пакет орнотуу үчүн колдонсоңуз, аны алып салып, кийинки чыгарылышка чейин чынжырды оңдоңуз.
Сиздин жеке Python кодуңуз pip конфигурациясын таптакыр этибарга албайт. requests чакыруусу прокси менен топтомду ошол сессия көрө турган жерге өткөрүүнү талап кылат, ошондуктан төмөнкү блок экөөнү тең сессия объектисине коёт.
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)
Акыркы чекит же порт туура эмес болгондо
Туннель кардары туташуу учурунда системанын проксисин көп жазат, бул pipти ошол портто эч качан жооп бербеген хостко багыттап калтырышы мүмкүн. pip жөндөөсүн өзгөртүүдөн мурун акыркы чекитти pip эмес кардар менен текшериңиз. Эгер curl ошол эле прокси аргументи менен ийгиликсиз болсо, бузулуу pipден жогору жана pip ичиндеги эч кандай конфигурация жардам бербейт.
Буйрук желеги жана чөйрө өзгөрмөлөрү ар башка чөйрөлөргө бирдей нерсени айтат: желек бир чакырууга, өзгөрмөлөр кийин башталган ар бир процесске тиешелүү. Ички индекске NO_PROXY кошуңуз, жеке пакет трафиги туннел аркылуу айланып өтүүнү аттап кетсин.
curl -x http://proxy.corp.internal:8080 --head https://pypi.org/simple/
pip install --proxy http://proxy.corp.internal:8080 requests
Жөндөөнү сактап, жолдун иштешин далилдеңиз
Прокси азыркы кабыктан узак жашашы керек болсо, аны pipдин өз конфигурациясында сактаңыз, анан pip чындап эмнени колдонорун окуңуз. debug чыгарылышы ар бир маанинин артындагы файлды жана өзгөрмөнү атайт, бул артыкчылык тууралуу талаштарды документтерди окугандан тезирээк чечет.
Текшерүү атайын эки кардарды колдонот. Стандарттык китепкананын суроосу маршрутту жана ишеним чынжырын далилдейт, ал эми жүктөө pipдин өз конфигурациясы алар менен макул экенин далилдейт. Биринчиси ийгиликтүү болуп, экинчиси ийгиликсиз болгондо, айырма тармакта эмес, pipдин ичинде.
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 |