प्रॉक्सी के पीछे 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