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

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

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

في ضيف KVM حديث، نادراً ما يكون العدّاد نفسه هو المشكلة الفعلية. يقرأ مصدر kvm-clock شبه الافتراضي قيمة يحافظ عليها المضيف، لذلك يتتبع الضيف مضيفه بدقة كبيرة عندما يكون سليماً. عادةً تكون الساعات غير الصحيحة بوضوح خاطئة لسبب أبسط. قد لا يكون أي daemon لمزامنة الوقت قيد التشغيل، أو قد يعمل daemonان ويتعارضان، أو قد لا تغادر حزم UDP الصادرة على المنفذ 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 سجل استجابات آخر 8 عمليات استطلاع، وتطبعه بالنظام الثماني: تعني 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 كامل، وهو الخيار الافتراضي الأفضل على جهاز افتراضي، لأسباب يمكنك رؤيتها في مخرجاته. يستعلم من عدة مصادر في الوقت نفسه ويستبعد المصادر التي تختلف عن البقية. ويقيس معدل خطأ ساعتك ويكتبه في ملف الانحراف، لذلك يصحح ميل الساعة بدلاً من ملاحقة كل عينة. كما يتعافى سريعاً من أمرين يمكن أن يحدثا للجهاز الافتراضي ولا يحدثان عادةً لجهاز فعلي: قد يوقفه المضيف مؤقتاً، وقد ينقله إلى مضيف آخر أثناء تشغيله. وعند إتاحة جهاز 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

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

sudo systemctl restart chrony
chronyc sources -v
chronyc tracking

لماذا تبقى الساعة الخاطئة بدقائق خاطئة

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

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

sudo chronyc makestep
chronyc tracking

يُفترض أن يعرض chronyc tracking الآن انحراف System time قريباً من الصفر، وأن يوضّح Last offset مقدار التصحيح الذي نُفّذ للتو. فكّر قبل تشغيل ذلك على مضيف قاعدة بيانات مشغول، لأن تحريك الساعة إلى الخلف قد يربك البرامج التي تفترض أن الوقت يتحرك إلى الأمام فقط. إعادة تشغيل الـdaemon هي النسخة الألطف من التصحيح نفسه، لأن نافذة 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. يختلف هذا العطل عن رفض المفتاح مباشرةً، إذ يطبع ذلك رسالة خاصة به، وتتناوله الدليل الخاص بأعطال المصادقة بالمفتاح العام.

يقول 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 steal. عندما لا يحصل الضيف على وقت جدولة عند استحقاق مقاطعة المؤقت، تتأخر عيناته، لذلك تتذبذب الإزاحة بدلاً من أن تتقارب. يعرض top ذلك في صورة قيمة st ضمن سطر CPU. يشرح قراءة وقت CPU steal على مضيف مشترك معنى هذا الرقم والإجراءات التي يمكنك اتخاذها لمعالجته.

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

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

تزامن الوقت إعداد يُطبَّق عند الإقلاع، لكنه قد يتعطل بصمت بعد أشهر. وهذا بالضبط النوع من المشكلات الذي تلتقطه الإجراءات الدورية ولا تتذكره الذاكرة. يستغرق الاطلاع على timedatectl وchronyc tracking معاً ثانيتين. شغّلهما ضمن الدقائق العشر الأولى على VPS جديد، وكرّر ذلك أثناء تنفيذ قائمة الصيانة الدورية لخادم Linux. إذا كنت تفضّل أن يُجري الفحص نفسه العملية ويُصدر تنبيهاً عندما يزداد الانحراف، فإن كتابة خدمة ومؤقت systemd تشرح النمط اللازم لوحدة صغيرة تُصدر تقريراً وفق جدول زمني. مثل هذا الفحص عبارة عن script قصير وليس daemon، ولذلك يحتاج إلى Type=oneshot بدلاً من الإعداد الافتراضي. كما يوضح الشرح المختصر لأنواع خدمات 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 ثانية، لذلك يجب أن يتفق الخادم وهاتفك على الفترة الزمنية الحالية. تقبل معظم خدمات التحقق فترة واحدة قبل الفترة الحالية أو بعدها، ما يوفر هامشاً يقارب نصف دقيقة في كل اتجاه. افحص 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، من دون تغيير ساعة النظام.