Proxy arxasında pip check_hostname xətası: pip, yoxsa tunel?

İki fərqli nasazlıq eyni pip traceback-ini çap edir və birinə uyğun bərpa digərini pisləşdirir. Tunellənmiş hostu adlandırmaq üçün çox köhnə olan müştəri yenilənmə tələb edir. Trafiki yenidən imzalayan proxy aşağı salınma deyil, etibarlı kök sertifikatı tələb edir. Proxy dəyişənini redaktə etməzdən əvvəl hansı ikidən biri olduğunu müəyyənləşdirin, çünki yollar əks istiqamətlərə aparır.

Parametrlərə toxunmadan son çərçivələri oxuyun

Traceback-in bitdiyi yer hansı qatın imtina etdiyini bildirir. Əgər yekun çərçivələr pip-in daxilindəki urllib3 TLS kodunun içindədirsə və mətn hostname-dən şikayət edirsə, müştəri kitabxanası yoxlama addımını bitirə bilməyib və bu, sertifikat problemindən daha çox versiya problemidir. Əgər mətn bunun əvəzinə rədd edilmiş bağlantı, həll olunmamış proxy adı və ya HTTP 407 bildirirsə, tunelin son nöqtəsi günahkardır və heç bir yeniləmə bunu dəyişməyəcək.

pip versiyasını və proxy dəyişənlərini uğursuz olan eyni shell-də tutun. Tunel qalxmazdan əvvəl açılmış shell sonra açılmışdan fərqli dəyərlər daşıyır və aralarındakı fərq çox vaxt bütün diaqnozdur.

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

Müştəri tuneldən daha köhnə olduqda

Köhnə pip buraxılışları socket tunellə örtüldükdən sonra təyinat hostunu itirən HTTPS yığını ilə gəlirdi. check_hostname mesajı həmin yığının müqayisə üçün ad olmadan yoxlamaya çatanda çıxardığı mesajdır. Yeniləmə nasazlığı aradan qaldırır, çünki yeni müştəri adı handshake boyunca saxlayır və yekun çərçivələr daxili TLS kodunu göstərdikdə dəyişiklik ilk cəhd üçün kifayət qədər ucuzdur.

Əgər indeksə uğursuz maşından çatmaq mümkün deyilsə, cari wheel-i buna qadir olan hostda endirin və fayldan quraşdırın. Bloq yazısından köçürülmüş versiya yerinə faktiki endirdiyiniz fayl adından istifadə edin.

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

Proxy trafiki yenidən imzaladıqda

TLS-i sonlandıran və sertifikatları korporativ kök altında yenidən verən proxy fərqli xəta yaradır: certificate verify failed, hostname şikayəti deyil. Bu fərq ipucudur, çünki müştəri serverə çatıb, sonra ona göstərilən kimliyi rədd edib. Bərpa həmin kökə açıq şəkildə etibar etməkdir, ya bir əmr üçün, ya da PIP_CERT dəyişəni ilə, belə ki müştəri proxy-nin təqdim etdiyinə zəncir qura bilsin. Kökü sistemin etibarlı anbarına əlavə etmək də işləyir, lakin bu, maşındakı hər proqram üçün etibarı dəyişir və bir paket quraşdırmasını düzəltməkdən daha böyük qərardır.

--trusted-host-u diaqnostik vasitə kimi saxlayın, heç vaxt dayanacaq vəziyyət kimi yox. O, saxlamağa çalışdığınız yoxlamanı söndürür, buna görə həqiqətən səhv sertifikat sonradan sağlam görünür. Onu bir paketin quraşdırılması üçün işlətmisinizsə, silin və növbəti buraxılışdan əvvəl zənciri bərpa edin.

Öz Python kodunuz pip konfiqurasiyasını tamamilə nəzərə almır. requests çağırışı proxy və paketin həmin sessiyanın görə biləcəyi yerə ötürülməsini tələb edir, buna görə aşağıdakı blok ikisini də sessiya obyektinə qoyur.

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)

Son nöqtə və ya port səhv olduqda

Tunel müştərisi tez-tez qoşularkən sistem proxy-sini yenidən yazır və bu, pip-i o portda heç vaxt cavab verməyən hosta yönəldə bilər. Hər hansı pip parametrini dəyişməzdən əvvəl son nöqtəni pip olmayan müştəri ilə yoxlayın. Əgər curl eyni proxy arqumenti ilə uğursuz olursa, nasazlıq pip-dən yuxarıdadır və pip daxilindəki heç bir konfiqurasiya kömək etməyəcək.

Əmr bayrağı və mühit dəyişənləri eyni şeyi fərqli əhatələrə deyir: bayraq bir çağırışa, dəyişənlər sonradan başlayan hər prosesə aiddir. Daxili indeks üçün NO_PROXY əlavə edin ki, özəl paket trafiki tuneldən keçən dövrəni atlasın.

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

Parametri daimi saxlayın və yolun işlədiyini sübut edin

Proxy cari shell-dən sonra da qalmalıdırsa, onu pip-in öz konfiqurasiyasında saxlayın, sonra pip-in həqiqətən nə istifadə edəcəyini oxuyun. debug çıxışı hər dəyərin arxasındakı faylı və dəyişəni adlandırır və bu, prioritet mübahisələrini sənədi oxumaqdan daha tez həll edir.

Yoxlama qəsdən iki müştəri işlədir. Standart kitabxana sorğusu marşrutu və etibar zəncirini sübut edir, endirmə isə pip-in öz konfiqurasiyasının onlarla razılaşdığını sübut edir. Birinci uğur qazanıb ikinci uğursuz olduqda, fərq şəbəkədə deyil, pip-in içindədir.

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