ਜਿੰਨਾ ਸੌਖਾ ਕੰਮ, ਓਨੀ ਹੀ ਵਾਰ ਮੈਂ ਗਲਤੀਆਂ ਕਰਦਾ ਹਾਂ

ਇਹ ਮਾਮੂਲੀ ਕੰਮ ਇੱਕ ਸ਼ੁੱਕਰਵਾਰ ਦੁਪਹਿਰ ਨੂੰ ਹੋਇਆ ਅਤੇ ਇਸ ਲਈ 2-3 ਮਿੰਟ ਦਾ ਸਮਾਂ ਲੈਣਾ ਚਾਹੀਦਾ ਸੀ। ਆਮ ਤੌਰ 'ਤੇ, ਹਮੇਸ਼ਾ ਵਾਂਗ.

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

“ਮੂਰਖ! - ਮੈਂ ਸੋਚਿਆ, ਸਰਵਰ ਕੰਸੋਲ 'ਤੇ ਸਵਿਚ ਕਰਨਾ - ਠੀਕ ਹੈ, ਮੈਂ ਕੁਝ ਹੋਰ ਮਿੰਟਾਂ ਲਈ ਬਰੇਕ ਲਵਾਂਗਾ।

ਚਲੋ ਵੇਖਦੇ ਹਾਂ ntp, rdate, sdwdate ਇੰਸਟਾਲ ਨਹੀਂ ਹੈ ਵਾਰ ਅਯੋਗ ਅਤੇ ਚੱਲ ਨਹੀਂ ਰਿਹਾ।

# timedatectl
      Local time: Sun 2019-08-25 20:44:39 +03
  Universal time: Sun 2019-08-25 17:44:39 UTC
        RTC time: Sun 2019-08-25 17:39:52
       Time zone: Europe/Minsk (+03, +0300)
     NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a

ਇੱਥੇ ਮੈਂ ਤੁਰੰਤ ਨੋਟ ਕਰਾਂਗਾ ਕਿ ਹਾਰਡਵੇਅਰ ਸਮਾਂ ਸਹੀ ਹੈ: ਅੱਗੇ ਨੈਵੀਗੇਟ ਕਰਨਾ ਆਸਾਨ ਹੋਵੇਗਾ।

ਇੱਥੋਂ ਹੀ ਗਲਤੀਆਂ ਦਾ ਸਿਲਸਿਲਾ ਸ਼ੁਰੂ ਹੋਇਆ।

ਪਹਿਲੀ ਗਲਤੀ. ਸਵੈ ਭਰੋਸਾ

ਕਲਿਕ-ਕਲਾਕ...

# systemctl enable systemd-timesyncd.service && systemctl start systemd-timesyncd.service && ntpdate 0.ru.pool.ntp.org && timedatectl set-ntp on && timedatectl
25 Aug 21:00:10 ntpdate[28114]: adjust time server 195.210.189.106 offset -249.015251 sec
      Local time: Sun 2019-08-25 21:00:10 +03
  Universal time: Sun 2019-08-25 18:00:10 UTC
        RTC time: Sun 2019-08-25 18:00:10
       Time zone: Europe/Minsk (+03, +0300)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: n/a

ਸਭ ਕੁਝ ਠੀਕ ਹੈ, ਸਮਾਂ ਸਮਕਾਲੀ ਹੈ, ਸਿਸਟਮ ਸਮਾਂ ਹਾਰਡਵੇਅਰ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। "ਇਸ ਨੂੰ ਲਓ," ਮੈਂ ਕਿਹਾ ਅਤੇ ਆਪਣੇ ਕਾਰੋਬਾਰ 'ਤੇ ਵਾਪਸ ਆ ਗਿਆ।

“ਕੀ ਲੈਣਾ? - ਸਾਥੀ ਨਾਰਾਜ਼ ਸੀ. "ਇਹ ਉਹੀ ਸਮਾਂ ਹੈ!"

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

# timedatectl
      Local time: Sun 2019-08-25 21:09:15 +03
  Universal time: Sun 2019-08-25 18:09:15 UTC
        RTC time: Sun 2019-08-25 18:05:04
       Time zone: Europe/Minsk (+03, +0300)
     NTP enabled: yes
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a

ਸਿਸਟਮ ਵਾਰ ਫਿਰ ਗਲਤ ਹੈ.

ਆਓ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ:

