ProHoster > Blog > Beheer > Hoe eenvoudiger de taak, hoe vaker ik een fout maak

Hoe eenvoudiger de taak, hoe vaker ik een fout maak

Hoe eenvoudiger de taak, hoe vaker ik een fout maak

Deze triviale taak ontstond op een vrijdag en zou 2-3 minuten van mijn tijd in beslag nemen. Al met al, zoals altijd.

Een collega vroeg me om een script op zijn server te corrigeren. Ik deed het, leverde het in en liet toevallig vallen: "De tijd loopt 5 minuten voor." Zijn server, laat hem zelf maar uitzoeken met de synchronisatie. Een half uur, een uur ging voorbij, en hij blijft maar puffen en zachtjes mopperen.

"Onbenul!" dacht ik, terwijl ik naar de console overschakelde. de server "Nou goed, ik neem me nog een paar minuten."

We kijken, ntp, rdate, sdwdate niet geĆÆnstalleerd, timesyncd uitgeschakeld en niet actief.

# 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

Hierbij vermeld ik dat de hardwaretijd juist is: hierop zal het makkelijker zijn om verder te werken.

Hier begon de keten van fouten.

Fout Ć©Ć©n. Zelfvertrouwen.

Klikklik...

# 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

Alles werkt prima, de tijd is gesynchroniseerd, het systeem komt overeen met de hardware. "Neem het maar mee," zei ik en keerde terug naar mijn zaken.

"Wat meenemen?" protesteerde mijn collega. "De tijd is dezelfde!"

Hoe meer standaardtaken je oplost, hoe meer je denken beperkt raakt en je niet meer denkt dat de honderdste of duizendste situatie anders zal zijn, maar niet deze keer.

# 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

De systeemtijd is opnieuw onjuist.

Laten we het nog een keer proberen:

# 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

Laten we het anders doen:

# 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

En zo:

# 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

De tijd wordt in een fractie van een seconde ingesteld, en begint meteen weer "voor te lopen".

Bij deze handmatige wijziging zien we in de logs alleen rapporten van het systeem dat de tijd gewijzigd is, respectievelijk in de goede/foute richting en af en toe Resyncing van systemd-timesyncd.

Aug 25 21:18:51 wisi systemd[1]: De tijd is gewijzigd
Aug 25 21:18:51 wisi systemd-timesyncd[29258]: Systeemtijd gewijzigd. Resyncing.
Aug 25 21:18:51 wisi systemd[1187]: De tijd is gewijzigd
Aug 25 21:18:51 wisi systemd[1]: De tijd is gewijzigd
Aug 25 21:18:51 wisi systemd[1187]: De tijd is gewijzigd

hier

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

Op dit moment moest ik al naar de oorzaak zoeken, maar mijn brein heeft door 18 jaar administratie statistieken van "tijd"-fouten opgebouwd en beschuldigt uit gewoonte opnieuw de synchronisatie.
We schakelen het volledig uit.

# 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

en in de logs

Aug 25 21:25:40 wisi systemd[1]: De tijd is gewijzigd
Aug 25 21:25:40 wisi systemd[1187]: De tijd is gewijzigd
Aug 25 21:29:30 wisi systemd[1]: De tijd is gewijzigd
Aug 25 21:29:30 wisi systemd[1187]: De tijd is gewijzigd

Resyncing is verdwenen en de overige logs zijn onberispelijk schoon.

We controleren de uitgangen tcpdump via poort 123 op alle interfaces. Geen verzoeken, maar de tijd blijft "weglopen".

Fout twee. Haast.

Er is nog maar een uur tot het einde van de werkweek, en ik wil het weekend niet ingaan met een onopgelost probleem (let niet op de tijd in de code, het artikel werd in de daaropvolgende dagen geschreven).
En hier, in plaats van de oorzaak te zoeken, begon ik een verklaring voor het resultaat te verzinnen. Ik zeg 'verzinnen', omdat ongeacht hoe logisch de verklaringen voor het resultaat ook zijn, dit een foutieve benadering van het probleem is.

Deze server is een streamingserver en converteert de DVB-S2-stroom naar IP. In de DVB-S-stroom zijn tijdstempels aanwezig, dus ontvangers, multiplexers, scramblers en televisies gebruiken ze vaak voor het synchroniseren van systeemklokken. De DVB-S-stuurprogramma's zijn in de kernel ingebouwd, dus de snelste manier om de DVB-S2-stroom gegarandeerd te stoppen, is door de kabels van de 'schotels' los te koppelen. Gelukkig staat de server achter de muur, dus dat moet maar zo.

