HestiaCP ਨਾਲ Apache2 ਦੇ ਵਾਰ-ਵਾਰ ਕਰੈਸ਼ ਹੋਣੇ? Monit ਆਟੋਮੇਟਿਡ ਨਿਗਰਾਨੀ ਅਤੇ ਸਮੱਸਿਆ ਨਿਪਟਾਰਾ ਗਾਈਡ (ਪੂਰੀ ਸੰਰਚਨਾ ਦੇ ਨਾਲ)

HestiaCP ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ Apache2 ਦੇ ਵਾਰ-ਵਾਰ ਕਰੈਸ਼ ਹੋਣ ਜਾਂ Monit ਦੇ ਆਟੋ-ਰੀਸਟਾਰਟ ਅਸਫਲਤਾਵਾਂ? ਇਹ ਲੇਖ Monit ਨਾਲ Apache2 ਦੀ ਨਿਗਰਾਨੀ ਕਰਦੇ ਸਮੇਂ ਆਮ ਮੁਸ਼ਕਲਾਂ ਤੋਂ ਬਚਣ, PID ਮਾਰਗ ਗਲਤ ਅਲਾਈਨਮੈਂਟ ਅਤੇ ਅਨੁਮਤੀ ਬਲਾਕਿੰਗ ਵਰਗੇ ਆਮ ਮੁੱਦਿਆਂ ਦਾ ਡੂੰਘਾਈ ਨਾਲ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ, ਅਤੇ ਉਤਪਾਦਨ-ਗ੍ਰੇਡ Monit ਆਟੋਮੇਸ਼ਨ ਕੌਂਫਿਗਰੇਸ਼ਨ ਫਾਈਲਾਂ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਨ ਲਈ ਇੱਕ ਵਿਹਾਰਕ ਗਾਈਡ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਹੁਣੇ ਉੱਚ-ਉਪਲਬਧਤਾ ਸਰਵਰ ਰੱਖ-ਰਖਾਅ ਤਕਨੀਕਾਂ ਵਿੱਚ ਮੁਹਾਰਤ ਹਾਸਲ ਕਰੋ ਅਤੇ ਅਸਫਲਤਾਵਾਂ ਤੋਂ ਦੂਜੇ-ਪੱਧਰ ਦੀ ਆਟੋਮੈਟਿਕ ਰਿਕਵਰੀ ਪ੍ਰਾਪਤ ਕਰੋ!

Apache2 ਦੀ ਨਿਗਰਾਨੀ ਲਈ Monit ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਮੈਨੂੰ ਆਈਆਂ ਮੁਸ਼ਕਲਾਂ

ਪਿਛਲੇ ਸ਼ੁੱਕਰਵਾਰ, ਸਰਵਰ ਨੇ ਮੈਨੂੰ ਅੱਧੀ ਰਾਤ ਨੂੰ ਇੱਕ ਮੋਨਿਟ ਅਲਰਟ ਦਿੱਤਾ।

ਮੈਂ ਘਬਰਾਹਟ ਨਾਲ ਪੈਨਲ ਵੱਲ ਦੇਖਿਆ, ਅਤੇ apache2 ਸਟੇਟਸ ਕਾਲਮ ਵਿੱਚ, ਇੱਕ ਲਾਲ ਟਾਈਮਆਉਟ ਸੀ।

ਮੈਂ ਇਸ ਬਾਰੇ ਥੋੜ੍ਹਾ ਸੋਚਿਆ। ਮੈਂ ਦਿਨ ਵੇਲੇ ਸਰਵਰ ਵਿੱਚ ਮੋਨਿਟ ਮਾਨੀਟਰਿੰਗ ਜੋੜੀ, ਅਤੇ ਮੈਂ ਇੱਕ ਔਨਲਾਈਨ ਟਿਊਟੋਰਿਅਲ ਤੋਂ ਕੌਂਫਿਗਰੇਸ਼ਨ ਨੂੰ ਕਾਪੀ ਅਤੇ ਪੇਸਟ ਕੀਤਾ। ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ, ਠੀਕ ਹੈ?

