Как настроить Linux-клиент для использования информации NTP, предоставленной через DHCP?

Question 1

Существует так много учебников, объясняющих, как настроить сервер dhcpd в отношении предоставления предложений по NTP клиентам DHCP, что я всегда думал, что конфигурация ntp выполняется автоматически. Недавно я начал замечать сбои времени в своей локальной сети, поэтому я предполагаю, что это было неверное предположение. Я решил выяснить, как можно минимизировать конфигурацию клиента NTP, если приложены усилия для настройки предложений ntp-server через dhcpd.

Мне не удалось найти много информации, кроме этого учебника помощи, специфичного для Ubuntu https://help.ubuntu.com/community/UbuntuTime. Даже здесь (см. абзац под “Устранение неполадок -> Какой конфигурационный файл используется?”) информация скудна, но говорится, что если файл /etc/ntp.conf.dhcp найден, он будет использоваться вместо этого. Прежде всего, на самом деле местоположение, о котором здесь упоминал автор, это /var/lib/ntp/ntp.conf.dhcp, как наблюдается в /etc/init.d/ntp, но независимо от этого наличие этого файла не гарантирует, что NTP будет запрашивать серверы у dhclient. В результате мне нужно явно добавить клаузу server в ntp.conf.dhcp для моего локального NTP сервера. Но в этом случае, почему я вообще настраиваю параметры NTP на сервере dhcpd?

Это кажется противоречащим интуиции, т.е. настроить параметры NTP один раз (т.е. на сервере) и позволить серверу dhcpd делегировать информацию клиентам. Как я могу минимизировать (если не избежать вовсе) конфигурацию клиента для NTP? В качестве альтернативы, как я могу получить информацию о ntp через dhclient.

Существует ли CLI-решение, подходящее для всех дистрибутивов Linux?

Я предполагаю, что у каждого клиента должны быть исполняемые файлы ntpd, но я не знаю, как действовать дальше.

Спасибо

ИЗМЕНЕНИЕ:
Подробный вывод клиента Ubuntu при ручном запуске dhclient:

sudo dhclient -1 -d -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0
Клиент DHCP Internet Systems Consortium 4.2.4
Авторские права 2004-2012 Internet Systems Consortium.
Все права защищены.
Для получения информации посетите https://www.isc.org/software/dhcp/

Прослушивание на LPF/eth0/20:cf:30:0e:6c:12
Отправка на LPF/eth0/20:cf:30:0e:6c:12
Отправка на Socket/fallback
DHCPREQUEST на 192.168.112.150 на eth0 к 255.255.255.255 порт 67 (xid=0x2e844b8f)
DHCPACK на 192.168.112.150 от 192.168.112.112
перезагрузка: Неизвестный экземпляр: 
invoke-rc.d: initscript smbd, действие "reload" не удалось.
RTNETLINK отвечает: Файл существует
 * Остановка сервера NTP ntpd
   ...готово.
 * Запуск сервера NTP ntpd
   ...готово.
привязано к 192.168.112.150 -- продление через 41963 секунды.

Сервис ntpd перезапускается, но после выполнения ntpq -cpe -cas я все равно не вижу своего локального NTP сервера в списке NTP серверов.

Конечно, мой сервер dhcpd действительно имеет option ntp-servers

subnet 192.168.112.0 netmask 255.255.255.0 {
        max-lease-time 604800;
        default-lease-time 86400;
        authoritative;
        ignore client-updates;

        option ntp-servers 192.168.112.112; #сам

        ... (много других опций)
}

Question 2

Если ваш DHCP сервер настроен на предоставление опции ntp-servers, вы можете настроить свой dhclient на запрос ntp-servers, добавив ntp-servers к строке запроса по умолчанию в dhclient.conf, как показано в конце этого примера из Ubuntu Linux (начиная с 19.04, но присутствует как минимум с 12.04):

request subnet-mask, broadcast-address, time-offset, routers,
        domain-name, domain-name-servers, domain-search, host-name,
        dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn, dhcp6.sntp-servers,
        netbios-name-servers, netbios-scope, interface-mtu,
        rfc3442-classless-static-routes, ntp-servers;

/etc/ntp.conf и информация из DHCP будут использованы для создания /etc/ntp.conf.dhcp.

