VPS கடிகார நேரத்தை சரி செய்வது எப்படி?

உங்கள் VPS கடிகாரம் ஏன் பின் தங்கியுள்ளது

எந்தவொரு திருத்தமும் செய்யப்படாததால் VPS கடிகாரம் பின் தங்கியுள்ளது. கர்னல் (kernel) ஒரு வன்பொருள் கவுண்டரிலிருந்து நேரத்தைக் கணக்கிடுகிறது; இது சற்று வேகமாகவும் அல்லது மெதுவாகவும் இயங்கக்கூடும். நேரத்தை ஒத்திசைக்கும் client (time sync client) எதுவும் இயங்காதபோது, அந்த சிறிய பிழை ஒவ்வொரு மணிநேரமும் அதிகரிக்கிறது. ஒரு virtual machine-க்குள் இரண்டாவது காரணம் உள்ளது: உங்கள் guest, பிற guest-களுடன் ஒரு physical CPU-வைப் பகிர்ந்து கொள்கிறது. எனவே, அது scheduled செய்யப்படாத தருணங்களில் நேரத்தைக் கணக்கிட முடியாது.

தற்போதைய KVM guest-ல், கவுண்டர் என்பது அரிதாகவே உண்மையான சிக்கலாக இருக்கும். paravirtual kvm-clock source, host பராமரிக்கும் மதிப்பை வாசிக்கிறது, எனவே ஒரு ஆரோக்கியமான guest அதன் host-ஐ நெருக்கமாகப் பின்தொடரும். கடிகாரங்கள் வெளிப்படையாகத் தவறாக இருப்பதற்கு வழக்கமாக ஒரு சாதாரண காரணமே இருக்கும். sync daemon எதுவும் இயங்கவில்லை, அல்லது இரண்டு daemon-கள் இயங்கி ஒன்றோடொன்று முரண்படுகின்றன, அல்லது outbound UDP port 123 உங்கள் provider-ன் நெட்வொர்க்கிலிருந்து வெளியேறவில்லை. ஒரு guest அதன் நேரக் கட்டுப்பாட்டை host-இடமிருந்தோ அல்லது NTP (network time protocol)-இடமிருந்தோ பெறுகிறது, அதன் சொந்த oscillator-இடமிருந்து அல்ல.

தவறான clock அமைப்பால் ஏற்படும் பாதிப்புகள்

• TOTP (time-based one-time password) இரு-காரணி அங்கீகாரக் குறியீடுகள் பொருந்தாமல் போகும்; இதனால், சரியான கடவுச்சொல் மற்றும் key இருந்தும் உங்களால் server-க்குள் நுழைய முடியாது.
• ஒரு நிமிடம் முன்பு வழங்கப்பட்ட certificate நிராகரிக்கப்படும், மேலும் 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) பிழையுடன் repository-ஐ ஏற்க மறுக்கும்.
• திட்டமிடப்பட்ட பணிகள் தவறான நேரத்தில் இயங்கும்; clock திடீரென மாறினால், ஒரு பணி இரண்டு முறை இயங்கலாம் அல்லது மற்றொரு பணி தவிர்க்கப்படலாம்.
• இரண்டு வெவ்வேறு server-களின் logs-ஐ ஒப்பிட முடியாது; இதனால் ஒரு சம்பவத்தின் காலவரிசையை ஊகத்தின் அடிப்படையிலேயே உருவாக்க வேண்டியிருக்கும்.

இதற்கான சகிப்புத்தன்மை (tolerance) பெரும்பாலானோர் எதிர்பார்ப்பதை விட மிகக் குறைவு. கீழே கொடுக்கப்பட்டுள்ள புள்ளிவிவரங்கள் ஆவணப்படுத்தப்பட்ட இயல்புநிலை மதிப்புகள், சோதனை முடிவுகள் அல்ல.

