ਇੱਕ ਟਨਲ ਲਈ ਜੋੜੀ ਗਈ ਰੀਸਟਾਰਟ ਨੀਤੀ ਮਸ਼ੀਨ ਦੀ ਹਰ ਟਨਲ ’ਤੇ ਲਾਗੂ ਹੋਣ ਲੱਗਦੀ ਹੈ। ਇਹ systemd ਦੀ ਬੱਗ ਨਹੀਂ ਹੈ; ਇਹ ਇੰਸਟੈਂਸ drop-in ਅਤੇ ਟੈਂਪਲੇਟ drop-in ਵਿਚਕਾਰ ਫ਼ਰਕ ਹੈ। ਤੁਸੀਂ ਫ਼ਾਈਲ ਕਿਹੜੇ ਮਾਰਗ ਹੇਠ ਲਿਖਦੇ ਹੋ, ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਿੰਨੀਆਂ ਸੇਵਾਵਾਂ ਇਸ ਨੂੰ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਣਗੀਆਂ।

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

ਲੱਛਣ: ਇੱਕ ਸੰਪਾਦਨ, ਹਰ ਟਨਲ

ਖ਼ਾਸ ਇੰਸਟੈਂਸ ਦਾ drop-in ਪੂਰੇ ਇੰਸਟੈਂਸ ਦੇ ਨਾਂ ਵਾਲੀ ਡਾਇਰੈਕਟਰੀ ਹੇਠ ਹੁੰਦਾ ਹੈ, ਜਿਵੇਂ [email protected]। ਟੈਂਪਲੇਟ drop-in [email protected] ਹੇਠ ਹੁੰਦਾ ਹੈ, ਵਿਚਕਾਰ @ ਚਿੰਨ੍ਹ ਹੁੰਦਾ ਹੈ ਅਤੇ ਇੰਸਟੈਂਸ ਦਾ ਨਾਂ ਨਹੀਂ ਹੁੰਦਾ। ਪਹਿਲਾ ਸਿਰਫ਼ office ’ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਦੂਜਾ ਉਸ ਟੈਂਪਲੇਟ ਤੋਂ ਬਣੀ ਹਰ ਸੇਵਾ ’ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ।

ਟੈਂਪਲੇਟ ਰੂਪ ਵੱਖਰੇ [email protected] ਟੈਂਪਲੇਟ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ, ਅਤੇ ਨਾਂ ਵਿੱਚ openvpn ਵਾਲੀਆਂ ਅਸੰਬੰਧਿਤ ਸੇਵਾਵਾਂ ਤੱਕ ਵੀ ਨਹੀਂ ਪਹੁੰਚਦਾ।

ਦਾਇਰੇ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਡਾਇਰੈਕਟਰੀ ਚੁਣੋ

ਦੋਵੇਂ ਡਾਇਰੈਕਟਰੀਆਂ /etc/systemd/system/ ਹੇਠ ਹਨ। ਆਖਰੀ system ਹਿੱਸਾ ਛੱਡਣ ਨਾਲ ਅਜਿਹਾ ਮਾਰਗ ਬਣਦਾ ਹੈ ਜਿਸ ਨੂੰ systemd ਸਿਸਟਮ ਓਵਰਰਾਈਡ ਵਜੋਂ ਨਹੀਂ ਪੜ੍ਹਦਾ, ਅਤੇ ਇਹ ਸਹੀ ਦਿਸਦੀ ਫ਼ਾਈਲ ਨੂੰ ਕੁਝ ਵੀ ਨਾ ਕਰਨ ਦਾ ਚੁੱਪ ਤਰੀਕਾ ਹੈ। ਪੂਰਾ ਮਾਰਗ ਇੱਕ ਵਾਰ ਲਿਖੋ ਅਤੇ ਦੁਬਾਰਾ ਵਰਤੋ।

