ಪ್ರೊಹೋಸ್ಟರ್ > Блог > ಆಡಳಿತ > ಸರಳವಾದ ಕಾರ್ಯ, ನಾನು ಹೆಚ್ಚಾಗಿ ತಪ್ಪುಗಳನ್ನು ಮಾಡುತ್ತೇನೆ

ಸರಳವಾದ ಕಾರ್ಯ, ನಾನು ಹೆಚ್ಚಾಗಿ ತಪ್ಪುಗಳನ್ನು ಮಾಡುತ್ತೇನೆ

ಸರಳವಾದ ಕಾರ್ಯ, ನಾನು ಹೆಚ್ಚಾಗಿ ತಪ್ಪುಗಳನ್ನು ಮಾಡುತ್ತೇನೆ

ಈ ಕ್ಷುಲ್ಲಕ ಕಾರ್ಯವು ಒಂದು ಶುಕ್ರವಾರ ಮಧ್ಯಾಹ್ನ ಹುಟ್ಟಿಕೊಂಡಿತು ಮತ್ತು 2-3 ನಿಮಿಷಗಳ ಸಮಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕು. ಸಾಮಾನ್ಯವಾಗಿ, ಯಾವಾಗಲೂ ಹಾಗೆ.

ಸಹೋದ್ಯೋಗಿಯೊಬ್ಬರು ತಮ್ಮ ಸರ್ವರ್‌ನಲ್ಲಿ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಸರಿಪಡಿಸಲು ನನ್ನನ್ನು ಕೇಳಿದರು. ನಾನು ಅದನ್ನು ಮಾಡಿದೆ, ಅದನ್ನು ಅವನಿಗೆ ಹಸ್ತಾಂತರಿಸಿದ್ದೇನೆ ಮತ್ತು ಅಜಾಗರೂಕತೆಯಿಂದ ಕೈಬಿಟ್ಟೆ: "ಸಮಯವು 5 ನಿಮಿಷಗಳು ವೇಗವಾಗಿದೆ." ಸರ್ವರ್ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಅನ್ನು ಸ್ವತಃ ನಿರ್ವಹಿಸಲಿ. ಅರ್ಧ ಗಂಟೆ, ಒಂದು ಗಂಟೆ ಕಳೆದಿದೆ, ಮತ್ತು ಅವನು ಇನ್ನೂ ಉಬ್ಬಿದನು ಮತ್ತು ಸದ್ದಿಲ್ಲದೆ ಶಪಿಸಿದನು.

“ಮೂರ್ಖ! - ನಾನು ಯೋಚಿಸಿದೆ, ಸರ್ವರ್ ಕನ್ಸೋಲ್‌ಗೆ ಬದಲಾಯಿಸುತ್ತಿದ್ದೇನೆ - ಸರಿ, ನಾನು ಇನ್ನೂ ಒಂದೆರಡು ನಿಮಿಷಗಳ ಕಾಲ ವಿರಾಮ ತೆಗೆದುಕೊಳ್ಳುತ್ತೇನೆ.

ನೋಡೋಣ ntp, rdate, sdwdate ಸ್ಥಾಪಿಸಲಾಗಿಲ್ಲ timeyncd ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು ಚಾಲನೆಯಲ್ಲಿಲ್ಲ.

# 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 ಸ್ಟ್ರೀಮ್ ಅನ್ನು ತೆಗೆದುಹಾಕಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ವೇಗವಾದ ಮಾರ್ಗವೆಂದರೆ "ಪ್ಲೇಟ್‌ಗಳಿಂದ" ಬರುವ ಕೇಬಲ್‌ಗಳನ್ನು ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸುವುದು. ಅದೃಷ್ಟವಶಾತ್, ಸರ್ವರ್ ಗೋಡೆಯ ಹಿಂದೆ ಇದೆ, ಹಾಗಾಗಿ ಅದು ಇರಲಿ.

ಸಹಜವಾಗಿ, ಲಾಗ್‌ಗಳು ಇರಬೇಕಾದದ್ದನ್ನು ಹೊಂದಿದ್ದರೆ, ಇದು ಸಂಭವಿಸುತ್ತಿರಲಿಲ್ಲ, ಆದರೆ ಅದರ ಬಗ್ಗೆ ಹೆಚ್ಚು, ಮತ್ತೆ, ಲೇಖನದ ಕೊನೆಯಲ್ಲಿ.

