Синхронизация времени в Linux: NTP, Chrony и systemd-timesyncd / Хабр

Что там у ntp?

Компьютеры во всем мире используют NTP (сетевой протокол времени) для синхронизации своего времени со стандартными эталонными часами через интернет с помощью иерархии серверов NTP. Основные серверы времени находятся на уровне 1, и они напрямую подключены к различным национальным службам времени на уровне 0 через спутник, радио или даже модемы по телефонным линиям.

На подавляющем большинстве эталонных серверов открыто несколько тысяч общедоступных серверов NTP stratum 2, которые доступны для всех. Многие организации и пользователи (включая меня) с большим количеством хостов, которым требуется NTP-сервер, предпочитают устанавливать свои собственные серверы времени, поэтому только один локальный хост обращается к stratum 2 или 3.

Ntp – атомные часы на каждом столе | для системного администратора

Зачем нужно точное время?

А кому вообще нужно это точное время? Конечно, оно нужно нам, пользователям, для того, чтобы мы меньше опаздывали. Представим себе современный аэропорт – для его работы сотни пилотов и диспетчеров должны пользоваться безошибочно идущими часами. Система регистрации товаров на складах, больничные учреждения, кассы по продаже железнодорожных билетов и многие другие учреждения требуют, чтобы время на всех объектах системы в той или иной степени было одинаково. Тем более компьютеры. На них работает масса служб и программ, для нормальной работы которых необходимо точное время, причем, как правило, более точное, чем это обычно нужно нам, людям. Системные службы, компоненты системы безопасности, да и просто прикладные программы могут быть очень критичны к точности часов. Наиболее ярким примером таких служб является протокол аутентификации Kerberos. Так, для его работы необходимо, чтобы на компьютерах, доступ к которым осуществляется с использованием этого протокола, системное время различалось не более чем на 5 минут. Кроме того, точное время на всех компьютерах значительно облегчает анализ журналов безопасности при расследовании инцидентов в локальной сети.

Протокол NTP

NTP (Network Time Protocol) – это протокол, предназначенный для синхронизации времени в сети. Он представляет собой набор достаточно сложных алгоритмов, призванных обеспечить высокую точность (до нескольких микросекунд) и отказоустойчивость системы синхронизации времени. Так, протокол предполагает одновременную синхронизацию с несколькими серверами.

Существует несколько версий этого протокола, имеющих некоторые отличия. Третья версия этого протокола в 1992 году была стандартизирована как RFC 1305. Четвертая (последняя на данный момент) версия привносит некоторые улучшения (автоматическая конфигурация и аутентификация, улучшение алгоритмов синхронизации) по сравнению с третьей, однако она еще не стандартизирована в RFC.

Кроме того, помимо протокола NTP, существует протокол SNTP (Simple Network Time Protocol). На уровне пакетов эти два протокола полностью совместимы. Основным отличием между ними является то, что SNTP не имеет сложных систем фильтрации и многоступенчатой корректировки ошибок, имеющихся в NTP. Таким образом, SNTP является упрощенной и более легкой в реализации версией NTP. Он предназначен для использования в тех сетях, где не требуется очень высокая точность времени, и в реализации от корпорации Microsoft обеспечивает точность в пределах 20 секунд в рамках предприятия и не более 2 секунд в пределах одного сайта. Протокол SNTP стандартизован как RFC 1769 (версия 3) и RFC 2030 (версия 4).

Модель синхронизации NTP предполагает иерархическую структуру. На первом уровне иерархии располагаются так называемые «первичные» серверы времени (First stratum). Они находятся в разных местах по всему миру и располагают самым точным временем. Таких серверов относительно немного, так как точное время на них поддерживается с помощью дорогостоящего специализированного оборудования (радиоканал, спутниковый канал). Серверы второго уровня (Second stratum) синхронизируются с серверами первого уровня, используя протокол NTP. Их уже значительно больше, однако они уже несколько рассинхронизированы (от 1 до 20 миллисекунд) относительно «первичных» серверов. Далее могут идти серверы третьего, четвертого и последующих уровней:
image001.gif
С переходом на каждый уровень немного возрастает погрешность относительно первичного сервера, но зато увеличивается общее число серверов и, следовательно, уменьшается их загрузка. Поэтому в качестве внешнего источника синхронизации вместо использования первичных серверов, обладающих наиболее точным временем, рекомендуется использовать вторичные серверы как менее загруженные.