[
  {
    "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 வினாடிகளுக்கு ஒருமுறை மாறும் counter மூலம் கணக்கிடப்படுகிறது; பெரும்பாலான சரிபார்ப்புக் கருவிகள் (verifiers) இருபுறமும் ஒரு படி (step) வரை அனுமதிக்கும். ஒவ்வொரு திசையிலும் அரை நிமிட கால அளவு மட்டுமே மொத்த சகிப்புத்தன்மை ஆகும். Kerberos இதில் அதிக சகிப்புத்தன்மை கொண்டது, அதன் இயல்புநிலை skew allowance 300 வினாடிகள் ஆகும். Certificate-க்கு எந்த சகிப்புத்தன்மையும் கிடையாது: அது 0 வினாடிகள் கொண்ட grace period-உடன் நிலையான நேரத்தோடு ஒப்பிடப்படுகிறது; எனவே, ஒரு வினாடி முன்னதாக இருக்கும் clock கூட மிகச் சரியான certificate-ஐ நிராகரித்துவிடும்.

மூன்று கடிகாரங்கள் மற்றும் எது முக்கியமானது

System clock என்பதுதான் முக்கியமான கடிகாரம். இது kernel-ன் CLOCK_REALTIME ஆகும்: 1 ஜனவரி 1970 UTC முதல் கடந்த வினாடிகளின் எண்ணிக்கை இது. இது நினைவகத்தில் (memory) சேமிக்கப்பட்டு, நேரத்தை முத்திரையிடும் (stamp) அனைத்து செயல்பாடுகளாலும் வாசிக்கப்படுகிறது. Log வரிகள், certificate சரிபார்ப்புகள், TOTP குறியீடுகள் மற்றும் கோப்பு மாற்ற நேரங்கள் அனைத்தும் இதிலிருந்தே பெறப்படுகின்றன. ஒரு server-ன் நேரம் தவறு என்று யாராவது கூறினால், அவர்கள் இந்தக் கடிகாரத்தையே குறிப்பிடுகிறார்கள்.

Hardware clock, இது RTC (real time clock) என்றும் அழைக்கப்படுகிறது. இயந்திரம் அணைக்கப்பட்டிருக்கும்போதும் இயங்கிக்கொண்டிருக்கும் ஒரு தனி counter இது. ஒரு physical machine-ல் இது battery மூலம் இயங்கும் chip ஆகும். ஒரு guest-க்குள் இது hypervisor மூலம் உருவகப்படுத்தப்படுகிறது (emulated), எனவே இது பெரும்பாலும் host-ன் ஒரு அங்கமாகும். Linux இதை boot-ன் போது ஒருமுறை தொடக்க மதிப்பாக வாசித்துவிட்டு, பின் தனது சொந்த எண்ணிக்கையைத் தொடர்கிறது. timedatectl இதை RTC time வரியில் அச்சிடுகிறது. ஒரு VPS-ல் அந்த வரியை வைத்து debug செய்ய வேண்டாம், ஏனெனில் அது உங்கள் system clock-ன் ஒத்திசைவு நிலையை விட, host-ன் நேரக் கணிப்பையே காட்டுகிறது. ஒரு container-ல் பொதுவாக /dev/rtc இருக்காது, எனவே hwclock --show கட்டளை hwclock: Cannot access the Hardware Clock via any known method. பிழையுடன் தோல்வியடையும்.

Clocksource என்பது அந்த வாசிப்புகளுக்கு இடையில் kernel எதைக் கொண்டு கணக்கிடுகிறது என்பதைக் குறிக்கிறது. உங்கள் kernel எதைத் தேர்ந்தெடுத்துள்ளது என்பதை அதனிடம் கேளுங்கள்:

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

KVM-ல் நீங்கள் பொதுவாக kvm-clock-ஐக் காண்பீர்கள். இது host-ஆல் பராமரிக்கப்படும் மதிப்பை வாசிக்கிறது, அதனால்தான் NTP client இல்லாத KVM guest கூட ஓரளவிற்குச் சரியாக இயங்குகிறது. tsc என்பது CPU-ன் சொந்த counter ஆகும். Xen guest-கள் xen-ஐயும், Hyper-V guest-கள் hyperv source-ஐயும் தெரிவிக்கின்றன. இந்த அமைப்பை மாற்ற வேண்டியதற்கான வலுவான காரணம் இல்லையெனில் அதை மாற்ற வேண்டாம், ஏனெனில் அந்த hardware-ல் நம்பகமான சிறந்த source-ஐ kernel ஏற்கனவே தேர்ந்தெடுத்திருக்கும்.

சில host-கள் PTP (precision time protocol) சாதனத்தை guest-க்கு வழங்குகின்றன. இது network வழியாக இல்லாமல், host கடிகாரத்தை நேரடியாக வாசிக்க chrony-க்கு உதவுகிறது. இதைச் சரிபார்ப்பது பயனுள்ளது, ஆனால் பகிரப்பட்ட VPS-களில் இது பெரும்பாலும் கிடைக்காது:

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

modprobe தோல்வியடைந்தாலோ அல்லது எந்த சாதனமும் தோன்றவில்லை என்றாலோ, உங்கள் host அதை வழங்கவில்லை என்று அர்த்தம்; அப்போது network NTP-யே உங்களுக்குத் தீர்வாகும். clock_name KVM virtual clock-ஐக் குறிப்பிட்டால், அதன் config-ல் refclock PHC /dev/ptp0 poll 2 வரியைப் பயன்படுத்தி chrony அதைச் செயல்படுத்த முடியும்.

உங்கள் கணினியில் நேரத்தின் நிலையைச் சரிபார்த்தல்

ஒரே ஒரு கட்டளையுடன் தொடங்கவும். "இந்தக் கடிகாரத்தை எது சரியாக வைத்திருக்கிறது" என்ற கேள்விக்கு இது ஒரே திரையில் பதிலளிக்கும்.

timedatectl

நீங்கள் நினைவில் வைத்திருக்கும் எண்ணை நம்புவதை விட, இந்த வரிகளைப் படிக்கவும்:

• Local time மற்றும் Universal time ஆகியவை உங்கள் timezone மற்றும் UTC-ல் அச்சிடப்பட்ட ஒரே தருணத்தைக் குறிக்கின்றன. இவை ஒன்றாக இருந்தால், கணினி ஏற்கனவே UTC-ல் உள்ளது என்று பொருள்.
• RTC time என்பது மேலே விவரிக்கப்பட்ட hardware clock ஆகும். VPS-ல் இதைப் புறக்கணிக்கவும்.
• Time zone என்பது local time-ஐ வடிவமைக்க system பயன்படுத்தும் முறையாகும்.
• System clock synchronized என்பது kernel-ன் சொந்தக் குறியீடு (flag) ஆகும். ஒரு time daemon தனது ஆதாரங்களை நம்பியவுடன் இதை அமைக்கும், எனவே no என்பது boot செய்ததிலிருந்து இந்தக் கடிகாரம் எதனாலும் சீரமைக்கப்படவில்லை என்று பொருள்.
• NTP service என்பது systemd-timesyncd-ன் நிலையைத் தெரிவிக்கிறது. chrony இயங்கும் கணினியில் n/a என்பது இயல்பானது, ஏனெனில் அங்கு timesyncd நிறுவப்பட்டிருக்காது. System clock synchronized: yes மற்றும் NTP service: n/a ஆகியவை ஒன்றாக இருந்தால், chrony தனது பணியைச் செய்கிறது மற்றும் kernel அதை ஏற்றுக்கொள்கிறது என்று பொருள்.

அடுத்து, உங்கள் நேரம் எவ்வளவு வேறுபட்டுள்ளது என்று கேட்கவும். உங்கள் தொலைபேசியுடன் ஒப்பிட்டுப் பார்க்க வேண்டாம். chrony இயங்கிக்கொண்டிருந்தால்:

chronyc tracking
chronyc sources -v

chronyc tracking இந்தக் கேள்விக்கான பதிலைத் தரும் எண்களை அச்சிடும். System time என்பது NTP நேரத்திலிருந்து தற்போதைய offset ஆகும், அதைத் தொடர்ந்து fast அல்லது slow என்ற சொல் வரும். Last offset என்பது கடைசியாகச் செய்யப்பட்ட திருத்தத்தின் அளவு. Frequency என்பது உங்கள் கடிகாரத்தில் chrony கண்டறிந்த பிழை விகிதம், இதை அது ஏற்கனவே சரிசெய்து வருகிறது. Leap status என்பது Normal என்று இருக்க வேண்டும். அது Not synchronised என்று இருந்து, Reference ID என்பது 00000000 () என்று இருந்தால், chrony இன்னும் ஒரு ஆதாரத்தை (source) உறுதிப்படுத்தவில்லை என்று பொருள்.

chronyc sources -v குறியீடுகளை நினைவில் வைத்திருக்கத் தேவையில்லை என்பதற்காகப் பட்டியலுக்கு மேலே ஒரு விளக்கத்தை அச்சிடும். இரண்டு நெடுவரிசைகள் பெரும்பாலான தகவல்களைக் கொண்டுள்ளன. ஒவ்வொரு வரியின் தொடக்கத்திலும் உள்ள நிலை எழுத்து (state character), chrony அந்த ஆதாரத்தை எவ்வாறு மதிப்பிடுகிறது என்பதைக் குறிக்கும். இதில் * என்பது தற்போது பயன்படுத்தப்படும் ஆதாரத்தைக் குறிக்கும், மேலும் ஒவ்வொரு வரியிலும் ? இருந்தால், எந்த ஆதாரமும் பதிலளிக்கவில்லை என்று பொருள். Reach என்பது கடைசி எட்டு முறை கேட்கப்பட்ட பதில்களின் வரலாற்றை octal முறையில் அச்சிடும்: 377 என்றால் எட்டு முறையும் பதில் கிடைத்துள்ளது என்று பொருள், 0 என்றால் எதுவும் கிடைக்கவில்லை என்று பொருள்.

systemd-timesyncd பொறுப்பில் இருந்தால்:

timedatectl timesync-status
timedatectl show-timesync --all

timesync-status அது தொடர்பு கொள்ளும் server, poll interval மற்றும் Offset மதிப்பைப் பிரிண்ட் செய்யும். கட்டளை நிலையை அச்சிடுவதற்குப் பதிலாக service குறித்த பிழையைத் திரும்ப அளித்தால், இந்த கணினியில் timesyncd daemon பொறுப்பில் இல்லை என்று பொருள், இதுவே உங்கள் கேள்விக்கான பதிலாகும்.

கூடுதல் கருவிகள் இல்லாமல் வெளி உலகத்துடன் ஒரு தோராயமான சரிபார்ப்பிற்கு, உங்கள் கடிகாரத்தை பொதுவான HTTP Date header-உடன் ஒப்பிடவும், இது GMT-ல் ஒரு வினாடி துல்லியத்துடன் வழங்கப்படுகிறது:

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

இதில் ஒரு வினாடி அல்லது இரண்டு வினாடி வித்தியாசம் இருப்பது இயல்பானது, இது எதையும் குறிக்காது. ஒரு நிமிட வித்தியாசம் இருந்தால், அது உங்கள் பிழை.

VPS-ல் chrony அல்லது systemd-timesyncd

Ubuntu மற்றும் Debian இயல்பாகவே systemd-timesyncd-ஐ வழங்குகின்றன. இது ஒரு SNTP (simple network time protocol) client ஆகும்: இது ஒரு நேரத்தில் ஒரு server-ஐ மட்டும் தொடர்பு கொண்டு நேரத்தைச் சரிசெய்கிறது. எப்போதும் online-ல் இருக்கும் மற்றும் ஓரளவிற்குச் சரியான நேரத்தைக் கொண்ட கணினிக்கு இது போதுமானது, மேலும் இது மிகக் குறைந்த வளங்களையே பயன்படுத்துகிறது.

chrony என்பது முழுமையான NTP செயல்பாட்டைக் கொண்டது மற்றும் virtual machine-களுக்கு இதுவே சிறந்த தேர்வாகும்; இதற்கான காரணங்களை அதன் output-ல் நீங்கள் காணலாம். இது ஒரே நேரத்தில் பல ஆதாரங்களை (sources) ஆய்வு செய்து, முரண்படும் ஆதாரங்களை நீக்கிவிடும். இது உங்கள் clock-ன் வேகப் பிழையை (rate error) அளந்து, அதை ஒரு drift file-ல் பதிவு செய்கிறது. எனவே, ஒவ்வொரு முறையும் நேரத்தைச் சரிசெய்வதற்குப் பதிலாக, clock-ன் வேகத்தையே இது சீரமைக்கிறது. ஒரு physical machine-ல் இல்லாத இரண்டு விஷயங்களை VM-ல் இது சிறப்பாகக் கையாளுகிறது: host-ஆல் VM-ஐ pause செய்ய முடியும், மேலும் இயங்கிக்கொண்டிருக்கும்போதே அதை வேறொரு host-க்கு மாற்ற முடியும். ஒரு host PTP device-ஐ வழங்கும்போது, அதை வாசிக்கும் திறன் chrony-க்கு மட்டுமே உண்டு.

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

apt இயங்கும்போது அதன் output-ஐ கவனிக்கவும். Debian மற்றும் Ubuntu-வில் chrony மற்றும் systemd-timesyncd ஆகிய இரண்டு packages-ம் time-daemon-ஐ வழங்குவதால், chrony-ஐ நிறுவும்போது apt தானாகவே timesyncd-ஐ நீக்கிவிடும். இது சரியான மற்றும் எதிர்பார்க்கப்படும் செயல்முறை. இரண்டையும் ஒரே நேரத்தில் இயக்க வேண்டாம்; ஏனெனில் ஒரே clock-ஐ இரண்டு daemons மாற்ற முயன்றால், அவை ஒன்றுடன் ஒன்று முரண்படும், மேலும் அவற்றின் offset தகவல்கள் நம்பகத்தன்மையற்றதாகிவிடும். Rocky மற்றும் AlmaLinux-ல் sudo dnf install -y chrony மூலம் நிறுவவும், அங்கு unit-ன் பெயர் chrony என்பதற்குப் பதிலாக chronyd என்று இருக்கும்.

Debian மற்றும் Ubuntu-வில் configuration file /etc/chrony/chrony.conf என்றும், Rocky மற்றும் Alma-வில் /etc/chrony.conf என்றும் இருக்கும். விநியோகத்தின் இயல்புநிலை அமைப்புகள் VPS-க்கு ஏற்கனவே போதுமானதாக இருப்பதால், தேவைப்பட்டால் மட்டுமே மாற்றவும். பின்வரும் இரண்டு directives-ஐப் புரிந்துகொள்வது அவசியம்:

• pool மற்றும் server வரிகள் நேர ஆதாரங்களைக் குறிப்பிடுகின்றன. iburst-ஐச் சேர்ப்பதன் மூலம், startup-ல் chrony வேகமான burst-ஐ அனுப்பும், இதனால் முதல் sync சில நிமிடங்களுக்குப் பதிலாக சில நொடிகளிலேயே முடிந்துவிடும்.
• makestep என்பது நேரத்தை மெதுவாகச் சரிசெய்வதா அல்லது நேரடியாகத் தாவுவதா (jump) என்பதைத் தீர்மானிக்கிறது. உங்கள் அமைப்பில் என்ன உள்ளது என்பதை grep -n makestep /etc/chrony/chrony.conf மூலம் சரிபார்க்கவும். Debian மற்றும் Ubuntu-வின் இயல்புநிலையான makestep 1 3 என்பதன் பொருள் இதுதான்: chronyd தொடங்கிய பிறகு முதல் மூன்று முறை, நேரம் ஒரு நொடிக்கு மேல் வேறுபட்டால் நேரடியாகச் சரிசெய்யவும், அதன் பிறகு மெதுவாக (slewing) சரிசெய்யவும்.

நெட்வொர்க் பாதையில் நேரத் தரவுகள் மாற்றப்படுவதைத் தடுக்க authentication தேவைப்பட்டால், chrony 4 மற்றும் அதற்குப் பிந்தைய பதிப்புகள் NTS (network time security)-ஐ ஆதரிக்கின்றன. முதலில் chronyd -v மூலம் உங்கள் பதிப்பை உறுதிப்படுத்தவும். NTS-க்கு UDP 123-உடன் சேர்த்து, outbound TCP port 4460-ம் திறந்திருக்க வேண்டும் என்பதைக் கவனத்தில் கொள்ளவும்:

server time.cloudflare.com iburst nts

நம்பகத்தன்மையை உறுதிப்படுத்தும் முன் restart செய்து சரிபார்க்கவும். ஒருவேளை configuration file-ல் பிழை இருந்தால், எந்த நேர daemon-ம் இயங்காது, ஆனால் clock இதை உங்களுக்குத் தெரிவிக்காது.

sudo systemctl restart chrony
chronyc sources -v
chronyc tracking

ஏன் ஒரு கடிகாரம் சில நிமிடங்கள் தவறாக இருந்தால் அது அப்படியே நீடிக்கிறது

ஒரு time daemon நேர வேறுபாட்டைச் சரிசெய்ய இரண்டு வழிகளைக் கொண்டுள்ளது. Slewing என்பது கடிகாரத்தின் வேகத்தை அதிகரித்து அல்லது குறைத்து பிழையைச் சரிசெய்யும்; இது நேரத்தை முன்னோக்கி நகர்த்தும், எந்த நேர முத்திரையையும் (timestamp) தவிர்க்கவோ அல்லது மீண்டும் காட்டவோ செய்யாது. Stepping என்பது நேரடியாகச் சரியான நேரத்திற்குத் தாவிச் செல்லும்; இது வேகமானது, ஆனால் கடிகாரத்தை பின்னோக்கி நகர்த்தவும் கூடும். Wall clock-ஐ அடிப்படையாகக் கொண்டு நேரத்தைக் கணக்கிடும் எந்தவொரு செயலிக்கும் கடிகாரம் பின்னோக்கி நகர்வது ஆபத்தானது, எனவே இரண்டு daemon-களுமே slewing முறையையே விரும்புகின்றன.

இந்த விருப்பத்தேர்வுதான், தவறான நேரத்தைக் காட்டும் கடிகாரம் நீண்ட நேரம் அதே நிலையில் இருக்கக் காரணம். makestep அனுமதிக்கும் கால இடைவெளிக்குள் மட்டுமே chrony நேரத்தைத் தாவிச் சரிசெய்யும் (stepping); பொதுவாக daemon தொடங்கிய பிறகு வரும் முதல் சில அப்டேட்களில் மட்டுமே இது நடக்கும். ஒரு வாரமாக இயங்கிக்கொண்டிருக்கும் chronyd, திடீரென நாற்பது வினாடி பிழையைக் கண்டறிந்தால், அது slewing முறையையே பயன்படுத்தும். நாற்பது வினாடிகளை slewing மூலம் சரிசெய்ய நீங்கள் எதிர்பார்க்கும் நேரத்தை விட அதிக காலம் எடுக்கும். எனவே, அமைதியான நேரத்தில் ஒருமுறை கட்டாயப்படுத்திச் சரிசெய்யவும்:

sudo chronyc makestep
chronyc tracking

chronyc tracking இப்போது System time offset பூஜ்ஜியத்திற்கு அருகில் இருப்பதைக் காட்ட வேண்டும், மேலும் Last offset இப்போது சரிசெய்யப்பட்ட பிழையின் அளவைக் காட்ட வேண்டும். பிஸியாக இயங்கும் database host-ல் இதைச் செய்வதற்கு முன் யோசிக்கவும், ஏனெனில் கடிகாரம் பின்னோக்கித் தாவினால், நேரம் எப்போதும் முன்னோக்கி மட்டுமே செல்லும் என்று கருதும் மென்பொருள்கள் குழப்பமடையக்கூடும். daemon-ஐ restart செய்வது இந்தச் சிக்கலைத் தீர்க்கும் மென்மையான வழியாகும், ஏனெனில் restart செய்யும்போது makestep கால இடைவெளி மீண்டும் தொடங்கும்.

Containers host-ன் கடிகாரத்தைப் பகிர்ந்து கொள்கின்றன

Container-க்கு என்று தனியாக wall clock கிடையாது, எனவே அதற்குள் எதையும் ஒத்திசைக்கத் தேவையில்லை. Linux time namespaces, monotonic மற்றும் boot-time கடிகாரங்களை மட்டுமே virtualize செய்கின்றன. CLOCK_REALTIME virtualize செய்யப்படுவதில்லை; அதாவது, ஒரு container தான் இயங்கும் host-ன் அதே system clock-ஐயே வாசிக்கிறது. Host-ல் உள்ள கடிகாரத்தைச் சரிசெய்தால், அந்த host-ல் இயங்கும் அனைத்து container-களும் ஒரே நேரத்தில் சரிசெய்யப்படும்.

இதன் விளைவாகச் சில விஷயங்களைக் கவனிக்க வேண்டும். Image-க்குள் chrony அல்லது ntpd-ஐ நிறுவ வேண்டாம், ஏனெனில் அது எந்தப் பயனும் தராது. Unprivileged container-க்குள் தேதியை மாற்ற முயன்றால் date: cannot set date: Operation not permitted பிழை ஏற்படும், ஏனெனில் அந்தச் செயல்பாட்டிற்கு kernel-க்கு CAP_SYS_TIME தேவைப்படுகிறது. CAP_SYS_TIME-ஐ வழங்குவது container-க்குத் தனிப்பட்ட கடிகாரத்தைத் தராது; மாறாக, அது host-ன் கடிகாரத்தையே மாற்றும் அதிகாரத்தை அளிக்கும், இதனால் மற்ற அனைத்து container-களின் கடிகாரமும் பாதிக்கப்படும்.

Container-க்குள் வெவ்வேறு time zone இருப்பது கடிகாரப் பிரச்சினை அல்ல. ஒரு image-ல் உள்ள /etc/localtime, அதே நேரத்தை மற்றொரு zone-க்கு ஏற்பக் காட்டும், எனவே கடிகாரம் சரியாக இருந்தாலும் date தவறாகத் தோன்றும். Container environment-ல் TZ=UTC-ஐ அமைத்தால் இந்தப் குழப்பம் நீங்கிவிடும். நீங்கள் தேர்ந்தெடுக்கும் runtime இதில் எந்த மாற்றத்தையும் ஏற்படுத்தாது, மேலும் rootless Podman மற்றும் Docker ஒப்பீடு அது எவற்றில் மாற்றத்தை ஏற்படுத்துகிறது என்பதை விளக்குகிறது.

நேர மண்டலங்கள்: server-ல் UTC, பயனர்களுக்கு உள்ளூர் நேரம்

இயந்திரத்தை UTC-க்கு அமைத்து, அதிலேயே வைத்திருக்கவும்.

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

UTC-ல் பகல்நேர சேமிப்பு நேரம் (daylight saving) கிடையாது, இதுவே அதற்கான முழுமையான காரணம். பகல்நேர சேமிப்பு நேரத்தைப் பின்பற்றும் ஒரு மண்டலத்தில், கடிகாரங்கள் பின்னோக்கிச் செல்லும் நாளில் 02:30 மணிக்கு நடக்க வேண்டிய ஒரு தினசரி பணி இரண்டு முறை இயங்கும்; கடிகாரங்கள் முன்னோக்கிச் செல்லும் நாளில் அந்தப் பணி இயங்கவே இயங்காது. மூன்று மணி நேரத்திற்கும் குறைவான மாற்றங்களை எவ்வாறு கையாள்வது என்பதை man 8 cron விளக்குகிறது: முன்னோக்கிச் செல்லும் மாற்றத்தால் விடுபட்ட பணிகள் மாற்றத்திற்குப் பிறகு உடனடியாக இயங்கும், அதேபோல் பின்னோக்கிச் செல்லும் மாற்றத்தால் மீண்டும் வரும் ஒரு மணி நேரத்திற்குள் சிக்கிக்கொள்ளும் பணிகள் இரண்டாவது முறை இயங்காது. இந்தச் செயல்பாடு நியாயமானதுதான், ஆனால் 03:00 மணிக்கு நீங்கள் இதைப் பற்றி கவலைப்பட வேண்டிய அவசியம் இருக்கக்கூடாது. UTC-ல் அந்தப் பணி ஆண்டின் ஒவ்வொரு நாளும் ஒருமுறை மட்டுமே இயங்கும். ஒரு பணி தவறான நேரத்தில் இயங்குவதற்குப் பதிலாக முற்றிலும் விடுபட்டுப் போனால், cron job அமைதியாக இயங்காமல் போவதற்கான காரணங்கள் என்பதே அதற்கு அதிக வாய்ப்புள்ள விளக்கமாகும்.

logs-ஐ வாசிப்பதற்கும் இதே வாதம் பொருந்தும். journalctl நேர முத்திரைகளை (timestamps) system நேர மண்டலத்திலேயே வடிவமைக்கும், journalctl --utc அதை UTC-க்கு மாற்றும். இரண்டு வெவ்வேறு மண்டலங்களில் உள்ள இரண்டு server-கள், ஒவ்வொரு சம்பவத்தையும் ஒரு மாற்றும் பயிற்சியாக (conversion exercise) மாற்றிவிடும்; அழுத்தமான சூழலில் செய்யப்படும் இத்தகைய மாற்றங்களே காலவரிசையைத் தவறாகப் புரிந்துகொள்ள வழிவகுக்கும். எனவே, system-களை UTC-லேயே வைத்திருக்கவும், நேர முத்திரைகளை UTC-லேயே சேமிக்கவும், மனிதர்கள் வாசிக்கும் இடத்தில் மட்டும் அதை மாற்றிக்கொள்ளவும். ஒரு கட்டளைக்கு மட்டும் உள்ளூர் நேரம் தேவைப்படுபவர்கள், இயந்திரத்தின் நேரத்தை மாற்றாமலேயே அதைப் பெற்றுக்கொள்ளலாம்:

TZ=Europe/Berlin date

timedatectl வெளியீட்டில் உள்ள மேலும் ஒரு வரி இந்தச் பகுதிக்கு உரியது. RTC in local TZ என்பது no என்று இருக்க வேண்டும். இதை yes என்று அமைப்பது, laptop-ல் Windows-ஐ dual-boot செய்யும்போது பயன்படுத்தப்படும் ஒரு தற்காலிகத் தீர்வாகும்; server-ல் இது பிற்காலத்தில் குழப்பத்தை ஏற்படுத்தும் ஒரு கூடுதல் offset-ஐ மட்டுமே சேர்க்கும். இது அமைக்கப்பட்டிருக்கும்போது, system நேரத்தை உள்ளூர் நேர மண்டலத்தில் வாசிக்க உள்ளமைக்கப்பட்டுள்ளது என்ற எச்சரிக்கையை timedatectl வெளியிடும்.

அறிகுறிகளை வைத்து சரிசெய்தல்

ஒரு server-ல் உங்கள் two-factor code நிராகரிக்கப்படுகிறது. எதையும் சரிபார்க்கும் முன் clock-ஐ சரிபார்க்கவும். இந்த code ஒவ்வொரு 30 வினாடிகளுக்கும் மாறும் counter-லிருந்து வருகிறது. எனவே, ஒரு server 90 வினாடிகள் பின்தங்கியிருந்தால், உங்கள் phone ஏற்கனவே கடந்த ஒரு step-க்கான code-ஐ அது கணக்கிடும். timedatectl கட்டளை System clock synchronized: no-ஐக் காட்டும், அல்லது chronyc tracking ஒரு பெரிய System time offset-ஐத் தெரிவிக்கும். இது நேரடியாக நிராகரிக்கப்படும் key-யிலிருந்து மாறுபட்டது; அது தனியான செய்தியைத் தரும் மற்றும் publickey authentication தோல்விகளுக்கான வழிகாட்டி-யில் விவரிக்கப்பட்டுள்ளது.

apt update ஒரு Release file இன்னும் செல்லுபடியாகாது என்று கூறுகிறது. முழுமையான செய்தி repository-ன் பெயரையும் அது எவ்வளவு காலம் செல்லுபடியாகாது என்பதையும் குறிப்பிடும், உதாரணமாக is not valid yet (invalid for another 1d 2h 3min 4s). repository-ன் Release file-ல் உள்ள தேதியை விட உங்கள் clock பின்தங்கியுள்ளது, அந்த கால அளவு எவ்வளவு பின்தங்கியுள்ளது என்பதற்கான நேரடி அளவீடு ஆகும். clock-ஐச் சரிசெய்யவும். இதைத் தவிர்க்க apt-ன் date check-ஐ முடக்க வேண்டாம், ஏனெனில் அந்தச் சோதனைதான் பழைய package index-ஐ உங்களுக்கு வழங்குவதைத் தடுக்கிறது.

ஒவ்வொரு source வரியும் unreachable நிலையைக் காட்டுகிறது மற்றும் Reach 0 ஆக உள்ளது. எந்தப் பதிலும் வரவில்லை என்றால், உங்கள் config-ஐப் பார்ப்பதை விட egress-ஐப் பார்க்கவும். NTP என்பது UDP port 123 outbound ஆகும், சில network-கள் இதை வடிகட்டலாம் அல்லது திசைதிருப்பலாம். sudo chronyc ntpdata கட்டளை Total TX மற்றும் Total RX உள்ளிட்ட source வாரியான counter-களை அச்சிடும். TX எண்ணிக்கை அதிகரித்து, RX பூஜ்ஜியமாகவே இருந்தால், உங்கள் packets வெளியேறுகின்றன, ஆனால் பதில் வரவில்லை என்று அர்த்தம்; இது உங்களுக்கும் source-க்கும் இடையில் உள்ள firewall-ஐக் குறிக்கிறது.

clock சரியாக இருந்தது, ஆனால் திடீரென மாறியது. Host நிகழ்வுகள் இதைச் செய்யும். மீட்டெடுக்கப்பட்ட snapshot, இடைநிறுத்தப்பட்ட guest, அல்லது மற்றொரு host-க்கு நேரடி migration ஆகியவை guest-ன் நேரத்தை உண்மையான நேரத்தை விடப் பின்தங்கச் செய்யலாம். chrony அடுத்த poll-ல் இதைக் கவனித்துச் சரிசெய்யும்; systemd-timesyncd நீண்ட poll இடைவெளி முடியும் வரை காத்திருக்கலாம். systemctl is-enabled chrony மூலம் daemon boot-ல் தொடங்குகிறதா என்பதை உறுதிப்படுத்தவும், ஏனெனில் கையால் தொடங்கப்பட்ட daemon அடுத்த reboot-க்குப் பிறகு இயங்காது.

offset சிறியதாக உள்ளது ஆனால் நிலைபெறவில்லை. CPU steal-ஐப் பார்க்கவும். அதன் timer interrupt தேவைப்படும்போது திட்டமிடப்படாத (scheduled) ஒரு guest-ன் மாதிரிகள் தாமதமாகும், எனவே offset நிலைபெறுவதற்குப் பதிலாக அலைந்து கொண்டிருக்கும். top இதை CPU வரியில் st என்ற எண்ணாகக் காட்டும். shared host-ல் CPU steal time-ஐ வாசித்தல் அந்த எண் எதைக் குறிக்கிறது மற்றும் அதை வைத்து நீங்கள் என்ன செய்யலாம் என்பதை விளக்குகிறது.

நீங்கள் வழங்கிய certificate இன்னும் செல்லுபடியாகாது என்று நிராகரிக்கப்படுகிறது. curl கட்டளை SSL certificate problem: certificate is not yet valid-ஐ அச்சிடும், browser-களும் இதையே சொல்லும். certificate சரியாக உள்ளது; அதைச் சரிபார்க்கும் clock பின்தங்கியுள்ளது. ஏதேனும் ஒரு machine-ல் தவறு இருக்கலாம், எனவே client மற்றும் server இரண்டையும் சரிபார்க்கவும். அதை வழங்கிய server-ன் clock தவறாக இருந்தால், certbot மற்றும் nginx certificate வழிகாட்டி அதே அமைப்பின் renewal பகுதியை விளக்குகிறது.

நீங்கள் ஏற்கனவே செய்யும் சோதனைகளுடன் இதையும் சேர்த்துக்கொள்ளுங்கள்

நேர ஒத்திசைவு (Time sync) என்பது boot-time அமைப்பாகும். இது சில மாதங்களுக்குப் பிறகு அமைதியாகத் தோல்வியடையக்கூடும். வழக்கமான சோதனைகள் மூலம் மட்டுமே இதைக் கண்டறிய முடியும், நினைவாற்றலை நம்பி இருக்க முடியாது. timedatectl மற்றும் chronyc tracking ஆகியவற்றைச் சேர்த்துப் படிக்க இரண்டு வினாடிகள் மட்டுமே ஆகும். இவற்றை புதிய VPS-ல் முதல் பத்து நிமிடங்களில் செய்ய வேண்டிய பணிகளின் ஒரு பகுதியாகச் செய்யுங்கள். மேலும், வழக்கமான Linux server பராமரிப்புப் பட்டியல் மூலம் பணிபுரியும்போதும் இவற்றைச் சரிபார்க்கவும். இந்தச் சோதனையைத் தானாகவே இயங்கச் செய்து, நேர வேறுபாடு (offset) அதிகரிக்கும்போது எச்சரிக்கை பெற விரும்பினால், systemd service மற்றும் timer எழுதுதல் என்ற பகுதியில் கொடுக்கப்பட்டுள்ள வழிமுறையைப் பின்பற்றி, குறிப்பிட்ட கால இடைவெளியில் அறிக்கை தரும் சிறிய unit-ஐ உருவாக்கலாம்.

FAQ

எனது VPS கடிகாரம் ஒத்திசைவில் உள்ளதா என்பதை எவ்வாறு சரிபார்ப்பது?

timedatectl கட்டளையை இயக்கி, System clock synchronized வரியைப் படிக்கவும். இது கர்னலின் சொந்தக் கொடியாகும் (flag); கடிகாரத்தை நிர்வகிக்கும் எந்த daemon-ஆலும் இது அமைக்கப்படும். எனவே, chrony இயங்கும் கணினியில் yes உடன் NTP service: n/a இருப்பது இயல்பானது மற்றும் சரியானது. பிழையின் அளவை அறிய, chronyc tracking கட்டளையை இயக்கி System time-ஐப் பார்க்கவும். ஒருவேளை systemd-timesyncd பயன்பாட்டில் இருந்தால், timedatectl timesync-status கட்டளையை இயக்கி Offset-ஐப் பார்க்கவும். கணினிக்கு வெளியேயுள்ள நேரத்துடன் ஒப்பிட, ஏதேனும் ஒரு HTTPS தளத்திலிருந்து கிடைக்கும் Date தலைப்பை (header) உங்கள் கணினியின் date -u உடன் ஒப்பிட்டுப் பார்க்கவும்.

VPS-ல் நான் chrony அல்லது systemd-timesyncd எதைப் பயன்படுத்த வேண்டும்?

முக்கியமான எதற்கும் chrony-ஐப் பயன்படுத்தவும். systemd-timesyncd என்பது ஒரு SNTP client ஆகும்; இது ஒரு server-ஐ மட்டுமே பின்தொடரும். எப்போதும் இணையத்தில் இணைக்கப்பட்டிருக்கும் மற்றும் தொடக்கத்திலேயே சரியான நேரத்தைக் கொண்டிருக்கும் கணினிகளுக்கு இது போதுமானது. chrony பல ஆதாரங்களை (sources) ஆய்வு செய்து, முரண்படும் ஆதாரங்களை நிராகரிக்கும்; உங்கள் கடிகாரத்தின் வேகப் பிழையைக் கற்றுக்கொள்ளும்; மேலும், host pause அல்லது live migration-க்குப் பிறகு விரைவாக நேரத்தை மீட்டெடுக்கும். Debian அல்லது Ubuntu-வில் chrony-ஐ நிறுவும்போது, systemd-timesyncd தானாகவே நீக்கப்படும், ஏனெனில் இரண்டு தொகுப்புகளும் time-daemon-ஐ வழங்குகின்றன. ஒரே நேரத்தில் இரண்டு time daemon-களை ஒருபோதும் இயக்க வேண்டாம்.

ஒரு server-ல் மட்டும் எனது TOTP குறியீடுகள் ஏன் தோல்வியடைகின்றன, மற்றவற்றில் சரியாக வேலை செய்கின்றன?

ஏனெனில் TOTP குறியீடு என்பது தற்போதைய நேரத்தைச் சார்ந்த ஒரு செயல்பாடாகும். ஒவ்வொரு 30 வினாடிகளுக்கும் ஒருமுறை மாறும் counter-லிருந்து இந்தக் குறியீடு உருவாகிறது; எனவே, server-ம் உங்கள் கைபேசியும் எந்த நிலையில் (step) உள்ளன என்பதில் உடன்பட வேண்டும். பெரும்பாலான சரிபார்ப்புக் கருவிகள் (verifiers) ஒரு படி முன்னரோ அல்லது பின்னரோ உள்ள நேரத்தை ஏற்றுக்கொள்கின்றன, இது ஒவ்வொரு திசையிலும் சுமார் அரை நிமிடம் வரை சலுகையை வழங்குகிறது. அந்த server-ல் timedatectl-ஐச் சரிபார்க்கவும். System clock synchronized-ல் no என்று காட்டினால், நேரத்தை ஒத்திசைக்கவும்; அப்போது shared secret-ஐ மாற்றாமலேயே குறியீடுகள் மீண்டும் சரியாக வேலை செய்யும்.

Docker container-க்குள் நான் நேரத்தை அமைக்க முடியுமா?

முடியாது, அதன் தேவையும் இல்லை. ஒரு container அதன் host-ன் CLOCK_REALTIME-ஐப் பகிர்ந்து கொள்கிறது, ஏனெனில் Linux time namespaces என்பது monotonic மற்றும் boot-time கடிகாரங்களை மட்டுமே virtualise செய்கின்றன. ஒரு unprivileged container-க்கு date: cannot set date: Operation not permitted கிடைக்கும். CAP_SYS_TIME-ஐச் சேர்ப்பது, container-க்குத் தனிப்பட்ட கடிகாரத்தை வழங்குவதற்குப் பதிலாக, host-ன் கடிகாரத்தையே மாற்ற அனுமதிக்கும். எனவே, host-ன் நேரத்தை ஒத்திசைக்கவும். container-க்குள் வேறுபட்ட உள்ளூர் நேரம் தேவைப்பட்டால், அது time zone அமைப்பைப் பொறுத்தது; எனவே container environment-ல் TZ-ஐ அமைக்கவும்.

ஒரு server UTC அல்லது உள்ளூர் நேரத்தைப் பயன்படுத்த வேண்டுமா?

UTC-யைப் பயன்படுத்த வேண்டும்; பயனர் வெளியீட்டைப் பார்க்கும் இடத்தில் மட்டும் உள்ளூர் நேரம் பயன்படுத்தப்பட வேண்டும். UTC நேரமானது பகல் சேமிப்பு நேரத்திற்காக (daylight saving) ஒருபோதும் மாறாது. எனவே, தினசரி வேலைகள் ஆண்டு முழுவதும் ஒரே நேரத்தில் நடக்கும், மேலும் வெவ்வேறு server-களிலிருந்து வரும் timestamps எந்த மாற்றமும் இன்றி வரிசைப்படுத்தப்படும். இதை sudo timedatectl set-timezone UTC மூலம் அமைக்கவும். உள்ளூர் நேரத்தைப் பார்க்க விரும்புவோர், ஒரு கட்டளைக்கு முன்னால் TZ=America/New_York date போன்றவற்றைச் சேர்க்கலாம்; இது system clock-ல் எந்த மாற்றத்தையும் ஏற்படுத்தாது.