ಸರಿ, ನಾವು ಈಗಾಗಲೇ ಎಲ್ಲಾ ಉಪಗ್ರಹ ಸಂಕೇತಗಳನ್ನು ತೆಗೆದುಹಾಕಿರುವುದರಿಂದ, ನಾವು ಭೂಮಂಡಲವನ್ನು ಸಹ ತೆಗೆದುಹಾಕುತ್ತೇವೆ - ಅದೇ ಸಮಯದಲ್ಲಿ ನಾವು ಎಲ್ಲಾ ನೆಟ್‌ವರ್ಕ್ ಕೇಬಲ್‌ಗಳನ್ನು ಹೊರತೆಗೆಯುತ್ತೇವೆ. ಸರ್ವರ್ ಹೊರಗಿನ ಪ್ರಪಂಚದಿಂದ ಕಡಿತಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಸಂಪೂರ್ಣವಾಗಿ ಸ್ವಾಯತ್ತವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ಸಿಸ್ಟಮ್ ಗಡಿಯಾರವು ಇನ್ನೂ ಅವಸರದಲ್ಲಿದೆ.

ಕೆಲಸದ ವಾರವು ಮುಗಿದಿದೆ, ಮತ್ತು ದಿನಾಂಕ/ಸಮಯದ ಸಮಸ್ಯೆಯು ನಿರ್ಣಾಯಕವಾಗಿಲ್ಲ, ಆದ್ದರಿಂದ ನೀವು ಮನೆಗೆ ಹೋಗಬಹುದು, ಆದರೆ ಇಲ್ಲಿ ನಾನು ಹೊಸ ತಪ್ಪನ್ನು ಮಾಡುತ್ತೇನೆ.

ದೋಷ ಮೂರು. ಸಲಹೆಗಾರರು

ಎಂದಿಗೂ! ಫೋರಮ್‌ಗಳು ಮತ್ತು ಸಾಮಾನ್ಯ ವಿಶೇಷ (ಎ ಲಾ ಸ್ಟಾಕ್‌ಓವರ್‌ಫ್ಲೋ) ಸೈಟ್‌ಗಳಲ್ಲಿ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಬೇಡಿ, ಅದಕ್ಕೆ ಉತ್ತರವು Google ನ ಮೊದಲ ಪುಟವನ್ನು ಅಧ್ಯಯನ ಮಾಡುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಮತ್ತು ಒಂದು ಮ್ಯಾನ್ ಪುಟವನ್ನು ಓದುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಬಯಸುತ್ತದೆ.

ಅವರು ನಿಮ್ಮನ್ನು Google ಗೆ ಮರಳಿ ಕಳುಹಿಸುತ್ತಾರೆ, ಅದೇ ವ್ಯಕ್ತಿಯನ್ನು ಓದುತ್ತಾರೆ ಮತ್ತು ಫೋರಂ/ಸೈಟ್‌ನ ನಿಯಮಗಳನ್ನು ಜನಪ್ರಿಯವಾಗಿ ವಿವರಿಸುತ್ತಾರೆ, ಆದರೆ ನಿಮಗೆ ಉತ್ತರವನ್ನು ನೀಡುವುದಿಲ್ಲ.

ಕೆಲವು ವಸ್ತುನಿಷ್ಠ ಅಂಶಗಳು ಇಲ್ಲಿವೆ:

  • ನಿಮ್ಮನ್ನು ಹೊರತುಪಡಿಸಿ ಯಾರೂ ಸಮಸ್ಯೆಯನ್ನು ತಿಳಿದುಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ;
  • ನಿಮ್ಮ ರೀತಿಯ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಯಾರೂ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುವಂತಿಲ್ಲ

ಮತ್ತು ವ್ಯಕ್ತಿನಿಷ್ಠ:

  • ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ನೀವು ಎಲ್ಲಾ ಇನ್ಪುಟ್ ಅನ್ನು ನೀಡದಿರಬಹುದು, ಏಕೆಂದರೆ ನೀವು ಈಗಾಗಲೇ "ಸರಿಯಾದ" ನಿರ್ದೇಶನದೊಂದಿಗೆ ಬಂದಿದ್ದೀರಿ ಮತ್ತು ಅದರ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುವ ಸಮಸ್ಯೆಯ ಸಾರವನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತಿದ್ದೀರಿ;
  • ಫೋರ್‌ಮ್ಯಾನ್ (ಮಾಡರೇಟರ್, ಓಲ್ಡ್-ಟೈಮರ್, ಅಡ್ಮಿನ್) ಯಾವಾಗಲೂ ಸರಿ, ಫೋರ್‌ಮ್ಯಾನ್ ತಪ್ಪಾಗಿದ್ದರೆ ... ನಿಮಗೆ ತಿಳಿದಿದೆ ...