ਅਗਲੀ ਸਵੇਰ, ਇਸਦਾ ਸਮਾਂ ਫਿਰ ਖਤਮ ਹੋ ਗਿਆ। ਤੀਜੀ ਵਾਰ ਤੋਂ ਬਾਅਦ, ਮਾਨੀਟਰ ਨੇ ਹਾਰ ਮੰਨ ਲਈ, ਅਤੇ ਪੈਨਲ 'ਤੇ "ਨਿਗਰਾਨੀ ਨਹੀਂ ਕੀਤੀ ਗਈ" ਦਿਖਾਈ ਦਿੱਤੀ।

ਮੈਂ.. .

ਮੈਂ ਮੰਨਦਾ ਹਾਂ, ਮੈਂ ਪਹਿਲਾਂ ਇਸਨੂੰ ਗੰਭੀਰਤਾ ਨਾਲ ਨਹੀਂ ਲਿਆ। Apache2 ਨਿਗਰਾਨੀ? ਤੁਸੀਂ ਔਨਲਾਈਨ ਬਹੁਤ ਸਾਰੇ ਟੈਂਪਲੇਟ ਸੰਰਚਨਾਵਾਂ ਲੱਭ ਸਕਦੇ ਹੋ, ਬਸ ਕਾਪੀ ਅਤੇ ਪੇਸਟ ਕਰੋ। ਪਰ ਉਸ ਪੇਸਟਿੰਗ ਪ੍ਰਕਿਰਿਆ ਨੇ ਮੈਨੂੰ ਸੱਚਮੁੱਚ ਗੁੱਸੇ ਕਰ ਦਿੱਤਾ।

ਹੇਸਟੀਆਸੀਪੀ ਦੇ ਡਿਫਾਲਟ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਮੋਨਿਟ ਪੋਰਟਾਂ ਵਿਚਕਾਰ ਟਕਰਾਅ ਦਾ ਮੂਲ ਕਾਰਨ

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

check process apache2 with pidfile /var/run/apache2/apache2.pid
    start program = "/usr/sbin/service apache2 start"
    stop program  = "/usr/sbin/service apache2 stop"
    if failed host 127.0.0.1 port 80 protocol http then restart
    if 5 restarts within 5 cycles then timeout

ਇਹ ਠੀਕ ਲੱਗਦਾ ਹੈ, ਠੀਕ ਹੈ? ਇਹ ਪੋਰਟ 80 ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ, ਅਤੇ ਜੇਕਰ ਇਹ ਕਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਮੁੜ ਚਾਲੂ ਹੋ ਜਾਂਦਾ ਹੈ। ਜੇਕਰ ਇਹ 5 ਵਾਰ ਮੁੜ ਚਾਲੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਵੀ ਕਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਸਦਾ ਸਮਾਂ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ।

ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡਾ Apache2 ਪੋਰਟ 80 'ਤੇ ਵੀ ਨਹੀਂ ਚੱਲ ਰਿਹਾ ਹੈ।

ਇਹ HestiaCP ਦਾ ਇੱਕ ਖ਼ਤਰਾ ਹੈ, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਲੋਕਾਂ ਦੇ ਇਸ ਵਿੱਚ ਫਸਣ ਦਾ ਮੂਲ ਕਾਰਨ ਹੈ। HestiaCP ਦਾ ਡਿਫਾਲਟ ਆਰਕੀਟੈਕਚਰ Nginx + Apache2 ਦਾ ਇੱਕ ਉਲਟਾ ਪ੍ਰੌਕਸੀ ਹੈ, ਜਿਸ ਵਿੱਚ Nginx ਅੱਗੇ ਪੋਰਟ 80 ਅਤੇ 443 'ਤੇ ਕਬਜ਼ਾ ਕਰਦਾ ਹੈ, ਅਤੇ Apache2 ਪਿੱਛੇ ਸਥਾਨਕ ਪੋਰਟ 8081 'ਤੇ ਚੱਲਦਾ ਹੈ।

