Re: [devel] Q: trustworhtiness of chrony

[Anton Farygin <rider@basealt.ru>]

14.08.2018 14:31, Andrey Savchenko пишет:
> On Mon, 13 Aug 2018 15:32:43 +0300 Dmitry V. Levin wrote:
>> On Mon, Aug 13, 2018 at 03:25:33PM +0300, Andrey Savchenko wrote:
>>> On Mon, 13 Aug 2018 14:59:04 +0300 Dmitry V. Levin wrote:
>>>> On Mon, Aug 13, 2018 at 02:52:13PM +0300, Yuri Sedunov wrote:
>>>>> У кого-то часы отстают?
>>>>>
>>>>> ...
>>>>> check OK
>>>>> 2018-Aug-13 11:27:30 :: [x86_64-i586] plan: #4 +4 -4 =11420
>>>>> arepo/x86_64-i586/rpms/i586-libappstream-glib-devel-0.7.12-alt1.i586.rpm: BUILDTIME in the future: Mon Aug 13 11:28:15 UTC 2018
>>>>> sisyphus_check: check-buildtime ERROR: buildtime violation
>>>>> arepo/x86_64-i586/rpms/i586-libappstream-glib-0.7.12-alt1.i586.rpm: BUILDTIME in the future: Mon Aug 13 11:28:13 UTC 2018
>>>>> sisyphus_check: check-buildtime ERROR: buildtime violation
>>>>> 2018-Aug-13 11:28:13 :: [x86_64-i586] sisyphus_check FAILED
>>>>> 2018-Aug-13 11:28:13 :: [x86_64-i586] build FAILED
>>>>> 2018-Aug-13 11:28:13 :: task #211319 for sisyphus FAILED
>>>> Да, один из сборочных узлов опять заресетился, время на нём сбилось,
>>>> ntpd подправляет его каждые несколько минут на несколько секунд,
>>>> процесс сходящийся.
>>> А можно поставить chrony и плавно поправить через tike skew без
>>> всяких скачков и прочего безобразия. Мало того, при запуске он сам
>>> умеет использовать поправку на вычисленную на основе собранных
>>> ранее данных систематическую погрешность системных часов. На
>> Кто-нибудь читал исходный код chrony,
>> что этот исходный код представляет из себя по сравнению с openntpd,
>> им вообще можно пользоваться там, где нужно минимизировать риск
>> исполнения произвольного кода?
> Для минимизации рисков в chrony предусмотрено использование
> seccomp. Не знаю, есть ли в openntpd такая функциональность.
> У chrony предусмотрено более десятка опций конфигурации, так что
> можно собрать chrony-minimal, если очень хочется.
>
> Что касается аудита кода. Чем конкретно вызвана эта необходимость?
> chrony можно настроить для использования внутреннего ntp-сервера,
> так что внешних векторов атаки не будет. Безусловно, анализ кода —
> это хорошо, но тогда нужно анализировать все потенциально уязвимые
> компоненты системы, т.к. нет смысла в одной безопасной при двух
> опасных.
>
> Поэтому меня интересует: выполнялся ли аудит кода ядра и openssl,
> которые применяются на нашей сборочнице? Если да, то где он?
> Сообществу будет очень интересно. Если нет, то зачем тогда особо
> придираться к серверу времени?
>
> Следующий вопрос: зачем вообще наша сборочница настолько придирчива
> к времени сборки, что сборка на 1 секунду в будущем приводит
> к провалу всего процесса сборки пакета?
>
> Что плохого может произойти, если сборочный узел на 1 секунду
> быстрее сборочницы? Прошу привести конкретные примеры. На мой
> взгляд это ограничение не обосновано. Почему именно 1 секунда? Ведь
> опережение на 0.5 секунды сборочница пропустит (нынешний код
> сравнивает посекундно). Что такого страшного может произойти за
> 1 секунду, чего гарантированно не произойдёт за полсекунды?
>
> Субъективно, даже получасовая разница во времени для задачи работы
> сборочницы ни на что особо не повлияет. Разница в несколько часов
> уже будет неудобна разработчикам, может запутывать по
> временным зонам, поэтому я и выбрал получасовой лимит.
>
> Существующее и, на мой взгляд, чрезмерное и необоснованное
> ограничение в 1 секунду сильно попортило нервы мне и коллегам,
> работающим с e2k, т.к. пакеты могут собираться часами (а отдельные
> и днями) и получать после этого случайный фейл — пустая трата
> времени и нервов. Сейчас благодаря chrony наша проблема решена, но
> я не понимаю, ради чего люди должны страдать на других сборочницах.
>
> На мой взгляд сборочница — как и любой сложный механизм — должна
> обладать функцией самокоррекции и отказоустойчивости хотя бы
> в некоторых пределах. Если есть проблема, при которой можно
> продолжить работу, нужно сообщить админу о проблему, по
> необходимости её скорректировать и продолжить работу. Такой подход
> позволит обеспечить жизнеспособность сборочницы в условиях
> современного мира и мне очень хотелось бы, чтоб он был учтёт при
> проектировании новой сборочницы. Иначе снова получим, что после
> внеплановой перезагрузки нужно лезть в недра, вычищать временные
> файлы и вручную менять статус тасков.

Спасибо тебе, Андрей за столь внятное письмо, с которым я практически 
полностью согласен.

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

С нашим openntpd некоторые системы вообще не заводятся (ceph, например), 
т.к. там расхождение времени ещё более критично для нормального 
функционирования, а ждать даже 10-20 минут пока поднимется файловая 
система - мы не можем.