NTP и Windows

Для синхронизации времени в ОС Windows 2000/XP/2003 используется протокол SNTP. Поддержка этого протокола реализована в виде системной службы Windows Time, входящей в состав операционной системы MS Windows 2000/XP/2003. Отличительной особенностью этой реализации является то, что служба Windows Time поддерживает доменную аутентификацию при обращении к эталонному серверу времени, что является немаловажным с точки зрения безопасности.

Существует несколько вариантов работы службы SNTP, входящей в Windows:

  • Иерархическая (NT5DS). Используется по умолчанию для всех компьютеров, объединенных в домен. Синхронизация времени на рабочих станциях и серверах домена производится по иерархии. Таким образом, рабочие станции и рядовые серверы синхронизируются с контроллером домена, аутентифицировавшим вход, контроллеры домена – с хозяином операции «эмулятор PDC», который в свою очередь синхронизируется с контроллером домена, стоящим на более высоком уровне иерархии. Следует заметить, что данный порядок синхронизации используется «по умолчанию» и может быть переопределен вручную или с использованием групповых политик. О том, как это сделать, будет рассказано ниже.
  • Принудительная синхронизация с выбранным NTP-сервером (NTP). В данном случае источник эталонного времени для службы Windows Time устанавливается либо вручную, либо с помощью групповых политик.
  • Отключение синхронизации (NoSync). Этот режим необходим для смешанной схемы поддержания времени, в которой для синхронизации с внешним источником используется продукт третьей фирмы, а для поддержания времени в рамках домена используется Windows Time.

Таким образом, в случае рабочей группы синхронизацию времени всё равно придется настраивать вручную. Например, один из компьютеров можно настроить на синхронизацию с внешним сервером по протоколу SNTP, а остальные – на синхронизацию с ним. Необходимые для этого действия будут описаны ниже.

Для домена рекомендуется использовать иерархическую синхронизацию по протоколу SNTP. В большинстве случаев она обеспечивает приемлемую точность системного времени в рамках леса домена. Кроме того, она автоматически обеспечивает безопасность обновления времени, благодаря поддержке аутентификации с Active Directory. Для поддержки «правильного» времени в домене необходимо синхронизировать контроллер домена верхнего уровня, владеющий ролью «эмулятор PDC», с внешним NTP-сервером. В нашем примере в роли такого сервера будет выступать Linux-машина с работающим демоном ntpd.

Настройка SNTP в Windows

Для настройки службы Windows Time используются две утилиты:

Net time используется главным образом для конфигурирования службы времени, а w32tm – для мониторинга и диагностики работы. Однако в Windows XP/2003 утилита w32tm претерпела существенные изменения и может быть использована для конфигурации службы времени. Настройка NTP далее будет проводиться на примере Windows XP/2003.

Итак, для того чтобы «вручную» указать источник синхронизации с помощью net time, достаточно написать в командной строке:

et time /setsntp:список_серверов_времени_через_пробел

Для получения информации о текущем сервере времени:

net time /querysntp

Узнать время на контроллере домена можно так:

net time /domain:имя_домена

А синхронизировать время с контроллером домена вот так:

net time /domain:имя_домена /set

Системной утилитой w32tm можно сделать все то же самое и даже больше:

Например, для того чтобы переопределить значения по умолчанию и настроить синхронизацию времени с внешним источником, можно воспользоваться командой:

w32tm /config /syncfromflags:manual /manualpeerlist:PeerList

А для того чтобы Windows Time применила новые настройки, вместо перезапуска службы можно использовать команду:

w32tm /config /update

Кроме того, в w32tm доступны следующие параметры, связанные с мониторингом времени на компьютерах:

Более подробные сведения о параметрах утилит net time и w32tm можно получить, используя ключ /? или открыв соответствующий раздел справочной системы «Help and Support Center» MS Windows XP/2003.

Нетрудно догадаться, что настройки службы Windows Time хранятся в реестре Windows в разделе HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32Time.

