प्रॉक्सीमागील 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