# ntpdate 0.ru.pool.ntp.org && timedatectl && sleep 1 && timedatectl
25 Aug 21:07:37 ntpdate[30350]: step time server 89.175.20.7 offset -249.220828 sec
      Local time: Sun 2019-08-25 21:07:37 +03
  Universal time: Sun 2019-08-25 18:07:37 UTC
        RTC time: Sun 2019-08-25 18:07:37
       Time zone: Europe/Minsk (+03, +0300)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: n/a
      Local time: Sun 2019-08-25 21:11:46 +03
  Universal time: Sun 2019-08-25 18:11:46 UTC
        RTC time: Sun 2019-08-25 18:07:37
       Time zone: Europe/Minsk (+03, +0300)
     NTP enabled: yes
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a

ਚਲੋ ਇਸਨੂੰ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਕਰੀਏ:

# date -s "2019-08-25 21:10:30" && date && sleep 1 && timedatectl
Sun Aug 25 21:10:30 +03 2019
Sun Aug 25 21:10:30 +03 2019
      Local time: Sun 2019-08-25 21:14:36 +03
  Universal time: Sun 2019-08-25 18:14:36 UTC
        RTC time: Sun 2019-08-25 18:10:30
       Time zone: Europe/Minsk (+03, +0300)
     NTP enabled: yes
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a

ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ:

# hwclock --hctosys && timedatectl && sleep 1 && timedatectl
      Local time: Sun 2019-08-25 21:11:31 +03
  Universal time: Sun 2019-08-25 18:11:31 UTC
        RTC time: Sun 2019-08-25 18:11:31
       Time zone: Europe/Minsk (+03, +0300)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: n/a
      Local time: Sun 2019-08-25 21:15:36 +03
  Universal time: Sun 2019-08-25 18:15:36 UTC
        RTC time: Sun 2019-08-25 18:11:32
       Time zone: Europe/Minsk (+03, +0300)
     NTP enabled: yes
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a

ਸਮਾਂ ਇੱਕ ਸਪਲਿਟ ਸਕਿੰਟ ਲਈ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਤੁਰੰਤ ਦੁਬਾਰਾ "ਕਾਹਲੀ" ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ।

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

Aug 25 21:18:51 wisi systemd[1]: Time has been changed
Aug 25 21:18:51 wisi systemd-timesyncd[29258]: System time changed. Resyncing.
Aug 25 21:18:51 wisi systemd[1187]: Time has been changed
Aug 25 21:18:51 wisi systemd[1]: Time has been changed
Aug 25 21:18:51 wisi systemd[1187]: Time has been changed

ਇੱਥੇ

# ps afx | grep "[1]187"
 1187 ?        Ss     0:02 /lib/systemd/systemd --user

ਇਸ ਮੌਕੇ 'ਤੇ, ਇਸ ਦਾ ਕਾਰਨ ਲੱਭਣਾ ਪਹਿਲਾਂ ਹੀ ਜ਼ਰੂਰੀ ਸੀ, ਪਰ ਪ੍ਰਸ਼ਾਸਨ ਦੇ 18 ਸਾਲਾਂ ਤੋਂ ਵੱਧ, ਦਿਮਾਗ ਨੇ "ਸਮੇਂ" ਦੀਆਂ ਗਲਤੀਆਂ 'ਤੇ ਅੰਕੜੇ ਇਕੱਠੇ ਕੀਤੇ ਹਨ ਅਤੇ, ਆਦਤ ਤੋਂ ਬਾਹਰ, ਦੁਬਾਰਾ ਸਮਕਾਲੀਕਰਨ ਨੂੰ ਜ਼ਿੰਮੇਵਾਰ ਠਹਿਰਾਇਆ ਹੈ।
ਚਲੋ ਇਸਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੰਦ ਕਰੀਏ।

# timedatectl set-ntp off && systemctl stop systemd-timesyncd.service
# hwclock --hctosys && timedatectl && sleep 1 && timedatectl
      Local time: Sun 2019-08-25 21:25:40 +03
  Universal time: Sun 2019-08-25 18:25:40 UTC
        RTC time: Sun 2019-08-25 18:25:40
       Time zone: Europe/Minsk (+03, +0300)
     NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a
      Local time: Sun 2019-08-25 21:29:31 +03
  Universal time: Sun 2019-08-25 18:29:31 UTC
        RTC time: Sun 2019-08-25 18:25:41
       Time zone: Europe/Minsk (+03, +0300)
     NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a

