لماذا تنحرف ساعة VPS وكيف تصلحها؟

سبب انحراف ساعة VPS

تنحرف ساعة VPS لأن لا شيء يصححها. تحسب النواة الوقت اعتماداً على عدّاد عتادي يعمل بسرعة أعلى أو أقل قليلاً، ومع عدم تشغيل عميل لمزامنة الوقت، يتراكم هذا الخطأ الصغير كل ساعة. توجد داخل الآلة الافتراضية علة ثانية: تشارك الآلة الافتراضية CPU فعلياً مع آلات افتراضية أخرى، ولذلك لا تستطيع حساب الوقت خلال الفترات التي لا تُجدول فيها.

في ضيف KVM حديث، نادراً ما يكون العدّاد نفسه هو المشكلة الفعلية. يقرأ مصدر kvm-clock شبه الافتراضي قيمة يحافظ عليها المضيف، ولذلك يتابع الضيف مضيفه بدقة كبيرة. تكون الساعات التي يظهر فيها خطأ واضح عادةً خاطئة لسبب أبسط. قد لا يكون أي daemon لمزامنة الوقت قيد التشغيل، أو قد يكون اثنان منهما قيد التشغيل ويتعارضان، أو قد لا يغادر UDP port 123 شبكة مزود الخدمة مطلقاً. يضبط الضيف وقته اعتماداً على المضيف أو على NTP (بروتوكول وقت الشبكة)، وليس اعتماداً على مذبذبه الخاص.

ما الذي يتعطّل فعلياً بسبب خطأ الساعة

• تتوقف رموز المصادقة الثنائية TOTP (كلمة المرور لمرة واحدة المستندة إلى الوقت) عن التطابق، لذلك تُمنع من الدخول إلى خادم رغم صحة كلمة المرور والمفتاح.
• تُرفض شهادة أُصدرت قبل دقيقة، ويطبع curl القيمة SSL certificate problem: certificate is not yet valid.
• يرفض apt update مستودعاً مع ظهور E: Release file for ... is not valid yet (invalid for another 1d 2h 3min 4s).
• تُنفَّذ المهام المجدولة في وقت غير صحيح، وقد يؤدي تغيّر الساعة المفاجئ إلى تشغيل إحدى المهام مرتين وتخطي مهمة أخرى.
• يتعذر ترتيب السجلات الواردة من خادمين على خط زمني واحد، لذلك يجب تجميع تسلسل الحادثة بالتخمين.

هامش السماح أصغر مما يتوقعه معظم الأشخاص. الأرقام أدناه هي القيم الافتراضية الموثقة، وليست قياسات من اختبار.

[
  {
    "label": "TLS certificate boundary",
    "tolerance_seconds": 0,
    "documented_in": "RFC 5280"
  },
  {
    "label": "chrony steps instead of slewing",
    "tolerance_seconds": 1,
    "documented_in": "Debian and Ubuntu chrony.conf"
  },
  {
    "label": "TOTP code, one time step",
    "tolerance_seconds": 30,
    "documented_in": "RFC 6238"
  },
  {
    "label": "Kerberos clock skew",
    "tolerance_seconds": 300,
    "documented_in": "MIT krb5 default"
  }
]

يُحسَب رمز TOTP من عدّاد يتقدم كل 30 ثانية، وتقبل معظم أدوات التحقق خطوة واحدة في أي من الاتجاهين. نصف دقيقة من الخطأ في كل اتجاه هو كامل الهامش المتاح. أما Kerberos فهو أكثر تسامحاً بكثير، إذ يبلغ هامش الانحراف الافتراضي لديه 300 ثانية. ولا تتسامح الشهادة مع الخطأ إطلاقاً؛ إذ تُفحَص مقابل لحظات زمنية ثابتة مع فترة سماح قدرها 0 ثانية، لذلك ترفض الساعة المتقدمة ثانية واحدة شهادةً صالحة تماماً.

الساعات الثلاث، وأيّها المهم

ساعة النظام هي المهمة. وهي CLOCK_REALTIME الخاصة بالنواة: عدد الثواني منذ 1 January 1970 UTC، المحفوظ في الذاكرة والذي تقرأه كل مكوّنات النظام التي تضيف طابعاً زمنياً. تأتي منها أسطر السجل، والتحقق من الشهادات، ورموز TOTP، وأوقات تعديل الملفات. عندما يقول أحدهم إن وقت الخادم غير صحيح، فهذه هي الساعة التي يقصدها.

