ਕੀ ਪੁਰਾਣਾ openfortivpn .deb ਤੁਹਾਡੇ Raspberry Pi ਲਈ ਸਹੀ ਹੈ?

ਫੋਰਮ ਦਾ ਜਵਾਬ ਤੁਹਾਨੂੰ ਪੂਰਾ ਫਾਈਲਨਾਮ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਫਾਈਲਨਾਮ ਹੱਲ ਵਰਗਾ ਲੱਗਦਾ ਹੈ: ਇੱਕ .deb, ਇੱਕ ਕਮਾਂਡ, ਹੋ ਗਿਆ। ਉਹ ਸਟਰਿੰਗ ਅਸਲ ਵਿੱਚ ਜੋ ਐਨਕੋਡ ਕਰਦੀ ਹੈ ਉਹ ਹੈ ਪੈਕੇਜ ਵਰਜ਼ਨ, CPU ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਉਹ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਸੂਟ ਜਿਸ ਦੇ ਵਿਰੁੱਧ ਇਹ ਉਸ ਦਿਨ ਬਣਾਇਆ ਗਿਆ ਸੀ ਜਿਸ ਦਿਨ ਕਿਸੇ ਨੇ ਪੋਸਟ ਲਿਖੀ ਸੀ। ਉਨ੍ਹਾਂ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਤੁਹਾਡੇ ਡੈਸਕ 'ਤੇ ਰੱਖੇ ਬੋਰਡ ਦਾ ਆਪਣੇ ਆਪ ਵਰਣਨ ਨਹੀਂ ਕਰਦਾ। ਪੁਰਾਣਾ ਡਾਊਨਲੋਡ ਇੱਕ ਮਸ਼ੀਨ ਦੀ ਸਥਿਤੀ ਦਾ ਸਨੈਪਸ਼ਾਟ ਹੈ, ਤੁਹਾਡੇ ਲਈ ਸਥਾਪਨਾ ਯੋਜਨਾ ਨਹੀਂ।

ਫਾਈਲਨਾਮ ਚੁੱਪਚਾਪ ਕੀ ਪਿੰਨ ਕਰਦਾ ਹੈ

openfortivpn_1.17.0-1_armhf.deb ਵਰਗਾ ਨਾਮ ਸੱਜੇ ਤੋਂ ਖੱਬੇ ਪੜ੍ਹੋ। ਪ੍ਰਤਿਅਯ ਉਹ ਆਰਕੀਟੈਕਚਰ ਹੈ ਜਿਸ ਲਈ ਬਾਈਨਰੀ ਕੰਪਾਇਲ ਕੀਤੀ ਗਈ ਸੀ, ਵਿਚਕਾਰਲਾ ਖੇਤਰ ਅਪਸਟ੍ਰੀਮ ਅਤੇ ਪੈਕੇਜਿੰਗ ਸੋਧ ਹੈ, ਅਤੇ ਅਣਕਿਹਾ ਚੌਥਾ ਖੇਤਰ ਉਸ ਸੂਟ ਦਾ ਲਾਇਬ੍ਰੇਰੀ ਸਮੂਹ ਹੈ ਜਿਸ ਵਿੱਚ ਇਹ ਬਣਾਇਆ ਗਿਆ ਸੀ।