ಕಾಮೆಂಟ್‌ಗಳಿಗೆ ಉತ್ತರಿಸುವಾಗ, ನೀವು ಸೆನ್ಸಾರ್ ಮಾಡಲಾದ ಶಬ್ದಕೋಶದ ಮಿತಿಯೊಳಗೆ ಉಳಿದಿದ್ದರೆ, ನೀವು ಬಲವಾದ ನರಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ.

ನಿರ್ಧಾರವನ್ನು

ಕಾರ್ಯಗಳನ್ನು ಸರಳ ಮತ್ತು ಸಂಕೀರ್ಣವಾಗಿ ವಿಭಜಿಸುವ ಅಗತ್ಯವಿಲ್ಲ.

ನಾವು ನಮ್ಮ ಅನುಭವ, ಅಂಕಿಅಂಶಗಳು, ಸಲಹೆಗಾರರನ್ನು ಅವಲಂಬಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತೇವೆ ಮತ್ತು ಅಂತಿಮ ಫಲಿತಾಂಶವನ್ನು "ವಿವರಿಸಲು" ಪ್ರಾರಂಭಿಸುವುದಿಲ್ಲ, ಆದರೆ ನಿರಂತರವಾಗಿ ಕಾರಣವನ್ನು ಹುಡುಕುತ್ತೇವೆ.

ಯಾರಾದರೂ ಸಮಯವನ್ನು ಹೊಂದಿಸುವುದರಿಂದ, ಅನುಗುಣವಾದ ಸಿಸ್ಟಮ್ ಕರೆ ಸಂಭವಿಸಬೇಕು.

ಸಾಫ್ಟ್‌ವೇರ್ ದಸ್ತಾವೇಜನ್ನು ಉತ್ತಮ ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳು ಮೂಲಗಳಾಗಿರುವಂತೆ, ಸಿಸ್ಟಮ್ ಆಡಳಿತದಲ್ಲಿ ಅತ್ಯುತ್ತಮ ಸಹಾಯಕ ಆಡಿಟ್ ಆಗಿದೆ, ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ ಆಡಿಟ್ಡ್.

ಒಂದು ಕ್ಷಣ ಅನುಮಾನನಾನು ಮನದ ಮೂಲಕ ಹೋದೆ, ಆದರೆ Linux ನಲ್ಲಿ ಸಮಯವನ್ನು ಮಾತ್ರ ಹೊಂದಿಸಬಹುದು ಎಂದು ಸಂಪೂರ್ಣವಾಗಿ ಖಚಿತವಾಗಿಲ್ಲ ಗಡಿಯಾರ_ಸೆಟ್ಟೈಮ್ и ದಿನದ ಸೆಟ್ಟೈಮ್, ಆದ್ದರಿಂದ ಮೊದಲ ಪರೀಕ್ಷೆಗಾಗಿ ನಾನು ಎಲ್ಲಾ "ಸೂಕ್ತವಾದ" ಕರೆಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ್ದೇನೆ:

# 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 -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

ನಾನು ಆಸಕ್ತಿ ಹೊಂದಿರುವ ಲಾಗ್ ಸ್ಥಳಗಳಲ್ಲಿ ಬೇರೆ ಯಾವುದೇ ಲಾಗ್‌ಗಳಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಂಡ ನಂತರ ಸಿಸ್ಕಾಲ್ಗಳು ಇವೆರಡನ್ನು ಹೊರತುಪಡಿಸಿ, ನಾನು ಅವುಗಳನ್ನು ಮಾತ್ರ ಬಳಸಿದ್ದೇನೆ.

ಸಿಸ್ಟಮ್ ಕರೆ ಆಡಿಟ್ ಅನ್ನು ಚಾಲನೆ ಮಾಡಲಾಗುತ್ತಿದೆ ಗಡಿಯಾರ_ಸೆಟ್ಟೈಮ್ и ದಿನದ ಸೆಟ್ಟೈಮ್ ಮತ್ತು ದಿನಾಂಕವನ್ನು ಬದಲಾಯಿಸಲು ಪ್ರಯತ್ನಿಸಿ:

# 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. ಬೈನರಿಯಿಂದ ಪರಿವರ್ತಿಸುವಾಗ aureport ದಿನಾಂಕದ ಪ್ರಕಾರ ಔಟ್‌ಪುಟ್ ಅನ್ನು ವಿಂಗಡಿಸಿದ ಕಾರಣ ಇದು ಮೇಲಿನ ವರದಿಯಲ್ಲಿ ಕೊನೆಗೊಂಡಿತು ಮತ್ತು ನಾವು ಹೊಂದಿಸುವ ಸಮಯದಲ್ಲಿ ಈವೆಂಟ್ ಸಂಭವಿಸಿದೆ ದಿನಾಂಕ -s "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

ಕಾಮೆಂಟ್ ಅನ್ನು ಸೇರಿಸಿ