ساعة العتاد، وتُسمى أيضاً RTC (ساعة الوقت الحقيقي)، هي عدّاد منفصل يستمر في العمل أثناء إيقاف تشغيل الجهاز. في الجهاز الفعلي تكون شريحة مدعومة ببطارية. أما داخل الضيف، فيحاكيها برنامج hypervisor، ولذلك فهي تعكس إلى حد كبير حالة المضيف. يقرأ Linux قيمتها مرة واحدة عند الإقلاع للحصول على قيمة ابتدائية، ثم يتابع العد باستخدام ساعته الخاصة. يعرضها timedatectl في السطر RTC time. لا تعتمد على هذا السطر لتصحيح مشكلة الوقت في VPS، لأنه يوضح تصور المضيف للوقت، لا حالة مزامنة ساعة النظام لديك. في الحاوية لا يوجد عادةً /dev/rtc أصلاً، ولذلك يفشل hwclock --show مع hwclock: Cannot access the Hardware Clock via any known method.

مصدر الساعة هو المصدر الذي تستخدمه النواة للعد بين عمليات القراءة تلك. اطلب من النواة معرفة المصدر الذي اختارته:

cat /sys/devices/system/clocksource/clocksource0/current_clocksource
cat /sys/devices/system/clocksource/clocksource0/available_clocksource

في KVM سترى عادةً kvm-clock. فهو يقرأ قيمة يحافظ عليها المضيف، ولهذا يبقى ضيف KVM الذي لا يشغّل عميلاً لـNTP قريباً من الوقت الصحيح لفترة من الزمن. أما tsc فهو عدّاد المعالج نفسه. تعرض ضيوف Xen القيمة xen، بينما تعرض ضيوف Hyper-V مصدراً من نوع hyperv. اترك هذا الإعداد كما هو ما لم يكن لديك سبب مقاس لتغييره، لأن النواة تختار بالفعل أفضل مصدر تثق به على تلك العتاد.

تتيح بعض المضيفات أيضاً جهاز PTP (بروتوكول الوقت الدقيق) للضيف، ما يسمح لـchrony بقراءة ساعة المضيف مباشرةً بدلاً من قراءتها عبر الشبكة. من المفيد التحقق من ذلك، وغالباً لا يتوفر على VPS مشترك:

sudo modprobe ptp_kvm
ls /dev/ptp*
cat /sys/class/ptp/ptp0/clock_name

إذا فشل modprobe أو لم يظهر أي جهاز، فهذا يعني أن المضيف لا يوفّره، وأن NTP عبر الشبكة هو خيارك. إذا سمّى clock_name ساعة KVM الافتراضية، فيمكن لـchrony استخدامها مع سطر refclock PHC /dev/ptp0 poll 2 في ملف الإعداد.

اقرأ حالة الوقت على جهازك

ابدأ بأمر واحد. يجيب هذا الأمر عن سؤال «هل يوجد شيء يحافظ على دقة هذه الساعة؟» في شاشة واحدة.

timedatectl

اقرأ هذه الأسطر بدلاً من الاعتماد على رقم تتذكره:

• Local time وUniversal time هما اللحظة نفسها مطبوعة وفق منطقتك الزمنية ووفق UTC. إذا كانا متطابقين، فإن الجهاز مضبوط بالفعل على UTC.
• RTC time هي ساعة العتاد الموضحة أعلاه. تجاهلها على VPS.
• Time zone هي القيمة التي يستخدمها النظام لتنسيق الوقت المحلي.
• System clock synchronized هي الراية الخاصة بالنواة. يضبطها برنامج خفي للوقت مرة واحدة بعد أن يثق بمصادره، لذلك تعني no أن لا شيء صحح هذه الساعة منذ الإقلاع.
• NTP service تعرض حالة systemd-timesyncd تحديداً. وتكون n/a طبيعية على جهاز يشغّل chrony، لأن timesyncd غير مثبت عليه. وتعني System clock synchronized: yes مع NTP service: n/a أن chrony يتولى المهمة وأن النواة توافقه.