В корне раздела определяются параметры работы самой службы, в подключе Config – настройки, связанные с работой самого протокола SNTP, режим синхронизации определяется в подключе Parameters. Настройки SNTP клиента и сервера находятся в подключах TimeProvidersNtpClient и TimeProvidersNtpServer соответственно. Рассмотрим основные значения, определяющие настройку NTP клиента и сервера:

  • Type – определяет режим работы NTP-клиента (NTDS5 – иерархическая, NTP – «вручную», NoSync – не синхронизировать, AllSync – доступны все типы синхронизации);
  • Enabled – определяет, включен ли данный компонент (клиент или сервер);
  • CrossSiteSyncFlags – определяет, можно ли синхронизировать время с источником, находящимся за пределами домена, в случае если используется иерархическая синхронизация (0 – нельзя, 1 – только с эмулятором PDC, 2 – со всеми);
  • EventLogFlags – определяет, будут ли сообщения от Windows Time заноситься в журнал или нет (очень полезная функция при отладке работы).
:/>  Как зайти в BIOS на Windows 10

Другой вариант настройки службы времени Windows Time – использование групповых политик. Настройки определяются в объекте групповой политики по следующему адресу: «Computer Configuration –> Administrative Templates –> System –> Windows Time Service».

Если у вас установлен Windows 2000 Server и такой настройки вы не нашли – не отчаивайтесь, вам просто нужно обновить «Административные шаблоны». Для этого скопируйте из системной папки system32GroupPolicyAdm любой машины с установленной Windows XP все .adm-файлы на сервер, являющийся контроллером домена. Далее, определяя объект групповой политики, нажмите правой кнопкой на «Administrative templates» и выберите «Add/Remove templates…» Удалите перечисленные там шаблоны и добавьте скопированные. После нажатия кнопки «OK» шаблоны будут обновлены, и вы сможете сконфигурировать службу времени, используя групповые политики:
image002.gif
image003.gif

Нетрудно заметить, что здесь главным образом перечислены все те настройки, которые можно изменять в реестре. Ничего удивительного в этом нет, ведь именно так и работает большинство групповых политик.

В ОС Windows XP появился еще один способ задания сервера времени, который может быть очень удобен для настройки синхронизации на домашнем компьютере или компьютере, входящем в рабочую группу:
image004.gif

NTP-сервер под Linux – внешняя синхронизация для Windows-домена

Как было сказано выше, протокол NTP более устойчив к ошибкам, поэтому в качестве источника эталонного времени для внешней синхронизации лучше использовать NTP-сервер. К тому же не всегда у контроллера домена верхнего уровня есть доступ к Интернету по порту UDP 123, используемого для работы NTP. Доступ вполне может быть закрыт по соображениям безопасности, что является обычной практикой крупных организаций. В таких случаях для решения этой проблемы можно установить в демилитаризированной зоне – DMZ – свой сервер времени, настроенный на синхронизацию с внешним источником, и использовать его в качестве эталонного источника времени для синхронизации контроллера домена верхнего уровня. В качестве такого компьютера вполне подойдет любая, не обязательно современная машина с *nix-подобной ОС, например, Linux, установленной в минимальной конфигурации, без X-сервера и других потенциально уязвимых вещей.

Существует масса программ для синхронизации времени для ОС Linux. Наиболее известными являются Xntpd (NTP версия 3), ntpd (NTP версия 4), Crony и ClockSpeed. В нашем примере мы будем использовать ntp-сервер ntpd, входящий в состав Redhat 9, поставляемый в пакете ntp-4.1.2-0.rc1.2.i386.rpm.

В состав пакета входит несколько программ, предназначенных для работы с NTP.

Вот основные из них:

Стандартной возможностью протокола NTP является возможность проведения аутентификации. При этом могут использоваться как симметричные алгоритмы (DES), появившиеся еще во второй версии протокола, так и несимметричные алгоритмы, с открытым ключом, являющиеся новшеством четвертой версии.

В случае использования симметричной схемы аутентификации клиент и сервер выбирают произвольный идентификатор и один из 65534 ключей, определенных стандартом. При использовании несимметричных алгоритмов, используется так называемая схема Autokey, отличительной особенностью которой является отсутствие необходимости предварительно распределять открытые ключи серверов.