drop-in ਨੂੰ ਸਹੀ ਵਿਭਾਗ ਸਿਰਲੇਖ ਵੀ ਚਾਹੀਦਾ ਹੈ। ਸੇਵਾ ਸੈਟਿੰਗਾਂ [Service] ਹੇਠ ਆਉਂਦੀਆਂ ਹਨ। ਸੈਟਿੰਗਾਂ ਹੋਣ ਪਰ ਵਿਭਾਗ ਨਾ ਹੋਣ ਵਾਲੀ ਫ਼ਾਈਲ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਜਾਂ ਰੱਦ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਫ਼ਾਈਲ ਉੱਥੇ ਅਧਿਕਾਰਤ ਦਿਸਦੀ ਰਹਿੰਦੀ ਹੈ ਜਦੋਂ ਕਿ unit ਪਹਿਲਾਂ ਵਾਂਗ ਵਿਵਹਾਰ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ।

ਇੱਕ ਤੋਂ ਵੱਧ drop-in ਜੋੜ ਰਹੇ ਹੋ ਤਾਂ ਮਕਸਦ ਫ਼ਾਈਲ ਨਾਂ ਵਿੱਚ ਰੱਖੋ। ਮਿਲਾਉਣ ਦਾ ਕ੍ਰਮ ਸ਼ਬਦਕੋਸ਼ੀ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਫ਼ਾਈਲ ਕੀ ਕਰਦੀ ਹੈ ਦੱਸਦਾ ਨਾਂ ਉਸ ਕ੍ਰਮ ਨੂੰ ਪੜ੍ਹਨਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।

ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਮਿਲਾਇਆ unit ਪੜ੍ਹੋ

ਕੁਝ ਵੀ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਮਿਲਾਇਆ unit ਪੜ੍ਹੋ। systemctl cat [email protected] ਮੁੱਖ unit ਅਤੇ ਲਾਗੂ ਹੋਣ ਵਾਲਾ ਹਰ drop-in ਮਿਲਾਉਣ ਕ੍ਰਮ ਵਿੱਚ ਛਾਪਦਾ ਹੈ। ਟੈਂਪਲੇਟ ਬਦਲਾਅ ਬਾਰੇ ਸੋਚਦੇ ਸਮੇਂ ਇਸ ਦੀ ਦੂਜੇ ਇੰਸਟੈਂਸ ਨਾਲ ਤੁਲਨਾ ਕਰੋ। ਉਹ ਤੁਲਨਾ ਠੀਕ-ਠੀਕ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਸੇਵਾਵਾਂ ਸੰਪਾਦਨ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਣਗੀਆਂ।

ਇੰਸਟੈਂਸ ਫ਼ਾਈਲ ਟੈਂਪਲੇਟ ਸੈਟਿੰਗਾਂ ਨੂੰ ਮਿਟਾਉਂਦੀ ਨਹੀਂ। ਦੋਵੇਂ ਮਿਲਾਏ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਤੁਹਾਡਾ ਭੁੱਲਿਆ ਟੈਂਪਲੇਟ ਮੁੱਲ ਅਜੇ ਵੀ ਲਾਗੂ ਹੋ ਸਕਦਾ ਹੈ।

ਹੋਰ ਨਾਮਿਤ drop-in, ਰਨਟਾਈਮ ਸੈਟਿੰਗਾਂ ਅਤੇ ਪੈਕੇਜਾਂ ਵੱਲੋਂ ਦਿੱਤੀ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਵੀ ਹਿੱਸਾ ਲੈਂਦੇ ਹਨ। ਇਹ ਨਾ ਮੰਨੋ ਕਿ ਤੁਸੀਂ ਆਖ਼ਰ ਵਿੱਚ ਸੰਪਾਦਿਤ ਕੀਤੀ ਫ਼ਾਈਲ ਹੀ ਪੂਰਾ unit ਹੈ। ਮਿਲਾਇਆ ਆਉਟਪੁੱਟ ਹੀ unit ਹੈ।

unit ਨੀਤੀ ਨੂੰ ਪਰੋਫ਼ਾਈਲ ਤੋਂ ਬਾਹਰ ਰੱਖੋ

