ਕਈ ਸਕ੍ਰਿਪਟਾਂ ਵਾਲੀ ਚੇਤਾਵਨੀ ਸ਼ਡਿਊਲਿੰਗ ਦੀ ਸ਼ਿਕਾਇਤ ਵਾਂਗ ਸੁਣਦੀ ਹੈ, ਇਸ ਲਈ ਸਪਸ਼ਟ ਹੱਲ ਇਹ ਹੈ ਕਿ ਲਾਈਨਾਂ ਨੂੰ ਤਦ ਤੱਕ ਮੁੜ-ਕ੍ਰਮਬੱਧ ਕਰੋ ਜਦੋਂ ਤੱਕ ਉਹ ਗਾਇਬ ਨਾ ਹੋ ਜਾਵੇ। ਪਰ ਇਹ ਸ਼ਡਿਊਲਿੰਗ ਦੀ ਸ਼ਿਕਾਇਤ ਨਹੀਂ ਹੈ। ਬਾਅਦ ਦੀ --up ਪਰਿਭਾਸ਼ਾ ਉਸ ਪੜਾਅ ਲਈ ਪਹਿਲਾਂ ਹੀ ਸੰਭਾਲੀ ਕਮਾਂਡ ਨੂੰ ਬਦਲ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਪਾਰਸਰ ਇਹੀ ਕਹਿੰਦਾ ਹੈ, ਭਾਵ ਤੁਹਾਡੀਆਂ ਦੋ ਸਕ੍ਰਿਪਟਾਂ ਵਿੱਚੋਂ ਠੀਕ ਇੱਕ ਹੀ ਕਦੇ ਚੱਲੀ ਹੈ। ਦੂਜੀ ਉਸਦੇ ਪਿੱਛੇ ਕਤਾਰ ਵਿੱਚ ਨਹੀਂ ਹੈ; ਉਹ ਚਲੀ ਗਈ ਹੈ।

ਇਸ ਲਈ ਚੇਤਾਵਨੀ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ, ਭਾਵੇਂ ਉਹ ਘਾਤਕ ਨਾ ਹੋਵੇ: ਇਹ ਜਿਸਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰਦੀ ਹੈ ਉਹ DNS ਅੱਪਡੇਟ ਜਾਂ ਰੂਟ ਬਦਲਾਅ ਹੈ ਜੋ ਚੁੱਪਚਾਪ ਹੋਣਾ ਬੰਦ ਹੋ ਗਿਆ।

ਚੇਤਾਵਨੀ ਕ੍ਰਮ ਬਾਰੇ ਨਹੀਂ ਹੈ

OpenVPN up ਪੜਾਅ ਲਈ ਇੱਕੋ ਵਰਤੋਂਕਾਰ-ਸਕ੍ਰਿਪਟ ਕਮਾਂਡ ਸੰਭਾਲਦਾ ਹੈ। ਜਦੋਂ ਪਾਰਸਰ ਨੂੰ ਕੋਈ ਹੋਰ ਪਰਿਭਾਸ਼ਾ ਮਿਲਦੀ ਹੈ, ਪਰੋਫਾਈਲ, ਸ਼ਾਮਲ ਕੀਤੀ ਫਾਈਲ ਜਾਂ ਕਮਾਂਡ ਲਾਈਨ ਤੋਂ, ਤਾਂ ਉਹ ਪਹਿਲਾਂ ਰੱਖੀ ਚੀਜ਼ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ ਅਤੇ ਚੇਤਾਵਨੀ ਦਿੰਦਾ ਹੈ। ਕੁਝ ਵੀ ਜੋੜਿਆ ਨਹੀਂ ਜਾਂਦਾ, ਕੁਝ ਵੀ ਦੋ ਵਾਰ ਨਹੀਂ ਚੱਲਦਾ, ਅਤੇ ਕ੍ਰਮ ਦਾ ਕੋਈ ਸਵਾਲ ਨਹੀਂ ਹੈ। ਜੋ ਕਮਾਂਡ ਬਚਦੀ ਹੈ ਉਹੀ ਪਾਰਸਰ ਨੇ ਆਖਰੀ ਵਾਰ ਦੇਖੀ ਸੀ, ਇਸ ਲਈ ਲਾਈਨ ਹਿਲਾਉਣ ਨਾਲ ਜੇਤੂ ਬਦਲ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਦੂਜੀ ਸਕ੍ਰਿਪਟ ਮਰੀ ਰਹਿੰਦੀ ਹੈ।

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