ਜੇਕਰ ਤੁਸੀਂ ਮੋਨਿਟ ਨੂੰ ਪੋਰਟ 80 'ਤੇ Apache2 ਦੀ ਲਾਈਵਨੈੱਸ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਕਹਿੰਦੇ ਹੋ, ਤਾਂ ਇਹ KFC ਲੱਭਣ ਲਈ ਮੈਕਡੋਨਲਡਜ਼ ਜਾਣ ਵਰਗਾ ਹੈ। ਸਰਵਰ ਤੁਹਾਨੂੰ ਖਾਲੀ ਨਜ਼ਰਾਂ ਨਾਲ ਦੇਖਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਦੋਵੇਂ ਇੱਕ ਦੂਜੇ ਵੱਲ ਦੇਖਦੇ ਹੋ। ਅੰਤ ਵਿੱਚ, ਮੋਨਿਟ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਹੇਠਾਂ ਹੋ ਅਤੇ ਬੇਚੈਨੀ ਨਾਲ ਮੁੜ ਚਾਲੂ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ।

ਰੀਸਟਾਰਟ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਪੋਰਟ ਅਜੇ ਵੀ 8081 ਹੈ। ਫਿਰ ਮੋਨਿਟ ਪੋਰਟ 80 ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ ਅਸਫਲ ਵੀ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਦੁਬਾਰਾ ਰੀਸਟਾਰਟ ਹੁੰਦਾ ਹੈ। ਇਹ ਚੱਕਰ ਉਦੋਂ ਤੱਕ ਦੁਹਰਾਇਆ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਮੋਨਿਟ ਇਹ ਫੈਸਲਾ ਨਹੀਂ ਕਰਦਾ ਕਿ ਇਹ ਮੁਰੰਮਤ ਤੋਂ ਪਰੇ ਹੈ ਅਤੇ ਸਮਾਂ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ।

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

ਇੱਕ ਖਰਾਬ Apache2 PID ਫਾਈਲ ਕਾਰਨ ਮੋਨਿਟ ਨੇ ਗਲਤੀ ਨਾਲ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਗੈਰ-ਮੌਜੂਦ ਵਜੋਂ ਪਛਾਣ ਲਿਆ।

ਪੋਰਟ ਨੂੰ 80 ਤੋਂ 8081 ਵਿੱਚ ਬਦਲਣ ਤੋਂ ਬਾਅਦ, ਮੋਨਿਟ ਨੂੰ ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ ਇਸਦਾ ਪਤਾ ਲਗਾਉਣ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਠੀਕ ਹੈ?

ਹਾਲਾਂਕਿ, ਅਸਲੀਅਤ ਵਿੱਚ, ਇਹ ਅਜੇ ਵੀ ਕਦੇ-ਕਦੇ "ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਅਸਫਲ " ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ।

ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਸੰਘਰਸ਼ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਮੈਨੂੰ ਅੰਤ ਵਿੱਚ ਪਤਾ ਲੱਗਾ ਕਿ ਕਾਰਨ ਸਧਾਰਨ ਸੀ: PID ਫਾਈਲ ਖਰਾਬ ਹੋ ਗਈ ਸੀ।

ਇਸ ਬਾਰੇ ਸੋਚੋ, ਮੋਨਿਟ ਬੇਚੈਨੀ ਨਾਲ Apache2 ਨੂੰ ਰੀਸਟਾਰਟ ਕਰ ਰਿਹਾ ਸੀ, ਹਰ ਵਾਰ ਜ਼ਬਰਦਸਤੀ ਇਸਨੂੰ ਮਾਰ ਰਿਹਾ ਸੀ ਅਤੇ ਰੀਸਟਾਰਟ ਕਰ ਰਿਹਾ ਸੀ, ਕਈ ਵਾਰ ਅੱਗੇ-ਪਿੱਛੇ ਜਾ ਰਿਹਾ ਸੀ। ਇਸ ਪ੍ਰਕਿਰਿਆ ਦੌਰਾਨ, /var/run/apache2/apache2.pid ਫਾਈਲ 0 ਬਾਈਟ ਹੋ ਸਕਦੀ ਹੈ।

ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਫਾਈਲ ਅਜੇ ਵੀ ਉੱਥੇ ਹੈ, ਪਰ ਇਹ ਖਾਲੀ ਹੈ।