64-ਬਿੱਟ Raspberry Pi OS ਸਥਾਪਨਾ 'ਤੇ ਸਿਸਟਮ ਆਰਕੀਟੈਕਚਰ arm64 ਹੈ, ਇਸ ਲਈ dpkg -i ਆਰਕੀਟੈਕਚਰ ਨਾ ਮਿਲਣ ਕਾਰਨ armhf ਪੈਕੇਜ ਨੂੰ ਰੱਦ ਕਰਦਾ ਹੈ। ਜਿੱਥੇ multiarch ਸਥਾਪਨਾ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ ਉੱਥੇ ਵੀ, ਬਾਈਨਰੀ ਉਸ ਰਿਲੀਜ਼ ਦੇ ਲਾਇਬ੍ਰੇਰੀ ਵਰਜ਼ਨਾਂ ਦੀ ਉਮੀਦ ਕਰਦੀ ਹੈ ਜਿਸ ਦੇ ਵਿਰੁੱਧ ਇਹ ਬਣੀ ਸੀ, ਅਤੇ ਨਵਾਂ ਬੇਸ ਸਿਸਟਮ ਉਹ ਹੁਣ ਨਹੀਂ ਦੇ ਸਕਦਾ। ਨਤੀਜਾ ਇੱਕ ਸਥਾਪਿਤ ਪੈਕੇਜ ਹੈ ਜਿਸਦਾ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਇਹ ਉਹ ਅਸਫਲਤਾ ਹੈ ਜਿਸਨੂੰ ਲੋਕ ਆਮ ਤੌਰ 'ਤੇ ਕਲਾਇੰਟ ਖੁਦ ਖਰਾਬ ਹੋਣ ਵਜੋਂ ਗਲਤ ਸਮਝਦੇ ਹਨ।

ਬੋਰਡ ਦਾ ARM ਡਿਵਾਈਸ ਹੋਣਾ ARM ਪੈਕੇਜ ਨੂੰ ਢੁਕਵਾਂ ਨਹੀਂ ਬਣਾਉਂਦਾ। ਆਰਕੀਟੈਕਚਰ ਇੱਕ ਧੁਰਾ ਹੈ; ਰਿਲੀਜ਼ ਅਤੇ ABI ਬਾਕੀ ਦੋ ਹਨ, ਅਤੇ ਉਹ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਅਸਫਲ ਹੁੰਦੇ ਹਨ।

ਡਾਊਨਲੋਡ ਲਿੰਕ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਨੂੰ ਪੁੱਛੋ

ਹਰ ਸੰਭਾਲਿਆ ਚੈਨਲ ਤੁਹਾਨੂੰ ਦੱਸ ਸਕਦਾ ਹੈ ਕਿ ਇਹ ਹੁਣ ਕੀ ਸਥਾਪਤ ਕਰੇਗਾ। ਕੋਈ ਵੀ ਫਾਈਲ ਟ੍ਰਾਂਸਫਰ ਵਿਚਾਰਨ ਤੋਂ ਪਹਿਲਾਂ ਟਾਰਗੇਟ ਮਸ਼ੀਨ 'ਤੇ, ਇਸ ਦੁਆਰਾ ਅਸਲ ਵਿੱਚ ਵਰਤੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਰਿਪੋਜ਼ਟਰੀਆਂ ਨਾਲ ਕੁਐਰੀ ਚਲਾਓ।

cat /etc/os-release
dpkg --print-architecture
apt-cache policy openfortivpn

ਵਰਜ਼ਨ ਅਤੇ ਰਿਪੋਜ਼ਟਰੀ ਨਾਮ ਵਾਲੀ ਉਮੀਦਵਾਰ ਲਾਈਨ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਕੋਲ ਇਸ ਸਿਸਟਮ ਲਈ ਪਹਿਲਾਂ ਹੀ ਬਿਲਡ ਹੈ। ਉਮੀਦਵਾਰ ਨਾ ਹੋਣਾ, ਜਾਂ ਤੁਹਾਡੇ ਦੁਆਰਾ ਵਰਤਣ ਦੀ ਯੋਜਨਾ ਨਾ ਰੱਖੇ ਸੂਟ ਤੋਂ ਉਮੀਦਵਾਰ ਆਉਣਾ, ਸੌਫਟਵੇਅਰ ਕਿਤੇ ਮੌਜੂਦ ਹੋਣ ਬਾਰੇ ਨਹੀਂ, ਤੁਹਾਡੇ ਸਰੋਤਾਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਹੈ।