ਅਤੇ ਲਾਗ ਵਿੱਚ

Aug 25 21:25:40 wisi systemd[1]: Time has been changed
Aug 25 21:25:40 wisi systemd[1187]: Time has been changed
Aug 25 21:29:30 wisi systemd[1]: Time has been changed
Aug 25 21:29:30 wisi systemd[1187]: Time has been changed

ਮੁੜ ਸਿੰਕ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ ਗਾਇਬ ਹੋ ਗਿਆ ਹੈ ਅਤੇ ਨਹੀਂ ਤਾਂ ਲੌਗ ਪੁਰਾਣੇ ਹਨ।

ਸਿੱਟਿਆਂ ਦੀ ਜਾਂਚ ਕਰ ਰਿਹਾ ਹੈ tcpdump ਸਾਰੇ ਇੰਟਰਫੇਸਾਂ 'ਤੇ ਪੋਰਟ 123 'ਤੇ. ਕੋਈ ਬੇਨਤੀਆਂ ਨਹੀਂ ਹਨ, ਪਰ ਸਮਾਂ ਅਜੇ ਵੀ ਭੱਜ ਰਿਹਾ ਹੈ.

ਗਲਤੀ ਦੋ। ਕਾਹਲੀ

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

ਇਹ ਸਰਵਰ ਇੱਕ ਸਟ੍ਰੀਮਿੰਗ ਸਰਵਰ ਹੈ ਅਤੇ DVB-S2 ਸਟ੍ਰੀਮ ਨੂੰ IP ਵਿੱਚ ਬਦਲਦਾ ਹੈ। DVB-S ਸਟ੍ਰੀਮ ਵਿੱਚ ਟਾਈਮਸਟੈਂਪ ਹੁੰਦੇ ਹਨ, ਇਸਲਈ ਰਿਸੀਵਰ, ਮਲਟੀਪਲੈਕਸਰ, ਸਕ੍ਰੈਂਬਲਰ ਅਤੇ ਟੈਲੀਵਿਜ਼ਨ ਅਕਸਰ ਸਿਸਟਮ ਕਲਾਕ ਨੂੰ ਸਮਕਾਲੀ ਕਰਨ ਲਈ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। DVB-S ਬੋਰਡ ਡਰਾਈਵਰ ਕਰਨਲ ਵਿੱਚ ਬਣਾਏ ਗਏ ਹਨ, ਇਸ ਲਈ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ ਕਿ DVB-S2 ਸਟ੍ਰੀਮ ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਗਿਆ ਹੈ "ਪਲੇਟਾਂ" ਤੋਂ ਆਉਣ ਵਾਲੀਆਂ ਕੇਬਲਾਂ ਨੂੰ ਡਿਸਕਨੈਕਟ ਕਰਨਾ। ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਸਰਵਰ ਕੰਧ ਦੇ ਪਿੱਛੇ ਹੈ, ਇਸ ਲਈ ਇਹ ਹੋਵੇ.

ਬੇਸ਼ੱਕ, ਜੇ ਲੌਗਸ ਵਿੱਚ ਇਹ ਹੁੰਦਾ ਕਿ ਉੱਥੇ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਅਜਿਹਾ ਨਹੀਂ ਹੋਣਾ ਸੀ, ਪਰ ਲੇਖ ਦੇ ਅੰਤ ਵਿੱਚ ਇਸ ਬਾਰੇ ਹੋਰ ਵੀ.

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

ਕੰਮ ਦਾ ਹਫ਼ਤਾ ਖਤਮ ਹੋ ਗਿਆ ਹੈ, ਅਤੇ ਮਿਤੀ/ਸਮੇਂ ਦਾ ਮੁੱਦਾ ਆਪਣੇ ਆਪ ਵਿੱਚ ਨਾਜ਼ੁਕ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਤੁਸੀਂ ਬਸ ਘਰ ਜਾ ਸਕਦੇ ਹੋ, ਪਰ ਇੱਥੇ ਮੈਂ ਇੱਕ ਨਵੀਂ ਗਲਤੀ ਕਰਦਾ ਹਾਂ।

ਗਲਤੀ ਤਿੰਨ। ਸਲਾਹਕਾਰ

