pip check_hostname սխալը վստահված սերվերի հետևում. pip, թե՞ թունել

Երկու տարբեր խափանումներ տպում են նույն pip հետագիծը, և մեկի համար հարմար վերանորոգումը վատթարացնում է մյուսը։ Թունելավորված հոսթը անվանելու համար չափազանց հին հաճախորդին անհրաժեշտ է թարմացում։ Երթևեկությունը վերաենթագրող վստահված սերվերին անհրաժեշտ է վստահելի արմատային վկայագիր, ոչ թե տարբերակի իջեցում։ Որոշեք, թե այս երկուսից որն ունեք, նախքան վստահված սերվերի փոփոխականը խմբագրելը, որովհետև ուղիները տանում են հակառակ ուղղություններով։

Կարդացեք վերջին կադրերը՝ նախքան կարգավորումներին դիպչելը

Այն տեղը, որտեղ ավարտվում է հետագիծը, ասում է, թե որ շերտը հանձնվեց։ Եթե փակող կադրերը գտնվում են pip-ի հետ եկող urllib3 TLS կոդի ներսում, և տեքստը բողոքում է հոսթանունից, ապա հաճախորդի գրադարանը չի կարողացել ավարտել ստուգման քայլը, և դա շատ ավելի հաճախ տարբերակի խնդիր է, քան վկայագրի խնդիր։ Եթե տեքստը փոխարենը հայտնում է մերժված կապի, չլուծված վստահված սերվերի անվան կամ HTTP 407 սխալի մասին, ապա թունելի վերջնակետն է մեղավոր, և ոչ մի թարմացում դա չի փոխի։

Գրառեք pip-ի տարբերակը և վստահված սերվերի փոփոխականները նույն shell-ում, որը ձախողվում է։ Թունելի բարձրանալուց առաջ բացված shell-ը կրում է տարբեր արժեքներ, քան դրանից հետո բացվածը, և նրանց միջև տարբերությունը հաճախ ամբողջ ախտորոշումն է։

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-ի սեփական կարգավորման մեջ, երբ այն պետք է գոյատևի ընթացիկ shell-ից, ապա կարդացեք, թե 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