VPN ਪਿੱਛੇ NFS: ਬੂਟ ਸਮੇਂ ਮਾਊਂਟ ਜਾਂ ਮੰਗ ਅਨੁਸਾਰ ਆਟੋਮਾਊਂਟ?
ਬੂਟ ਸਮੇਂ ਮਾਊਂਟ ਅਜੇ ਨਾ ਉੱਠੀ ਟਨਲ ਉੱਤੇ ਅਟਕਦਾ ਹੈ। ਆਟੋਮਾਊਂਟ ਪਹਿਲੀ ਪਹੁੰਚ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ, ਅਤੇ VPN ਦੀ ਨਿਰਭਰਤਾ ਟ੍ਰਿਗਰ ਉੱਤੇ ਨਹੀਂ, ਮਾਊਂਟ ਯੂਨਿਟ ਉੱਤੇ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਦੋ ਸੰਰਚਨਾਵਾਂ ਇੱਕੋ ਸਮੱਸਿਆ ਹੱਲ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਉਲਟ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਫੇਲ੍ਹ ਹੁੰਦੀਆਂ ਹਨ। ਸਾਂਝ ਨੂੰ ਬੂਟ ਸਮੇਂ ਮਾਊਂਟ ਕਰਨਾ ਹਰ ਸੇਵਾ ਨੂੰ ਇੱਕ ਫਾਈਲਸਿਸਟਮ ਦਿੰਦਾ ਹੈ ਜੋ ਜਾਂ ਤਾਂ ਮੌਜੂਦ ਹੈ ਜਾਂ ਦੱਸਦਾ ਹੈ ਕਿ ਬੂਟ ਕਿਉਂ ਅਟਕਿਆ। ਮੰਗ ਅਨੁਸਾਰ ਆਟੋਮਾਊਂਟ ਮਸ਼ੀਨ ਨੂੰ ਤੇਜ਼ ਬੂਟ ਦਿੰਦਾ ਹੈ ਅਤੇ ਉਡੀਕ ਉਸ ਨੂੰ ਸੌਂਪ ਦਿੰਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਪਥ ਨੂੰ ਛੂਹਦਾ ਹੈ। VPN ਪਿੱਛੇ ਦੂਜਾ ਆਮ ਤੌਰ 'ਤੇ ਵਧੀਆ ਸੌਦਾ ਹੈ, ਅਤੇ ਕਾਰਨ ਇਹ ਹੈ ਕਿ ਟਨਲ ਇੱਕ ਅਜਿਹਾ ਕ੍ਰਮ ਥੋਪਦੀ ਹੈ ਜੋ ਬੂਟ ਕ੍ਰਮ ਦੇਖ ਨਹੀਂ ਸਕਦਾ।
ਬੂਟ ਮਾਊਂਟ ਬਨਾਮ ਆਟੋਮਾਊਂਟ
ਬੂਟ ਸਮੇਂ ਮਾਊਂਟ ਸਮਝਣਾ ਸੌਖਾ ਹੈ। ਫਾਈਲਸਿਸਟਮ ਟਾਰਗਿਟ ਮਾਊਂਟ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ, ਉਸ ਉੱਤੇ ਨਿਰਭਰਤਾ ਘੋਸ਼ਿਤ ਕਰਨ ਵਾਲੀਆਂ ਸੇਵਾਵਾਂ ਉਸ ਤੋਂ ਬਾਅਦ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਜੇ ਸਰਵਰ ਪਹੁੰਚ ਵਿੱਚ ਨਾ ਹੋਵੇ ਤਾਂ ਮਸ਼ੀਨ ਵਿਕਲਪਾਂ ਅਨੁਸਾਰ ਜਾਂ ਉਡੀਕ ਕਰਦੀ ਹੈ ਜਾਂ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ। ਹੇਠਾਂ ਦਾ ਸਭ ਕੁਝ ਉਹੀ ਇੱਕ ਫੈਸਲਾ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਂਦਾ ਹੈ।
ਆਟੋਮਾਊਂਟ ਇਸ ਨੂੰ ਉਲਟ ਦਿੰਦਾ ਹੈ। ਪਥ ਤੁਰੰਤ ਮੌਜੂਦ ਹੁੰਦਾ ਹੈ, ਅਸਲ ਮਾਊਂਟ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਚੀਜ਼ ਇਸ ਨੂੰ ਖੋਲ੍ਹਦੀ ਹੈ, ਅਤੇ ਜਲਦੀ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੀਆਂ ਸੇਵਾਵਾਂ ਅਜੇ ਨਾ ਉੱਠੀ ਟਨਲ ਉੱਤੇ ਨਹੀਂ ਅਟਕਦੀਆਂ।
ਤੁਲਨਾ ਇਸ ਉੱਤੇ ਆਉਂਦੀ ਹੈ ਕਿ ਦੇਰੀ ਕੌਣ ਸਹਿੰਦਾ ਹੈ। ਜਿਸ ਵਰਕਸਟੇਸ਼ਨ ਨੂੰ ਵਰਤੋਂਕਾਰ ਦੇ ਕੰਮ ਕਰ ਸਕਣ ਤੋਂ ਪਹਿਲਾਂ ਸਾਂਝ ਚਾਹੀਦੀ ਹੈ ਉਸ ਨੂੰ ਸ਼ਾਇਦ ਉਡੀਕ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਬੈਗ ਵਿੱਚ ਬੂਟ ਹੋਣ ਵਾਲੇ ਲੈਪਟਾਪ ਨੂੰ, ਜਾਂ ਜਿਸ ਸਰਵਰ ਦੀ ਸਾਂਝ ਚੋਣਵੀਂ ਹੈ, ਉਡੀਕ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ।
ਕੋਈ ਵੀ ਵਿਕਲਪ ਗੁੰਮ ਰਸਤਾ ਠੀਕ ਨਹੀਂ ਕਰਦਾ। ਦੋਵੇਂ ਸਿਰਫ਼ ਇਹ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਫੇਲ੍ਹਤਾ ਕਦੋਂ ਦੇਖੀ ਜਾਵੇਗੀ।
fstab ਲਾਈਨ, ਵਿਕਲਪ ਦਰ ਵਿਕਲਪ
ਮੰਨ ਲਓ ਕਿ ਮੌਜੂਦਾ OpenVPN ਕਲਾਇੰਟ ਇੰਸਟੈਂਸ [email protected] ਹੈ, ਸਰਵਰ files.corp.example ਹੈ ਅਤੇ ਮਾਊਂਟ ਪੁਆਇੰਟ /mnt/work ਹੈ। ਤਿੰਨੇ ਆਪਣੀ ਸਾਈਟ ਦੇ ਅਧਿਕਾਰਤ ਮੁੱਲਾਂ ਨਾਲ ਬਦਲੋ। ਕੰਮ ਕਰਨ ਵਾਲੀ ਇੱਕ ਲਾਈਨ ਇਵੇਂ ਦਿਖਦੀ ਹੈ:
files.corp.example:/export/work /mnt/work nfs _netdev,nofail,x-systemd.automount,[email protected],x-systemd.mount-timeout=30s 0 0
_netdev ਮਾਊਂਟ ਨੂੰ ਨੈੱਟਵਰਕਿੰਗ ਦੀ ਲੋੜ ਵਾਲਾ ਦੱਸਦਾ ਹੈ, ਅਤੇ ਇਹ ਕਿਸੇ ਟਨਲ ਦਾ ਨਾਮ ਨਹੀਂ ਲੈਂਦਾ। nofail ਆਮ ਫਾਈਲਸਿਸਟਮ ਟਾਰਗਿਟ ਲਈ ਸਾਂਝ ਨੂੰ ਚੋਣਵੀਂ ਰੱਖਦਾ ਹੈ। x-systemd.automount ਤੁਰੰਤ ਮਾਊਂਟ ਕਰਨ ਦੀ ਥਾਂ ਮੰਗ ਅਨੁਸਾਰ ਟ੍ਰਿਗਰ ਬਣਾਉਂਦਾ ਹੈ।
x-systemd.requires= ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਮਾਊਂਟ ਯਤਨ ਨੂੰ VPN ਯੂਨਿਟ ਨਾਲ ਬੰਨ੍ਹਦਾ ਹੈ, ਅਤੇ ਇਹ ਟ੍ਰਿਗਰ ਉੱਤੇ ਨਹੀਂ, ਮਾਊਂਟ ਕਾਰਵਾਈ ਉੱਤੇ ਆਉਂਦਾ ਹੈ। ਆਟੋਮਾਊਂਟ ਯੂਨਿਟ ਉੱਤੇ ਹੀ ਵਿਆਪਕ ਕ੍ਰਮ ਰੱਖਣਾ ਹੀ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਲੋਕ ਚੱਕਰ ਬਣਾਉਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ ਸ਼ਿਕਾਇਤ systemd ਬਾਅਦ ਵਿੱਚ ਉਸ ਭਾਸ਼ਾ ਵਿੱਚ ਕਰਦਾ ਹੈ ਜਿਸ ਨੂੰ ਕੋਈ ਦੋ ਵਾਰ ਨਹੀਂ ਪੜ੍ਹਦਾ।
x-systemd.mount-timeout=30s ਸ਼ੁਰੂਆਤੀ ਮਾਊਂਟ ਕਮਾਂਡ ਨੂੰ ਸੀਮਿਤ ਕਰਦਾ ਹੈ। ਇਹ ਬਾਅਦ ਵਿੱਚ ਹੋਣ ਵਾਲੀ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਸੀਮਿਤ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਇਹ ਇਸ ਵਿਕਲਪ ਬਾਰੇ ਸਭ ਤੋਂ ਆਮ ਗਲਤਫਹਿਮੀ ਹੈ।
‘ਸ਼ੁਰੂ ਹੋਇਆ’ ਦਾ ਕੀ ਅਰਥ ਨਹੀਂ
ਤੁਸੀਂ ਨਾਮ ਦਿੱਤੀ VPN ਯੂਨਿਟ ਲਈ ਸਰਗਰਮ ਹੋਣ ਦਾ ਅਰਥ ਜਾਂਚੋ। ਟਨਲ ਸੇਵਾ ਫਾਈਲ ਸਰਵਰ ਤੱਕ ਰਸਤਾ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂ ਨਿੱਜੀ ਨਾਮ ਹੱਲ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ ਆਪ ਨੂੰ ਸ਼ੁਰੂ ਹੋਇਆ ਦੱਸ ਸਕਦੀ ਹੈ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਕ੍ਰਮ ਲਾਉਣਾ ਤਦ ਤੁਹਾਨੂੰ ਕੁਝ ਨਹੀਂ ਦਿੰਦਾ। ਲਗਭਗ ਹਰ ਫੇਲ੍ਹ ਯਤਨ ਇਸੇ ਖਾਲੀ ਥਾਂ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ। ਇਹ ਅਦਿੱਖ ਵੀ ਹੈ ਜਦ ਤੱਕ ਤੁਸੀਂ ਯੂਨਿਟ ਦੀ ਸਥਿਤੀ ਦੀ ਥਾਂ ਰਸਤਾ ਅਤੇ ਹੱਲਕਰਤਾ ਨਾ ਦੇਖੋ।
ਜਿੱਥੇ ਹੋਵੇ ਉੱਥੇ ਕਨੈਕਸ਼ਨ ਦੇ ਮਾਲਕ ਦਾ ਆਪਣਾ ਤਿਆਰੀ ਸੰਕੇਤ ਵਾਧੂ ਪੂਰਵ-ਸ਼ਰਤ ਵਜੋਂ ਵਰਤੋ। ਨਿਸ਼ਚਿਤ ਨੀਂਦ ਇੱਕ ਅੰਦਾਜ਼ਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਡੈਸਕ ਉੱਤੇ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਹੌਲੀ ਨੈੱਟਵਰਕ ਉੱਤੇ ਜਾਂ ਮੁੜ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ।
ਉਦਾਹਰਨ ਪਥ ਲਈ ਬਣੀਆਂ ਯੂਨਿਟਾਂ ਦੇਖੋ: mnt-work.automount ਅਤੇ mnt-work.mount। ਸਮੀਖਿਅਤ fstab ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ systemd ਮੁੜ ਲੋਡ ਕਰੋ ਅਤੇ ਅਸੰਬੰਧਿਤ ਐਂਟਰੀਆਂ ਅਭਿਆਸ ਕਰਨ ਵਾਲੀ ਵਿਆਪਕ ਮਾਊਂਟ ਕਮਾਂਡ ਚਲਾਉਣ ਦੀ ਥਾਂ ਉਹ ਯੂਨਿਟ ਸਿੱਧੀਆਂ ਸੰਭਾਲੋ।
ਇੱਥੇ ਇੱਕ ਹੋਰ ਚੇਤਾਵਨੀ ਆਉਂਦੀ ਹੈ। ਸ਼ੁਰੂਆਤ ਵਿੱਚ /mnt/work ਨੂੰ ਛੂਹਣ ਵਾਲੀ ਸੇਵਾ ਅਜੇ ਵੀ ਮਾਊਂਟ ਟ੍ਰਿਗਰ ਕਰਦੀ ਹੈ ਅਤੇ ਅਜੇ ਵੀ ਉਸ ਦੀ ਉਡੀਕ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਸਾਂਝ ਨੂੰ ਚੋਣਵੀਂ ਚਿੰਨ੍ਹਿਤ ਕਰਨਾ ਹਰ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਧੀਰਜਵਾਨ ਨਹੀਂ ਬਣਾਉਂਦਾ।
ਮਾਊਂਟ ਤੋਂ ਬਾਅਦ ਇਹ ਦੂਜੀ ਫੇਲ੍ਹਤਾ ਹੈ
NFS ਮਾਊਂਟ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਫਾਈਲਸਿਸਟਮ ਦਾ ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਅਤੇ ਬਹਾਲੀ ਵਿਵਹਾਰ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਬਾਅਦ ਵਾਲੀ ਰੁਕਾਵਟ ਪੜ੍ਹਨ ਜਾਂ ਲਿਖਣ ਨਾਲ ਕੀ ਕਰਦੀ ਹੈ। ਤੁਹਾਡੇ ਸੈੱਟ ਕੀਤੇ ਮਾਊਂਟ ਟਾਈਮਆਊਟ ਦਾ ਇਸ ਉੱਤੇ ਕੋਈ ਪ੍ਰਭਾਵ ਨਹੀਂ ਹੈ।
ਸਾਫਟ ਮਾਊਂਟ ਕੁਝ ਉਡੀਕਾਂ ਛੋਟੀਆਂ ਕਰਦਾ ਹੈ ਅਤੇ ਗਲਤੀਆਂ ਦਾ ਅਰਥ ਬਦਲਦਾ ਹੈ, ਨਾਲ ਹੀ ਡੇਟਾ ਅਖੰਡਤਾ ਦੇ ਉਹ ਨਤੀਜੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤਦ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ ਸੌਖਾ ਹੈ ਜਦੋਂ ਟੀਚਾ ਤੇਜ਼ ਬੂਟ ਹੋਵੇ। ਸ਼ੁਰੂਆਤ ਦੇ ਦੋ ਸਕਿੰਟ ਜਿੱਤਣ ਲਈ ਇਸ ਨੂੰ ਚੁਣਨਾ ਘੱਟ ਹੀ ਚੰਗਾ ਸੌਦਾ ਹੈ। ਜੇ ਲੋੜ ਸੱਚਮੁੱਚ ਰੁਕਾਵਟ ਦੌਰਾਨ ਸੀਮਿਤ ਕਾਰਵਾਈ ਹੈ, ਤਾਂ ਉਹ ਐਪਲੀਕੇਸ਼ਨ ਪੱਧਰ ਦਾ ਫੈਸਲਾ ਹੈ, fstab ਝੰਡਾ ਨਹੀਂ।
ਟਨਲ ਡਿੱਗਣ ਵੇਲੇ ਲਿਖਣ ਦੇ ਵਿਚਕਾਰ ਹੋਣ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਇਹ ਤੈਅ ਕਰੋ ਅਤੇ ਲਿਖ ਕੇ ਰੱਖੋ। ਉਹ ਜਵਾਬ ਕਿਸੇ ਵੀ ਵਿਕਲਪ ਲੜੀ ਤੋਂ ਵੱਧ ਲਾਹੇਵੰਦ ਹੈ।
ਇੱਕ ਨਹੀਂ, ਚਾਰ ਸਥਿਤੀਆਂ ਜਾਂਚੋ
ਟਨਲ ਉਪਲਬਧ ਹੋਣ ਵੇਲੇ ਆਮ ਬੂਟ ਸੌਖਾ ਕੇਸ ਹੈ ਅਤੇ ਲਗਭਗ ਕੁਝ ਵੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਲੜੀ ਠੀਕ ਲਿਖੀ ਹੈ ਅਤੇ ਬੱਸ। VPN ਤੋਂ ਬਿਨਾਂ ਪਹਿਲੀ ਪਹੁੰਚ ਜਾਂਚੋ, ਫਿਰ ਉਸ ਦੇ ਉੱਠਣ ਉੱਤੇ ਬਹਾਲੀ, ਫਿਰ ਸਫਲ ਮਾਊਂਟ ਤੋਂ ਬਾਅਦ ਨਿਯੰਤਰਿਤ ਰੁਕਾਵਟ।
ਚਾਰ ਸਥਿਤੀਆਂ, ਚਾਰ ਨਿਰੀਖਣ, ਅਤੇ ਨੋਟ fstab ਐਂਟਰੀ ਦੇ ਕੋਲ ਜਾਂਦੇ ਹਨ। ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਸੰਰਚਨਾ ਦੀ ਥਾਂ ਵਿਵਹਾਰ ਵਿਰਾਸਤ ਵਿੱਚ ਮਿਲਦਾ ਹੈ ਜਿਸ ਨੂੰ ਉਸ ਨੂੰ ਉਲਟਾ ਇੰਜੀਨੀਅਰ ਕਰਨਾ ਪਵੇ।