ਕਦੇ ਨਹੀਂ! ਫੋਰਮਾਂ ਅਤੇ ਜਨਰਲ ਸਪੈਸ਼ਲਾਈਜ਼ਡ (ਏ ਲਾ ਸਟੈਕਓਵਰਫਲੋ) ਸਾਈਟਾਂ 'ਤੇ ਕਦੇ ਵੀ ਸਵਾਲ ਨਾ ਪੁੱਛੋ ਜੇਕਰ ਇਸਦੇ ਜਵਾਬ ਲਈ ਗੂਗਲ ਦੇ ਪਹਿਲੇ ਪੰਨੇ ਦਾ ਅਧਿਐਨ ਕਰਨ ਅਤੇ ਇੱਕ ਮੈਨ ਪੇਜ ਨੂੰ ਪੜ੍ਹਨ ਤੋਂ ਵੱਧ ਦੀ ਲੋੜ ਹੈ।

ਉਹ ਤੁਹਾਨੂੰ ਗੂਗਲ 'ਤੇ ਵਾਪਸ ਭੇਜਣਗੇ, ਉਸੇ ਆਦਮੀ ਨੂੰ ਪੜ੍ਹਣਗੇ ਅਤੇ ਫੋਰਮ/ਸਾਈਟ ਦੇ ਨਿਯਮਾਂ ਦੀ ਪ੍ਰਸਿੱਧ ਵਿਆਖਿਆ ਕਰਨਗੇ, ਪਰ ਤੁਹਾਨੂੰ ਕੋਈ ਜਵਾਬ ਨਹੀਂ ਦੇਣਗੇ।

ਇੱਥੇ ਕੁਝ ਉਦੇਸ਼ ਕਾਰਕ ਹਨ:

• ਤੁਹਾਡੇ ਤੋਂ ਇਲਾਵਾ ਕੋਈ ਵੀ ਸਮੱਸਿਆ ਨੂੰ ਨਹੀਂ ਜਾਣ ਸਕਦਾ;
• ਕੋਈ ਵੀ ਤੁਹਾਡੇ ਵਰਗੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਟੈਸਟ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ

ਅਤੇ ਵਿਅਕਤੀਗਤ:

• ਤੁਸੀਂ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਸਾਰੀ ਜਾਣਕਾਰੀ ਨਹੀਂ ਦੇ ਸਕਦੇ ਹੋ, ਕਿਉਂਕਿ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ "ਸਹੀ" ਦਿਸ਼ਾ ਲੈ ਕੇ ਆਏ ਹੋ ਅਤੇ ਇਸ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਦੇ ਹੋਏ ਮੁੱਦੇ ਦਾ ਸਾਰ ਪੇਸ਼ ਕਰ ਰਹੇ ਹੋ;
• ਫੋਰਮੈਨ (ਸੰਚਾਲਕ, ਓਲਡ-ਟਾਈਮਰ, ਐਡਮਿਨ) ਹਮੇਸ਼ਾ ਸਹੀ ਹੁੰਦਾ ਹੈ, ਜੇਕਰ ਫੋਰਮੈਨ ਗਲਤ ਹੈ... ਠੀਕ ਹੈ, ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ...

ਜੇ, ਟਿੱਪਣੀਆਂ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਸਮੇਂ, ਤੁਸੀਂ ਸੈਂਸਰ ਕੀਤੀ ਸ਼ਬਦਾਵਲੀ ਦੀਆਂ ਸੀਮਾਵਾਂ ਦੇ ਅੰਦਰ ਰਹੇ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਮਜ਼ਬੂਤ ​​​​ਨਸ ਹੈ.

ਫੈਸਲੇ ਦਾ

ਕਾਰਜਾਂ ਨੂੰ ਸਧਾਰਨ ਅਤੇ ਗੁੰਝਲਦਾਰ ਵਿੱਚ ਵੰਡਣ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ.

ਅਸੀਂ ਆਪਣੇ ਤਜ਼ਰਬੇ, ਅੰਕੜਿਆਂ, ਸਲਾਹਕਾਰਾਂ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਾਂ ਅਤੇ ਅੰਤਮ ਨਤੀਜੇ ਨੂੰ "ਸਮਝਾਉਣਾ" ਨਹੀਂ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ, ਪਰ ਲਗਾਤਾਰ ਕਾਰਨ ਦੀ ਖੋਜ ਕਰਦੇ ਹਾਂ।

ਕਿਉਂਕਿ ਕੋਈ ਸਮਾਂ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ, ਅਨੁਸਾਰੀ ਸਿਸਟਮ ਕਾਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।

