ProHoster > blog > Gweinyddiaeth > Po symlaf yw'r dasg, y mwyaf aml y byddaf yn gwneud camgymeriadau

Po symlaf yw'r dasg, y mwyaf aml y byddaf yn gwneud camgymeriadau

Po symlaf yw'r dasg, y mwyaf aml y byddaf yn gwneud camgymeriadau

Cododd y dasg ddibwys hon un prynhawn dydd Gwener a dylai fod wedi cymryd 2-3 munud o amser. Yn gyffredinol, fel bob amser.

Gofynnodd cydweithiwr i mi drwsio'r sgript ar ei weinydd. Fe wnes i hynny, ei roi iddo a gollwng yn anfwriadol: “Mae amser yn 5 munud yn gyflym.” Gadewch i'r gweinydd drin y cydamseriad ei hun. Hanner awr, aeth awr heibio, ac roedd yn dal i pwffian a melltithio'n dawel.

“Dwl! - meddyliais, gan newid i gonsol y gweinydd - iawn, byddaf yn cymryd seibiant am ychydig funudau eraill. ”

Gawn ni weld ntp, rdate, sdwdate heb ei osod amsersyncd anabl a ddim yn rhedeg.

# 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

Yma nodaf ar unwaith fod yr amser caledwedd yn gywir: bydd yn haws llywio ymhellach.

Dyma lle dechreuodd y gyfres o gamgymeriadau.

Y camgymeriad cyntaf. Hunan hyder

Cliciwch-clac...

# 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

Mae popeth yn iawn, mae'r amser wedi'i gydamseru, mae amser y system yn cyfateb i'r un caledwedd. “Cymerwch hi,” dywedais a dychwelais at fy musnes.

“Cymer beth? — yr oedd y cydweithiwr yn ddig. “Mae'r un amser!”

Po fwyaf y byddwch chi'n datrys problemau nodweddiadol, y mwyaf y bydd eich meddwl yn mynd yn blinker ac nid ydych chi'n meddwl mwyach y bydd y canfed neu'r filfed sefyllfa yn wahanol, ond nid y tro hwn.

# 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

Mae amser y system yn anghywir eto.

Gadewch i ni geisio eto:

# 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

Gadewch i ni ei wneud yn wahanol:

# 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

Ac fel hyn:

# 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

Mae'r amser wedi'i osod ar gyfer eiliad hollt, ac yn syth yn dechrau "rhuthro" eto.

Ar yr un pryd, yn y logiau, ar adeg newid â llaw o'r fath, dim ond adroddiadau system a welwn fod yr amser wedi newid, yn y drefn honno, i'r cyfeiriad cywir / anghywir ac yn achlysurol Wrthi'n cysoni o 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

yma

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

Ar y pwynt hwn, roedd angen edrych am y rheswm eisoes, ond dros 18 mlynedd o weinyddu, mae'r ymennydd wedi cronni ystadegau ar gamgymeriadau "amser" ac, allan o arfer, unwaith eto yn beio cydamseru.
Gadewch i ni ei ddiffodd yn llwyr. 

# 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

ac yn y logiau

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

Wrthi'n cysoni diflannodd ac fel arall mae'r boncyffion yn berffaith.

Gwirio'r casgliadau tcpdump ar borth 123 ar bob rhyngwyneb. Nid oes unrhyw geisiadau, ond mae amser yn dal i redeg i ffwrdd.

Gwall dau. Brwyn

