🥇कार्य जितना सरल होगा, मैं उतनी ही बार गलतियाँ करूँगा

यह छोटा-सा काम एक शुक्रवार दोपहर को उठा और इसमें 2-3 मिनट का समय लगना चाहिए था। सामान्य तौर पर, हमेशा की तरह।

एक सहकर्मी ने मुझसे अपने सर्वर पर स्क्रिप्ट ठीक करने के लिए कहा। मैंने इसे किया, इसे उसे सौंप दिया और अनजाने में गिरा दिया: "समय 5 मिनट तेज है।" सर्वर को सिंक्रोनाइज़ेशन स्वयं संभालने दें। आधा घंटा, एक घंटा बीत गया, और वह अभी भी फूला हुआ था और चुपचाप शाप दे रहा था।

"मूर्ख! - मैंने सोचा, सर्वर कंसोल पर स्विच करते हुए - ठीक है, मैं कुछ और मिनटों के लिए ब्रेक लूंगा।

चलो देखते हैं एनटीपी, आरडेट, एसडीडब्ल्यूडेट स्थापित नहीं हे टाइमसिंकडी अक्षम है और चल नहीं रहा है.

# 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

पुनः सिंक गायब हो गए और अन्यथा लॉग प्राचीन हैं।

निष्कर्षों की जाँच करना टीसीपीडम्प सभी इंटरफ़ेस पर पोर्ट 123 पर। कोई अनुरोध नहीं है, लेकिन समय अभी भी भागा जा रहा है।

त्रुटि दो. जल्दबाज़ी करना

कार्य सप्ताह समाप्त होने में एक घंटा बचा है, और मैं एक छोटी सी अनसुलझी समस्या के साथ सप्ताहांत के लिए नहीं निकलना चाहता (कोड में समय पर ध्यान न दें, लेख अगले दिनों में लिखा गया था) ).
और यहाँ फिर, कारण की तलाश करने के बजाय, मैंने परिणाम के लिए स्पष्टीकरण देने का प्रयास करना शुरू कर दिया। मैं "आविष्कार" कहता हूं क्योंकि परिणाम के लिए स्पष्टीकरण कितना भी तार्किक क्यों न हो, यह समस्या को हल करने का एक त्रुटिपूर्ण दृष्टिकोण है।

यह सर्वर एक स्ट्रीमिंग सर्वर है और DVB-S2 स्ट्रीम को IP में परिवर्तित करता है। डीवीबी-एस स्ट्रीम में टाइमस्टैम्प होते हैं, इसलिए रिसीवर, मल्टीप्लेक्सर्स, स्क्रैम्बलर और टेलीविज़न अक्सर सिस्टम घड़ी को सिंक्रनाइज़ करने के लिए उनका उपयोग करते हैं। DVB-S बोर्ड ड्राइवर कर्नेल में निर्मित होते हैं, इसलिए DVB-S2 स्ट्रीम को हटा दिए जाने को सुनिश्चित करने का सबसे तेज़ तरीका "प्लेट्स" से आने वाले केबलों को डिस्कनेक्ट करना है। सौभाग्य से, सर्वर दीवार के पीछे है, तो ऐसा ही होगा।

निःसंदेह, यदि लॉग में वह शामिल होता जो होना चाहिए, तो ऐसा नहीं होता, लेकिन उस पर और अधिक जानकारी, फिर से, लेख के अंत में।

खैर, चूंकि हमने पहले ही सभी उपग्रह सिग्नल हटा दिए हैं, हम स्थलीय सिग्नल भी हटा देंगे - साथ ही हम सभी नेटवर्क केबल भी हटा देंगे। सर्वर बाहरी दुनिया से कट जाता है और पूरी तरह से स्वायत्त रूप से काम करता है, लेकिन सिस्टम घड़ी अभी भी जल्दी में है।

कार्य सप्ताह समाप्त हो गया है, और दिनांक/समय का मुद्दा स्वयं महत्वपूर्ण नहीं है, इसलिए आप बस घर जा सकते हैं, लेकिन यहां मैं एक नई गलती करता हूं।

त्रुटि तीन. सलाहकार

