ਕੀ ਉਪਭੋਗਤਾ ਸੈਸ਼ਨ ਦੇ ਕੋਲ VPN ਉੱਤੇ SSHFS ਮਾਊਂਟ ਦੀ ਮਾਲਕੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ?

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

ਦੋ ਪਛਾਣਾਂ, ਦੋ ਵੱਖਰੀਆਂ ਇਜਾਜ਼ਤਾਂ

VPN ਕਲਾਇੰਟ ਨੂੰ ਰੂਟ ਅਤੇ ਇੰਟਰਫੇਸ ਬਦਲਣ ਲਈ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਚਾਹੀਦੇ ਹਨ। SSHFS ਮਾਊਂਟ ਨੂੰ ਫਾਈਲ ਸਰਵਰ ਵੱਲੋਂ ਸਵੀਕਾਰ ਕੀਤੀ SSH ਪਛਾਣ ਅਤੇ ਫਾਈਲਾਂ ਪੜ੍ਹਨ ਵਾਲੇ ਖਾਤੇ ਦੀ ਮਾਲਕੀ ਵਾਲਾ FUSE ਮਾਊਂਟ ਚਾਹੀਦਾ ਹੈ। ਰੂਟ ਵਜੋਂ ਚੱਲਣ ਵਾਲੀ ਇੱਕ ਸਕ੍ਰਿਪਟ ਪਹਿਲੀ ਸ਼ਰਤ ਪੂਰੀ ਕਰਦੀ ਹੈ ਅਤੇ ਦੂਜੀ ਨੂੰ ਚੁੱਪਚਾਪ ਤੋੜ ਦਿੰਦੀ ਹੈ।

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

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

ਪਹਿਲਾਂ ਹੱਥੀਂ ਉਪਭੋਗਤਾ-ਮਾਲਕੀ ਵਾਲਾ ਮਾਊਂਟ ਸਥਾਪਿਤ ਕਰੋ

ਖਾਲੀ ਮਾਊਂਟਪੁਆਇੰਟ, ਅਧਿਕ੍ਰਿਤ SSH ਖਾਤਾ ਅਤੇ ਟਨਲ ਰਾਹੀਂ ਸਰਵਰ ਤੱਕ ਕੰਮ ਕਰਨ ਵਾਲਾ ਰਾਹ ਵਾਲੇ ਸਾਈਨ-ਇਨ ਕੀਤੇ ਉਪਭੋਗਤਾ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਹੱਥੀਂ ਮਾਊਂਟ ਉਹ ਆਧਾਰ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ ਜੋ ਕਿਸੇ ਵੀ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਦੁਹਰਾਉਣਾ ਪੈਂਦਾ ਹੈ।

mkdir -p "$HOME/mnt/team"
sshfs [email protected]:/exports/team "$HOME/mnt/team"
mount | grep sshfs

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

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

ਟ੍ਰਿਗਰ ਨੂੰ ਉਸੇ ਸੈਸ਼ਨ ਸੰਦਰਭ ਵਿੱਚ ਕੰਮ ਕਰਨ ਦਿਓ

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

ਕਾਰਵਾਈ ਨੂੰ ਉਮੀਦ ਕੀਤੇ ਹੋਸਟਨਾਮ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਮੌਜੂਦਾ ਮਾਊਂਟ ਨੂੰ ਨੋਟਿਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਇੱਕ ਸੀਮਿਤ ਕੋਸ਼ਿਸ਼ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਹਰ ਕੁਝ ਸਕਿੰਟਾਂ ਵਿੱਚ ਨਵੀਂ SSHFS ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕਰਨ ਵਾਲਾ ਜਾਂ ਸਰਵਰ ਬੰਦ ਹੋਣ 'ਤੇ ਪ੍ਰਮਾਣ ਪੱਤਰ ਬੇਨਤੀ ਦੁਹਰਾਉਣ ਵਾਲਾ ਪੋਲ ਲੂਪ ਛੋਟੀ ਰੁਕਾਵਟ ਨੂੰ ਅਟਕੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਢੇਰ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਕੋਸ਼ਿਸ਼ ਨੂੰ ਟਾਈਮਆਊਟ ਅਤੇ ਇੱਕ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਨਾਲ ਸੀਮਿਤ ਕਰੋ।

nmcli -g UUID connection show --active
systemctl --user list-units 'sshfs*'
pgrep -a sshfs

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

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

ਮਜ਼ਬੂਰੀ ਕਲੀਨਅੱਪ ਤੋਂ ਪਹਿਲਾਂ ਡਿਸਕਨੈਕਟ ਦੀ ਯੋਜਨਾ ਬਣਾਓ

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

fusermount3 -u "$HOME/mnt/team"
mountpoint "$HOME/mnt/team"

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

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

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