Вашему ntpd необходимо указать использовать /etc/ntp.conf.dhcp, если он существует. В версии Ubuntu, которую я использую, это делается через /etc/dhcp/dhclient-exit-hooks.d/ntp. <– это файл, который говорит NTPd использовать /etc/ntp.conf.dhcp, если он существует, и просто использовать /etc/ntp.conf, если его нет.

Question 3

Все зависит от настройки сети/компонентов DHCP/NTP, которые вы используете, и для какой комбинации ваша дистрибуция выполнила интеграцию.

По состоянию на 2020 год, по крайней мере, некоторые дистрибуции считают Chrony лучшей¹ альтернативой NTPD, и поэтому Chrony устанавливается по умолчанию, а интеграция клиента DHCP с клиентом DHCP поддерживается только для Chrony.

Для настройки сети популярным вариантом среди дистрибуций является NetworkManager (где NetworkManager автоматически выполняет вызов клиента DHCP с конфигурацией по умолчанию для дистрибуции). Таким образом, ожидается, что локальный NTP сервер, предоставляемый DHCP, будет выбран, если вы используете значения по умолчанию вашей дистрибуции, т.е. NetworkManager и Chrony.

NetworkManager и Chrony

При использовании Chrony вы можете проверить, была ли информация о сервере NTP, объявленном DHCP, передана Chrony следующим образом:

# chronyc sources
210 Число источников = 5
МС Имя/IP адрес         Стратум Опрашивание Доступ Последний ответ Последний образец               
===============================================================================
^- fritz.box                     3   6     0  1015   +627us[  -23us] +/-   47ms
^* ntp3.rrze.ipv6.uni-erlan>     1   7   377    47   +997us[+1007us] +/-   26ms
^+ tethys.hot-chilli.net         2   7   377    47   +522us[ +533us] +/-   51ms
^+ mail.jabber-germany.de        3   7   377    46   +352us[ +352us] +/-   61ms
^+ 2a.ncomputers.org             2   7   377    44  -2900us[-2900us] +/-   73ms

(Это с системы Fedora 31 с NetworkManager и Chrony, использующими конфигурацию по умолчанию.)

Пример показывает, что мой локальный NTP сервер, включенный в мой домашний маршрутизатор (fritz.box), который объявляется через DHCP, на самом деле известен Chrony (каким-то конфигурационным/кодом соединения NetworkManager), но в настоящее время он не используется Chrony (см. M -> - – т.е. второй столбец), потому что последние 8 ответов были недействительными (см. Reach -> 0).

S
    Этот столбец указывает состояние источника.
      ·   * указывает на источник, с которым chronyd в настоящее время
            синхронизирован.
      ·   + указывает на приемлемые источники, которые комбинируются с
            выбранным источником.
      ·   - указывает на приемлемые источники, которые исключены комбинирующим алгоритмом.
[..]
Доступ
Это показывает регистр доступности источника, напечатанный в виде восьмеричного числа. Регистр имеет 8 бит и обновляется при каждом получении или пропущенном пакете от источника. Значение 377 указывает на то, что был получен действительный ответ для всех из последних восьми передач.

(chronyc(1) на F32)

Как видите, при таких дистрибуциях все должно работать “из коробки”.² Вам просто нужно убедиться, что Chrony и NetworkManager установлены (и что ваш локальный NTP сервер отправляет действительные ответы).

Networkd и Timesyncd

Networkd и Timesyncd являются частями systemd и, когда они включены (вместо NetworkManager и Chrony), они занимаются настройкой сети и работают как клиент NTP.

Если systemd уже используется (вероятно, так и есть), его можно считать более легковесной альтернативой для серверов и небольших встроенных устройств по сравнению с NetworkManager и Chrony. Однако некоторые дистрибуции, такие как RHEL/CentOS 8, не пакуют эти компоненты.

Когда и Networkd, и Timesyncd включены, Networkd по умолчанию делает NTP, предоставленный DHCP, доступным для Timesyncd, который предпочитает его перед другими.

¹ См. также:

Chrony должен использоваться для всех систем, за исключением систем, которые управляются или контролируются инструментами, не поддерживающими chrony, или систем с аппаратными опорными часами, которые не могут работать с chrony.

(Рекомендация RedHat в руководстве администратора RHEL 7)