بعد ذلك، تحقق من مقدار الانحراف. لا تقدّره بمقارنته بهاتفك. إذا كان chrony قيد التشغيل:

chronyc tracking
chronyc sources -v

تطبع chronyc tracking الأرقام التي تجيب عن السؤال. تعرض System time الإزاحة الحالية عن وقت NTP، وتتبعها الكلمة fast أو slow. تعرض Last offset مقدار أحدث تصحيح. أما Frequency فهو خطأ المعدل الذي قاسه chrony في ساعتك ويعوضه بالفعل. يجب أن تعرض Leap status القيمة Normal. إذا عرضت Not synchronised وكانت Reference ID تساوي 00000000 ()، فلم يحدد chrony مصدراً بعد.

تطبع chronyc sources -v مفتاحاً توضيحياً فوق القائمة، لذلك لا تحتاج إلى تذكر الرموز. تحمل عمودان معظم المعنى. يوضح حرف الحالة في بداية كل سطر كيفية تقييم chrony لذلك المصدر؛ حيث تشير * إلى المصدر المستخدم حالياً، بينما تعني ? في كل سطر أن لا شيء يجيب. تعرض Reach سجل استجابات آخر ثماني عمليات استطلاع بالنظام الثماني: تعني 377 أن العمليات الثماني كلها تلقت استجابة، وتعني 0 أن أياً منها لم يتلق استجابة.

إذا كان systemd-timesyncd هو المسؤول بدلاً من ذلك:

timedatectl timesync-status
timedatectl show-timesync --all

تطبع timesync-status الخادم الذي يتصل به، وفترة الاستطلاع، وقيمة Offset. إذا أعاد الأمر خطأً يتعلق بالخدمة بدلاً من طباعة الحالة، فهذا يعني أن timesyncd ليس البرنامج الخفي المسؤول على هذا الجهاز، وهذه بحد ذاتها إجابة عن سؤالك.

لإجراء فحص تقريبي مقابل العالم الخارجي من دون أدوات إضافية، قارن ساعتك برأس HTTP العام Date، الذي يُرسل بتوقيت GMT وبدقة ثانية واحدة:

date -u
curl -sI https://www.cloudflare.com | grep -i '^date:'

من الطبيعي أن يكون الفرق هنا ثانية أو ثانيتين، ولا يعني ذلك شيئاً. أما الفرق البالغ دقيقة فيشير إلى وجود خلل لديك.

chrony أو systemd-timesyncd على خادم VPS

تأتي Ubuntu وDebian مع systemd-timesyncd مثبتاً افتراضياً. وهو عميل SNTP (بروتوكول وقت الشبكة البسيط): يستعلم من خادم واحد في كل مرة، ويدفع الساعة تدريجياً نحوه. على جهاز متصل بالإنترنت باستمرار ويبدأ بوقت صحيح تقريباً، يكون ذلك كافياً، كما أن تشغيله يستهلك موارد تكاد لا تُذكر.

chrony تطبيق كامل لبروتوكول NTP، وهو الخيار الافتراضي الأفضل على جهاز افتراضي للأسباب التي يمكنك رؤيتها في مخرجاته. يستعلم من عدة مصادر في الوقت نفسه، ويستبعد المصادر التي تختلف عن غيرها. ويقيس معدل انحراف ساعتك ويكتبه في ملف drift، لذلك يصحح ميل الساعة بدلاً من ملاحقة كل عينة. كما يتعافى سريعاً من حالتين تحدثان للجهاز الافتراضي ولا تحدثان عادةً للجهاز الفعلي: قد يوقفه المضيف مؤقتاً، وقد ينقله إلى مضيف آخر أثناء تشغيله. وعند إتاحة جهاز PTP من المضيف، يكون chrony هو الذي يقرأه.

sudo apt update && sudo apt install -y chrony
systemctl status chrony --no-pager
chronyc sources -v
chronyc tracking

راقب مخرجات apt أثناء تشغيله. في Debian وUbuntu، توفّر الحزمتان chrony وsystemd-timesyncd كلتاهما time-daemon، لذلك يزيل apt timesyncd أثناء تثبيت chrony. هذا السلوك صحيح ومطلوب. لا تشغّل البرنامجين معاً أبداً، لأن خدمتين تضبطان الساعة نفسها ستتعارضان، ولا يمكن الوثوق بالإزاحة التي تبلغ عنها أي منهما أثناء ذلك. في Rocky وAlmaLinux، ثبّت الحزمة باستخدام sudo dnf install -y chrony، حيث تُسمّى الوحدة chronyd بدلاً من chrony.

