ProHoster > Blog > Administracija > Što su zadaci jednostavniji, to više griješim.

Što su zadaci jednostavniji, to više griješim.

Što su zadaci jednostavniji, to više griješim.

Ova trivijalna zadaća pojavila se jednog petka i trebala je trajati 2-3 minute. Uglavnom, kao i obično.

Kolegica je zamolila da ispravim skriptu na njenom serveru. Uradio sam, predao joj i nenamjerno ispustio: "Vrijeme žuri pet minuta." Njezin server, neka se ona sama nosi s sinhronizacijom. Prošlo je pola sata, sat, a ona još uvijek mumlja i šapće.

"Budala!" - pomislio sam, prebacujući se u konzolu. poslužitelja — dobro, odvojiću još par minuta.

Pogledajmo, ntp, rdate, sdwdate nisu instalirani, timesyncd je isključen i nije pokrenut.

# 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

Ovdje odmah napominjem da je hardversko vrijeme točno: prema njemu će kasnije biti lakše orijentirati se.

Odavde su počeli redovi grešaka.

Greška prva. Samouvjerenost.

Kuc-kuc…

# 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

Sve je odlično, vrijeme je sinhronizirano, sistemsko odgovara hardverskom. "Uzmi", - ispustio sam i vratio se svojim stvarima.

"Što uzeti?" - zgroženo je rekla kolegica. - "Vrijeme je isto!"

Što više rješavate tipične zadatke, to se više zakovate u razmišljanju i već ne mislite da će stota ili tisućita situacija biti drugačija, ali ne ovog puta.

# 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

Sistemsko vrijeme ponovno nije ispravno.

Pokušajmo još jednom:

# 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

Probajmo drugačije:

# 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

A ovako:

# 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

Vrijeme se postavlja na djelić sekunde, a odmah zatim ponovno počinje "žuriti".

Međutim, u logovima, u trenutku takve ručne promjene, vidimo samo izvještaje sustava, da je vrijeme promijenjeno, odgovarajući u ispravnom/neispravnom smjeru i povremeno Resyncing od systemd-timesyncd.

Aug 25 21:18:51 wisi systemd[1]: Vrijeme je promijenjeno
Aug 25 21:18:51 wisi systemd-timesyncd[29258]: Sistem vrijeme promijenjeno. Resyncing.
Aug 25 21:18:51 wisi systemd[1187]: Vrijeme je promijenjeno
Aug 25 21:18:51 wisi systemd[1]: Vrijeme je promijenjeno
Aug 25 21:18:51 wisi systemd[1187]: Vrijeme je promijenjeno

ovdje

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

U tom trenutku već je trebalo tražiti uzrok, ali mozak je tijekom 18 godina administrativnog iskustva stekao statistiku grešaka u "vremenu" i iz navike ponovno optužuje sinhronizaciju.
Isključujemo je potpuno.

# 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

i u logovima

Aug 25 21:25:40 wisi systemd[1]: Vrijeme je promijenjeno
Aug 25 21:25:40 wisi systemd[1187]: Vrijeme je promijenjeno
Aug 25 21:29:30 wisi systemd[1]: Vrijeme je promijenjeno
Aug 25 21:29:30 wisi systemd[1187]: Vrijeme je promijenjeno

Resyncing nestalo je i ostali logovi su besprijekorno čisti.

Provjeravamo izlaze tcpdump na 123. portu na svim sučeljima. Nema zahtjeva, ali vrijeme još uvijek "bježi".

Greška druga. Žurba.

Do kraja radnog tjedna ostalo je sat vremena, a ne želim otići na vikend s neriješenim problemom (ne obraćajte pažnju na vrijeme u kodu, članak je pisan u sljedećim danima).
Umjesto da tražim uzrok, ponovno sam počeo smišljati objašnjenje rezultata. Kažem "smišljati" jer, bez obzira na to koliko god objašnjenja rezultata bila logična, to je pogrešan pristup rješavanju problema.

Ovaj server je streaming server koji pretvara DVB-S2 tok u IP. U DVB-S toku postoje vremenske oznake, pa ih prijemnici, multiplexeri, scrambleri i televizori često koriste za sinhronizaciju svojih sistemskih satova. DVB-S drajveri su uključeni u jezgro, pa je najbrži način da se garantovano ukloni DVB-S2 tok - isključiti kablove iz 'tanjira'. Na sreću, server je iza zida, pa je tako i biti.

Naravno, da je u logovima bilo ono što bi trebalo biti, ovo se ne bi dogodilo, ali o tome, opet, na kraju članka.

I budući da smo već uklonili sve satelitske signale, uklanjamo i zemaljske — usput cijepajući sve mrežne kablove. Server postaje odrezan od vanjskog svijeta i radi potpuno autonomno, ali sistemski satovi i dalje žure.

Radna nedelja je završena, a pitanje datuma/vremena na njemu nije kritično, pa se može jednostavno otići kući, ali ovdje pravim novi propust.

Greška treća. Savjetnici.

Nikada! Nikada ne postavljajte pitanja na forumima i općenito specijaliziranim (poput stackoverflow) sajtovima, ako odgovor na njih zahtijeva više od prostog istraživanja prve stranice Gugl rezultata i čitanja jedne stranice mana.

Pošalju vas natrag na Google, da pročitate opet isti man i objasne vam pravila foruma/sajta, ali ne daju odgovor.

Postoje objektivni faktori:

  • nitko osim vas ne može znati problem jednako dobro;
  • nitko ne može provesti testove u uvjetima poput vaših;

tako i subjektivni:

  • možda nećete dati sve ulaze za rješavanje zadatka, jer ste već smislili "ispravnu" pravcu i iznosite suštinu pitanja oslanjajući se na njega;
  • starješina (moderator, dugogodišnji član, admin) uvijek je u pravu, ako starješina nije u pravu… znate već...

Ako ste tokom odgovarajućih komentara ostali unutar okvira civilizovanog rečnika, to znači da imate čelične nerve.

Rešenje

Nema potrebe dijeliti zadatke na jednostavne i složene.

Prestajemo se oslanjati na svoje iskustvo, statistiku, savjetnike i počinjemo ne 'objašnjavati' konačni rezultat, nego dosljedno istraživati uzrok.

Ako netko postavlja vrijeme, tada bi trebao nastati odgovarajući sistemski poziv.

Kao što su najbolji dokumenti u softverskoj dokumentaciji izvorni kodovi, tako je u sistemskom administriranju najbolji pomoćnik - revizija, u našem slučaju. auditd.

Momenat sumnjeProučio sam manove, ali nisam bio do kraja siguran da se vrijeme u Linuxu može postaviti samo clock_settime i settimeofday, stoga sam za prvi test odabrao sve "odgovarajuće" pozive:

# 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

i odbacio s390_runtime_instr, stime, timerfd_create, koje auditctl nisam prepoznao, prvobitno sam pokrenuo reviziju u obliku:

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

Uverivši se da na mjestima logova koja me zanimaju nema drugih syscalls osim ta dva, dalje sam koristio samo njih.

Pokrećemo reviziju sistemskih poziva clock_settime i settimeofday i pokušavamo promijeniti datum:

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

Pet sekundi kašnjenja dodano kako bi naš "parazite" sigurno ispravio vrijeme.

Gledamo izvještaj:

# 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

Ovdje vidimo naš date i nepoznat nam chkcache_proces. Pojavio se u gornjem izvještaju jer je aureport sortirano ispravio ispis po datumu prilikom konverzije iz binarnog oblika, a događaj se dogodio u vrijeme koje smo postavili. date -s "2019-08-22 12:10:00".
Tko ga je stvorio?

# 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 — naš parazite je pronađen. Unatoč njegovom "malicioznom" ponašanju, ne možemo se odreći sustava uvjetnog pristupa, ali volio bih znati, oscam, WTF?

Odgovor brzo pronađen u izvorima:

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

Kako ovo lijepo izgleda ovdje zakomentirana linija warning’a…

Izvor: habr.com

Kupite pouzdan hosting za web stranice s DDoS zaštitom, VPS VDS servere 🔥 Kupite pouzdan hosting za web stranice s DDoS zaštitom, VPS VDS servere | ProHoster