બે જુદી ખામીઓ એ જ 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
What you seeFirst commandRepair
hostname message inside vendored TLS framespython3 -m pip --versionupgrade the client
certificate verify failed after the tunnelcurl -x http://proxy.corp.internal:8080 --head https://pypi.org/simple/trust the corporate root
connection refused or HTTP 407env | grep -i -E 'proxy|no_proxy'correct host, port or credentials

સંબંધિત લેખો