Mon, Aug 31, 2015 at 02:31:46, adsh wrote about "[freebsd] Re: [freebsd] 
ntpdate стартует раньше, чем bind": 

> Давайте  вернёмся  к тому, с чего начали. У автора темы не
> резолвились сервера точного  времени  из-за  того, что резолвер
> стартовал позже программы установки точного времени.

Да.

> Ему  было  предложено штатное рекомендуемое решение - использовать
> ntpd в режиме корректировки  времени  в любом диапазоне. Поскольку
> ntpd устанавливает время не мгновенно,  а  делает  несколько
> попыток, это решает проблему.

Уже нет. "Решает проблему" оно только в сферической сети в вакууме.
Начнём с того, что ntpd не умеет повторять запрос резолвинга. Точнее,
умеет для peer'ов всех видов, если есть на это опция сборки, не
включенная во FreeBSD. Это значит, что если резолвинг откажет из-за
торможения следующего старта или из-за того, что придёт немедленный
отказ (вполне возможно с некоторыми резолверами), то ntpd вообще не
получит никаких IP. Ещё хуже с именами в restrict, там повторов
вообще не настроишь, и асинхронный резолвинг явно выключен (понятно
почему, но ждущему старта от этого не легче).

(Это уж я не вспоминаю в прямой укор, что у всех DNS записей есть TTL
и вообще-то резолвинг надо повторять через некоторое время. Случаи,
когда IP резолвился из *.pool.ntp.org и "залипал" в ntpd годами,
описаны.)

> Потом уже началось притягивание за уши,
[...]
> Если Вы отбросите всю эту мнительность, то увидите,  что  текущее
> рекомендуемое  разработчиками  решение было дано в самом первом
> ответе.
[...]

Я вижу, что Вы чрезмерно подвержены влиянию официальных авторитетов.
"Рекомендумое разработчиками" для Вас - безусловная истина, а всё
прочее - "притягивание за уши". В то время как практически изучившие
проблему знают, что команда профессора Миллза сильна только в
математике, а как программисты они слабы и на ровном месте пропускают
очевидное (как я слышал, там бо́льшая часть программирования делается
студентами на курсовые).

>  Автор  пока  не  возражал  и не приводил дополнительных условий
> задачи.                                            

Это не является причиной ограничивать обсуждение только тем, что
просил исходный автор. Как модератор, напоминаю, что тут свободное
обсуждение всего и любыми методами в пределах законов и полиси, а не
"вопрос-ответ" стиля StackOverflow.

> Потом  начались  утверждение  оппонентов  о  том, что очерёдность
> запуска ntpd в сравнении с ntpdate имеет какое-то существенное
> значение, хотя очевидно, что это нет так, ибо он синхронизирует
> время не сразу, а через несколько минут.                                

Мне очевидно, что очерёдность запуска продолжает иметь значение,
потому что:

1. Уже упомянутые выши проблемы с резолвингом. Вы самонадеянно
предположили, что в "синхронизирует время" включается и надёжный
резолвинг сторон. Это не так.

2. Вы принципиально игнорируете проблему сервисов, которым важно
точное внешнее время с самого начала, а не когда-то заметно потом.
Таких сервисов полно, начиная с СУБД.
(Впрочем, в этом игнорировании вы объединяетесь с разработчиками
FreeBSD. Те не делают виртуальное свойство стартового скрипта "время
синхронизировано". Но для того, чтобы это сделать, нужно построить
что-то, не к обеду будь сказано, systemd-образное, что при написании в
стиле автора оного просто убьёт систему. Сделать это когда-нибудь -
нужно, но так, чтобы было диагностируемо и управляемо легко и в любой
момент.)

> Разработчик  считал,  что  программа  ntpdate  было  нужна  лишь для
> того, чтобы привести  начальное  время  в  диапазоны  обслуживаемые
> ntpd.

Повторюсь - "разработчик считал" оказалось резко противоположно тому,
что хочет комьюнити, у которого для большинства установок есть
достаточно надёжные средства синхронизироваться до уровня, когда не
нужно делать time step (что важнее, чем попасть в какие-то
определённые неизвестно почему и как "диапазоны обслуживаемые ntpd").
Пусть это будет включать в себя настроенный левой пяткой на другой
машине ntpd, с точностью до секунды-двух, но оно есть, и достаточно
для старта.

В то же время альтернатива в виде sntp с его "кто первый, тот и в
тапках, даже если у него стратум равен ULONG_MAX" оказалась уже за
пределами разумного.

> Вот, собственно, и весь расклад.                                    

И ещё раз: если хотите обсуждать по сути, отучайтесь циклиться на
авторитетах и давить ими в дискуссии. Не знаю, из каких корней растёт
у Вас такая манера, но успеха тут она не получит.


-netch-

Ответить