प्रोक्सी पछाडि pip check_hostname त्रुटि: 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