ملف الإعداد هو /etc/chrony/chrony.conf في Debian وUbuntu، و/etc/chrony.conf في Rocky وAlma. الإعداد الافتراضي للتوزيعة مناسب بالفعل لخادم VPS، لذلك لا تغيّره إلا لسبب واضح. هناك توجيهان يستحقان الفهم:

• تسمّي أسطر pool وserver مصادر الوقت. تؤدي إضافة iburst إلى جعل chrony يرسل دفعة سريعة عند بدء التشغيل، لذلك تحدث المزامنة الأولى خلال ثوانٍ بدلاً من دقائق.
• يحدد makestep متى يقفز chrony بالساعة بدلاً من تصحيحها تدريجياً. تحقّق من قيمته باستخدام grep -n makestep /etc/chrony/chrony.conf. تعني القيمة الافتراضية في Debian وUbuntu، makestep 1 3، ما يلي: خلال التحديثات الثلاثة الأولى بعد بدء chronyd، اضبط الساعة قفزاً إذا كان فرقها أكثر من ثانية واحدة، وبعد ذلك صحّحها تدريجياً فقط.

إذا أردت مصادقة حركة الوقت للحماية من العبث بها أثناء مرورها في الشبكة، فإن chrony 4 والإصدارات الأحدث يدعمان NTS (أمن وقت الشبكة). تحقّق من إصدارك أولاً باستخدام chronyd -v، ولاحظ أن NTS يحتاج أيضاً إلى فتح منفذ TCP الصادر 4460، إضافة إلى UDP 123:

server time.cloudflare.com iburst nts

أعد التشغيل وتحقّق قبل أن تثق بالخدمة. فإذا تعذر تحليل الإعداد، فلن يبقى لديك أي برنامج خفي لمزامنة الوقت، ولن تخبرك الساعة بذلك.

sudo systemctl restart chrony
chronyc sources -v
chronyc tracking

لماذا تبقى الساعة التي تتأخر عدة دقائق متأخرة

لدى خدمة الوقت طريقتان لتصحيح الانحراف. يسرّع التصحيح التدريجي الساعة أو يبطئها حتى يختفي الخطأ، وبذلك يستمر الوقت في التقدم ولا يتكرر أي طابع زمني أو يتم تخطيه. أما التصحيح الفوري فينقل الساعة مباشرة إلى القيمة الصحيحة. وهذا سريع، لكنه قد يرجع بالساعة إلى الخلف. يُعد الرجوع إلى الخلف خطيراً لكل ما يقيس الزمن المنقضي من ساعة الحائط، لذلك تفضّل الخدمتان التصحيح التدريجي.

لهذا التفضيل تبقى الساعة المنحرفة بشدة غير صحيحة مدة طويلة. ينفّذ chrony التصحيح الفوري فقط ضمن النافذة التي يحددها makestep، والتي تكون افتراضياً خلال التحديثات الأولى القليلة بعد بدء الخدمة. إذا استمرت خدمة chronyd في العمل أسبوعاً ثم اكتشفت انحرافاً مدته أربعون ثانية، فستصححه تدريجياً. ويستغرق تصحيح أربعين ثانية بهذه الطريقة وقتاً أطول بكثير مما تريد الانتظار. نفّذ التصحيح مرة واحدة وبشكل مقصود في وقت هادئ:

sudo chronyc makestep
chronyc tracking

يجب أن يعرض chronyc tracking الآن انحراف System time قريباً من الصفر، ويجب أن يوضح Last offset مقدار التصحيح الذي نُفّذ للتو. فكّر قبل تنفيذ ذلك على خادم قاعدة بيانات نشط، لأن رجوع الساعة إلى الخلف قد يربك البرامج التي تفترض أن الوقت يتحرك إلى الأمام فقط. إعادة تشغيل الخدمة هي النسخة الألطف من التصحيح نفسه، لأن نافذة makestep تُفتح مجدداً عند البدء.

تتشارك الحاويات ساعة الخادم المضيف

