Access Server ਉਸ post_auth ਸਕ੍ਰਿਪਟ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਡਿਸਕ ਉੱਤੇ ਸੰਪਾਦਿਤ ਕੀਤੀ

ਸੰਪਾਦਿਤ mac.py ਜੋ ਕੁਝ ਵੀ ਨਹੀਂ ਬਦਲਦੀ, ਆਮ ਪਹਿਲਾ ਲੱਛਣ ਹੈ। ਡਿਸਕ ਉੱਤੇਲੀ ਫ਼ਾਈਲ ਉਹ ਨਹੀਂ ਜੋ Access Server ਚਲਾਉਂਦਾ ਹੈ; ਪਰਮਾਣਕਰਨ ਸੇਵਾ ਸਕ੍ਰਿਪਟ ਨੂੰ ਸਰਵਰ ਦੇ ਕਾਨਫ਼ਿਗ ਡੇਟਾਬੇਸ ਤੋਂ ਲੋਡ ਕਰਦੀ ਹੈ, ਅਤੇ ਉਹੀ ਸੰਭਾਲੀ ਕਾਪੀ ਲੌਗਇਨ ਦਾ ਫ਼ੈਸਲਾ ਕਰਦੀ ਹੈ। ਜਦ ਤੱਕ ਸੰਭਾਲਿਆ ਮੁੱਲ ਨਹੀਂ ਬਦਲਿਆ ਜਾਂਦਾ, ਹਰ ਟੈਸਟ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਪੁਰਾਣੀ ਸਕ੍ਰਿਪਟ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦੀ ਹੈ।

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

ਫ਼ਾਈਲ ਸਰੋਤ ਹੈ, ਚੱਲਦੀ ਕਾਪੀ ਨਹੀਂ

Access Server post-auth ਸਕ੍ਰਿਪਟ ਨੂੰ auth.module.post_auth_script ਕੁੰਜੀ ਹੇਠ ਰੱਖਦਾ ਹੈ। ਫ਼ਾਈਲ ਸੰਪਾਦਿਤ ਕਰਨ ਨਾਲ ਸਿਰਫ਼ ਤੁਹਾਡੀ ਕੰਮ ਵਾਲੀ ਕਾਪੀ ਅੱਪਡੇਟ ਹੁੰਦੀ ਹੈ। ਡੈਮਨ ਸੰਭਾਲਿਆ ਮੁੱਲ ਪੜ੍ਹਦਾ ਹੈ, ਇਸ ਲਈ ਪੁਰਾਣੀ ਐਂਟਰੀ ਮਿਟਾ ਕੇ ਨਵੀਂ ਫ਼ਾਈਲ ਉਸ ਦੀ ਥਾਂ ਨਾ ਰੱਖਣ ਤੱਕ ਬਦਲਾਅ ਅਦਿੱਖ ਰਹਿੰਦਾ ਹੈ। ਉਹੀ ਸੰਭਾਲਿਆ ਮੁੱਲ ਪਰਮਾਣਕਰਨ ਸੇਵਾ ਦੀ ਵੇਖੀ ਜਾਣ ਵਾਲੀ ਇਕੱਲੀ ਕਾਪੀ ਹੈ।

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

./sacli -k auth.module.post_auth_script ConfigGet

ਸੰਭਾਲੀ ਕਾਪੀ ਬਦਲੋ, ਫਿਰ ਲਾਗੂ ਕਰੋ

ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਮਿਟਾਉਣਾ ਸਜਾਵਟ ਨਹੀਂ ਹੈ। ConfigPut ਨਾਲ --value_file ਇੱਕ ਕਦਮ ਵਿੱਚ ਮੁੱਲ ਬਦਲਦਾ ਹੈ, ਅਤੇ ਪਹਿਲਾਂ ConfigDel ਕਰਨਾ ਪੁਰਾਣੀ ਜਾਂ ਖਰਾਬ ਐਂਟਰੀ ਦੇ ਬਚੇ ਰਹਿਣਾ ਅਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ। ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਚੱਲਦੀ ਸਕ੍ਰਿਪਟ ਦੀ ਕਾਪੀ ਸਕ੍ਰਿਪਟ ਫ਼ੋਲਡਰ ਤੋਂ ਬਾਹਰ ਰੱਖੋ।

./sacli -k auth.module.post_auth_script ConfigDel
# store the file, then apply it
./sacli -k auth.module.post_auth_script --value_file=/root/post_auth.py ConfigPut
./sacli start

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

ਮੁੱਲ ਫ਼ਾਈਲ ਲਈ ਪੂਰਾ ਰਾਹ ਵਰਤੋ ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ root ਇਸ ਨੂੰ ਪੜ੍ਹ ਸਕਦਾ ਹੈ। ਤੁਹਾਡੇ ਸ਼ੈਲ ਤੋਂ ਹੱਲ ਹੋਣ ਵਾਲਾ ਪਰ ਸੇਵਾ ਖਾਤੇ ਤੋਂ ਨਾ ਹੋਣ ਵਾਲਾ ਰਾਹ ConfigGet ਵਿੱਚ ਠੀਕ ਦਿਸਣ ਵਾਲਾ ਅਤੇ ਪਹਿਲੇ ਲੌਗਇਨ ਉੱਤੇ ਫੇਲ੍ਹ ਹੋਣ ਵਾਲਾ ਸੰਭਾਲਿਆ ਮੁੱਲ ਦਿੰਦਾ ਹੈ। sacli start ਤੋਂ ਬਾਅਦ ਸੰਭਾਲਿਆ ਨਤੀਜਾ ਇੱਕ ਵਾਰ ਫਿਰ ਜਾਂਚੋ, ਪਹਿਲਾਂ ਨਹੀਂ।

ਮਾਡਿਊਲ ਦਾਇਰਾ ਜਾਂ ਪ੍ਰਤੀ ਕਨੈਕਸ਼ਨ: ਸਵਾਲ ਕਿੱਥੇ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ

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

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

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

ਰੱਦ ਦੇ ਦੋ ਰਾਹ, ਇੱਕ ਮਾਲਕ

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

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

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

ਪ੍ਰਬੰਧਕ ਨੂੰ ਲਾਕ ਆਉਟ ਨਾ ਕਰਦਿਆਂ ਲਾਗੂ ਕਰੋ

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

ਦੋ ਸ਼ਰਤਾਂ ਉਡੀਕ ਕਰੋ ਕਹਿੰਦੀਆਂ ਹਨ: ਤੁਸੀਂ root ਵਜੋਂ ਮੁੱਲ ਫ਼ਾਈਲ ਨਹੀਂ ਪੜ੍ਹ ਸਕਦੇ, ਜਾਂ ਪ੍ਰਬੰਧ ਇੰਟਰਫ਼ੇਸ ਤੱਕ ਦੂਜਾ ਰਾਹ ਨਹੀਂ ਹੈ। ਦੋਵੇਂ ਛੋਟੇ ਬਦਲਾਅ ਨੂੰ ਲਾਕਆਉਟ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ, ਅਤੇ ਦਿਨ ਦੇ ਅਖੀਰ ਵਿੱਚ ਉਤਪਾਦਨ ਸਰਵਰ ਉੱਤੇ ਟੈਸਟ ਕਰਨ ਦੇ ਯੋਗ ਕੋਈ ਨਹੀਂ। Access Server ਦਸਤਾਵੇਜ਼ post-auth ਇੰਟਰਫ਼ੇਸ ਅਤੇ ਉਸ ਦੇ ਸਮਰਥਿਤ ਖੇਤਰਾਂ ਨੂੰ ਕਵਰ ਕਰਦੇ ਹਨ।