कभी नहीं! फ़ोरम और सामान्य विशिष्ट (एक ला स्टैकओवरफ़्लो) साइटों पर कभी भी प्रश्न न पूछें यदि इसके उत्तर के लिए Google के पहले पृष्ठ का अध्ययन करने और एक मैन पेज को पढ़ने से अधिक की आवश्यकता होती है।

वे आपको वापस Google पर भेज देंगे, उसी आदमी को पढ़ेंगे और फ़ोरम/साइट के नियमों को लोकप्रिय रूप से समझाएंगे, लेकिन आपको कोई उत्तर नहीं देंगे।

यहां कुछ वस्तुनिष्ठ कारक दिए गए हैं:

समस्या भी आपके अलावा कोई नहीं जान सकता;
कोई भी आपकी जैसी परिस्थितियों में परीक्षण नहीं कर सकता

और व्यक्तिपरक:

आप समस्या को हल करने के लिए सभी इनपुट नहीं दे सकते, क्योंकि आप पहले ही "सही" दिशा लेकर आ चुके हैं और उस पर ध्यान केंद्रित करते हुए मुद्दे का सार प्रस्तुत कर रहे हैं;
फोरमैन (मॉडरेटर, पुराने-टाइमर, व्यवस्थापक) हमेशा सही होता है, यदि फोरमैन गलत है... ठीक है, आप जानते हैं...

यदि, टिप्पणियों का उत्तर देते समय, आप सेंसर की गई शब्दावली की सीमा के भीतर रहते हैं, तो आपकी नसें मजबूत हैं।

समाधान

कार्यों को सरल और जटिल में विभाजित करने की आवश्यकता नहीं है।

हम अपने अनुभव, आँकड़ों, सलाहकारों पर भरोसा करना बंद कर देते हैं और अंतिम परिणाम को "व्याख्या" नहीं करना शुरू करते हैं, बल्कि लगातार कारण की तलाश करते हैं।

चूंकि कोई व्यक्ति समय निर्धारित करता है, इसलिए संबंधित सिस्टम कॉल अवश्य होनी चाहिए।

जिस प्रकार सॉफ़्टवेयर दस्तावेज़ीकरण में सबसे अच्छे दस्तावेज़ स्रोत होते हैं, उसी प्रकार हमारे मामले में सिस्टम प्रशासन में सबसे अच्छा सहायक ऑडिट होता है ऑडिट किया गया.

संदेह का क्षणमैं मन से गुजरा, लेकिन पूरी तरह से आश्वस्त नहीं था कि समय केवल लिनक्स में ही सेट किया जा सकता है घड़ी_सेटटाइम и settimeofday, इसलिए पहले परीक्षण के लिए मैंने सभी "उपयुक्त" कॉलों को चुना:

# 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 -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

यह सुनिश्चित करने के बाद कि जिन लॉग स्थानों में मेरी रुचि है, उनमें कोई अन्य लॉग नहीं है Syscalls इन दोनों के अलावा मैंने इनका ही आगे उपयोग किया।

सिस्टम कॉल ऑडिट चलाना घड़ी_सेटटाइम и settimeofday और दिनांक बदलने का प्रयास करें:

# 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. यह उपरोक्त रिपोर्ट में समाप्त हो गया क्योंकि ऑरेपोर्ट ने बाइनरी से कनवर्ट करते समय आउटपुट को दिनांक के अनुसार क्रमबद्ध किया, और घटना हमारे द्वारा निर्धारित समय पर हुई दिनांक -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 - हमारा परजीवी मिल गया है। इसके "दुर्भावनापूर्ण" व्यवहार के बावजूद, सशर्त पहुंच प्रणाली को अस्वीकार करना असंभव है, लेकिन मैं फिर भी जानना चाहूंगा ऑस्कैम, डब्ल्यूटीएफ?

इसका उत्तर तुरंत मिल जाता है सूत्रों का कहना है:

#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

कार्य जितना सरल होगा, उतनी ही अधिक बार मैं गलतियाँ करूँगा

पहली गलती. खुद पे भरोसा

त्रुटि दो. जल्दबाज़ी करना

त्रुटि तीन. सलाहकार

समाधान

एक टिप्पणी जोड़ें उत्तर रद्द