لا تملك الحاوية ساعة جدارية خاصة بها، لذلك لا يوجد شيء لمزامنته داخلها. تعمل مساحات أسماء الوقت في Linux على جعل ساعتي الوقت الرتيب ووقت الإقلاع افتراضيتين فقط. لا تكون CLOCK_REALTIME افتراضية، وهذا يعني أن الحاوية تقرأ ساعة النظام نفسها التي يقرأها الخادم المضيف الذي تعمل عليه. أصلح الساعة على الخادم المضيف، وستُصلح كل حاوية على ذلك الخادم في اللحظة نفسها.

تترتب على ذلك عدة نتائج. لا تثبّت chrony أو ntpd في صورة، لأن ذلك لن يفيد في أفضل الأحوال. يفشل ضبط التاريخ داخل حاوية غير مميّزة بسبب date: cannot set date: Operation not permitted، لأن النواة تتطلب CAP_SYS_TIME لاستدعاء النظام هذا. لا يمنح منح CAP_SYS_TIME الحاوية ساعة خاصة، بل يمنحها القدرة على تغيير ساعة الخادم المضيف، وبالتالي ساعة كل حاوية أخرى أيضاً.

لا تمثل المنطقة الزمنية المختلفة داخل الحاوية مشكلة في الساعة. تطبع الصورة التي تتضمن /etc/localtime اللحظة نفسها بعد تنسيقها لمنطقة زمنية أخرى، لذلك يبدو date خاطئاً رغم أن الساعة صحيحة. اضبط TZ=UTC في بيئة الحاوية، وينتهي الالتباس. لا يغيّر وقت التشغيل الذي اخترته شيئاً هنا، وتشرح مقارنة Podman وDocker دون root ما يتغير فعلياً.

المناطق الزمنية: UTC على الخادم، والتوقيت المحلي للمستخدمين

اضبط الجهاز على UTC واتركه كذلك.

timedatectl list-timezones | grep -i utc
sudo timedatectl set-timezone UTC
timedatectl

لا يتضمن UTC التوقيت الصيفي، وهذا هو السبب الحاسم. تعمل مهمة يومية عند 02:30 مرتين في اليوم الذي تعود فيه الساعات إلى الوراء ضمن منطقة تطبق التوقيت الصيفي، ولا تعمل إطلاقاً في اليوم الذي تتقدم فيه الساعات. يوثّق man 8 cron المعالجة الخاصة بالتغييرات التي تقل عن ثلاث ساعات: تُشغَّل المهام التي تخطتها قفزة إلى الأمام بعد التغيير بوقت قصير، ولا تُشغَّل المهام التي وقعت داخل ساعة مكررة بسبب قفزة إلى الخلف مرة ثانية. هذا السلوك معقول، لكن لا ينبغي أن تضطر إلى تحليله عند الساعة 03:00. في UTC تعمل المهمة مرة واحدة يومياً، كل يوم من أيام السنة. إذا كانت إحدى مهامك مفقودة تماماً بدلاً من تشغيلها في وقت غير معتاد، فغالباً ما يكون سبب عدم تشغيل مهمة cron بصمت هو التفسير الأرجح.

ينطبق السبب نفسه على قراءة السجلات. ينسّق journalctl الطوابع الزمنية وفق المنطقة الزمنية للنظام، ويفرض journalctl --utc استخدام UTC. يحوّل وجود خادمين في منطقتين زمنيتين مختلفتين كل حادثة إلى عملية تحويل للتوقيت، والتحويلات التي تُجرى تحت الضغط هي سبب إساءة قراءة التسلسل الزمني. أبقِ الأنظمة على UTC، وخزّن الطوابع الزمنية وفق UTC، وأجرِ التحويل مرة واحدة عند عرضها على المستخدم. يمكن لأي شخص يريد عرض التوقيت المحلي لأمر واحد أن يطلب ذلك دون تغيير توقيت الجهاز:

TZ=Europe/Berlin date

ينتمي سطر آخر في مخرجات timedatectl إلى هذا القسم. يجب أن يقرأ RTC in local TZ القيمة no. ضبطه على yes حل التفافي لتشغيل Windows وLinux بنظام الإقلاع المزدوج على حاسوب محمول، أما على الخادم فلا يضيف إلا إزاحة قد تسبب مشكلة لشخص ما لاحقاً. عند ضبطه، يطبع timedatectl تحذيراً يفيد بأن النظام مهيأ لقراءة وقت RTC وفق المنطقة الزمنية المحلية.

