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 наша проблема решена, но
я не понимаю, ради чего люди должны страдать на других сборочницах.

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

Best regards,
Andrew Savchenko