ਜਿਵੇਂ ਕਿ ਸੌਫਟਵੇਅਰ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਸਭ ਤੋਂ ਵਧੀਆ ਦਸਤਾਵੇਜ਼ ਸਰੋਤ ਹੁੰਦੇ ਹਨ, ਉਸੇ ਤਰ੍ਹਾਂ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਨ ਵਿੱਚ ਸਭ ਤੋਂ ਵਧੀਆ ਸਹਾਇਕ ਆਡਿਟ ਹੁੰਦਾ ਹੈ, ਸਾਡੇ ਕੇਸ ਵਿੱਚ ਆਡਿਟ ਕੀਤਾ.

ਸ਼ੱਕ ਦਾ ਇੱਕ ਪਲਮੈਂ ਮਾਨਾ ਵਿੱਚੋਂ ਲੰਘਿਆ, ਪਰ ਪੂਰਾ ਯਕੀਨ ਨਹੀਂ ਸੀ ਕਿ ਲੀਨਕਸ ਵਿੱਚ ਸਮਾਂ ਹੀ ਸੈੱਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ clock_settime и ਦਿਨ ਦਾ ਸਮਾਂ, ਇਸ ਲਈ ਪਹਿਲੇ ਟੈਸਟ ਲਈ ਮੈਂ ਸਾਰੀਆਂ "ਉਚਿਤ" ਕਾਲਾਂ ਦੀ ਚੋਣ ਕੀਤੀ:

# man syscalls | col | grep -F '(2)' | grep -vE '(:|;)' | grep -E '(time|date|clock)' | sed "s/(2).*//" | xargs -I SYSCALL echo "-S SYSCALL " | xargs echo
-S adjtimex -S clock_adjtime -S clock_getres -S clock_gettime -S clock_nanosleep -S clock_settime -S futimesat -S getitimer -S gettimeofday -S mq_timedreceive -S mq_timedsend -S rt_sigtimedwait -S s390_runtime_instr -S setitimer -S settimeofday -S stime -S time -S timer_create -S timer_delete -S timer_getoverrun -S timer_gettime -S timer_settime -S timerfd_create -S timerfd_gettime -S timerfd_settime -S times -S utime -S utimensat -S utimes

ਅਤੇ ਰੱਦ ਕਰਨਾ s390_runtime_instr, stime, timerfd_create, ਜੋ auditctl ਇਸ ਨੂੰ ਨਹੀਂ ਪਛਾਣਿਆ, ਸ਼ੁਰੂ ਵਿੱਚ ਫਾਰਮ ਵਿੱਚ ਇੱਕ ਆਡਿਟ ਸ਼ੁਰੂ ਕੀਤਾ:

auditctl -a exit,always -S adjtimex -S clock_adjtime -S clock_getres -S clock_nanosleep -S clock_settime -S futimesat -S getitimer -S gettimeofday -S mq_timedreceive -S mq_timedsend -S rt_sigtimedwait -S semtimedop -S setitimer -S settimeofday -S time -S timer_create -S timer_delete -S timer_getoverrun -S timer_gettime -S timer_settime -S timerfd_gettime -S timerfd_settime -S times -S utime -S utimensat -S utimes

ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਤੋਂ ਬਾਅਦ ਕਿ ਲੌਗ ਟਿਕਾਣਿਆਂ ਵਿੱਚ ਕੋਈ ਹੋਰ ਲੌਗ ਨਹੀਂ ਹਨ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਮੇਰੀ ਦਿਲਚਸਪੀ ਹੈ ਸਾਈਕਲ ਇਹਨਾਂ ਦੋਨਾਂ ਤੋਂ ਇਲਾਵਾ, ਮੈਂ ਉਹਨਾਂ ਨੂੰ ਅੱਗੇ ਵਰਤਿਆ.

ਇੱਕ ਸਿਸਟਮ ਕਾਲ ਆਡਿਟ ਚੱਲ ਰਿਹਾ ਹੈ clock_settime и ਦਿਨ ਦਾ ਸਮਾਂ ਅਤੇ ਮਿਤੀ ਨੂੰ ਬਦਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ:

# auditctl -a exit,always -S clock_settime -S settimeofday && date -s "2019-08-22 12:10:00" && sleep 5 && auditctl -D

