ProHoster > blog > administrasi > Semakin sederhana tugasnya, semakin sering saya melakukan kesalahan

Semakin sederhana tugasnya, semakin sering saya melakukan kesalahan

Semakin sederhana tugasnya, semakin sering saya melakukan kesalahan

Tugas sepele ini muncul pada suatu Jumat sore dan seharusnya memakan waktu 2-3 menit. Secara umum, seperti biasa.

Seorang kolega meminta saya untuk memperbaiki skrip di servernya. Saya melakukannya, menyerahkannya kepadanya dan secara tidak sengaja menjatuhkan: “Waktunya 5 menit cepat.” Biarkan server menangani sinkronisasi itu sendiri. Setengah jam, satu jam berlalu, dan dia masih terengah-engah dan diam-diam mengumpat.

"Bodoh! — Saya pikir, beralih ke konsol server — oke, saya akan istirahat beberapa menit lagi.”

Kami melihat ntp, rdate, sdwdate tidak terpasang sinkronisasi waktu dinonaktifkan dan tidak berjalan.

# 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

Di sini saya akan segera mencatat bahwa waktu perangkat keras sudah benar: akan lebih mudah untuk menavigasi lebih jauh.

Di sinilah rentetan kesalahan dimulai.

Kesalahan pertama. Percaya diri

Klik-klak...

# 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

Semuanya baik-baik saja, waktu tersinkronisasi, waktu sistem sesuai dengan waktu perangkat keras. “Ambillah,” kataku dan kembali ke urusanku.

"Ambil apa? - rekannya marah. “Ini waktu yang sama!”

Semakin banyak Anda memecahkan masalah-masalah yang umum, semakin pemikiran Anda menjadi kabur dan Anda tidak lagi berpikir bahwa situasi keseratus atau keseribu akan berbeda, tetapi tidak kali ini.

# 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

Waktu sistem salah lagi.

Mari coba lagi:

# 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

Mari kita lakukan secara berbeda:

# 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

Jadi:

# 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

Waktu disetel untuk sepersekian detik, dan segera mulai “bergegas” lagi.

Pada saat yang sama, dalam log, pada saat perubahan manual tersebut, kita hanya melihat sistem melaporkan bahwa waktu telah berubah, masing-masing, ke arah yang benar/salah dan kadang-kadang Menyinkronkan ulang dari 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

di sini

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

Pada titik ini, sudah perlu untuk mencari alasannya, tetapi selama 18 tahun pemerintahan, otak telah mengumpulkan statistik tentang kesalahan “waktu” dan, karena kebiasaan, sekali lagi menyalahkan sinkronisasi.
Mari kita matikan sepenuhnya. 

# 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

dan di log

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

Menyinkronkan ulang menghilang dan selain itu lognya masih asli.

Memeriksa kesimpulan tcpdump pada port 123 di semua antarmuka. Tidak ada permintaan, tapi waktu masih terus berjalan.

Kesalahan kedua. Bergegas

Masih ada satu jam lagi sampai akhir minggu kerja, dan saya tidak ingin berangkat akhir pekan dengan masalah sepele yang belum terselesaikan (jangan perhatikan waktu di kode, artikelnya ditulis di hari-hari berikutnya ).
Dan di sini lagi, alih-alih mencari alasannya, saya mulai mencoba memberikan penjelasan atas hasilnya. Saya mengatakan “menciptakan” karena betapapun logisnya penjelasan mengenai hasilnya, ini adalah pendekatan yang salah dalam memecahkan masalah.

Server ini adalah server streaming dan mengubah aliran DVB-S2 menjadi IP. Aliran DVB-S berisi stempel waktu, sehingga receiver, multiplexer, pengacak, dan televisi sering menggunakannya untuk menyinkronkan jam sistem. Driver papan DVB-S sudah terpasang di dalam kernel, jadi cara tercepat untuk memastikan bahwa aliran DVB-S2 dihilangkan adalah dengan melepaskan kabel yang berasal dari “pelat”. Untungnya, servernya ada di balik tembok, biarlah.

Tentu saja, jika log tersebut berisi apa yang seharusnya ada, hal ini tidak akan terjadi, tetapi lebih dari itu, sekali lagi, di akhir artikel.

Nah, karena kami telah menghapus semua sinyal satelit, kami juga akan menghapus sinyal terestrial - pada saat yang sama kami mencabut semua kabel jaringan. Server menjadi terputus dari dunia luar dan bekerja sepenuhnya secara mandiri, namun jam sistem masih terburu-buru.

Minggu kerja sudah selesai, dan masalah tanggal/waktunya sendiri belum kritis, jadi bisa pulang saja, tapi disini saya membuat kesalahan baru.

Kesalahan ketiga. Penasihat

Tidak pernah! Jangan pernah mengajukan pertanyaan di forum dan situs khusus umum (ala stackoverflow) jika jawabannya memerlukan lebih dari sekadar mempelajari halaman pertama Google dan membaca satu halaman manual.

Mereka akan mengirim Anda kembali ke Google, membaca orang yang sama dan menjelaskan aturan forum/situs secara populer, tetapi tidak akan memberi Anda jawaban.

Berikut adalah beberapa faktor obyektif:

  • tidak seorang pun kecuali Anda yang dapat mengetahui masalahnya juga;
  • tidak ada yang bisa melakukan tes dalam kondisi yang sama seperti Anda

dan subjektif:

  • Anda mungkin tidak memberikan semua masukan untuk penyelesaian masalah, karena Anda sudah menemukan arah yang “benar” dan sedang memaparkan inti permasalahan dengan fokus pada hal tersebut;
  • mandornya (moderator, oldtimer, admin) selalu benar, kalau mandornya salah.. nah lho..

Jika, saat membalas komentar, Anda tetap berada dalam batas kosakata yang disensor, maka Anda memiliki keberanian yang kuat.

keputusan

Tidak perlu membagi tugas menjadi sederhana dan rumit.

Kami berhenti mengandalkan pengalaman, statistik, penasihat kami dan mulai tidak “menjelaskan” hasil akhirnya, tetapi secara konsisten mencari alasannya.

Karena seseorang mengatur waktunya, panggilan sistem yang sesuai harus terjadi.

Sama seperti dalam dokumentasi perangkat lunak, dokumen terbaik adalah sumbernya, demikian pula dalam administrasi sistem, asisten terbaik adalah audit, dalam kasus kami auditd.

Sesaat keraguanSaya memeriksa mana, tetapi tidak sepenuhnya yakin bahwa waktu di Linux hanya dapat diatur jam_settime и settimeofday, jadi untuk tes pertama saya memilih semua panggilan yang “cocok”:

# 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

dan membuang s390_runtime_instr, stime, timerfd_create, yang auditctl tidak menyadarinya, awalnya melakukan audit berupa:

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

Setelah memastikan tidak ada log lain di lokasi log yang saya minati panggilan sistem Selain keduanya, saya hanya menggunakan keduanya saja.

Menjalankan audit panggilan sistem jam_settime и settimeofday dan coba ubah tanggalnya:

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

Penundaan lima detik ditambahkan sehingga “parasit” kami dijamin dapat mengoreksi waktu.

Mari kita lihat laporannya:

# 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

Di sini kita melihat milik kita tanggal dan tidak kita ketahui chkcache_processes. Itu berakhir di laporan di atas karena aureport mengurutkan output berdasarkan tanggal ketika mengkonversi dari biner, dan peristiwa tersebut terjadi pada waktu yang kita tetapkan tanggal -s "2019-08-22 12:10:00".
Siapa yang melahirkannya?

# 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 - parasit kita telah ditemukan. Meskipun perilakunya “berbahaya”, tidak mungkin untuk menolak sistem akses bersyarat, tapi saya tetap ingin mengetahuinya oscam, APA?

Jawabannya dapat dengan cepat ditemukan di kode sumber:

#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");
}

Betapa lucunya tampilannya di sini berkomentar garis peringatan...

Sumber: www.habr.com

Tambah komentar