Mae awr ar ôl tan ddiwedd yr wythnos waith, a dydw i ddim eisiau gadael am y penwythnos gyda phroblem ddibwys heb ei datrys (peidiwch â thalu sylw i'r amser yn y cod, ysgrifennwyd yr erthygl yn y dyddiau canlynol ).
Ac yma eto, yn lle chwilio am y rheswm, dechreuais geisio dod o hyd i esboniad am y canlyniad. Rwy’n dweud “dyfeisio” oherwydd ni waeth pa mor rhesymegol yw’r esboniad am y canlyniad, mae’n ddull diffygiol o ddatrys y broblem.

Mae'r gweinydd hwn yn weinydd ffrydio ac mae'n trosi'r ffrwd DVB-S2 i IP. Mae ffrwd DVB-S yn cynnwys stampiau amser, felly mae derbynyddion, amlblecwyr, sgramblo a setiau teledu yn aml yn eu defnyddio i gydamseru cloc y system. Mae gyrwyr bwrdd DVB-S yn cael eu cynnwys yn y cnewyllyn, felly y ffordd gyflymaf o sicrhau bod y ffrwd DVB-S2 yn cael ei thynnu i ffwrdd yw datgysylltu'r ceblau sy'n dod o'r “platiau”. Yn ffodus, mae'r gweinydd y tu ôl i'r wal, felly bydded felly.

Wrth gwrs, pe bai'r logiau wedi cynnwys yr hyn a ddylai fod yno, ni fyddai hyn wedi digwydd, ond yn fwy am hynny, eto, ar ddiwedd yr erthygl.

Wel, gan ein bod eisoes wedi cael gwared ar yr holl signalau lloeren, byddwn hefyd yn cael gwared ar rai daearol - ar yr un pryd rydyn ni'n tynnu'r holl geblau rhwydwaith allan. Daw'r gweinydd i ffwrdd o'r byd y tu allan ac mae'n gweithio'n gwbl annibynnol, ond mae cloc y system yn dal i fod ar frys.

Mae'r wythnos waith ar ben, ac nid yw'r mater dyddiad/amser ei hun yn hollbwysig, felly gallwch chi fynd adref, ond dyma fi'n gwneud camgymeriad newydd.

Gwall tri. Ymgynghorwyr

Byth! Peidiwch byth â gofyn cwestiynau ar fforymau a gwefannau arbenigol cyffredinol (a la stackoverflow) os yw'r ateb iddo yn gofyn am fwy nag astudio tudalen gyntaf Google a darllen tudalen un dyn.

Byddant yn eich anfon yn ôl at Google, yn darllen yr un dyn ac yn esbonio rheolau'r fforwm / gwefan yn boblogaidd, ond ni fyddant yn rhoi ateb i chi.

Dyma rai ffactorau gwrthrychol:

  • ni all neb heblaw eich bod chi'n gwybod y broblem hefyd;
  • ni all neb gynnal profion o dan yr un amodau â'ch rhai chi

a goddrychol:

  • efallai na fyddwch yn rhoi'r holl fewnbwn ar gyfer datrys y broblem, oherwydd eich bod eisoes wedi dod o hyd i'r cyfeiriad “cywir” ac yn cyflwyno hanfod y mater gan ganolbwyntio arno;
  • mae'r fforman (cymedrolwr, hen-amserydd, gweinyddwr) bob amser yn iawn, os yw'r fforman yn anghywir... wel, wyddoch chi...

Os ydych, wrth ateb sylwadau, wedi aros o fewn terfynau geirfa wedi'i sensro, yna mae gennych nerfau cryf.

penderfyniad

Nid oes angen rhannu tasgau yn rhai syml a chymhleth.

Rydyn ni'n rhoi'r gorau i ddibynnu ar ein profiad, ein hystadegau, ein hymgynghorwyr ac yn dechrau peidio ag “esbonio” y canlyniad terfynol, ond i chwilio'n gyson am y rheswm.

Gan fod rhywun yn gosod yr amser, rhaid i'r alwad system gyfatebol ddigwydd.

Yn union fel yn nogfennaeth meddalwedd y dogfennau gorau yw'r ffynonellau, felly mewn gweinyddiaeth system y cynorthwyydd gorau yw archwilio, yn ein hachos ni archwiliedig.

Moment o amheuaethEs i drwy'r mana, ond nid oeddwn yn gwbl sicr y gellir gosod yr amser yn Linux yn unig amser gosod cloc и amser gosod y dydd, felly ar gyfer y prawf cyntaf dewisais yr holl alwadau “addas”:

# 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

a thaflu s390_runtime_instr, stime, timerfd_create, sydd awditctl ddim yn ei gydnabod, lansiwyd archwiliad i ddechrau ar y ffurf:

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

Ar ôl gwneud yn siŵr nad oes unrhyw logiau eraill yn y lleoliadau log mae gennyf ddiddordeb ynddynt syscalls Heblaw y ddau hyn, defnyddiais hwy ymhellach yn unig.

Cynnal archwiliad galwadau system amser gosod cloc и amser gosod y dydd a cheisiwch newid y dyddiad:

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

Ychwanegir oedi o bum eiliad fel bod ein “parasit” yn sicr o gywiro'r amser.

Edrychwn ar yr adroddiad:

# 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

Yma gwelwn ein dyddiad ac yn anhysbys i ni chkcache_processes. Daeth i ben yn yr adroddiad uchod oherwydd bod aureport wedi didoli'r allbwn yn ôl dyddiad wrth drosi o ddeuaidd, a digwyddodd y digwyddiad ar yr amser a osodwyd gennym dyddiad -s "2019-08-22 12:10:00".
Pwy roddodd enedigaeth iddo?

# 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/lleol/bin/oscam - mae ein paraseit wedi'i ddarganfod. Er gwaethaf ei ymddygiad “maleisus”, mae’n amhosib gwrthod y system mynediad amodol, ond hoffwn wybod o hyd oscam, WTF?

Ceir yr ateb yn gyflym yn ffynonellau:

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

Pa mor giwt mae'n edrych yma sylwadau allan llinell rhybudd...

Ffynhonnell: hab.com

Ychwanegu sylw