ਜੇ ਮੈਟਾਡੇਟਾ ਰਿਫ੍ਰੈਸ਼ ਅਸਫਲ ਹੋਵੇ, ਤਾਂ ਉਸ ਅਸਫਲਤਾ ਨੂੰ ਪੈਕੇਜ ਦੇ ਸਵਾਲ ਤੋਂ ਵੱਖ ਰੱਖੋ। ਨਾਮ ਰਿਜ਼ੋਲਿਊਸ਼ਨ, ਰਿਪੋਜ਼ਟਰੀ ਟ੍ਰਾਂਸਪੋਰਟ, ਗੁੰਮ Release ਦਸਤਖਤ ਅਤੇ ਜੀਵਨ ਦੇ ਅੰਤ 'ਤੇ ਸੂਟ—ਸਭ ਕਲਾਇੰਟ ਸ਼ਾਮਲ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ apt update ਤੋੜ ਦਿੰਦੇ ਹਨ। ਸਰੋਤ ਠੀਕ ਕਰਨਾ VPN ਕਲਾਇੰਟ ਚੁਣਨ ਤੋਂ ਵੱਖਰਾ ਕੰਮ ਹੈ, ਅਤੇ ਦੋਵਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਹੀ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਲੋਕ ਮੌਜੂਦਾ ਸਿਸਟਮ ਨੂੰ ਪੁਰਾਣੀ ਰਿਲੀਜ਼ ਵੱਲ ਦਿਖਾਉਂਦੇ ਹਨ।

apt ਕੀ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਡਾਊਨਲੋਡ ਕੀਤੀ ਫਾਈਲ ਕੀ ਨਹੀਂ ਪ੍ਰਾਪਤ ਕਰਦੀ

ਆਮ ਸਥਾਪਨਾ ਦਸਤਖਤਾਂ ਦੀ ਲੜੀ ਦੀ ਪਾਲਣਾ ਕਰਦੀ ਹੈ: ਆਰਕਾਈਵ ਆਪਣੀ ਇੰਡੈਕਸ 'ਤੇ ਦਸਤਖਤ ਕਰਦਾ ਹੈ, ਇੰਡੈਕਸ ਹਰ ਪੈਕੇਜ ਲਈ ਹੈਸ਼ ਰੱਖਦੀ ਹੈ, ਅਤੇ ਪੈਕੇਜ ਨੂੰ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਆਰਕਾਈਵ ਪ੍ਰਮਾਣੀਕਰਨ ਹਵਾਲਾ ਉਸ ਲੜੀ ਨੂੰ ਹਰ ਵਿਅਕਤੀਗਤ ਫਾਈਲ ਨਾਲ ਜੁੜੇ ਦਸਤਖਤ ਦੀ ਜਾਂਚ ਦੇ ਵਿਚਾਰ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ।

ਪੁਰਾਣੇ HTTP ਲਿੰਕ ਤੋਂ ਸੰਭਾਲੀ ਫਾਈਲ ਵਿੱਚ ਇਸਦਾ ਕੁਝ ਵੀ ਨਹੀਂ ਹੈ। ਇਹ ਰਿਪੋਜ਼ਟਰੀ ਪਛਾਣ ਤੋਂ ਬਿਨਾਂ ਆਉਂਦੀ ਹੈ, ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਵੱਲੋਂ ਕਲਾਇੰਟ ਨੂੰ ਪੈਚ ਕਰਨ 'ਤੇ ਅੱਪਡੇਟ ਨਹੀਂ ਹੁੰਦੀ, ਅਤੇ ਇਸਨੂੰ ਬਦਲਣ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਕਿਸਦੀ ਹੈ ਇਹ ਕੋਈ ਦਰਜ ਨਹੀਂ ਕਰਦਾ। ਪਿੰਨ ਕੀਤੇ ਆਰਟੀਫੈਕਟ ਵਾਲੇ ਪ੍ਰਬੰਧਕ ਲਈ ਇਹ ਅਜੇ ਵੀ ਜਾਇਜ਼ ਚੋਣ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਚੋਣ ਨਾਲ ਮਾਲਕ, ਕਿਤੇ ਦਰਜ ਚੈਕਸਮ ਅਤੇ ਅਗਲੇ ਸੁਰੱਖਿਆ ਅੱਪਡੇਟ ਦੀ ਯੋਜਨਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।