ਇੱਕ ਪੰਜ-ਸਕਿੰਟ ਦੇਰੀ ਜੋੜੀ ਜਾਂਦੀ ਹੈ ਤਾਂ ਜੋ ਸਾਡੇ "ਪੈਰਾਸਾਈਟ" ਨੂੰ ਸਮੇਂ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਗਾਰੰਟੀ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ।

ਆਓ ਰਿਪੋਰਟ 'ਤੇ ਨਜ਼ਰ ਮਾਰੀਏ:

# aureport -s -i

Syscall Report
=======================================
# date time syscall pid comm auid event
=======================================
Warning - freq is non-zero and incremental flushing not selected.
1. 08/22/2019 12:10:00 settimeofday 3088 chkcache_proces root 479630
2. 08/26/2019 09:37:06 clock_settime 1538 date root 479629

ਇੱਥੇ ਸਾਨੂੰ ਸਾਡੇ ਵੇਖੋ ਦੀ ਮਿਤੀ ਅਤੇ ਸਾਡੇ ਲਈ ਅਣਜਾਣ chkcache_processes. ਇਹ ਉਪਰੋਕਤ ਰਿਪੋਰਟ ਵਿੱਚ ਖਤਮ ਹੋਇਆ ਕਿਉਂਕਿ ਔਰੀਪੋਰਟ ਨੇ ਬਾਈਨਰੀ ਤੋਂ ਪਰਿਵਰਤਿਤ ਕਰਨ ਵੇਲੇ ਆਉਟਪੁੱਟ ਨੂੰ ਮਿਤੀ ਅਨੁਸਾਰ ਕ੍ਰਮਬੱਧ ਕੀਤਾ, ਅਤੇ ਘਟਨਾ ਉਸ ਸਮੇਂ ਵਾਪਰੀ ਜਦੋਂ ਅਸੀਂ ਸੈੱਟ ਕੀਤਾ ਸੀ ਮਿਤੀ "2019-08-22 12:10:00".
ਉਸ ਨੂੰ ਕਿਸਨੇ ਜਨਮ ਦਿੱਤਾ?

# ausearch -sc settimeofday --comm "chkcache_proces"
----
time->Thu Aug 22 12:10:00 2019
type=PROCTITLE msg=audit(1566465000.000:479630): proctitle="/usr/local/bin/oscam"
type=SYSCALL msg=audit(1566465000.000:479630): arch=c000003e syscall=164 success=yes exit=0 a0=7fde0dfc6e60 a1=0 a2=136cf a3=713ba56 items=0 ppid=3081 pid=3088 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts20 ses=68149 comm="chkcache_proces" exe="/usr/local/bin/oscam" key=(null)

/usr/local/bin/oscam - ਸਾਡਾ ਪਰਜੀਵੀ ਲੱਭਿਆ ਗਿਆ ਹੈ. ਇਸਦੇ "ਭੈੜੇ" ਵਿਵਹਾਰ ਦੇ ਬਾਵਜੂਦ, ਸ਼ਰਤੀਆ ਪਹੁੰਚ ਪ੍ਰਣਾਲੀ ਤੋਂ ਇਨਕਾਰ ਕਰਨਾ ਅਸੰਭਵ ਹੈ, ਪਰ ਮੈਂ ਅਜੇ ਵੀ ਜਾਣਨਾ ਚਾਹਾਂਗਾ oscam, WTF?

ਇਸ ਦਾ ਜਵਾਬ ਜਲਦੀ ਮਿਲ ਜਾਂਦਾ ਹੈ ਸਰੋਤ ਕੋਡ:

#if defined(CLOCKFIX)
if (tv.tv_sec > lasttime.tv_sec || (tv.tv_sec == lasttime.tv_sec && tv.tv_usec >= lasttime.tv_usec)) // check for time issues!
{
  lasttime = tv; // register this valid time
}
  else
{
  tv = lasttime;
  settimeofday(&tv, NULL); // set time back to last known valid time
  //fprintf(stderr, "*** WARNING: BAD TIME AFFECTING WHOLE OSCAM ECM HANDLING, SYSTEMTIME SET TO LAST KNOWN VALID TIME **** n");
}

ਇਹ ਇੱਥੇ ਕਿੰਨਾ ਪਿਆਰਾ ਲੱਗਦਾ ਹੈ ਟਿੱਪਣੀ ਕੀਤੀ ਲਾਈਨ ਚੇਤਾਵਨੀ...

ਸਰੋਤ: www.habr.com