ਜਦੋਂ ਮੋਨਿਟ ਇਸ ਫਾਈਲ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਕੁਝ ਵੀ ਨਹੀਂ ਮਿਲਦਾ। ਇਹ ਤੁਹਾਡੇ Apache2 ਨੂੰ ਨਹੀਂ ਪਛਾਣਦਾ, ਭਾਵੇਂ ਤੁਹਾਡਾ Apache2 ਬੈਕਗ੍ਰਾਊਂਡ ਵਿੱਚ ਬਿਲਕੁਲ ਠੀਕ ਚੱਲ ਰਿਹਾ ਹੋਵੇ; ਮੋਨਿਟ ਨੂੰ ਨਹੀਂ ਲੱਗਦਾ ਕਿ ਇਹ ਪ੍ਰਕਿਰਿਆ ਮੌਜੂਦ ਹੈ।

ਜਦੋਂ ਮੈਂ ਇਹ ਦੇਖਿਆ, ਤਾਂ ਮੈਂ ਇੱਕ ਪਲ ਲਈ ਬੇਵਕੂਫ਼ ਰਹਿ ਗਿਆ।

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

HestiaCP ਵਾਤਾਵਰਣ ਵਿੱਚ Apache2 ਨਿਗਰਾਨੀ ਲਈ ਸਮੱਸਿਆ ਨਿਪਟਾਰਾ ਅਤੇ ਮੁਰੰਮਤ ਦੇ ਕਦਮ

ਇਮਾਨਦਾਰੀ ਨਾਲ ਕਹਾਂ ਤਾਂ, ਜਾਂਚ ਪ੍ਰਕਿਰਿਆ ਗੁੰਝਲਦਾਰ ਨਹੀਂ ਹੈ, ਪਰ ਤੁਹਾਨੂੰ ਇਹ ਜਾਣਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਕਿਸ ਦਿਸ਼ਾ ਵਿੱਚ ਜਾਂਚ ਕਰਨੀ ਹੈ।

ਪਹਿਲਾ ਕਦਮ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨਾ ਹੈ ਕਿ ਤੁਹਾਡਾ Apache2 ਕਿਸ ਪੋਰਟ 'ਤੇ ਸੁਣ ਰਿਹਾ ਹੈ। ਬਸ ਟਰਮੀਨਲ ਵਿੱਚ ਇੱਕ ਕਮਾਂਡ ਟਾਈਪ ਕਰੋ।

netstat -tulpn | grep apache2

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਤੁਸੀਂ `ss` ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ; ਪ੍ਰਭਾਵ ਉਹੀ ਹੈ।

ss -tulpn | grep apache2

ਤੁਸੀਂ ਇਸ ਦੇ ਸਮਾਨ ਆਉਟਪੁੱਟ ਵੇਖੋਗੇ।

tcp  0  0 127.0.0.1:8081       0.0.0.0:*  LISTEN  2942372/apache2

ਇਹ 8081 ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਹੋਈ ਹੈ, 80 ਨਹੀਂ। ਇਹੀ ਸਮੱਸਿਆ ਦੀ ਜੜ੍ਹ ਹੈ।

ਦੂਜਾ ਕਦਮ ਖਰਾਬ ਹੋਈ PID ਫਾਈਲ ਦੀ ਮੁਰੰਮਤ ਕਰਨਾ ਹੈ। ਇਹ ਸੌਖਾ ਹੈ।

monit unmonitor apache2
systemctl restart apache2
cat /var/run/apache2/apache2.pid

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

ਇੱਕ ਵਾਰ ਜਦੋਂ ਇਹ ਕਦਮ ਪੂਰਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸਮੱਸਿਆ ਮੂਲ ਰੂਪ ਵਿੱਚ ਹੱਲ ਹੋ ਜਾਂਦੀ ਹੈ।