ਪੁਰਾਣੀ ਹਦਾਇਤ ਚੱਲਦੀ ਰੱਖਣ ਲਈ ਦਸਤਖਤ ਦੀਆਂ ਗਲਤੀਆਂ ਦਬਾਉਣਾ ਜਾਂ TLS ਪ੍ਰਮਾਣਿਕਤਾ ਬੰਦ ਕਰਨਾ ਪ੍ਰਕਿਰਿਆ ਦਾ ਉਹ ਇੱਕੋ ਹਿੱਸਾ ਹਟਾ ਦਿੰਦਾ ਹੈ ਜੋ ਕੁਝ ਜਾਂਚ ਰਿਹਾ ਸੀ। ਇਸਦੀ ਬਜਾਏ ਅਸਫਲ ਹੋ ਰਹੀ ਜਾਂਚ ਨੂੰ ਬਹਾਲ ਕਰੋ।

ਕਲਾਇੰਟ ਸਥਾਪਤ ਕਰੋ, ਫਿਰ ਕਨੈਕਸ਼ਨ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਡੀਬੱਗ ਕਰੋ

ਜਦੋਂ ਸੰਭਾਲਿਆ ਉਮੀਦਵਾਰ ਮੌਜੂਦ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਆਮ ਸਮੀਖਿਆ ਕੀਤੇ ਲੈਣ-ਦੇਣ ਰਾਹੀਂ ਸਥਾਪਤ ਕਰੋ ਅਤੇ ਪੈਕੇਜ ਮੈਨੇਜਰ ਨੂੰ ਕੀ ਕੀਤਾ ਦਰਜ ਕਰਨ ਦਿਓ।

ਜੇ ਤੈਨਾਤੀ ਨੂੰ ਸੱਚਮੁੱਚ ਅਪਸਟ੍ਰੀਮ ਬਿਲਡ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਪ੍ਰੋਜੈਕਟ ਦੀਆਂ ਮੌਜੂਦਾ ਬਿਲਡ ਹਦਾਇਤਾਂ ਦੀ ਪਾਲਣਾ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਹੁਣ ਤੁਹਾਡੇ ਦੁਆਰਾ ਸੰਭਾਲੇ ਜਾਣ ਵਾਲੇ ਸੌਫਟਵੇਅਰ ਵਜੋਂ ਲਓ: ਵਿਕਾਸ ਪੈਕੇਜ, pkg-config, TLS ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਹੈਡਰ ਅਤੇ PPP ਡੈਮਨ ਅਸਲ ਨਿਰਭਰਤਾਵਾਂ ਹਨ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਤੁਹਾਨੂੰ ਲੋੜੀਂਦੀ ਹਟਾਉਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵੀ।

ਸਥਾਪਨਾ ਸਿਰਫ ਸਥਾਨਕ ਸੌਫਟਵੇਅਰ ਪੜਾਅ ਹੈ। ਗੇਟਵੇ ਨੂੰ ਕਲਾਇੰਟ ਦਾ ਪ੍ਰੋਟੋਕਾਲ ਅਤੇ ਪ੍ਰਮਾਣੀਕਰਨ ਪ੍ਰਵਾਹ ਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਕਲਾਇੰਟ ਨੂੰ ਗੇਟਵੇ ਵੱਲੋਂ ਪੇਸ਼ ਕੀਤੇ ਸਰਟੀਫਿਕੇਟ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਟਨਲ ਨੂੰ ਕੰਮ ਕਰਨ ਵਾਲੀ PPP ਪਰਤ ਦੇ ਨਾਲ ਰੂਟ ਅਤੇ ਰਿਜ਼ਾਲਵਰ ਮਾਲਕ ਦੀ ਲੋੜ ਹੈ। ਪੂਰਾ ਹੋਇਆ ਪੈਕੇਜ ਲੈਣ-ਦੇਣ ਇਸ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਗੇਟਵੇ ਖਾਤਾ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਜਾਂ ਨਿੱਜੀ ਰੇਂਜ ਪਹੁੰਚਯੋਗ ਹੈ। ਇੰਸਟਾਲਰ ਦੁਬਾਰਾ ਚਲਾਉਣ ਦੀ ਬਜਾਏ ਹਰ ਪਰਤ ਨੂੰ ਉੱਥੇ ਹੀ ਜਾਂਚੋ ਜਿੱਥੇ ਇਹ ਟੁੱਟਦੀ ਹੈ।

