پروکسی کے پیچھے 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