ਮੋਨੀਟ ਪਰੰਪਰਾਗਤ ਅਨੁਕੂਲ ਅਤੇ ਹਮਲਾਵਰ ਸੁਰੱਖਿਆ ਸੰਰਚਨਾਵਾਂ ਦਾ ਤੁਲਨਾਤਮਕ ਵਿਸ਼ਲੇਸ਼ਣ

Apache2 ਨੂੰ Monit ਨਾਲ ਕੌਂਫਿਗਰ ਕਰਨ ਬਾਰੇ ਔਨਲਾਈਨ ਟਿਊਟੋਰਿਅਲ ਆਮ ਤੌਰ 'ਤੇ ਦੋ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ ਆਉਂਦੇ ਹਨ।

ਇੱਕ ਕਿਸਮ "ਰਵਾਇਤੀ ਅਨੁਕੂਲਨ ਕਿਸਮ" ਹੈ, ਜੋ ਸੇਵਾਵਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਅਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਗੁੰਝਲਦਾਰ ਪਾਬੰਦੀਆਂ ਨੂੰ ਜੋੜਨ ਤੋਂ ਬਿਨਾਂ ਸਥਾਨਕ ਪੋਰਟਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ `service` ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ। ਇਸ ਸੰਰਚਨਾ ਨੂੰ HestiaCP 'ਤੇ ਸਿਰਫ਼ ਪੋਰਟ ਨੂੰ ਬਦਲ ਕੇ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹ ਮੁਕਾਬਲਤਨ ਸਥਿਰ ਹੈ।

ਇੱਕ ਹੋਰ ਤਰੀਕਾ "ਅਗਰੈਸਿਵ ਪ੍ਰੋਟੈਕਸ਼ਨ" ਹੈ, ਜੋ ਸੇਵਾਵਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ systemctl ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਚਾਈਲਡ ਪ੍ਰਕਿਰਿਆ ਪਾਬੰਦੀਆਂ ਜੋੜਦਾ ਹੈ, ਅਤੇ ਸਖ਼ਤ ਖੋਜ ਤਰਕ ਨੂੰ ਨਿਯੁਕਤ ਕਰਦਾ ਹੈ। ਇਹ ਬਹੁਤ ਵਧੀਆ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਪਰ ਇਸ ਵਿੱਚ ਇੱਕ ਘਾਤਕ ਨੁਕਸ ਹੈ: ਵਰਤੀ ਗਈ ਸਟਾਪ ਕਮਾਂਡ `killall -9` ਹੈ।

`killall -9` ਦਾ ਕੀ ਅਰਥ ਹੈ? ਇਸਦਾ ਅਰਥ ਹੈ ਡਿਵਾਈਸ ਨੂੰ ਜ਼ਬਰਦਸਤੀ ਮਾਰਨਾ ਭਾਵੇਂ ਇਹ ਕੁਝ ਵੀ ਕਰ ਰਿਹਾ ਹੋਵੇ। ਇਹ ਬਰੂਟ-ਫੋਰਸ ਓਪਰੇਸ਼ਨ ਆਸਾਨੀ ਨਾਲ ਖਰਾਬ PID ਫਾਈਲਾਂ ਨੂੰ ਪਿੱਛੇ ਛੱਡ ਸਕਦਾ ਹੈ, ਜੋ ਕਿ ਸਮੱਸਿਆ ਹੈ ਜਿਸਦਾ ਮੈਂ ਹੁਣੇ ਜ਼ਿਕਰ ਕੀਤਾ ਹੈ।

ਮੇਰਾ ਨਿੱਜੀ ਤਜਰਬਾ ਇਹ ਹੈ ਕਿ ਇੱਕ ਹਮਲਾਵਰ ਸੰਰਚਨਾ ਵਿੱਚ ਚਾਈਲਡ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਸੀਮਤ ਕਰਨਾ ਸੱਚਮੁੱਚ ਲਾਭਦਾਇਕ ਹੈ। ਜਦੋਂ ਤੁਹਾਡਾ Apache2 ਇੱਕ CC ਹਮਲੇ ਦੁਆਰਾ ਭਰਿਆ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਚਾਈਲਡ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਸੀਮਤ ਕਰਨ ਨਾਲ ਸਰਵਰ ਨੂੰ ਮੈਮੋਰੀ ਖਤਮ ਹੋਣ ਤੋਂ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਹਾਲਾਂਕਿ, `killall -9` ਪਹੁੰਚ ਸੱਚਮੁੱਚ ਵਰਤੋਂ ਯੋਗ ਨਹੀਂ ਹੈ।