Для настройки аутентификации в ntpd существуют утилиты ntp-genkeys, ntpq и ntpdc.

Вся функциональность NTP, связанная с поддержкой точного времени, реализована в демоне ntpd. Его настройка производится обычным для UNIX способом – путем редактирования конфигурационного файла ntp.conf, находящегося в папке /etc.

Зададим следующие опции для работы NTP-сервера.

Сначала укажем серверы, с которыми будет производиться синхронизация времени:

server ntp.nasa.gov # A stratum 1 server at nasa.org
server ntp1.demos.net # A stratum 2 server at demos.net

Далее мы ограничим доступ к нашему серверу, так как мы не хотим, чтобы другие серверы могли сами менять наше время:

restrict ntp.research.gov mask 255.255.255.255 nomodify notrap noquery

Здесь маска 255.255.255.255 используется для ограничения доступа к нашему серверу со стороны сервера ntp.nasa.gov. Теперь определим список узлов в нашей локальной сети, которым мы хотим разрешить доступ к нашему NTP-серверу для получения времени:

restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap

Также нам требуется, чтобы Linux-машина имела полный доступ к ресурсам своего сервера:

restrict 127.0.0.1

И теперь самое важное: мы должны убедиться в том, что запрет по умолчанию, имеющий более высокий приоритет, закомментирован:

#restrict default ignore

После сохранения файла ntp.conf настройку можно считать оконченной, однако может так получиться, что после запуска демона время все еще не будет синхронизироваться. Дело в том, что протокол NTP изначально разрабатывался как протокол поддержания времени, а не его установки. Поэтому, если разница между показаниями часов достаточно велика (более чем несколько минут), то синхронизация производиться не будет. В этом случае имеет смысл первоначально установить время вручную при помощи команды ntpdate (также можно добавить команду ntpdate в стартовые скрипты машины):

[root@nix]# ntpdate clock.vsu.ru
17 Feb 23:44:54 ntpdate[32085]: step time server 198.123.30.132 offset 25.307598 sec
[root@nix]# ntpdate clock.vsu.ru
17 Feb 23:45:05 ntpdate[32086]: adjust time server 198.123.30.132 offset 0.002181 sec
[root@nix]# ntpdate clock.vsu.ru

Запуск ntp-демона производится через инициализационные скрипты. Если программа устанавливалась из rpm-пакета, то скорее всего все вопросы, связанные с ее автоматическим запуском, уже решены. Для того чтобы в этом убедиться, можно воспользоваться командой:

[root@nix tmp]# chkconfig -list ntpd
ntpd 0:on 1:off 2:off 3:on 4:off 5:on 6:off

Если вы не видите этой строки, значит, автоматический запуск ntpd не настроен. Чтобы это исправить, наберите:

[root@nix tmp]# chkconfig –level 035 ntpd on

Для управления NTP (старт, запуск, перезапуск, статус) используются стандартный инициализационный скрипт:

[root@nix]# /etc/init.d/ntpd start

Для просмотра статистики синхронизации сервера можно воспользоваться следующей командой:

[root@nix]# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*tick.usnogps.na .USNO. 1 u 38 64 377 220.00 0.149 7.08
-navobs1.wustl.e .PSC. 1 u 55 64 377 193.47 6.857 4.81
-ntp-nasa.arc.na .GPS. 1 u 43 64 377 254.88 7.471 9.58
-ntp0.NL.net .GPS. 1 u 144 512 377 122.54 12.515 13.75
-ntp2.ien.it .IEN. 1 u 558 1024 377 133.94 14.594 41.99
timekeeper.isi. .GPS. 1 u 13 64 377 245.30 3.454 15.08
news-zero.demos ntp0.usno.navy. 2 u 16 64 377 37.51 -3.239 11.14
LOCAL(0) LOCAL(0) 10 l - 64 377 0.00 0.000 10.01

Режимы работы NTP сервера/клиента

Клиент/сервер

Этот режим на сегодняшний день наиболее часто используется в сети Интернет. Схема работы – классическая. Клиент посылает запрос, на который в течение некоторого времени сервер присылает ответ. Настройка клиента производится с помощью директивы server в конфигурационном файле, где указывается DNS имя сервера времени.

