ಪ್ರಾಕ್ಸಿ ಹಿಂದೆ pip check_hostname ದೋಷ: pip ಅಥವಾ ಸುರಂಗ?
ಪ್ರಾಕ್ಸಿ ಹಿಂದೆ ಎರಡು ವಿಭಿನ್ನ ವೈಫಲ್ಯಗಳು ಒಂದೇ 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
| What you see | First command | Repair |
|---|---|---|
| hostname message inside vendored TLS frames | python3 -m pip --version | upgrade the client |
| certificate verify failed after the tunnel | curl -x http://proxy.corp.internal:8080 --head https://pypi.org/simple/ | trust the corporate root |
| connection refused or HTTP 407 | env | grep -i -E 'proxy|no_proxy' | correct host, port or credentials |