Natuurlijk, als de logs hadden bevat wat daar zou moeten staan, zou dit niet zijn gebeurd, maar daarover, wederom, aan het einde van het artikel.

En omdat we alle satellietsignalen hebben verwijderd, zullen we ook de terrestrische signalen verwijderen ā€” tegelijk trekken we alle netwerkkabels eruit. De server is afgesneden van de buitenwereld en werkt volledig autonoom, maar de systeemklok loopt nog steeds voor.

De werkweek is voorbij, en de vraag naar datum/tijd op de server is niet kritisch, dus kan ik gewoon naar huis gaan, maar hier maak ik opnieuw een fout.

Fout drie. Adviseurs.

Nooit! Stel nooit vragen op forums en gespecialiseerde (zoals stackoverflow) websites, als het antwoord meer vereist dan het doorbladeren van de eerste pagina van Google en het lezen van Ć©Ć©n pagina manueel.

Je wordt teruggestuurd naar Google om alles opnieuw te lezen in dezelfde man, en ze leggen je de regels van het forum/site populair uit, maar geven geen antwoord.

Hier zijn zowel objectieve factoren:

  • niemand kan de oorzaak van het probleem zo goed kennen als jij;
  • niemand kan tests uitvoeren onder dezelfde omstandigheden als jij;

en subjectieve factoren:

  • je kunt alle informatie voor het oplossen van het probleem niet geven, omdat je al de 'juiste' richting hebt bedacht en de kern van de vraag daarop baseert;
  • de senior (moderator, veteraan, admin) heeft altijd gelijk, als de senior ongelijk heeftā€¦ nou, je weet hoe dat gaatā€¦

Als je bij antwoordende opmerkingen binnen de fatsoenlijke taal bent gebleven, betekent dit dat je sterke zenuwen hebt.

Oplossing

Je hoeft taken niet te splitsen in eenvoudige en complexe.

Laten we stoppen met leunen op onze ervaring, statistieken, adviseurs en beginnen niet de uiteindelijke uitkomst te 'verklappen', maar stap voor stap de oorzaak te zoeken.

Als iemand de tijd instelt, moet er een overeenkomstige systeemaanroep plaatsvinden.

Net zoals in de softwaredocumentatie de beste documenten de bronbestanden zijn, zo is in systeembeheer de beste aanvulling een audit, in ons geval. auditd.

Een moment van twijfel.Ik heb de manpagina's doorlopen, maar was er niet helemaal zeker van dat de tijd in Linux alleen kon worden ingesteld met. clock_settime. en settimeofday., daarom heb ik voor de eerste test alle "geschikte" aanroepen gekozen:

# 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

en heb ik verwijderd. s390_runtime_instr, stime, timerfd_create., waarvan ik. auditctl in eerste instantie niet herkende, begon ik de audit met:

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.

Nadat ik me ervan verzekerde dat er geen andere meldingen in de logboeken waren op de plaatsen die me interesseerden. syscalls behalve deze twee, heb ik alleen deze gebruikt.

We starten de audit van de systeemaanroepen. clock_settime. en settimeofday. en proberen de datum te veranderen:

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

Er is een vertraging van vijf seconden toegevoegd zodat onze "parasiet" de tijd zeker kan corrigeren.

Laten we het rapport bekijken:

# 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

Hier zien we onze. date en een onbekende voor ons. chkcache_proces.. Hij kwam in het vorige rapport omdat aureport de uitvoer op datum sorteerde bij de conversie van de binaire weergave, en het voorval plaatsvond op de tijd die wij hadden ingesteld. date -s "2019-08-22 12:10:00"..
Wie heeft hem voortgebracht?

# 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 ā€” onze parasiet is gevonden. Ondanks zijn "kwaadaardige" gedrag is het niet mogelijk om het toegangscontrolesysteem op te geven, maar ik zou toch graag willen weten. oscam., WTF?

Het antwoord is snel te vinden in. de bronbestanden.:

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

Wat ziet dat er schattig uit hier. de gecommentarieerde. regel. van de waarschuwing.ā€¦

Bron: habr.com

Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers šŸ”„ Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers | ProHoster