Бұл маңызды емес тапсырма жұма күні түстен кейін пайда болды және 2-3 минут уақыт алуы керек еді. Жалпы, әдеттегідей.
Бір әріптесім оның серверіндегі сценарийді түзетуімді сұрады. Мен мұны істедім, оны оған бердім және байқаусызда тастадым: «Уақыт 5 минут жылдам». Серверге синхрондауды өзі басқаруға мүмкіндік беріңіз. Жарты сағат, бір сағат өтті, ол әлі де үріп, үнсіз қарғыс айтты.
«Ақымақ! — Мен сервер консоліне ауыса отырып, — жарайды, мен тағы бірнеше минут үзіліс жасаймын деп ойладым.
Қарайық ntp, rdate, sdwdate орнатылмаған timesycd өшірілген және жұмыс істемейді.
# 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
Мұнда мен аппараттық уақыт дұрыс екенін бірден атап өтемін: одан әрі шарлау оңайырақ болады.
Міне, қателер қатары басталды.
Бірінші қате. Өзіне деген сенімділік
Басу-клик...
# 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
Барлығы жақсы, уақыт синхрондалған, жүйе уақыты аппараттық құралға сәйкес келеді. «Ал», - дедім де, ісіме оралдым.
«Нені алайық? – деп ашуланды әріптес. «Бұл бір уақыт!»
Типтік есептерді қаншалықты көп шешсеңіз, соғұрлым сіздің ойыңыз жыпылықтайды және сіз енді жүздік немесе мыңдық жағдай басқаша болады деп ойламайсыз, бірақ бұл жолы емес.
# 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
Жүйе уақыты қайтадан дұрыс емес.
Қайталап көрейік:
# 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
Басқаша жасайық:
# 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
Және бұл сияқты:
# 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
Уақыт бір секундқа белгіленіп, бірден қайтадан «асығыс» бастайды.
Сонымен қатар, журналдарда мұндай қолмен өзгерту кезінде біз тек уақыттың сәйкесінше дұрыс/бұрыс бағытта және кейде өзгергені туралы жүйелік есептерді көреміз. Қайта синхрондау 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
осында
# ps afx | grep "[1]187"
1187 ? Ss 0:02 /lib/systemd/systemd --user
Осы сәтте оның себебін іздеу керек болды, бірақ 18 жыл бойы басқару миы «уақыт» қателері туралы статистиканы жинақтады және әдеттен тыс синхронизацияны тағы да айыптайды.
Оны толығымен өшірейік.
# 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
және журналдарда
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
Қайта синхрондау жоғалып кетті, әйтпесе бөренелер таза.
Қорытындыларды тексеру tcpdump барлық интерфейстердегі 123 портында. Өтініш жоқ, бірақ уақыт әлі зымырап жатыр.
Екінші қате. Асық
Жұмыс аптасының аяқталуына бір сағат қалды, мен демалыс күндері шешілмей жатқан болмашы мәселемен кеткім келмейді (кодтағы уақытқа назар аудармаңыз, мақала келесі күндері жазылған. ).
Міне, мен себебін іздеудің орнына, нәтижені түсіндіруге тырыстым. Мен «ойлап табу» деп айтамын, өйткені нәтиженің түсіндірмесі қаншалықты қисынды болса да, бұл мәселені шешудегі қате көзқарас.
Бұл сервер ағындық сервер болып табылады және DVB-S2 ағынын IP-ге түрлендіреді. DVB-S ағынында уақыт белгілері бар, сондықтан қабылдағыштар, мультиплексорлар, скрамблерлер және теледидарлар оларды жүйелік сағатты синхрондау үшін жиі пайдаланады. DVB-S тақтасының драйверлері ядроға салынған, сондықтан DVB-S2 ағынының жойылуын қамтамасыз етудің ең жылдам жолы «пластинкалардан» келетін кабельдерді ажырату болып табылады. Бақытымызға орай, сервер қабырғаның артында, солай болсын.
Әрине, егер журналдарда не болуы керек болса, бұл орын алмас еді, бірақ бұл туралы мақаланың соңында тағы да.
Біз барлық спутниктік сигналдарды алып тастағандықтан, біз жердегілерді де алып тастаймыз - сонымен бірге барлық желілік кабельдерді шығарамыз. Сервер сыртқы әлемнен ажыратылады және толығымен автономды жұмыс істейді, бірақ жүйелік сағат әлі де асығыс.
Жұмыс аптасы аяқталды, күн/уақыт мәселесінің өзі маңызды емес, сондықтан сіз жай ғана үйге бара аласыз, бірақ бұл жерде мен жаңа қателік жібердім.
Үшінші қате. Кеңесшілер
Ешқашан! Ешқашан форумдарда және жалпы мамандандырылған (a la stackoverflow) сайттарда сұрақ қоймаңыз, егер оған жауап Google-дың бірінші бетін оқып, бір адам бетін оқуды қажет етпесе.
Олар сізді Google-ға қайта жібереді, сол адамды оқып, форумның/сайттың ережелерін көпшілікке түсіндіреді, бірақ сізге жауап бермейді.
Міне, кейбір объективті факторлар:
- мәселені сізден басқа ешкім біле алмайды;
- Ешкім сіз сияқты шарттарда сынақ жүргізе алмайды
және субъективті:
- сіз мәселені шешуге барлық мүмкіндікті бермеуіңіз мүмкін, өйткені сіз «дұрыс» бағытты ойлап таптыңыз және оған назар аудара отырып, мәселенің мәнін ұсынып отырсыз;
- бригадир (модератор, ескі, админ) әрқашан дұрыс, егер бригадир қателессе... жарайды, сіз білесіз ...
Түсініктемелерге жауап бергенде, сіз цензураға ұшыраған сөздіктің шегінде қалсаңыз, онда сізде күшті жүйке бар.
шешім
Тапсырмаларды қарапайым және күрделі деп бөлудің қажеті жоқ.
Біз өз тәжірибемізге, статистикаға, кеңесшілерге сенуді доғарамыз және түпкілікті нәтижені «түсіндірмей», оның себебін дәйекті түрде іздей бастаймыз.
Біреу уақытты орнатқандықтан, сәйкес жүйелік қоңырау орын алуы керек.
Бағдарламалық жасақтамадағы құжаттамада ең жақсы құжаттар көздер болатыны сияқты, жүйе әкімшілігінде де ең жақсы көмекші аудит болып табылады, біздің жағдайда аудитт.
Бір сәт күмәнМен манадан өттім, бірақ Linux жүйесінде уақытты тек орнатуға болатынына толық сенімді емес едім сағат_орнату уақыты и күннің уақыты, сондықтан бірінші сынақ үшін мен барлық «қолайлы» қоңырауларды таңдадым:
# 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
және тастау s390_runtime_instr, stime, timerfd_create, қай auditctl оны танымады, бастапқыда келесі нысанда аудитті бастады:
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Мені қызықтыратын журнал орындарында басқа журналдар жоқ екеніне көз жеткізгеннен кейін қателіктер Осы екеуінен басқа мен тек соларды ғана қолдандым.
Жүйелік қоңыраулар аудитін іске қосу сағат_орнату уақыты и күннің уақыты және күнді өзгертуге тырысыңыз:
# auditctl -a exit,always -S clock_settime -S settimeofday && date -s "2019-08-22 12:10:00" && sleep 5 && auditctl -D
Біздің «паразит» уақытты түзетуге кепілдік беру үшін бес секундтық кідіріс қосылады.
Есепті қарастырайық:
# 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
Міне, біз өзімізді көреміз дата және бізге белгісіз chkcache_processes. Ол жоғарыдағы есепте аяқталды, өйткені екілік жүйеден түрлендіру кезінде aureport шығысты күні бойынша сұрыптады және оқиға біз орнатқан уақытта орын алды. күні -s "2019-08-22 12:10:00".
Оны кім дүниеге әкелді?
# 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 - біздің паразит табылды. Оның «зиянды» әрекетіне қарамастан, шартты кіру жүйесінен бас тарту мүмкін емес, бірақ мен әлі де білгім келеді. oscam, WTF?
Жауабын тез табуға болады :
#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");
}
Бұл жерде қандай сүйкімді көрінеді түсініктеме берді түзу ескерту...
Ақпарат көзі: www.habr.com