استكشاف الأخطاء وإصلاحها حسب العَرَض

يُرفَض رمز المصادقة الثنائية على خادم واحد. افحص الساعة قبل أي شيء آخر. يُحتسَب الرمز من عدّاد يتقدم كل 30 ثانية، لذلك يحسب خادم متأخر 90 ثانية رمزاً من خطوة تجاوزها هاتفك بالفعل. سيعرض timedatectl القيمة System clock synchronized: no، أو سيُبلغ chronyc tracking عن إزاحة كبيرة مقدارها System time. يختلف هذا الفشل عن رفض المفتاح مباشرةً، إذ يطبع النظام رسالته الخاصة، وتغطيه دليل أعطال مصادقة publickey.

يقول apt update إن ملف Release غير صالح بعد. تذكر الرسالة الكاملة المستودع والمدة التي سيظل خلالها غير صالح، مثل is not valid yet (invalid for another 1d 2h 3min 4s). ساعتك متأخرة عن التاريخ الموجود داخل ملف Release للمستودع، وهذه المدة قياس مباشر لمقدار التأخر. أصلح الساعة. لا تعطل فحص التاريخ في apt لتجاوز المشكلة، لأن هذا الفحص هو ما يمنع جهة ما من تزويدك بفهرس حزم قديم.

يُظهر كل سطر مصدر الحالة غير القابلة للوصول، وتكون قيمة Reach هي 0. لا يستجيب أي شيء، لذلك افحص الاتصالات الصادرة بدلاً من إعداداتك. يستخدم NTP منفذ UDP 123 للاتصالات الصادرة، وقد تحظر بعض الشبكات هذه الاتصالات أو تعيد توجيهها. يطبع sudo chronyc ntpdata عدادات لكل مصدر، بما فيها Total TX وTotal RX. إذا ارتفع عداد TX بينما بقي RX عند الصفر، فهذا يعني أن حزمك تغادر ولا يعود شيء، ما يشير إلى وجود جدار ناري بينك وبين المصدر.

كانت الساعة صحيحة ثم قفزت. قد تتسبب أحداث المضيف في ذلك. يمكن أن تترك لقطة مستعادة، أو ضيفاً متوقفاً مؤقتاً، أو عملية ترحيل مباشرة إلى مضيف آخر، تصور الضيف للوقت متأخراً عن الوقت الفعلي. يلاحظ chrony ذلك عند الاستطلاع التالي ويصححه، بينما قد ينتظر systemd-timesyncd أولاً انتهاء فترة استطلاع طويلة. تأكد من بدء البرنامج الخدمي عند الإقلاع باستخدام systemctl is-enabled chrony، لأن البرنامج الخدمي الذي يبدأ يدوياً يتوقف بعد إعادة التشغيل التالية.

الإزاحة صغيرة لكنها لا تستقر أبداً. افحص وقت سرقة CPU. إذا لم تتم جدولة ضيف عند حلول موعد مقاطعة المؤقت، تتأخر عيناته، لذلك تتذبذب الإزاحة بدلاً من أن تتقارب. يعرض top ذلك باعتباره القيمة st في سطر CPU. يشرح قراءة وقت سرقة CPU على مضيف مشترك معنى هذا الرقم وما يمكنك فعله حياله.

رُفضت شهادة أصدرتها للتو باعتبارها غير صالحة بعد. يطبع curl القيمة SSL certificate problem: certificate is not yet valid، وتعرض المتصفحات رسالة مشابهة. الشهادة سليمة، لكن الساعة التي تتحقق منها متأخرة. قد تكون أي من الآلتين هي سبب المشكلة، لذلك افحص العميل والخادم. إذا كان الخادم الذي أصدرها هو صاحب الساعة الخاطئة، فإن دليل شهادات certbot وnginx يشرح جانب التجديد من الإعداد نفسه.

أضِفه إلى الفحوصات التي تجريها بالفعل

