ப்ராக்ஸிக்குப் பின்னால் 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