Tämä vähäpätöinen tehtävä syntyi eräänä perjantai-iltapäivänä ja sen olisi pitänyt kestää 2-3 minuuttia. Yleisesti, kuten aina.
Kollegani pyysi minua korjaamaan komentosarjan hänen palvelimelleen. Tein sen, ojensin sen hänelle ja pudotin vahingossa: "Aika on 5 minuuttia nopeaa." Anna palvelimen hoitaa synkronointi itse. Puoli tuntia, tunti kului, ja hän edelleen puhalsi ja kirosi hiljaa.
"Tyhmä! "Ajattelin, että vaihdan palvelinkonsoliin - okei, pidän vielä muutaman minuutin tauon."
Me katsomme ntp, rdate, sdwdate ei asennettu Timesyncd pois käytöstä eikä käynnissä.
# 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
Tässä huomaan heti, että laitteiston aika on oikea: on helpompi navigoida pidemmälle.
Tästä alkoi virhesarja.
Ensimmäinen virhe. Itsetunto
Klikkaa-klik...
# 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
Kaikki on kunnossa, aika on synkronoitu, järjestelmän aika vastaa laitteistoa. "Ota se", sanoin ja palasin työhöni.
"Ota mitä? - kollega suuttui. "On sama aika!"
Mitä enemmän ratkaiset tyypillisiä ongelmia, sitä enemmän ajattelusi hämärtyy ja et enää ajattele, että sadas tai tuhannes tilanne on erilainen, mutta ei tällä kertaa.
# 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
Järjestelmän aika on taas väärä.
Yritetään uudestaan:
# 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
Tehdään toisin:
# 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
Ja niin:
# 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
Aika asetetaan sekunnin murto-osalle ja alkaa välittömästi "kiireillä".
Samaan aikaan lokeissa näemme tällaisen manuaalisen muutoksen aikaan vain järjestelmäraportteja, että kellonaika on muuttunut, vastaavasti, oikeaan/väärään suuntaan ja toisinaan. Synkronoidaan uudelleen systemd-timesyncd:stä.
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
täällä
# ps afx | grep "[1]187"
1187 ? Ss 0:02 /lib/systemd/systemd --user
Syytä piti tässä vaiheessa jo etsiä, mutta 18 vuoden hallinnon aikana aivot ovat keränneet tilastoja "aikavirheistä" ja syyttävät tottumuksesta taas synkronointia.
Sammuta se kokonaan.
# 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
ja lokeissa
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
Synkronoidaan uudelleen kadonnut ja muuten tukit ovat koskemattomia.
Johtopäätösten tarkistaminen tcpdump kaikkien liitäntöjen portissa 123. Pyyntöjä ei ole, mutta aika juoksee edelleen.
Virhe kaksi. Kiire
Työviikon loppuun on tunti jäljellä, enkä halua lähteä viikonlopuksi triviaalin ratkaisemattoman ongelman kanssa (älä kiinnitä huomiota koodin aikaan, artikkeli on kirjoitettu seuraavina päivinä ).
Ja tässä taas syyn etsimisen sijaan aloin yrittää keksiä selitystä tulokselle. Sanon "keksi", koska olipa tuloksen selitys kuinka looginen tahansa, se on virheellinen lähestymistapa ongelman ratkaisemiseen.
Tämä palvelin on suoratoistopalvelin ja muuntaa DVB-S2-virran IP-osoitteeksi. DVB-S-virta sisältää aikaleimoja, joten vastaanottimet, multiplekserit, sekoituslaitteet ja televisiot käyttävät niitä usein järjestelmän kellon synkronointiin. DVB-S-kortin ajurit on rakennettu ytimeen, joten nopein tapa varmistaa DVB-S2-virran poistaminen on irrottaa "levyiltä" tulevat kaapelit. Onneksi palvelin on seinän takana, olkoon niin.
Tietenkin, jos lokit olisivat sisältäneet sen, mitä siellä pitäisi olla, näin ei olisi tapahtunut, mutta siitä lisää artikkelin lopussa.
No, koska olemme jo poistaneet kaikki satelliittisignaalit, poistamme myös maanpäälliset - samalla vedämme kaikki verkkokaapelit irti. Palvelin erottuu ulkomaailmasta ja toimii täysin itsenäisesti, mutta järjestelmän kellolla on edelleen kiire.
Työviikko on ohi, eikä itse päivämäärä/kellonaika ole kriittinen, joten voit mennä kotiin, mutta tässä teen uuden virheen.
Virhe kolme. Neuvonantajat
Ei koskaan! Älä koskaan kysy kysymyksiä foorumeilla ja yleisillä erikoistuneilla (a la stackoverflow) -sivustoilla, jos niihin vastaaminen vaatii muutakin kuin Googlen ensimmäisen sivun ja yhden man-sivun lukemisen.
He lähettävät sinut takaisin Googleen, lukevat samaa miestä ja selittävät foorumin/sivuston säännöt, mutta eivät anna sinulle vastausta.
Tässä on joitain objektiivisia tekijöitä:
- kukaan paitsi sinä ei voi myöskään tietää ongelmaa;
- kukaan ei voi suorittaa testejä samoissa olosuhteissa kuin sinä
ja subjektiivinen:
- et ehkä anna kaikkea panosta ongelman ratkaisemiseen, koska olet jo keksinyt "oikean" suunnan ja esittelet asian ydintä keskittyen siihen;
- työnjohtaja (moderaattori, vanhanaikainen, admin) on aina oikeassa, jos työnjohtaja on väärässä... no, tiedäthän...
Jos pysyt kommentteihin vastatessasi sensuroidun sanaston rajoissa, sinulla on vahvat hermot.
päätös
Tehtäviä ei tarvitse jakaa yksinkertaisiin ja monimutkaisiin.
Lakkaamme luottamasta kokemukseemme, tilastoihimme, neuvonantajiimme ja alamme olla "selittelemättä" lopputulosta, vaan etsimään johdonmukaisesti syytä.
Koska joku asettaa ajan, vastaavan järjestelmäkutsun on tapahduttava.
Kuten ohjelmistodokumentaatiossa parhaat asiakirjat ovat lähteitä, niin myös järjestelmänhallinnassa paras apulainen on auditointi, meidän tapauksessamme auditoitu.
Epäilyn hetkiKävin manan läpi, mutta en ollut täysin varma, että kellonaikaa voi vain asettaa Linuxissa clock_settime и asetettu kellonaika, joten valitsin ensimmäiseen testiin kaikki "sopivat" kutsut:
# 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
ja heittää pois s390_runtime_instr, stime, timerfd_create, mikä auditctl ei tunnistanut sitä, käynnisti aluksi tarkastuksen muodossa:
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 utimesKun olen varmistanut, ettei minua kiinnostavissa lokipaikoissa ole muita lokeja syscalls Näiden kahden lisäksi käytin vain niitä edelleen.
Järjestelmäkutsun tarkastuksen suorittaminen clock_settime и asetettu kellonaika ja yritä muuttaa päivämäärää:
# auditctl -a exit,always -S clock_settime -S settimeofday && date -s "2019-08-22 12:10:00" && sleep 5 && auditctl -D
Viiden sekunnin viive lisätään, jotta "loinen" korjaa ajan taatusti.
Katsotaanpa raportti:
# 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
Tässä näemme meidän data ja meille tuntematon chkcache_processes. Se päätyi yllä olevaan raporttiin, koska aureport lajitteli tulosteen päivämäärän mukaan binääristä muunnettaessa ja tapahtuma tapahtui asettamamme hetkellä päivämäärä -s "2019-08-22 12:10:00".
Kuka synnytti hänet?
# 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 - loisemme on löydetty. Sen "haitallisesta" käytöksestä huolimatta on mahdotonta kieltäytyä ehdollisen pääsyn järjestelmästä, mutta haluaisin silti tietää oscam, MITÄ VITTUU?
Vastaus löytyy nopeasti :
#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");
}
Kuinka söpöltä täällä näyttää kommentoi ulos linja Varoitus...
Lähde: will.com