unit ਨੀਤੀ ਅਤੇ VPN ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਵੱਖਰੇ ਰੱਖੋ। ਪਰੋਫ਼ਾਈਲ ਨਿਰਦੇਸ਼ [Service] ਹੇਠ ਹੋਣ ਕਰਕੇ ਵੈਧ systemd ਵਾਕ-ਰਚਨਾ ਨਹੀਂ ਬਣਦਾ। ਰੀਸਟਾਰਟ ਸੈਟਿੰਗ ਵੀ .ovpn ਫ਼ਾਈਲ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦੀ।

ਇਹ ਵੱਖਰਾਵਾ ਹੀ ਕਾਰਨ ਹੈ ਕਿ ਰੀਸਟਾਰਟ ਨੀਤੀOpenVPN ਵੱਲੋਂ ਖ਼ੁਦ ਕੀਤੀ ਪੀਅਰ ਰਿਕਵਰੀ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੈ। ਦਾਇਰਾ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਹੜਾ ਵਿਵਹਾਰ ਚਾਹੁੰਦੇ ਹੋ।

ਇਸ ਨੂੰ ਲਾਗੂ ਕਰੋ ਅਤੇ ਇੰਸਟੈਂਸ ਜਾਂਚੋ

ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ, systemctl daemon-reload ਨਾਲ ਮੈਨੇਜਰ ਦੀਆਂ ਪਰਿਭਾਸ਼ਾਵਾਂ ਦੁਬਾਰਾ ਲੋਡ ਕਰੋ। ਉਹ ਦੁਬਾਰਾ ਲੋਡ ਟਨਲ ਨੂੰ ਰੀਸਟਾਰਟ ਨਹੀਂ ਕਰਦਾ; ਇਹ ਸਿਰਫ਼ unit ਫ਼ਾਈਲਾਂ ਦੁਬਾਰਾ ਪੜ੍ਹਦਾ ਹੈ। ਫਿਰ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਸੀ ਉਹ ਲਾਈਫ਼ਸਾਈਕਲ ਕਾਰਵਾਈ ਠੀਕ ਉਸੇ ਇੰਸਟੈਂਸ ’ਤੇ ਲਾਗੂ ਕਰੋ।

ਲੋਡ ਹੋਇਆ unit ਦੁਬਾਰਾ ਪੜ੍ਹ ਕੇ ਅਤੇ ਤੁਸੀਂ ਬਦਲਿਆ ਵਿਵਹਾਰ ਦੇਖ ਕੇ ਜਾਂਚੋ। ਸਰਗਰਮ ਕੰਮ ਚੁੱਕਦਾ ਰੀਸਟਾਰਟ ਯੋਜਨਾਬੱਧ ਰੁਕਾਵਟ ਦਾ ਹੱਕਦਾਰ ਹੈ, ਉਤਪਾਦਨ ਟਨਲ ’ਤੇ ਤੇਜ਼ ਜਾਂਚ ਦਾ ਨਹੀਂ। ਓਵਰਰਾਈਡ ਦਾ ਮਕਸਦ ਅਤੇ ਦਾਇਰਾ ਡਿਪਲੌਇਮੈਂਟ ਕੋਲ ਲਿਖੋ ਤਾਂ ਜੋ ਅਗਲਾ ਵਿਅਕਤੀ ਜਾਣ ਸਕੇ ਕਿ ਫ਼ਾਈਲ ਸਾਂਝੀ ਕਰਨ ਲਈ ਸੀ ਜਾਂ ਨਹੀਂ।

ਜੇ ਨੀਤੀ ਸੱਚਮੁੱਚ ਸਾਂਝੀ ਹੈ, ਤਾਂ ਇਸ ਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਟੈਂਪਲੇਟ ਵਿੱਚ ਲੈ ਜਾਓ ਅਤੇ ਕੰਮ ਪੂਰਾ ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ ਦੂਜਾ ਇੰਸਟੈਂਸ ਜਾਂਚੋ।systemd unit ਸੰਦਰਭ drop-in ਤਰਜੀਹ ਅਤੇ ਮਿਲਾਉਣ ਕ੍ਰਮ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦਾ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