কাজটি যত সহজ, ততবার আমি ভুল করি

এই তুচ্ছ কাজটি এক শুক্রবার বিকেলে শুরু হয়েছিল এবং 2-3 মিনিট সময় নেওয়া উচিত ছিল। সাধারণভাবে, বরাবরের মতো।

একজন সহকর্মী আমাকে তার সার্ভারে স্ক্রিপ্টটি ঠিক করতে বলেছিলেন। আমি এটা করেছি, তার হাতে তুলে দিলাম এবং অসাবধানতাবশত বাদ দিলাম: "সময় 5 মিনিট দ্রুত।" সার্ভারকে সিঙ্ক্রোনাইজেশন নিজেই পরিচালনা করতে দিন। আধঘণ্টা, একঘণ্টা পেরিয়ে গেল, তারপরও সে ফুঁপিয়ে ফুঁপিয়ে চুপচাপ অভিশাপ দিল।

“বোকা! — আমি ভেবেছিলাম, সার্ভার কনসোলে স্যুইচ করছি — ঠিক আছে, আমি আরও কয়েক মিনিটের জন্য বিরতি নেব।”

আমরা দেখি ntp, rdate, sdwdate ইনস্টল করা না টাইমসিএনডি অক্ষম এবং চলমান না।

# 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 স্ট্রীমকে আইপিতে রূপান্তর করে। DVB-S স্ট্রীমে টাইমস্ট্যাম্প রয়েছে, তাই রিসিভার, মাল্টিপ্লেক্সার, স্ক্র্যাম্বলার এবং টেলিভিশনগুলি প্রায়শই সিস্টেম ঘড়িকে সিঙ্ক্রোনাইজ করতে ব্যবহার করে। DVB-S বোর্ড ড্রাইভারগুলি কার্নেলের মধ্যে তৈরি করা হয়েছে, তাই DVB-S2 স্ট্রীমটি সরানো হয়েছে তা নিশ্চিত করার দ্রুততম উপায় হল "প্লেট" থেকে আসা তারের সংযোগ বিচ্ছিন্ন করা। সৌভাগ্যবশত, সার্ভারটি প্রাচীরের পিছনে রয়েছে, তাই এটি হোক।

অবশ্যই, লগগুলিতে যা থাকা উচিত তা যদি থাকত, তবে এটি ঘটত না, তবে নিবন্ধের শেষে এটির বিষয়ে আরও কিছু।

ঠিক আছে, যেহেতু আমরা ইতিমধ্যেই সমস্ত স্যাটেলাইট সংকেতগুলি সরিয়ে ফেলেছি, আমরা স্থলজগতগুলিকেও সরিয়ে দেব - একই সাথে আমরা সমস্ত নেটওয়ার্ক তারগুলি টেনে আনব। সার্ভারটি বাইরের বিশ্ব থেকে বিচ্ছিন্ন হয়ে যায় এবং সম্পূর্ণ স্বায়ত্তশাসিতভাবে কাজ করে, তবে সিস্টেম ঘড়িটি এখনও তাড়াহুড়ো করে।

কাজের সপ্তাহ শেষ হয়ে গেছে, এবং তারিখ/সময় সমস্যাটি নিজেই সমালোচনামূলক নয়, তাই আপনি কেবল বাড়িতে যেতে পারেন, কিন্তু এখানে আমি একটি নতুন ভুল করেছি।

ত্রুটি তিন. উপদেষ্টারা

কখনই না! ফোরাম এবং সাধারণ বিশেষায়িত (a la stackoverflow) সাইটগুলিতে কখনই প্রশ্ন জিজ্ঞাসা করবেন না যদি উত্তরের জন্য Google-এর প্রথম পৃষ্ঠা অধ্যয়ন করা এবং একটি ম্যান পৃষ্ঠা পড়ার চেয়ে আরও বেশি কিছুর প্রয়োজন হয়।

তারা আপনাকে Google-এ ফেরত পাঠাবে, একই ব্যক্তিকে পড়বে এবং ফোরাম/সাইটের নিয়মগুলি জনপ্রিয়ভাবে ব্যাখ্যা করবে, কিন্তু আপনাকে উত্তর দেবে না।

এখানে কিছু উদ্দেশ্যমূলক কারণ রয়েছে:

• আপনি ছাড়া কেউ সমস্যাটিও জানতে পারবে না;
• আপনার মতো একই অবস্থার অধীনে কেউ পরীক্ষা পরিচালনা করতে পারবে না

এবং বিষয়গত:

• আপনি সমস্যাটি সমাধানের জন্য সমস্ত ইনপুট নাও দিতে পারেন, কারণ আপনি ইতিমধ্যে "সঠিক" দিকনির্দেশ নিয়ে এসেছেন এবং এটিতে ফোকাস করে সমস্যার সারাংশ উপস্থাপন করছেন;
• ফোরম্যান (মডারেটর, ওল্ড-টাইমার, অ্যাডমিন) সবসময় সঠিক, যদি ফোরম্যান ভুল হয়... আচ্ছা, আপনি জানেন...

যদি, মন্তব্যের উত্তর দেওয়ার সময়, আপনি সেন্সর করা শব্দভান্ডারের সীমার মধ্যে থেকে যান, তাহলে আপনার শক্তিশালী স্নায়ু আছে।

রায়

সহজ এবং জটিল কাজগুলিকে ভাগ করার দরকার নেই।

আমরা আমাদের অভিজ্ঞতা, পরিসংখ্যান, উপদেষ্টাদের উপর নির্ভর করা বন্ধ করি এবং শেষ ফলাফলের "ব্যাখ্যা" করতে শুরু করি না, কিন্তু ধারাবাহিকভাবে কারণ অনুসন্ধান করতে শুরু করি।

যেহেতু কেউ সময় সেট করে, সংশ্লিষ্ট সিস্টেম কল অবশ্যই ঘটতে হবে।

যেমন সফ্টওয়্যার ডকুমেন্টেশনে সর্বোত্তম নথিগুলি উত্স হয়, তেমনি সিস্টেম প্রশাসনে সর্বোত্তম সহকারী হল অডিট, আমাদের ক্ষেত্রে নিরীক্ষা.

সন্দেহের মুহূর্তআমি মানার মধ্য দিয়ে গিয়েছিলাম, কিন্তু পুরোপুরি নিশ্চিত ছিলাম না যে শুধুমাত্র লিনাক্সে সময় সেট করা যাবে clock_settime и নির্ধারিত সময়, তাই প্রথম পরীক্ষার জন্য আমি সমস্ত "উপযুক্ত" কল বেছে নিয়েছি:

# 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

আমি আগ্রহী লগ অবস্থানগুলিতে অন্য কোনও লগ নেই তা নিশ্চিত করার পরে syscalls এই দুটি ছাড়াও, আমি তাদের আরও ব্যবহার করেছি।

একটি সিস্টেম কল অডিট চলমান clock_settime и নির্ধারিত সময় এবং তারিখ পরিবর্তন করার চেষ্টা করুন:

# 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