تزامن الوقت إعداد يُطبَّق عند الإقلاع وقد يفشل بصمت بعد أشهر، وهذا بالضبط النوع من المشكلات التي تلتقطها الإجراءات الدورية ولا تلتقطها الذاكرة. يستغرق timedatectl وchronyc tracking ثانيتين لقراءتهما معاً. شغّلهما ضمن الدقائق العشر الأولى على VPS جديد، ثم شغّلهما مرة أخرى أثناء تنفيذ قائمة التحقق الدورية لصيانة خادم Linux. إذا كنت تفضّل أن يُجري الفحص نفسه ويُصدر تنبيهاً عند زيادة الانحراف، فإن كتابة خدمة ومؤقت systemd تشرح نمط إنشاء وحدة صغيرة تُصدر تقريراً وفق جدول زمني.

FAQ

كيف أتحقق من مزامنة ساعة VPS؟

شغّل timedatectl واقرأ السطر System clock synchronized. هذه هي الراية الخاصة بنواة النظام، ويضبطها البرنامج الخدمي المسؤول عن مزامنة الساعة. لذلك فإن ظهور yes مع NTP service: n/a أمر طبيعي وسليم على جهاز يستخدم chrony. لمعرفة مقدار الخطأ، شغّل chronyc tracking واقرأ System time، أو شغّل timedatectl timesync-status واقرأ Offset إذا كان systemd-timesyncd هو المسؤول. ولإجراء فحص مقابل مصدر خارج الجهاز، قارن date -u مع الترويسة Date التي يعيدها أي موقع HTTPS.

هل أستخدم chrony أم systemd-timesyncd على VPS؟

استخدم chrony في أي خادم مهم. systemd-timesyncd هو عميل SNTP يتبع خادماً واحداً، وهو مناسب لجهاز يبقى متصلاً بالإنترنت ويبدأ بوقت قريب من الدقة. يستعلم chrony من عدة مصادر، ويرفض المصادر المتعارضة، ويتعلم معدل خطأ ساعتك، ويتعافى سريعاً بعد إيقاف المضيف مؤقتاً أو إجراء live migration. يؤدي تثبيت chrony على Debian أو Ubuntu إلى إزالة systemd-timesyncd تلقائياً، لأن كلتا الحزمتين توفران time-daemon. لا تشغّل برنامجين لمزامنة الوقت في الوقت نفسه.

لماذا تفشل رموز TOTP على خادم واحد بينما تعمل في كل مكان آخر؟

لأن رمز TOTP يعتمد على الوقت الحالي. يُنشأ الرمز من عدّاد يتقدم كل 30 ثانية، لذلك يجب أن يتفق الخادم وهاتفك على الفترة الزمنية الحالية. يقبل معظم برامج التحقق فترة واحدة قبل الفترة الحالية أو بعدها، ما يوفر هامشاً يقارب 30 ثانية في كل اتجاه. تحقّق من timedatectl على ذلك الخادم. إذا كانت قيمة System clock synchronized هي no، فأصلح المزامنة، وستتطابق الرموز مجدداً من دون تغيير السر المشترك.

هل يمكنني ضبط الوقت داخل حاوية Docker؟

لا، ولا تحتاج إلى ذلك. تشارك الحاوية المضيف في CLOCK_REALTIME، لأن مساحات أسماء الوقت في Linux تجعل ساعتي الوقت monotonic ووقت الإقلاع افتراضيتين فقط. تحصل الحاوية غير ذات الامتيازات على date: cannot set date: Operation not permitted، وإضافة CAP_SYS_TIME تتيح لها تغيير ساعة المضيف بدلاً من منحها ساعة مستقلة. زامِن المضيف بدلاً من ذلك. ويكون اختلاف الوقت المحلي داخل الحاوية إعداداً للمنطقة الزمنية، لذلك اضبط TZ في بيئة الحاوية.

هل ينبغي أن يستخدم الخادم UTC أم الوقت المحلي؟

استخدم UTC، وطبّق الوقت المحلي عند قراءة شخص للمخرجات. لا يتغير UTC بسبب التوقيت الصيفي، لذلك تُشغَّل المهمة اليومية مرة واحدة كل يوم طوال السنة، وتتطابق الطوابع الزمنية من الخوادم المختلفة من دون تحويل. اضبطه باستخدام sudo timedatectl set-timezone UTC. ويمكن لمن يريد عرضاً محلياً أن يسبق أمراً واحداً، مثل TZ=America/New_York date، من دون تغيير ساعة النظام.