Симметричный активный/пассивный режим

Этот режим используется в том случае, если производится синхронизация времени между большим количеством равноправных машин. Помимо того, что каждая машина синхронизируется с внешним источником, она также осуществляет синхронизацию со своими соседями (peer), выступая для них в качестве клиента и сервера времени. Поэтому даже если машина «потеряет» внешний источник, она все еще сможет получить точное время от своих соседей. Соседи могут работать в двух режимах – активном и пассивном. Работая в активном режиме, машина сама передает свое время всем машинам-соседям, перечисленным в секции peers конфигурационного файла ntp.conf. Если же в этой секции соседи не указаны, то считается, что машина работает в пассивном режиме. Для того чтобы злоумышленник не смог скомпрометировать другие машины, представившись в качестве активного источника, необходимо использовать аутентификацию.

Режим Broadcast

Этот режим рекомендуется использовать в тех случаях, когда малое количество серверов обслуживает большое количество клиентов. Работая в этом режиме, сервер периодически рассылает пакеты, используя широковещательный адрес подсети. Клиент, настроенный на синхронизацию таким способом, получает широковещательный пакет сервера и производит синхронизацию с сервером. Особенностью этого режима является то, что время доставляется в рамках одной подсети (ограничение broadcast-пакетов). Кроме того, для защиты от злоумышленников необходимо использовать аутентификацию.

Режим Multicast

Данный режим во многом похож на broadcast. Отличие заключается в том, что для доставки пакетов используются multicast-адреса сетей класса D адресного пространства IP-адресов. Для клиентов и серверов задается адрес multicast-группы, которую они используют для синхронизации времени. Это делает возможным синхронизацию групп машин, расположенных в различных подсетях, при условии, что соединяющие их маршрутизаторы поддерживают протокол IGMP и настроены на передачу группового трафика.

:/>  Ssd Mini Tweaker для Windows 10, 8, 7 | Что с компом?

Режим Manycast

Этот режим является нововведением четвертой версии протокола NTP. Он подразумевает поиск клиентом среди своих сетевых соседей manycast-серверов, получение от каждого из них образцов времени (с использованием криптографии) и выбор на основании этих данных трех «лучших» manycast-серверов, с которыми клиент будет производить синхронизацию. В случае выхода из строя одного из серверов клиент автоматически обновляет свой список.

Для передачи образцов времени клиенты и серверы, работающие в manycast-режиме, используют адреса multicast-групп (сети класса D). Клиенты и серверы, использующие один и тот же адрес, формируют одну ассоциацию. Количество ассоциаций определяется количеством используемых multicast-адресов.

Часто возникающие вопросы

Почему после команды net time /setsntp:server время не синхронизируется?

Убедитесь, что для службы w32time задан тип запуска «Автоматически».
Убедитесь, что порт UDP 123 используемого NTP-сервера доступен.
Убедитесь, что время между клиентом и сервером не отличается слишком сильно.

Может ли SNTP-клиент синхронизироваться с NTP-сервером?

Да, может, так как протокол SNTP является подмножеством NTP и полностью с ним совместим.

Можно ли использовать NTP-сервер от третьих производителей в ОС Windows 2000/XP/2003?

Да, можно воспользоваться любым сервером, платным или бесплатным. Предварительно следует отключить соответствующие компоненты (клиентские или серверные) службы Windows Time.

Почему NTP-клиент не работает на компьютере с установленным MS SQL Server?

Скорее всего проблема заключается в том, что SQL Server каким-либо образом занимает порт UDP 123. В качестве решения можно предложить запуск клиента NTP до MS SQL Server.

Демона ntpd после запуска работает 10-20 минут, после чего останавливается. В чем может быть проблема?

Убедитесь, что время клиента и сервера отличается не слишком сильно (не более 5 минут). В противном случае выполните принудительную синхронизацию при помощи ntpdate.

Можно ли синхронизировать время в OS Windows NT4, 95, 98, Me?

Можно, при помощи программ третьих фирм, например, NetTime, Automacahron, World Time5, ntpd Windows NT port.

