പ്രോക്സിക്ക് പിന്നിൽ 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