RAM ਵਿੱਚ ਚੱਲਣ ਵਾਲਾ VPN ਰਨਟਾਈਮ ਲੌਗਾਂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ

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

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

ਸਟੋਰੇਜ ਅਤੇ ਸੰਗ੍ਰਹਿ ਦੋ ਵੱਖਰੇ ਸਵਾਲ ਹਨ

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

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

tmpfs ਕੋਈ ਗਾਰੰਟੀ ਨਹੀਂ

Linux tmpfs ਭੌਤਿਕ RAM ਡਿਸਕ ਨਹੀਂ ਹੈ। ਕਰਨਲ ਦਸਤਾਵੇਜ਼ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਜਦੋਂ ਮਾਊਂਟ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਤਾਂ ਪੰਨੇ swap ਵਿੱਚ ਲਿਖੇ ਜਾ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ tmpfs ਫਾਈਲ ਡਿਸਕ ਤੱਕ ਪਹੁੰਚ ਸਕਦੀ ਹੈ ਭਾਵੇਂ ਐਪਲੀਕੇਸ਼ਨ ਨੇ ਕਦੇ ਉੱਥੇ ਨਕਲ ਨਾ ਕੀਤੀ ਹੋਵੇ। mount ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ swap-ਅਧਾਰਿਤ tmpfs ਕੰਮ ਵਿੱਚ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਹੋਰ ਮੈਮੋਰੀ ਫਾਈਲਸਿਸਟਮ ਹੋਰ ਵੀ ਵੱਖਰੇ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ। /run ਹੇਠਾਂ ਦਾ ਰਾਹ ਅਸਥਿਰਤਾ ਦਰਸਾਉਂਦਾ ਹੈ ਇਹ ਮੰਨਣ ਦੀ ਬਜਾਏ ਅਸਲੀ ਮਾਊਂਟ ਵਿਕਲਪ ਪੜ੍ਹੋ।

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

Journald ਕੋਲ ਦੋ ਮੰਜ਼ਿਲਾਂ ਅਤੇ ਇੱਕ ਫਾਰਵਰਡਰ ਹੈ

Journald ਇਸ ਵੰਡ ਨੂੰ ਸਾਫ਼ ਦਿਖਾਉਂਦਾ ਹੈ। ਅਸਥਿਰ ਸਟੋਰੇਜ ਐਂਟਰੀਆਂ /run/log/journal ਹੇਠਾਂ ਰੱਖਦਾ ਹੈ, ਸਥਾਈ ਸਟੋਰੇਜ /var/log/journal ਹੇਠਾਂ, ਅਤੇ ਸਵੈਚਾਲਿਤ ਮੋਡ ਦੋਵਾਂ ਵਿੱਚੋਂ ਚੁਣਦਾ ਹੈ; ਲਾਗੂ ਮੋਡ ਚੱਲ ਰਹੇ ਸਿਸਟਮ ਤੋਂ ਆਉਂਦਾ ਹੈ, ਇਮੇਜ ਦੇ ਵੇਰਵੇ ਤੋਂ ਨਹੀਂ। ਅਸਥਿਰ ਵੱਲ ਬਦਲਣ ਨਾਲ ਪਹਿਲਾਂ ਹੀ ਸਥਾਈ ਤੌਰ ਉੱਤੇ ਲਿਖਿਆ ਨਹੀਂ ਮਿਟਦਾ। ਫਾਰਵਰਡਿੰਗ ਵੀ ਵੱਖਰਾ ਚੈਨਲ ਹੈ: ਸਥਾਨਕ ਤੌਰ ਉੱਤੇ ਕੁਝ ਵੀ ਨਾ ਰੱਖਣ ਵਾਲੀ ਸਟੋਰੇਜ ਸੈਟਿੰਗ ਵੀ ਸੁਨੇਹੇ ਕਿਸੇ ਹੋਰ ਟਾਰਗਿਟ ਨੂੰ ਦੇ ਸਕਦੀ ਹੈ।

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

ਰੀਬੂਟ ਤੋਂ ਬਾਅਦ ਕੀ ਬਚਣਾ ਚਾਹੀਦਾ ਹੈ

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

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

ਲਾਗੂ ਸਟੋਰੇਜ ਅਤੇ ਫਾਰਵਰਡਿੰਗ ਕਨਫਿਗਰੇਸ਼ਨ ਦੀ ਕੁਝ ਨਿਰਦੋਸ਼ ਘਟਨਾਵਾਂ ਨਾਲ ਤੁਲਨਾ ਕਰੋ, ਫਿਰ ਮਸ਼ੀਨ ਨੂੰ ਰੀਬੂਟ ਜਾਂ ਬਦਲੋ ਅਤੇ ਦੁਬਾਰਾ ਜਾਂਚੋ ਕਿ ਕੀ ਬਚਿਆ ਅਤੇ ਸੇਵਾ ਨੇ ਆਪਣੀ ਸਥਿਤੀ ਕਿੱਥੋਂ ਬਹਾਲ ਕੀਤੀ।