При попытке входа в домен Windows появляется сообщение, что время между контроллером домена и рабочей станцией отличается слишком сильно, при том, что синхронизация точно настроена.

 Скорее всего проблема в том, что время сбилось очень сильно (сброс CMOS, хакерская диверсия) и службе не удается пройти аутентификацию по протоколу Kerberos. Для решения этой проблемы нужно либо вручную подвести время, либо не использовать этот вид аутентификацию при обновлении времени.

Время одно — часов много


Хосты Linux должны учитывать, что существует системное время и время RTC. RTC (Real Time Clock — часы реального времени) является немного странным и не особо точным названием для аппаратных часов.

Аппаратные часы работают непрерывно, даже когда компьютер выключен, используя аккумулятор на материнской плате системы. Основная функция RTC — хранить время, когда соединение с сервером времени недоступно. В те времена, когда нельзя было подключиться к серверу времени через интернет каждый компьютер должен был иметь точные внутренние часы.

Аппаратные часы не понимают концепцию часовых поясов; в RTC хранится только время, а не часовой пояс или смещение от UTC (Всемирное координированное время, которое также известно как GMT или среднее время по Гринвичу). Вы можете установить RTC с помощью инструмента, о котором я расскажу позже в этой статье.

Системное время — это время, которое ОС отображает на часах GUI на вашем рабочем столе, в выходных данных команды date, в метках времени журналов. Это также относится ко времени создания, изменения и открытия файлов.

На странице man для rtc есть полное описание RTC и системных часов.

Запуск 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 ~]#

Командаw32tm /monitor

  1. Может быть выполнена на любом компьютере (или контроллере) домена.
  2. Показывает список всех контроллеров домена (с которыми может выполняться синхронизация времени).
  3. Для каждого контроллера домена в поле “NTP:” отображает разницу во времени с PDC контроллером домена (который является источником для синхронизации времени во всём домене).
  4. Для каждого контроллера домена в поле “RefID:” отображается информация об источнике синхронизации времени для этого контроллера домена. Для всех контроллеров домена (кроме КД с ролью PDC) это должен быть либо другой контроллер домена, либо КД с ролью PDC.

Командаw32tm /query /configuration /verbose

  1. Может быть выполнена на любом компьютере или контроллере домена.
  2. Выводит все настройки службы времени windows для текущего компьютера.
  3. Убедитесь, что в результатах выполнения команды на всех компьютерах и контроллерах домена (кроме PDC) в разделе [TimeProviders] поле Type имеет значение NT5DS. Если это не так, настройки синхронизации на таких компьютерах надо исправлять (как – см. далее).
  4. Если у Вас Windows 2003, то Вы не можете выполнить эту команду. Вместо этого Вы можете посмотреть параметры конфигурации службы времени в реестре: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeParameters, в частности параметр Type.

Командаw32tm /query /sourceилиw32tm /query /peers

  1. Может быть выполнена на любом компьютере или контроллере домена.
  2. Показывает источник для синхронизации времени (с каким компьютером синхронизируется время того компьютера, на котором запущена эта команда). Для любых компьютеров/серверов это должен быть один из контроллеров домена, для любого контроллера домена (кроме PDC) это должен быть другой КД (обычно – с ролью PDC), для КД с ролью PDC это должен быть внешний источник синхронизации времени (интернет).
    Если в результатах выполнения команды отобразилось сообщение “VM IC Time Synchronization Provider” – значит, эта виртуальная машина синхронизируется с хостом виртуализации. Если эта виртуальная машина – один из контроллеров домена, такую настройку следует изменить!

Конфигурирование 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

Настройка синхронизации времени на контроллере домена с ролью pdc

Наш КД с ролью PDC необходимо настроить на синхронизацию с внешним источником (в интернете). Для этой цели не подходит тип синхронизации NT5DS и синхронизации в соответствии с иерархией домена (DOMHIER). Поэтому на нашем КД с ролью PDC мы используем тип синхронизации NTP и синхронизация будет настроена вручную (MANUAL).

w32tm /config /syncfromflags:manual /manualpeerlist:”0.pool.ntp.org, 1.pool.ntp.org, 2.pool.ntp.org” /reliable:yes /update

