Більшість людей стежать за часом. Ми встаємо вчасно, щоб виконати наші ранкові ритуали та вирушити на роботу, зробити перерву на обід, вкластися у терміни проекту, відзначити дні народження та свята, сісти на літак тощо.
Більше того: дехто з нас одержимий часом. Мій годинник харчується від сонячної енергії та отримує точний час з Національного інституту стандартів та технологій () у Форт-Коллінз (штат Колорадо) через довгохвильову радіостанцію . Сигнали часу синхронізуються з атомним годинником, також розташованим у форті Коллінз. Мій Fitbit синхронізується з моїм телефоном, який синхронізується із сервером , який зрештою синхронізується з атомним годинником.
Пристрої теж стежать за часом
Є багато причин, через які нашим пристроям та комп'ютерам потрібен точний час. Наприклад, у банківській сфері, на фондових ринках та інших фінансових підприємствах транзакції мають виконуватися у належному порядку, і для цього критично важливі точні часові послідовності.
Наші телефони, планшети, автомобілі, системи GPS та комп'ютери потребують точного налаштування часу та дати. Я хочу, щоб годинник на робочому столі мого комп'ютера показував правильний час. Я хочу, щоб у моєму локальному календарі нагадування з'являлися у потрібний час. Правильне час також гарантує, що завдання cron і systemd запускалися у потрібний час.
Дата та час також важливі для ведення журналу, тому трохи простіше знайти ті чи інші логі, орієнтуючись за датою та часом. Наприклад, одного разу я працював у DevOps (на той час його так не називали) і займався налаштуванням системи електронної пошти в штаті Північна Кароліна. Раніше ми обробляли понад 20 мільйонів листів на день. Відстеження електронної пошти через серію серверів або визначення точної послідовності подій з використанням файлів журналів на географічно рознесених хостах може бути набагато простіше, якщо комп'ютери синхронізовані за часом.
Час один - годин багато
Хости Linux повинні враховувати, що є системний час і час RTC. RTC (Real Time Clock — годинник реального часу) є трохи дивною і не особливо точною назвою для апаратного годинника.
Апаратний годинник працює безперервно, навіть коли комп'ютер вимкнений, використовуючи акумулятор на материнській платі системи. Основна функція RTC – зберігати час, коли з'єднання з сервером часу недоступне. У ті часи, коли не можна було підключитися до сервера часу через інтернет, кожен комп'ютер повинен був мати точний внутрішній годинник. Операційні системи повинні були звертатися до RTC під час завантаження, і користувач повинен був вручну встановити системний час, використовуючи апаратний інтерфейс конфігурації BIOS, щоб переконатися, що він правильний.
Апаратні годинники не розуміють концепцію часових поясів; в RTC зберігається лише час, а не часовий пояс або зсув від UTC (Всесвітній координований час, який також відомий як GMT або середній час за Грінвічем). Ви можете встановити RTC за допомогою інструмента, про який я розповім пізніше у цій статті.
Системний час - це час, який ОС відображає на годиннику GUI на вашому робочому столі, у вихідних даних команди date, у мітках часу журналів. Це також стосується часу створення, зміни та відкриття файлів.
На сторінці є повний опис RTC та системного годинника.
Що там у NTP?
Комп'ютери у всьому світі використовують NTP (мережевий протокол часу) для синхронізації свого часу зі стандартним еталонним годинником через інтернет за допомогою ієрархії серверів NTP. Основні сервери часу знаходяться на рівні 1, і вони безпосередньо підключені до різних національних служб часу на рівні 0 через супутник, радіо чи навіть модеми по телефонних лініях. Служби часу на рівні 0 можуть бути атомним годинником, радіоприймачем, який налаштований на сигнали, що передаються атомним годинником, або приймачем GPS, що використовує високоточні сигнали годинника, що передаються супутниками GPS.
На переважній більшості еталонних серверів відкрито кілька тисяч загальнодоступних серверів NTP stratum 2, які доступні всім. Багато організацій і користувачів (включаючи мене) з великою кількістю хостів, яким потрібно NTP-сервер, воліють встановлювати свої власні сервери часу, тому тільки один локальний хост звертається до stratum 2 або 3. Потім вони налаштовують вузли, що залишилися в мережі для використання локального сервера часу . У разі моєї домашньої мережі це сервер рівня 3.
Різні реалізації NTP
Початкова реалізація NTP – це ntpd. Потім до неї приєдналися дві новіші, chronyd і systemd-timesyncd. Усі три синхронізують час локального хоста із сервером часу NTP. Служба systemd-timesyncd не така надійна, як chronyd, але цього достатньо для більшості цілей. Якщо RTC не синхронізовано, вона може поступово коригувати час, щоб синхронізуватися з NTP-сервером, коли локальний системний час трохи зміщується. Служба systemd-timesync не може використовуватися як сервер часу.
— це реалізація NTP, що містить дві програми: демон chronyd та інтерфейс командного рядка під назвою chronyc. У Chrony є деякі функції, які у багатьох випадках просто незамінні:
- Chrony може синхронізуватися із сервером часу набагато швидше, ніж старий сервіс ntpd. Це добре для ноутбуків чи настільних комп'ютерів, які не працюють постійно.
- Він може компенсувати коливання тактових частот, наприклад, коли хост перемикається в режим сну або входить в режим сну, або коли тактова частота змінюється через стрибкоподібну зміну частоти, яке уповільнює тактові частоти при низьких навантаженнях.
- Він вирішує проблеми з часом, пов'язані з нестабільним мережевим з'єднанням або навантаженням мережі.
- Він регулює затримки у мережі.
- Після початкової тимчасової синхронізації Chrony ніколи не зупиняє годинника. Це забезпечує стабільні та узгоджені часові інтервали для багатьох системних служб та додатків.
- Chrony може працювати навіть без підключення до мережі. У цьому випадку локальний сервер або хост можна оновити вручну.
- Chrony може виступати як NTP-сервер.
Ще раз: NTP - це протокол, який може бути реалізований на хості Linux з використанням Chrony або systemd-timesyncd.
RPM-пакети NTP, Chrony та systemd-timesyncd доступні у стандартних репозиторіях Fedora. RPM systemd-udev — це менеджер подій ядра, який Fedora встановлений за умовчанням, але не є обов'язковим для використання.
Ви можете встановити всі три та перемикатися між ними, але це створить зайвий головний біль. Тож краще не варто. Сучасні релізи Fedora, CentOS і RHEL перейшли на Chrony як стандартну реалізацію, і крім того, вони мають systemd-timesyncd. Я вважаю, що Chrony працює добре, забезпечує кращий інтерфейс, ніж служба NTP, надає набагато більше інформації та підвищує контроль, що, безумовно, сподобається системним адміністраторам.
Вимкнення служб NTP
Можливо, на вашому хості вже запущено службу NTP. Якщо це так, вам потрібно вимкнути її перед перемиканням на щось інше. У мене був запущений chronyd, тому я використовував наступні команди, щоб зупинити та вимкнути його. Запустіть відповідні команди для будь-якого демона NTP, який ви використовуєте на своєму хості:
[root@testvm1 ~]# systemctl disable chronyd ; systemctl stop chronyd
Removed /etc/systemd/system/multi-user.target.wants/chronyd.service.
[root@testvm1 ~]#Перевірте, чи служба зупинена та вимкнена:
[root@testvm1 ~]# systemctl status chronyd
● chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:chronyd(8)
man:chrony.conf(5)
[root@testvm1 ~]#Перевірка статусу перед запуском
Статус системної синхронізації годинника дозволяє визначити, чи запущено службу NTP. Оскільки ви ще не запустили NTP, команда timesync-status натякне на це:
[root@testvm1 ~]# timedatectl timesync-status
Failed to query server: Could not activate remote peer.Прямий запит статусу надає важливу інформацію. Наприклад, команда timedatectl без аргументу чи параметрів виконує підкоманду status за умовчанням:
[root@testvm1 ~]# timedatectl status
Local time: Fri 2020-05-15 08:43:10 EDT
Universal time: Fri 2020-05-15 12:43:10 UTC
RTC time: Fri 2020-05-15 08:43:08
Time zone: America/New_York (EDT, -0400)
System clock synchronized: no
NTP service: inactive
RTC in local TZ: yes
Warning: The system is configured to read the RTC time in the local time zone.
This mode cannot be fully supported. It will create various problems
with time zone changes and daylight saving time adjustments. The RTC
time is never updated, it relies on external facilities to maintain it.
If at all possible, use RTC in UTC by calling
'timedatectl set-local-rtc 0'.
[root@testvm1 ~]#Так ви отримаєте місцевий час для вашого хоста, час UTC та RTC. У цьому випадку системний час встановлено на часовий пояс America / New_York (TZ), RTC встановлено на час у місцевому часовому поясі, а служба NTP не активна. Час RTC почав трохи відхилятися від системного часу. Це нормально для систем, годинник яких не був синхронізований. Величина усунення на хості залежить від часу, що минув з останньої синхронізації системи.
Ми також отримали попередження про використання місцевого часу для RTC – це стосується змін часового поясу та налаштувань літнього часу. Якщо комп'ютер вимкнено в той момент, коли потрібно внести зміни, RTC не зміниться. Але для серверів чи інших хостів, які працюють цілодобово, це взагалі проблема. Крім того, будь-яка служба, яка забезпечує синхронізацію часу NTP, коригуватиме час хоста ще на початковому етапі запуску, тому після завершення запуску час знову стане правильним.
Встановлення часового поясу
Зазвичай ви вказуєте часовий пояс під час процедури встановлення, і у вас немає завдання міняти його надалі. Однак трапляються випадки, коли необхідно змінити часовий пояс. Є кілька інструментів, які можуть допомогти. Для визначення місцевого часового поясу хоста Linux використовує файли часових поясів. Ці файли знаходяться у каталозі /usr/share/zoneinfo. За промовчанням для мого часового поясу система прописує ось це: /etc/ localtime -> ../usr/share/zoneinfo/America/New_York. Але вам не потрібно знати такі тонкощі, щоб змінити часовий пояс.
Головне — знати офіційну назву часового поясу для вашого розташування та відповідну команду. Скажімо, ви хочете змінити часовий пояс на Лос-Анджелес:
[root@testvm2 ~]# timedatectl list-timezones | column
<SNIP>
America/La_Paz Europe/Budapest
America/Lima Europe/Chisinau
America/Los_Angeles Europe/Copenhagen
America/Maceio Europe/Dublin
America/Managua Europe/Gibraltar
America/Manaus Europe/Helsinki
<SNIP>Тепер можна встановити часовий пояс. Я використовував команду date для перевірки змін, але ви також можете використовувати timedatectl:
[root@testvm2 ~]# date
Tue 19 May 2020 04:47:49 PM EDT
[root@testvm2 ~]# timedatectl set-timezone America/Los_Angeles
[root@testvm2 ~]# date
Tue 19 May 2020 01:48:23 PM PDT
[root@testvm2 ~]#Тепер знову можна змінити часовий пояс свого хоста на місцевий час.
systemd-timesyncd
Демон systemd timesync надає реалізацію NTP, яку легко керувати в контексті systemd. Він встановлюється за замовчуванням у Fedora та Ubuntu. Однак запускається він за умовчанням лише в Ubuntu. Я не впевнений щодо інших дистрибутивів. Ви можете перевірити у себе:
[root@testvm1 ~]# systemctl status systemd-timesyncdКонфігурація systemd-timesyncd
Файл конфігурації для systemd-timesyncd – це /etc/systemd/timesyncd.conf. Це простий файл із меншою кількістю включених опцій, ніж у старих сервісах NTP та chronyd. Ось вміст цього файлу (без додаткових змін) на моїй віртуальній машині з Fedora:
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See timesyncd.conf(5) for details.
[Time]
#NTP=
#FallbackNTP=0.fedora.pool.ntp.org 1.fedora.pool.ntp.org 2.fedora.pool.ntp.org 3.fedora.pool.ntp.org
#RootDistanceMaxSec=5
#PollIntervalMinSec=32
#PollIntervalMaxSec=2048Єдиний розділ, який містить, крім коментарів, це [Time]. Усі інші рядки закоментовані. Це значення за промовчанням, їх не потрібно змінювати (якщо у вас немає причин для цього). Якщо у вас немає сервера часу NTP, визначеного в рядку NTP =, за промовчанням у Fedora використовується резервний сервер часу Fedora. Я зазвичай додаю свій сервер часу:
NTP=myntpserverЗапуск timesync
Запустити і зробити systemd-timesyncd активним можна так:
[root@testvm2 ~]# systemctl enable systemd-timesyncd.service
Created symlink /etc/systemd/system/dbus-org.freedesktop.timesync1.service → /usr/lib/systemd/system/systemd-timesyncd.service.
Created symlink /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service → /usr/lib/systemd/system/systemd-timesyncd.service.
[root@testvm2 ~]# systemctl start systemd-timesyncd.service
[root@testvm2 ~]#Встановлення апаратного годинника
Ось як виглядає ситуація після запуску timesyncd:
[root@testvm2 systemd]# timedatectl
Local time: Sat 2020-05-16 14:34:54 EDT
Universal time: Sat 2020-05-16 18:34:54 UTC
RTC time: Sat 2020-05-16 14:34:53
Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no Спочатку різниця між RTC і місцевим часом (EDT) не перевищує секунди, і розбіжність зростає ще кілька секунд протягом наступних кількох днів. Оскільки в RTC немає поняття часових поясів, команда timedatectl повинна виконати порівняння, щоб визначити потрібний часовий пояс. Якщо час RTC точно не відповідає місцевому часу, то він не відповідає і місцевому часовому поясу.
У пошуках додаткової інформації я перевірив стан systemd-timesync і виявив ось що:
[root@testvm2 systemd]# systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: disabled)
Active: active (running) since Sat 2020-05-16 13:56:53 EDT; 18h ago
Docs: man:systemd-timesyncd.service(8)
Main PID: 822 (systemd-timesyn)
Status: "Initial synchronization to time server 163.237.218.19:123 (2.fedora.pool.ntp.org)."
Tasks: 2 (limit: 10365)
Memory: 2.8M
CPU: 476ms
CGroup: /system.slice/systemd-timesyncd.service
└─822 /usr/lib/systemd/systemd-timesyncd
May 16 09:57:24 testvm2.both.org systemd[1]: Starting Network Time Synchronization...
May 16 09:57:24 testvm2.both.org systemd-timesyncd[822]: System clock time unset or jumped backwards, restoring from recorded timestamp: Sat 2020-05-16 13:56:53 EDT
May 16 13:56:53 testvm2.both.org systemd[1]: Started Network Time Synchronization.
May 16 13:57:56 testvm2.both.org systemd-timesyncd[822]: Initial synchronization to time server 163.237.218.19:123 (2.fedora.pool.ntp.org).
[root@testvm2 systemd]#Зверніть увагу на повідомлення журналу, в якому йдеться про те, що системний час не встановлено або скинуто назад. Служба Timesync встановлює системний час на основі мітки. Мітки часу підтримуються демоном timesync і створюються при кожній успішній синхронізації.
Команда timedatectl не має можливості взяти значення апаратного годинника з системного годинника. Вона може встановити час і дату лише із значення, введеного в командному рядку. Ви можете встановити RTC на те саме значення, що й системний час, використовуючи команду hwclock:
[root@testvm2 ~]# /sbin/hwclock --systohc --localtime
[root@testvm2 ~]# timedatectl
Local time: Mon 2020-05-18 13:56:46 EDT
Universal time: Mon 2020-05-18 17:56:46 UTC
RTC time: Mon 2020-05-18 13:56:46
Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
NTP service: active
RTC in local TZ: yesОпція —localtime говорить про те, що апаратний годинник показує місцевий час, а не UTC.
Для чого вам взагалі RTC?
Будь-яка реалізація NTP встановить системний годинник під час запуску. І навіщо тоді RTC? Це не зовсім так: це станеться лише у випадку, якщо у вас є з'єднання з сервером часу. Однак багато систем не мають постійного доступу до мережного з'єднання, тому апаратний годинник корисний для того, щоб Linux міг на їх основі встановити системний час. Це краще, ніж налаштування часу вручну, навіть якщо воно може відхилятися від реального часу.
Висновок
У цій статті розглянуто деякі інструменти для керування датою, часом та часовими поясами. Інструмент systemd-timesyncd надає NTP-клієнта, який може синхронізувати час на локальному хості з NTP-сервером. Однак systemd-timesyncd не надає серверну службу, тому, якщо вам потрібен NTP-сервер у вашій мережі, ви повинні використовувати ще щось - наприклад, Chrony, для роботи в якості сервера.
Я волію мати єдину реалізацію для будь-яких служб у моїй мережі, тому використовую Chrony. Якщо вам не потрібен локальний NTP-сервер або якщо ви не проти використовувати Chrony як сервер і systemd-timesyncd як SNTP-клієнт. Адже немає необхідності використовувати додаткові можливості Chrony як клієнта, якщо вас влаштовує функціонал systemd-timesyncd.
Ще одне зауваження: ви не повинні використовувати інструменти systemd для реалізації NTP. Ви можете використовувати стару версію ntpd, Chrony або іншу NTP реалізацію. Адже systemd складається з великої кількості сервісів; багато хто з них є необов'язковими, тому їх можна відключити і використовувати замість них ще щось. Це не величезний монолітний монстр. Можна не любити systemd або його частини, але ви повинні ухвалити обґрунтоване рішення.
Мені подобається реалізація NTP в systemd, але я віддаю перевагу Chrony, тому що він краще відповідає моїм потребам. Це Linux, дитинка -)
На правах реклами
VDSina пропонує , Великий вибір операційних систем для автоматичної установки, є можливість встановити будь-яку ОС з власного , зручна власної розробки та добова оплата. Нагадаємо, у нас є вічні сервери, які точно непідвладні часу 😉
Джерело: habr.com