ਅਸਲ ਲਾਂਚ ਵਿੱਚ ਦੋਵੇਂ ਪਰਿਭਾਸ਼ਾਵਾਂ ਲੱਭੋ

ਤੁਹਾਡੇ ਸੰਪਾਦਿਤ ਪਰੋਫਾਈਲ ਤੋਂ ਨਹੀਂ, ਸਗੋਂ ਡੈਮਨ ਨੂੰ ਅਸਲ ਵਿੱਚ ਕੀ ਮਿਲਿਆ ਉਸ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ps -ef ਅਤੇ ਯੂਨਿਟ ਦਾ ExecStart ਕਮਾਂਡ ਲਾਈਨ ਦਿਖਾਉਂਦੇ ਹਨ, ਜਿਸ ਵਿੱਚ ਕੰਟੇਨਰ ਦਾਖਲਾ ਬਿੰਦੂ ਜਾਂ ਰੈਪਰ ਤੋਂ --up ਜੁੜ ਸਕਦਾ ਹੈ; ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਦੀ init ਫਾਈਲ ਵੀ ਇਹੀ ਕਰ ਸਕਦੀ ਹੈ। systemctl cat openvpn-server@server ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਸੇਵਾ ਆਪ ਕੀ ਜੋੜਦੀ ਹੈ, ਅਤੇ ਕਨਫਿਗਰੇਸ਼ਨ ਡਾਇਰੈਕਟਰੀ ਉੱਤੇ ਪੁਨਰਾਵਰਤੀ grep ਫਾਈਲ-ਪੱਧਰੀ ਪਰਿਭਾਸ਼ਾਵਾਂ ਲੱਭਦਾ ਹੈ। ਨਕਲਾਂ ਆਮ ਤੌਰ ਉੱਤੇ ਵੱਖਰੀਆਂ ਪਰਤਾਂ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਇੱਕ ਫਾਈਲ ਸੰਪਾਦਿਤ ਕਰਨ ਨਾਲ ਕੁਝ ਨਾ ਬਦਲਣ ਦਾ ਕਾਰਨ ਵੀ ਇਹੀ ਹੈ।

ਸਕ੍ਰਿਪਟ ਨੂੰ ਹੋਰ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਕਾਪੀ ਕਰਨਾ ਜਾਂ ਨਾਮ ਬਦਲਣਾ ਵੀ ਨਿਰਦੇਸ਼ ਨਹੀਂ ਹਟਾਉਂਦਾ। ਪਾਰਸਰ ਫਾਈਲਾਂ ਨਹੀਂ, ਪਰਿਭਾਸ਼ਾਵਾਂ ਗਿਣਦਾ ਹੈ।

ਇੱਕ ਹੀ hook ਕੰਮ ਦਾ ਮਾਲਕ ਹੋਵੇ

ਟਿਕਾਊ ਹੱਲ ਇੱਕੋ ਡਿਸਪੈਚਰ ਹੈ ਜੋ ਦੋਵੇਂ ਕਾਰਵਾਈਆਂ ਸੋਚ-ਸਮਝ ਕੇ ਕ੍ਰਮ ਵਿੱਚ ਚਲਾਉਂਦਾ ਹੈ। set -eu ਵਾਲੀ ਛੋਟੀ shell ਸਕ੍ਰਿਪਟ ਲੋੜੀਂਦਾ ਏਕੀਕਰਣ ਅਤੇ ਫਿਰ ਸਥਾਨਕ ਕਾਰਵਾਈ ਬੁਲਾਉਂਦੀ ਹੈ, ਅਤੇ ਦਲੀਲਾਂ ਦੀਆਂ ਸੀਮਾਵਾਂ ਬਚੀਆਂ ਰਹਿਣ ਲਈ "$@" ਪਾਸ ਕਰਦੀ ਹੈ; ਇਸ ਨਾਲ ਵਿਵਹਾਰ ਇੱਕੋ ਜਾਂਚਯੋਗ ਥਾਂ ਉੱਤੇ ਰਹਿੰਦਾ ਹੈ। ਦਲੀਲਾਂ ਪਾਸ ਕਰਨਾ ਉਨ੍ਹਾਂ ਨੂੰ ਸਿਰਫ਼ ਬਚਾਉਂਦਾ ਹੈ; ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਦੋਵੇਂ ਸਹਾਇਕ ਇੱਕੋ ਇੰਟਰਫੇਸ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਹਰ ਇੱਕ ਦਾ ਇਕਰਾਰਨਾਮਾ ਪੜ੍ਹੋ। ਤੈਅ ਕਰੋ ਕਿ ਅਸਫਲਤਾ ਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਕੀ ਅੰਸ਼ਕ ਤਬਦੀਲੀਆਂ ਵਾਪਸ ਲੈਣੀਆਂ ਹਨ।

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