Теперь можно ускорить применение параметров и синхронизацию времени, перезагрузив службу времени и форсировав синхронизацию:

net stop w32timenet start w32time w32tm /resync /force или w32tm /resync /rediscover

После выполнения этих команд (сделав паузу в несколько минут на применение параметров и выполнение синхронизации) сравните время на контроллере домена с временем в интернете:

Немного теории

Синхронизация времени в домене может (теоретически) работать сама, безо всяких настроек. Выглядит это обычно так:

  1. Компьютеры домена и серверы синхронизируют свое время с контроллерами домена (с ближайшими к ним).
  2. Контроллеры домена синхронизируют свое время с контроллером домена, которому назначена FSMO роль PDC (в терминах windows 2000 – “первичный контроллер домена”).
  3. Контроллер домена (КД) с ролью PDC синхронизирует время с внешним источником.
:/>  Планировщик заданий Windows 10 — возможности и практическое применение

А дальше – начинаются ньюансы:

Проверка статуса перед запуском

Статус системной синхронизации часов позволяет определить, запущена ли служба 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

Первоначальная реализация NTP — это ntpd. Затем к ней присоединились две более новых, chronyd и systemd-timesyncd. Все три синхронизируют время локального хоста с сервером времени NTP. Служба systemd-timesyncd не так надёжна, как chronyd, но этого достаточно для большинства целей.

Chrony — это реализация NTP, содержащая две программы: демон chronyd и интерфейс командной строки под названием chronyc. У Chrony есть некоторые функции, которые во многих случаях просто незаменимы:


Ещё раз: NTP — это протокол, который может быть реализован на хосте Linux с использованием Chrony или systemd-timesyncd.

RPM-пакеты NTP, Chrony и systemd-timesyncd доступны в стандартных репозиториях Fedora. RPM systemd-udev — это менеджер событий ядра, который в Fedora установлен по умолчанию, но не является обязательным для использования.

Вы можете установить все три и переключаться между ними, но это создаст лишнюю головную боль. Так что лучше не стоит. Современные релизы Fedora, CentOS и RHEL перешли на Chrony как стандартную реализацию, и кроме того, у них есть systemd-timesyncd. Я считаю, что Chrony работает хорошо, обеспечивает лучший интерфейс, чем служба NTP, предоставляет гораздо больше информации и повышает контроль, что безусловно понравится системным администраторам.

Установка аппаратных часов


Вот как выглядит ситуация после запуска 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 и обнаружил вот что:

Установка часового пояса

Обычно вы указываете часовой пояс во время процедуры установки, и у вас нет задачи менять его в дальнейшем. Однако бывают случаи, когда необходимо изменить часовой пояс. Есть несколько инструментов, которые могут помочь. Для определения местного часового пояса хоста 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 ~]#

Теперь вновь можете изменить часовой пояс своего хоста на местное время.

Устройства тоже следят за временем

Есть много причин, по которым нашим устройствам и компьютерам нужно точное время. Например, в банковской сфере, на фондовых рынках и других финансовых предприятиях транзакции должны выполняться в надлежащем порядке, и для этого критически важны точные временные последовательности.

Наши телефоны, планшеты, автомобили, системы GPS и компьютеры требуют точной настройки времени и даты. Я хочу, чтобы часы на рабочем столе моего компьютера показывали правильное время. Я хочу, чтобы в моём локальном календаре напоминания появлялись в нужное время. Правильное время также гарантирует, что задания cron и systemd запускались в нужное время.

Дата и время также важны для ведения журнала, поэтому немного проще найти те или иные логи, ориентируясь по дате и времени. Например, однажды я работал в DevOps (в то время его так не называли) и занимался настройкой системы электронной почты в штате Северная Каролина.

Раньше мы обрабатывали более 20 миллионов писем в день. Отслеживание электронной почты через серию серверов или определение точной последовательности событий с использованием файлов журналов на географически разнесенных хостах может быть намного проще, если соответствующие компьютеры синхронизированы по времени.

Заключение

В этой статье рассмотрены некоторые инструменты для управления датой, временем и часовыми поясами. Инструмент 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, детка -)

Оставьте комментарий

Adblock
detector