ਪੁਰਾਣੇ ਫਾਈਲਨਾਮ ਦੀ ਥਾਂ ਲੈਣ ਵਾਲੀ ਯੋਜਨਾ

ਪਹਿਲਾਂ ਪਲੇਟਫਾਰਮ ਪਛਾਣ ਲਿਖੋ: OS ਰਿਲੀਜ਼, ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਵਰਤੀ ਜਾ ਰਹੀ ਸਰੋਤ ਸੂਚੀ। ਫਿਰ ਪੈਕੇਜ ਕਿੱਥੋਂ ਆਉਂਦਾ ਹੈ ਉਸ ਅਧਿਕ੍ਰਿਤ ਥਾਂ ਦਾ ਨਾਮ ਦਿਓ—ਭਾਵੇਂ ਉਹ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਰਿਪੋਜ਼ਟਰੀ ਹੋਵੇ, ਪਿੰਨ ਕੀਤੀ ਕੁੰਜੀ ਵਾਲੀ ਵਿਕਰੇਤਾ ਰਿਪੋਜ਼ਟਰੀ ਹੋਵੇ, ਜਾਂ ਤੁਸੀਂ ਖੁਦ ਕੰਪਾਇਲ ਅਤੇ ਪੈਕੇਜ ਕਰੋ ਉਹ ਬਿਲਡ ਹੋਵੇ।

ਅੰਤ ਵਿੱਚ ਸੰਭਾਲਕਰਤਾ ਅਤੇ ਅੱਪਡੇਟ ਮਾਰਗ ਦਾ ਨਾਮ ਦਿਓ। ਜਿਸ Pi 'ਤੇ ਅਜਿਹਾ ਕਲਾਇੰਟ ਚੱਲ ਰਿਹਾ ਹੈ ਜਿਸਦਾ ਕੋਈ ਮਾਲਕ ਨਹੀਂ, ਉਹ ਪਹਿਲੇ ਲਾਇਬ੍ਰੇਰੀ ਅੱਪਡੇਟ ਤੱਕ ਚੱਲੇਗਾ, ਅਤੇ ਫਿਰ ਉਸੇ ਸਮੱਸਿਆ ਵਾਲਾ ਕੋਈ ਵਿਅਕਤੀ ਉਹੀ ਫੋਰਮ ਥ੍ਰੈਡ ਦੁਬਾਰਾ ਲੱਭ ਲਵੇਗਾ।

ਸੁਧਾਰਿਆ ਹੋਇਆ ਵਿਸ਼ਵਾਸ ਇੱਕ ਲਾਈਨ ਵਿੱਚ ਕਹਿਣ ਜਿੰਨਾ ਸਰਲ ਹੈ: ਪੁਰਾਣਾ ਪੈਕੇਜ ਇਸ ਗੱਲ ਦਾ ਸਬੂਤ ਹੈ ਕਿ ਕਲਾਇੰਟ ਕਦੇ ਬਣਿਆ ਅਤੇ ਚੱਲਿਆ, ਇਸ ਗੱਲ ਦਾ ਸਬੂਤ ਨਹੀਂ ਕਿ ਇਹ ਅੱਜ ਰਾਤ ਤੁਹਾਡੇ ਬੋਰਡ 'ਤੇ ਸਥਾਪਤ ਹੋਵੇਗਾ। ਤਿੰਨੇ ਧੁਰੇ ਜਾਂਚੋ, ਫਿਰ ਅਜਿਹਾ ਚੈਨਲ ਚੁਣੋ ਜਿਸਨੂੰ ਤੁਸੀਂ ਅੱਪਡੇਟ ਕਰਦੇ ਰਹਿ ਸਕੋ।