ਸਫ਼ਾਈ ਸੰਬੰਧਿਤ down ਪੜਾਅ ਦੀ ਹੈ। DNS ਮੁੜ ਲਿਖਣ ਵਾਲੀ ਜਾਂ ਰੂਟ ਜੋੜਨ ਵਾਲੀ up ਕਾਰਵਾਈ ਨੂੰ ਦਸਤਾਵੇਜ਼ੀ ਉਲਟਾਉਣ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਸਿਰਫ਼ ਸ਼ੁਰੂਆਤ ਸੰਭਾਲਣ ਵਾਲਾ ਡਿਸਪੈਚਰ ਅੱਧਾ ਡਿਜ਼ਾਈਨ ਹੈ।

ਸਿਰਫ਼ ਚੁੱਪ ਨਹੀਂ, ਏਕੀਕਰਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

ਦੁਹਰਾਈ ਚੇਤਾਵਨੀ ਹਟਾਉਣਾ ਸੌਖਾ ਹਿੱਸਾ ਹੈ; ਏਕੀਕਰਣ ਨੂੰ ਅਜੇ ਵੀ ਕੰਮ ਕਰਨਾ ਹੈ। ਜੁੜਨ ਤੋਂ ਬਾਅਦ resolvectl status ਨਾਲ ਜਾਂ /etc/resolv.conf ਪੜ੍ਹ ਕੇ ਰਿਜ਼ੋਲਵਰ ਦੀ ਸਥਿਤੀ ਜਾਂਚੋ, ਅਤੇ ip route ਨਾਲ ਰੂਟਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਫਿਰ ਡਿਸਕਨੈਕਟ ਕਰਕੇ ਦੁਬਾਰਾ ਜੁੜੋ, ਕਿਉਂਕਿ ਕਾਹਲੀ ਵਿੱਚ ਜੋੜਿਆ hook ਪਿਛਲੇ ਸੈਸ਼ਨ ਤੋਂ ਕੁਝ ਛੱਡ ਜਾਂਦਾ ਹੈ। journalctl -u openvpn-server@server -b ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਤੁਹਾਡਾ ਡਿਸਪੈਚਰ ਚੱਲਿਆ ਅਤੇ ਕੀ ਛਾਪਿਆ।

hook ਦੇ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਜਿੱਥੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਉੱਥੇ ਹੀ ਰੱਖੋ। script-security ਵਧਾਉਣਾ ਜਾਂ ਡੈਮਨ ਨੂੰ ਵੱਧ ਅਧਿਕਾਰਾਂ ਨਾਲ ਚਲਾਉਣਾ ਬਦਲੇ hook ਲਈ ਹੱਲ ਨਹੀਂ ਹੈ; ਇਹ ਵਧਾਉਂਦਾ ਹੈ ਕਿ ਹਰ ਭਵਿੱਖੀ ਸਕ੍ਰਿਪਟ, ਹਮਲਾਵਰ ਵੱਲੋਂ ਨਾਮ ਦਿੱਤੀ ਸਕ੍ਰਿਪਟ ਵੀ, ਕੀ ਕਰ ਸਕਦੀ ਹੈ।

ਹੱਲ ਸੱਚਾ ਹੋਣ ਦਾ ਸੰਕੇਤ ਲੌਗ ਵਿੱਚ ਚੁੱਪ ਨਹੀਂ ਹੈ। ਉਹ DNS ਜਵਾਬ, ਰੂਟ ਐਂਟਰੀ ਅਤੇ ਸਫ਼ਾਈ ਹਨ, ਜੋ ਦੋ ਮੁੜ-ਕਨੈਕਸ਼ਨਾਂ ਤੋਂ ਬਾਅਦ ਵੀ ਠੀਕ ਚੱਲਦੇ ਹਨ।

ਸੰਬੰਧਿਤ ਲੇਖ