ਟਰਮੀਨਲ ਵਿੱਚ ਡਾਊਨਲੋਡ ਕੰਮ ਕਰਦੇ ਹਨ, ਪਰ VPN ਉੱਤੇ VS Code ਐਕਸਟੈਂਸ਼ਨ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ
ਕੰਟੇਨਰ ਵਿੱਚ curl ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਐਕਸਟੈਂਸ਼ਨ ਫਿਰ ਵੀ ਇੰਸਟਾਲ ਨਹੀਂ ਹੁੰਦਾ। ਪ੍ਰੌਕਸੀ ਸੈਟਿੰਗਾਂ ਕਾਪੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਥਾਨਕ ਐਡੀਟਰ ਅਤੇ ਦੂਰਲੇ ਵਾਤਾਵਰਣ ਦੀ ਤੁਲਨਾ ਕਰੋ।
ਕੰਟੇਨਰ ਦੇ ਟਰਮੀਨਲ ਵਿੱਚ ਸਫਲ ਹੋਣ ਵਾਲੇ ਡਾਊਨਲੋਡ ਉਸ ਟਰਮੀਨਲ ਦੇ ਵਾਤਾਵਰਣ ਦਾ ਅਸਲ ਸਬੂਤ ਹਨ। ਉਹ ਐਡੀਟਰ ਪ੍ਰਕਿਰਿਆ, ਐਕਸਟੈਂਸ਼ਨ ਇੰਸਟਾਲਰ ਜਾਂ ਉਸ ਬਾਈਨਰੀ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੇ ਜੋ ਐਕਸਟੈਂਸ਼ਨ ਬਾਅਦ ਵਿੱਚ ਲਿਆਉਂਦਾ ਹੈ। ਉਨ੍ਹਾਂ ਤਿੰਨਾਂ ਵਿਚਕਾਰ ਪ੍ਰੌਕਸੀ ਵੇਰੀਏਬਲ ਕਾਪੀ ਕਰਨਾ ਇੱਕ ਫੇਲ੍ਹ ਹੋਈ ਬੇਨਤੀ ਨੂੰ ਅਸੰਬੰਧਿਤ ਸੋਧਾਂ ਦੀ ਪੂਰੀ ਦੁਪਹਿਰ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਦੋ ਵਾਤਾਵਰਣ ਆਮ ਤੌਰ 'ਤੇ ਠੀਕ ਇੱਕ ਗੱਲ ਵਿੱਚ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ। ਉਹ ਗੱਲ ਲੱਭਣਾ ਪ੍ਰੌਕਸੀ ਦਸਤਾਵੇਜ਼ ਦੋ ਵਾਰ ਪੜ੍ਹਨ ਨਾਲੋਂ ਤੇਜ਼ ਹੈ।
ਕਿਹੜੀ ਪ੍ਰਕਿਰਿਆ ਨੇ ਫੇਲ੍ਹ ਬੇਨਤੀ ਕੀਤੀ
ਇੱਕ ਇੰਸਟਾਲ ਦੌਰਾਨ ਤਿੰਨ ਬੇਨਤੀਆਂ ਫੇਲ੍ਹ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਹਰ ਇੱਕ ਦੀ ਆਪਣੀ ਨੈੱਟਵਰਕ ਪਛਾਣ ਹੈ। ਐਡੀਟਰ Marketplace ਤੋਂ ਮੈਟਾਡੇਟਾ ਅਤੇ ਪੈਕੇਜ URL ਮੰਗਦਾ ਹੈ, ਫਿਰ ਪੈਕੇਜ ਡਾਊਨਲੋਡ ਕਰਦਾ ਹੈ। ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਐਕਸਟੈਂਸ਼ਨ ਹੋਸਟ ਅਜਿਹਾ ਕੋਡ ਚਲਾਉਂਦਾ ਹੈ ਜੋ ਭਾਸ਼ਾ ਸਰਵਰ ਜਾਂ ਆਪਣੀ ਬਾਈਨਰੀ ਲਿਆ ਸਕਦਾ ਹੈ। ਕਿਹੜਾ ਪੜਾਅ ਟੁੱਟਾ, ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਪ੍ਰੌਕਸੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਗਲਤੀ ਦੀ ਸਤ੍ਹਾ ਉਸ ਪੜਾਅ ਦਾ ਨਾਮ ਘੱਟ ਹੀ ਲੈਂਦੀ ਹੈ।
ਕੰਮ ਕਰਦਾ ਟਰਮੀਨਲ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਕੰਟੇਨਰ ਇੰਟਰਨੈੱਟ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ, ਇਹ ਨਹੀਂ ਕਿ ਐਡੀਟਰ ਪਹੁੰਚ ਸਕਦਾ ਹੈ। ਐਕਸਟੈਂਸ਼ਨ ਲੌਗ ਵਿੱਚ ਉਹ ਆਖਰੀ URL ਪੜ੍ਹੋ ਜੋ ਉਸਨੇ ਅਜ਼ਮਾਇਆ। ਉੱਥੇ ਨਾਮ ਦਿੱਤਾ ਹੋਸਟ ਪ੍ਰਕਿਰਿਆ ਅਤੇ ਉਸ ਉੱਤੇ ਲਾਗੂ ਨੀਤੀ ਦੀ ਪਛਾਣ ਕਰਦਾ ਹੈ।
ਸਥਾਨਕ ਐਡੀਟਰ ਅਤੇ ਦੂਰਲਾ ਕੰਟੇਨਰ ਦੋ ਵਾਤਾਵਰਣ ਹਨ
ਦੂਰਲੇ ਵਰਕਸਪੇਸ ਵਿੱਚ ਐਕਸਟੈਂਸ਼ਨ ਉਸ ਪਾਸੇ ਚੱਲਦਾ ਹੈ ਜਿਸਦਾ ਐਲਾਨ ਉਸਦੀ ਕਿਸਮ ਕਰਦੀ ਹੈ। ਇੰਟਰਫੇਸ ਐਕਸਟੈਂਸ਼ਨ ਸਥਾਨਕ ਐਡੀਟਰ ਕੋਲ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਵਰਕਸਪੇਸ ਐਕਸਟੈਂਸ਼ਨ ਕੰਟੇਨਰ ਵਿੱਚ ਚੱਲਦੇ ਹਨ। ਇੱਕ ਵਿੱਚ ਸੈੱਟ ਪ੍ਰੌਕਸੀ ਦੂਜੇ ਲਈ ਅਦਿੱਖ ਹੈ, ਅਤੇ ਮੁੜ-ਨਿਰਮਾਣ ਕੰਟੇਨਰ ਦਾ ਵਾਤਾਵਰਣ ਉਸਦੀ ਕੌਂਫਿਗਰੇਸ਼ਨ ਫਾਈਲ ਤੋਂ ਬਣਾਉਂਦਾ ਹੈ, ਤੁਹਾਡੇ ਵੱਲੋਂ ਸ਼ੈੱਲ ਵਿੱਚ ਨਿਰਯਾਤ ਕੀਤੇ ਤੋਂ ਨਹੀਂ। ਇਹ ਵੰਡ ਸਮਝਾਉਂਦੀ ਹੈ ਕਿ ਕਿਉਂ ਉਹੀ ਐਕਸਟੈਂਸ਼ਨ ਲੈਪਟਾਪ ਉੱਤੇ ਇੰਸਟਾਲ ਹੁੰਦਾ ਹੈ ਅਤੇ SSH ਰਾਹੀਂ ਉਸੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ।
ਕੁਝ ਵੀ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਇੰਸਟਾਲੇਸ਼ਨ ਟਿਕਾਣਾ ਪੜ੍ਹੋ। ਜਦੋਂ ਲੌਗ ਦੂਰਲੇ ਇੰਸਟਾਲ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਕੰਟੇਨਰ ਦਾ ਵਾਤਾਵਰਣ ਹੀ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ।
ਪ੍ਰੌਕਸੀ ਉੱਥੇ ਰੱਖੋ ਜਿੱਥੇ ਬੇਨਤੀ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ
ਅਸਲ ਵਿੱਚ HTTP ਪ੍ਰੌਕਸੀ ਚਾਹੁਣ ਵਾਲੇ Dev Container ਲਈ, ਵੇਰੀਏਬਲ ਕੰਟੇਨਰ ਕੌਂਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਮੁੜ-ਨਿਰਮਾਣ ਇਸਨੂੰ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰੇ। ਹੇਠਾਂ ਦਿੱਤਾ ਟੁਕੜਾ ਇਸਨੂੰ ਉਸ ਵਾਤਾਵਰਣ ਲਈ ਸੈੱਟ ਕਰਦਾ ਹੈ। ਪਲੇਸਹੋਲਡਰ ਪਤਾ ਤੁਹਾਡੇ ਆਪਣੇ ਗੇਟਵੇ ਦੀ ਨੁਮਾਇੰਦਗੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਅਪਵਾਦ ਲਾਜ਼ਮੀ ਨਹੀਂ ਹਨ।
"containerEnv": {
"HTTP_PROXY": "http://proxy.corp.example:8080",
"HTTPS_PROXY": "http://proxy.corp.example:8080",
"NO_PROXY": "localhost,127.0.0.1,.internal.example"
}
ਵੇਰੀਏਬਲ ਦਾ ਨਾਮ ਮੰਜ਼ਿਲ ਪ੍ਰੋਟੋਕੋਲ ਦੱਸਦਾ ਹੈ, ਇਸ ਲਈ HTTPS_PROXY ਮੁੱਲ ਕਾਨੂੰਨੀ ਤੌਰ 'ਤੇ http ਨਾਲ ਸ਼ੁਰੂ ਹੋ ਸਕਦਾ ਹੈ। ਸਮਰਥਿਤ ਮੁੜ-ਨਿਰਮਾਣ ਮਾਰਗ ਰਾਹੀਂ ਬਦਲਾਅ ਲਾਗੂ ਕਰੋ ਅਤੇ ਅਪਵਾਦ ਰੱਖੋ, ਕਿਉਂਕਿ ਅੰਦਰੂਨੀ ਹੋਸਟਾਂ ਨੂੰ ਰੋਕਣ ਵਾਲੀ ਪ੍ਰੌਕਸੀ ਕੰਟੇਨਰ ਲਈ ਲੋੜੀਂਦੀਆਂ ਸੇਵਾਵਾਂ ਤੋੜ ਦਿੰਦੀ ਹੈ।
ਭਰੋਸੇ ਦੀਆਂ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਪਹੁੰਚ ਤੋਂ ਵੱਖ ਕਰੋ
ਜੁੜਦੀ ਹੈ ਅਤੇ ਫਿਰ ਸਰਟੀਫਿਕੇਟ ਜਾਂਚ ਦੀ ਗਲਤੀ ਵਾਪਸ ਕਰਦੀ ਹੈ ਅਜਿਹੀ ਪ੍ਰੌਕਸੀ, ਕਨੈਕਸ਼ਨ ਨੂੰ ਨਕਾਰਨ ਵਾਲੀ ਪ੍ਰੌਕਸੀ ਨਾਲੋਂ ਬਾਅਦ ਦੇ ਪੜਾਅ 'ਤੇ ਪਹੁੰਚੀ ਹੈ। ਪਹਿਲੀ ਅਸਫਲਤਾ ਲਈ ਸੰਸਥਾ ਦੀ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਭਰੋਸਾ ਸਮੱਗਰੀ ਬੇਨਤੀ ਕਰਨ ਵਾਲੇ ਵਾਤਾਵਰਣ ਵਿੱਚ ਇੰਸਟਾਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਦੂਜੀ ਲਈ ਪਹੁੰਚਯੋਗ ਪਤਾ ਅਤੇ ਪੋਰਟ ਚਾਹੀਦਾ ਹੈ। ਦੋਵਾਂ ਨੂੰ ਇੱਕ ਸਮੱਸਿਆ ਮੰਨਣ ਨਾਲ ਅਜਿਹਾ ਹੱਲ ਨਿਕਲਦਾ ਹੈ ਜੋ ਕਿਸੇ ਲਈ ਵੀ ਕੰਮ ਨਹੀਂ ਕਰਦਾ।
ਜਾਂਚ ਬੰਦ ਕਰਨਾ, ਜਾਂ ਐਡੀਟਰ ਨੂੰ ਉੱਚ ਅਧਿਕਾਰਾਂ ਨਾਲ ਚਲਾਉਣਾ, ਗੁੰਮ ਪ੍ਰੌਕਸੀ ਜਾਂ ਗੁੰਮ ਭਰੋਸਾ-ਚੇਨ ਦੀ ਮੁਰੰਮਤ ਨਹੀਂ ਹੈ। ਦੋਵੇਂ ਦਿਖਣ ਵਾਲੀ ਗਲਤੀ ਨੂੰ ਚੁੱਪ ਗਲਤੀ ਨਾਲ ਬਦਲਦੇ ਹਨ। ਫਿਰ ਉਹੀ ਐਕਸਟੈਂਸ਼ਨ ਦੁਬਾਰਾ ਅਜ਼ਮਾਓ ਅਤੇ ਅਗਲਾ ਫੇਲ੍ਹ ਹੋਣ ਵਾਲਾ URL ਨੋਟ ਕਰੋ।
env | grep -iE '^(http|https|no)_proxy='
code --install-extension ms-python.python --force
ਯਾਦ ਰੱਖੋ ਕਿ ਵਰਕਸਪੇਸ ਦੇ ਕਿਸ ਪਾਸੇ ਨੇ ਉਹ URL ਪੈਦਾ ਕੀਤਾ। ਪੜਾਅ, ਹੋਸਟ ਅਤੇ ਪਾਸੇ ਦਾ ਨਾਮ ਦੇਣ ਵਾਲੀ ਛੋਟੀ ਨੋਟ ਕਿਸੇ ਵੱਲੋਂ ਬਦਲੀਆਂ ਸੈਟਿੰਗਾਂ ਦੀ ਸੂਚੀ ਨਾਲੋਂ ਵੱਧ ਕੀਮਤੀ ਹੈ, ਕਿਉਂਕਿ ਅਗਲਾ ਵਿਅਕਤੀ ਉਹੀ ਨੋਟ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ।