ProHoster > Blogg > Administration > Ju enklare uppgiften Àr, desto oftare gör jag misstag

Ju enklare uppgiften Àr, desto oftare gör jag misstag

Ju enklare uppgiften Àr, desto oftare gör jag misstag

Denna triviala uppgift uppstod en av fredagarna och skulle ta 2-3 minuters tid. SĂ„ som vanligt.

En kollega bad om en Àndring av skriptet pÄ sin server. Jag gjorde det, lÀmnade över det till honom och slÀngde utan att tÀnka: "Tiden gÄr snabbt med 5 minuter". Hans server fÄr han sjÀlv ta hand om synkroniseringen. Halv timme, en timme gick, och han fortsÀtter att svettas och mumla för sig sjÀlv.

"Du dumhuvud!" tÀnkte jag medan jag bytte till konsolen. servern "NÄvÀl, jag kan avbryta en stund till."

Vi kollar pÄ, ntp, rdate, sdwdate inte installerade, timesyncd avstÀngd och igÄng.

# 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

HÀr ska jag genast nÀmna att den hÄrdvaru-tid som finns Àr korrekt: pÄ den kan jag enklare orientera mig vidare.

HÀrifrÄn började en serie av misstag.

Första felet. SjÀlvsÀkerhet

Klick-klick


# 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

Allt Àr perfekt, tiden Àr synkroniserad, systemtiden stÀmmer överens med hÄrdvarutiden. "Ta den", sa jag och Ätergick till mina sysslor.

"Vad ska jag ta?" sa kollegan förvÄnat. "Tiden Àr densamma!"

Ju fler typiska uppgifter man löser, desto mer stÀnger man in sig och tÀnker inte att den hundrade eller tusende situationen kommer att vara annorlunda, men inte den hÀr gÄngen.

# 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

Systemtiden Àr Äterigen felaktig.

LĂ„t oss prova igen:

# 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

LÄt oss göra pÄ ett annat sÀtt:

# 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

Och sÄ hÀr:

# 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

Tiden stÀlls in pÄ en brÄkdel av en sekund, och börjar direkt att "gÄ snabbt" igen.

Vid den tidpunkten i loggarna, under en sÄdan manuell förÀndring, ser vi bara rapporter frÄn systemet om att tiden har förÀndrats, i riktning mot korrekt/inkorrekt och dÄ och dÄ Resyncing frÄn systemd-timesyncd.

Aug 25 21:18:51 wisi systemd[1]: Tiden har Àndrats
Aug 25 21:18:51 wisi systemd-timesyncd[29258]: Systemtiden har Àndrats. Resynkroniserar.
Aug 25 21:18:51 wisi systemd[1187]: Tiden har Àndrats
Aug 25 21:18:51 wisi systemd[1]: Tiden har Àndrats
Aug 25 21:18:51 wisi systemd[1187]: Tiden har Àndrats

hÀr

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

Vid den tiden borde jag redan ha börjat leta efter orsaken, men hjÀrnan har under 18 Är som administratör byggt upp statistik över "tidsfel" och skyller av vana fortfarande pÄ synkroniseringen.
Vi stÀnger av den helt.

# 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

och i loggarna

Aug 25 21:25:40 wisi systemd[1]: Tiden har Àndrats
Aug 25 21:25:40 wisi systemd[1187]: Tiden har Àndrats
Aug 25 21:29:30 wisi systemd[1]: Tiden har Àndrats
Aug 25 21:29:30 wisi systemd[1187]: Tiden har Àndrats

Resyncing försvann och resten av loggarna Àr oskadda.

Vi kontrollerar utsignaler Fungerar libdns korrekt? => Kör via port 123 pÄ alla grÀnssnitt. Inga förfrÄgningar finns, men tiden "springer" fortfarande bort.

Andra felet. Hastverk

Det ÄterstÄr en timme av arbetsveckan, och jag vill inte lÀmna för helgen med en lÀtt uppgift som Àr ogjord (lÀgg inte mÀrke till tiden i koden, artikeln skrevs under de följande dagarna).
Och hÀr, istÀllet för att leta efter orsaken, började jag försöka hitta en förklaring till resultatet. Jag sÀger "hitta", för oavsett hur logiska förklaringarna kan vara, Àr detta en felaktig metod för att lösa problemet.

Denna server Àr en streamingserver och omvandlar DVB-S2-strömmen till IP. I DVB-S-strömmen finns tidsstÀmplar, sÄ mottagare, multiplexorer, skrÀmblerare och TV-apparater anvÀnder ofta dem för att synkronisera systemtimmarna. DVB-S-drivrutinerna Àr kompilerade i kÀrnan, sÄ det snabbaste sÀttet att garantera att DVB-S2-strömmen försvinner Àr att koppla bort kablarna frÄn "parabolerna". Lyckligtvis Àr servern bakom vÀggen, sÄ sÄ fÄr det vara.

SjÀlvklart, om loggarna hade innehÄllit det som de skulle, skulle detta inte ha intrÀffat, men mer om det senare i artikeln.

Och nu nĂ€r vi har tagit bort alla satellitsignaler, lĂ„t oss ta bort Ă€ven de terrestriella – samtidigt drar vi ur alla nĂ€tverkskablar. Servern blir avskuren frĂ„n omvĂ€rlden och fungerar helt autonomt, men systemtimmarna rusar fortfarande.

Arbetsveckan Àr slut, och frÄgan om datum/tid Àr inte kritisk, sÄ vi kan helt enkelt gÄ hem, men hÀr gör jag ett nytt misstag.

Fel nummer tre. RĂ„dgivarna

Aldrig! StÀll aldrig frÄgor pÄ forum och allmÀnna specialiserade (som stackoverflow) webbplatser, om svaret krÀver mer Àn att lÀsa resultatet pÄ första sidan av Google och att lÀsa en sida av man.

Du kommer att bli skickad tillbaka till Google för att lÀsa samma man och fÄ reglerna för forumet/webbplatsen förklarade för dig, men du kommer inte fÄ nÄgot svar.

HÀr finns bÄde objektiva faktorer:

  • ingen annan Ă€n du kan veta problemet lika bra;
  • ingen kan utföra tester under samma förhĂ„llanden som du har;

och subjektiva:

  • du kanske inte ger alla ingĂ„ngar för att lösa uppgiften, för att du redan har tĂ€nkt pĂ„ den "rĂ€tta" riktningen och förklarar kĂ€rnan i frĂ„gan utifrĂ„n den;
  • den Ă€ldre (moderatorn, veteranen, administratören) har alltid rĂ€tt, om den Ă€ldre har fel... ja, du vet...

Om du hÄller dig inom ramarna för cencurerad vokabulÀr i dina svarskommentarer, betyder det att du har starka nerver.

Lösning

Det Àr inte nödvÀndigt att dela upp uppgifter i enkla och svÄra.

Vi slutar förlita oss pÄ vÄr erfarenhet, statistik, rÄdgivare och börjar inte "förklara" det slutliga resultatet, utan letar systematiskt efter orsaken.

Om nÄgon stÀller in tiden mÄste det dÀrför finnas ett motsvarande systemanrop.

Som i mjukvarudokumentationen Àr de bÀsta dokumenten kÀllkoden, sÄ Àr den bÀsta hjÀlpen inom systemadministration revision, i vÄrt fall. auditd.

En sekund av tvivel.Jag skummade igenom manualerna, men jag var inte helt sÀker pÄ att tiden i Linux bara kan stÀllas in med. clock_settime. och settimeofday., dÀrför valde jag för det första testet alla "lÀmpliga" anrop:

# 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

och bortsett ifrÄn. s390_runtime_instr, stime, timerfd_create., som. auditctl. inte kÀnde igen, startade jag ursprungligen revisionen med:

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.

Efter att ha försÀkrat mig om att det inte fanns andra i loggarna pÄ de stÀllen som intresserade mig. syscalls. förutom dessa tvÄ anvÀnde jag endast deras.

Vi startar revisionen av systemanrop. clock_settime. och settimeofday. och försöker Àndra datumet:

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

En fem sekunders fördröjning har lagts till sÄ att vÄr "parasit" garanterat kan justera tiden.

Vi ser rapporten:

# 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

HÀr ser vi vÄr. date och en okÀnd för oss. chkcache_proces.. Den dök upp i rapporten ovan eftersom aureport sorterade utdata efter datum vid omvandlingen frÄn binÀrt format, och hÀndelsen intrÀffade vid den tidpunkt vi stÀllde in. date -s "2019-08-22 12:10:00"..
Vem skapade den?

# 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 — vĂ„r parasit Ă€r hittad. Trots dess "skadliga" beteende kan vi inte avstĂ„ frĂ„n systemet för Ă„tkomstkontroll, men jag skulle Ă€ndĂ„ vilja veta. oscam., WTF?

Svaret hittades snabbt i. kÀllkoden.:

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

Hur snyggt ser det inte ut hÀr. den kommenterade. raden. av varningen.


KĂ€lla: habr.com

Köp pĂ„litlig webbhotell med DDoS-skydd, VPS VDS-servrar đŸ”„ Köp pĂ„litlig webbhotell med DDoS-skydd, VPS VDS-servrar | ProHoster