ਇਸ ਲਈ ਅੰਤ ਵਿੱਚ ਮੈਂ ਸਮਝੌਤਾ ਕੀਤਾ ਅਤੇ ਦੋਵਾਂ ਸੰਰਚਨਾਵਾਂ ਦੇ ਫਾਇਦਿਆਂ ਨੂੰ ਜੋੜ ਦਿੱਤਾ।

HestiaCP Apache2 Monit ਸਰਵੋਤਮ ਅਭਿਆਸ ਸੰਰਚਨਾ

ਹੇਠ ਦਿੱਤੀ ਸਮੱਗਰੀ ਨਾਲ /etc/monit/conf.d/apache2 ਫਾਈਲ ਨੂੰ ਸੋਧੋ।

check process apache2 with pidfile /var/run/apache2/apache2.pid
    start program = "/bin/systemctl start apache2"
    stop program  = "/bin/systemctl stop apache2"
    if children > 120 for 2 cycles then restart
    if failed host 127.0.0.1 port 8081 protocol http for 2 cycles then restart
    if 5 restarts within 10 cycles then timeout

ਮੈਨੂੰ ਇਹਨਾਂ ਕੁਝ ਲਾਈਨਾਂ ਦੇ ਸੰਰਚਨਾ ਪਿੱਛੇ ਤਰਕ ਬਾਰੇ ਸੰਖੇਪ ਵਿੱਚ ਦੱਸਣ ਦਿਓ।

HestiaCP ਦੇ ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ ਆਰਕੀਟੈਕਚਰ ਨਾਲ ਬਿਲਕੁਲ ਮੇਲ ਕਰਨ ਲਈ ਪੋਰਟ 8081 ਲਿਖੋ; ਮੂਰਖਤਾ ਨਾਲ ਪੋਰਟ 80 ਲਿਖਣਾ ਬੰਦ ਕਰੋ।

PID ਫਾਈਲ ਨੂੰ ਰੋਕਣ ਲਈ `killall -9` ਦੀ ਬਜਾਏ `systemctl stop` ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰੋ, ਤਾਂ ਜੋ ਇਹ ਖਰਾਬ ਨਾ ਹੋਵੇ।

ਇੱਕ ਚਾਈਲਡ ਪ੍ਰਕਿਰਿਆ ਸੀਮਾ ਜੋੜੀ ਗਈ ਹੈ: ਜੇਕਰ ਬੱਚਿਆਂ ਦੀ ਗਿਣਤੀ 120 ਤੋਂ ਵੱਧ ਜਾਂਦੀ ਹੈ, ਤਾਂ CC ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਣ ਲਈ ਪ੍ਰਕਿਰਿਆ ਲਗਾਤਾਰ ਦੋ ਚੱਕਰਾਂ ਤੋਂ ਬਾਅਦ ਮੁੜ ਸ਼ੁਰੂ ਹੋਵੇਗੀ, ਪਰ ਇਹ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹਮਲਾਵਰ ਨਹੀਂ ਹੈ।

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

ਅੰਤਿਮ ਸਮਾਂ ਸਮਾਪਤੀ ਸੀਮਾ ਨੂੰ 10 ਚੱਕਰਾਂ ਦੇ ਅੰਦਰ 5 ਵਾਰ ਮੁੜ-ਚਾਲੂ ਕਰਨ ਲਈ ਢਿੱਲ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਕਾਫ਼ੀ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਰਹਿੰਦੀ ਹੈ।

HestiaCP ਨਿਗਰਾਨੀ ਦੀ ਨਿਗਰਾਨੀਕੌਂਫਿਗਰੇਸ਼ਨ ਸਮੱਸਿਆ ਨਿਪਟਾਰਾ ਸੰਖੇਪ ਅਤੇ ਅਨੁਭਵ ਸਾਂਝਾਕਰਨ

ਕੌਂਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਬਦਲਾਅ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਮੈਂ apache2 ਦੀ ਨਿਗਰਾਨੀ ਕੀਤੀ, ਅਤੇ ਪੈਨਲ ਨੇ ਅੰਤ ਵਿੱਚ ਇੱਕ ਹਰਾ "OK" ਸੂਚਕ ਦਿਖਾਇਆ।

ਉਸ ਸਮੇਂ ਆਪਣੀਆਂ ਭਾਵਨਾਵਾਂ ਨੂੰ ਕਿਵੇਂ ਬਿਆਨ ਕਰਾਂ? ਇਹ ਇੱਕ ਕੀੜੇ ਨਾਲ ਜੂਝਦੇ ਹੋਏ ਦੋ ਦਿਨ ਬਿਤਾਉਣ ਵਰਗਾ ਸੀ, ਸਿਰਫ ਕਾਰਨ ਦਾ ਪਤਾ ਲਗਾਉਣ ਲਈ ਸੰਰਚਨਾ ਦੀ ਇੱਕ ਲਾਈਨ ਗਲਤ ਸੀ। ਇਹ ਨਿਰਾਸ਼ਾਜਨਕ ਅਤੇ ਹਾਸੋਹੀਣਾ ਦੋਵੇਂ ਸੀ।

ਮੋਨੀਟ ਆਪਣੇ ਆਪ ਵਿੱਚ ਇੱਕ ਚੰਗੀ ਚੀਜ਼ ਹੈ, ਅਤੇ ਡੈਮਨ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨਾ ਇੱਕ ਅਜਿਹਾ ਕੰਮ ਹੈ ਜੋ ਹਰ ਸਰਵਰ ਨੂੰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਪਰ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਬਹੁਤ ਸਾਰੇ ਔਨਲਾਈਨ ਟਿਊਟੋਰਿਅਲ ਇਸ ਧਾਰਨਾ 'ਤੇ ਅਧਾਰਤ ਹਨ ਕਿ "Apache2 ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਪੋਰਟ 80 ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ," ਜਦੋਂ ਕਿ HestiaCP ਇੱਕ ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਹ ਧਾਰਨਾ ਸੱਚ ਨਹੀਂ ਹੈ।

ਜੇਕਰ ਤੁਸੀਂ ਹਦਾਇਤਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਸਮੱਸਿਆ ਤੁਸੀਂ ਨਹੀਂ ਹੋ; ਇਹ ਹੈ ਕਿ ਟਿਊਟੋਰਿਅਲ ਤੁਹਾਡੇ ਨਾਲੋਂ ਵੱਖਰੇ ਦ੍ਰਿਸ਼ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ।

ਇਸ ਲਈ ਜੇਕਰ ਤੁਸੀਂ ਵੀ HestiaCP ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ ਅਤੇ Apache2 ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ Monit ਨਾਲ ਖੇਡ ਰਹੇ ਹੋ, ਤਾਂ ਦੋ ਗੱਲਾਂ ਯਾਦ ਰੱਖੋ: ਪੋਰਟ ਨੂੰ 8081 ਵਿੱਚ ਬਦਲੋ, ਅਤੇ ਇਸਨੂੰ ਰੋਕਣ ਲਈ `systemctl` ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰੋ, `killall -9` ਦੀ ਨਹੀਂ। ਜੇਕਰ ਤੁਸੀਂ ਇਹ ਦੋ ਗੱਲਾਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਹੋਰ ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਬਚਣ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

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

ਮੇਰਾ ਲੇਖ ਪੜ੍ਹਨ ਲਈ ਧੰਨਵਾਦ। ਅਗਲੀ ਵਾਰ ਮਿਲਦੇ ਹਾਂ।