[devel] [Fwd: [#211319] FAILED srpm=libappstream-glib-0.7.12-alt1.src.rpm]

[devel] [Fwd: [#211319] FAILED srpm=libappstream-glib-0.7.12-alt1.src.rpm]

[Yuri Sedunov]

У кого-то часы отстают?

...
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
-- 
Yuri N. Sedunov

Re: [devel] [Fwd: [#211319] FAILED srpm=libappstream-glib-0.7.12-alt1.src.rpm]

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 906 bytes --]

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 подправляет его каждые несколько минут на несколько секунд,
процесс сходящийся.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] [Fwd: [#211319] FAILED srpm=libappstream-glib-0.7.12-alt1.src.rpm]

[Yuri Sedunov]

В Пн, 13/08/2018 в 14:59 +0300, Dmitry V. Levin пишет:
> 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 подправляет его каждые несколько минут на несколько секунд,
> процесс сходящийся.

А, ntpdate'ом разом подвести нельзя?

-- 
Yuri N. Sedunov

Re: [devel] [Fwd: [#211319] FAILED srpm=libappstream-glib-0.7.12-alt1.src.rpm]

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]

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 без
всяких скачков и прочего безобразия. Мало того, при запуске он сам
умеет использовать поправку на вычисленную на основе собранных
ранее данных систематическую погрешность системных часов. На
сборочнице e2k именно так и решил проблему, т.к. openntpd там
колбасило в интервале ±30 секунд месяцами.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

[devel] Q: trustworhtiness of chrony

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1580 bytes --]

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,
им вообще можно пользоваться там, где нужно минимизировать риск
исполнения произвольного кода?


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Q: trustworhtiness of chrony

[Anton Farygin]

13.08.2018 15:32, Dmitry V. Levin пишет:
> 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,
> им вообще можно пользоваться там, где нужно минимизировать риск
> исполнения произвольного кода?

Ну можешь посмотреть, наверное тебя в любом случае не устроит чьё-то 
мнение, хочется своё получить ?

Кода в нём заметно больше чем в openntpd, но он хоть работает нормально, 
а не подводить часы в течении недели.

Кстати, нельзя ли openntpd запатчить так, что бы он подводил время при 
старте в случае расхождения ? Хотя бы с доверенных серверов, как это 
сделано в chrony.

Re: [devel] Q: trustworhtiness of chrony

[Alexey V. Vissarionov]

[-- Attachment #1: Type: text/plain, Size: 698 bytes --]

On 2018-08-13 15:40:00 +0300, Anton Farygin wrote:

 > Кстати, нельзя ли openntpd запатчить так, что бы он подводил время
 > при старте в случае расхождения ?

Надеюсь, все догадаются, откуда эта цитата:

-s  Set the time immediately at startup if the local clock is off
    by more than 180 seconds. Allows for a large time correction,
    eliminating the need to run rdate(8) before starting. This is
    the default.

Простейшее решение - поменять одну константу.
Правильное решение - добавить параметр -o <max_offset>


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Q: trustworhtiness of chrony

[Anton Farygin]

13.08.2018 15:44, Alexey V. Vissarionov пишет:
> On 2018-08-13 15:40:00 +0300, Anton Farygin wrote:
>
>   > Кстати, нельзя ли openntpd запатчить так, что бы он подводил время
>   > при старте в случае расхождения ?
>
> Надеюсь, все догадаются, откуда эта цитата:
>
> -s  Set the time immediately at startup if the local clock is off
>      by more than 180 seconds. Allows for a large time correction,
>      eliminating the need to run rdate(8) before starting. This is
>      the default.
>
> Простейшее решение - поменять одну константу.
> Правильное решение - добавить параметр -o <max_offset>
>
>
Только вот почему-то это всё стало плохо работать с какого-то времени. 
Раньше было лучше.
Но ещё остался актуальным вопрос со скоростью старта сервера.

Re: [devel] Q: trustworhtiness of chrony

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 6917 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] Q: trustworhtiness of chrony

[Anton Farygin]

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 минут пока поднимется файловая 
система - мы не можем.

Re: [devel] Q: trustworhtiness of chrony

[Dmitry V. Levin]

On Tue, Aug 14, 2018 at 02:31:14PM +0300, Andrey Savchenko wrote:
> 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 такая функциональность.

В openntpd реализован privsep.  Та версия openntpd, которая в Сизифе,
старше seccomp.  Вообще seccomp без privsep это маркетинг и грабли.

> У chrony предусмотрено более десятка опций конфигурации, так что
> можно собрать chrony-minimal, если очень хочется.

Кому-то придётся в это посмотреть.

> Что касается аудита кода. Чем конкретно вызвана эта необходимость?

Жизненными принципами. :)

> chrony можно настроить для использования внутреннего ntp-сервера,
> так что внешних векторов атаки не будет.

Это будет сделано в любом случае.

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

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

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

> Поэтому меня интересует: выполнялся ли аудит кода ядра и openssl,
> которые применяются на нашей сборочнице? Если да, то где он?

На сборочнице используется openssh, который в конфигурации, используемой
на сборочнице, почти не использует openssl.

Общеизвестно, что самым слабым звеном операционной системы, используемой
на сборочнице, является ядро.  Даже при том, что на сборочнице
используемое подмножество ядра ограничено.

> Сообществу будет очень интересно. Если нет, то зачем тогда особо
> придираться к серверу времени?

Чтобы сервер времени не создавал дополнительных угроз.

> Следующий вопрос: зачем вообще наша сборочница настолько придирчива
> к времени сборки, что сборка на 1 секунду в будущем приводит
> к провалу всего процесса сборки пакета?

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


-- 
ldv

Re: [devel] Q: trustworhtiness of chrony

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2410 bytes --]

On Tue, 14 Aug 2018 15:12:11 +0300 Dmitry V. Levin wrote:
> On Tue, Aug 14, 2018 at 02:31:14PM +0300, Andrey Savchenko wrote:
[...]
> > Безусловно, анализ кода —
> > это хорошо, но тогда нужно анализировать все потенциально уязвимые
> > компоненты системы, т.к. нет смысла в одной безопасной при двух
> > опасных. 
> 
> С одной стороны, принято считать, что безопасность системы не превосходит
> безопасности самого слабого звена.

Вот результаты аудита кода chrony и сравнения его с другими
реализациями:

https://www.coreinfrastructure.org/blogs/securing-network-time/
https://wiki.mozilla.org/images/e/e4/Chrony-report.pdf

TL;DR: Он показал себя лучше, чем ntpd и ntpsec.
 
> > Сообществу будет очень интересно. Если нет, то зачем тогда особо
> > придираться к серверу времени?
> 
> Чтобы сервер времени не создавал дополнительных угроз.

Это правильный подход. Но дополнительных проблем он тоже не должен
создавать, а он сейчас создаёт.
 
> > Следующий вопрос: зачем вообще наша сборочница настолько придирчива
> > к времени сборки, что сборка на 1 секунду в будущем приводит
> > к провалу всего процесса сборки пакета?
> 
> Время должно быть синхронно.  Я не хочу думать о том, какими
> неприятностями в данном случае грозит рассинхронизация времени,
> поскольку время просто должно быть синхронно.

Синхронность времени на практике всегда означает "отклонение
в пределах заданного Δt". Следует выбрать обоснованное значение Δt.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] Q: trustworhtiness of chrony

[Vitaly Kuznetsov]

On Mon, Aug 13, 2018 at 2:32 PM Dmitry V. Levin <ldv@altlinux.org> wrote:
>
> Кто-нибудь читал исходный код chrony,
> что этот исходный код представляет из себя по сравнению с openntpd,
> им вообще можно пользоваться там, где нужно минимизировать риск
> исполнения произвольного кода?
>

Chrony рекоммендуется к использованию по умолчанию в RHEL7, но я
хотел написать о другом. NTP - не единственный протокол синхронизации
времени. Насколько я понимаю, сборочнице не так важно быть
синхронизованной с внешним миром, гораздо важнее ей быть
синхронизованной с самой собой. Для этих целей существует, к примеру,
протокол PTP поддерживаемый большинством современных серверных
сетевых карт. Как клиент можно использовать тот же chrony.

Re: [devel] Q: trustworhtiness of chrony

[Leonid Krivoshein]

14.08.2018 16:35, Vitaly Kuznetsov пишет:
> [...] Насколько я понимаю, сборочнице не так важно быть
> синхронизованной с внешним миром, гораздо важнее ей быть
> синхронизованной с самой собой. Для этих целей существует, к примеру,
> [...]

ntpd умеет синхронизировать с чем угодно, с самим собой (RTC), с 
партнёрами по кластеру.

server 127.127.1.2
fudge 127.127.1.2 stratum 1
peer 192.168.1.2
peer 192.168.1.3
...

Первый IP -- захардкоренный в сервере, синхронизация с внутренними часами.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] Q: trustworhtiness of chrony

[Vitaly Kuznetsov]

On Tue, Aug 14, 2018 at 11:56 PM Leonid Krivoshein
<klark.devel@gmail.com> wrote:
>
>
> 14.08.2018 16:35, Vitaly Kuznetsov пишет:
> > [...] Насколько я понимаю, сборочнице не так важно быть
> > синхронизованной с внешним миром, гораздо важнее ей быть
> > синхронизованной с самой собой. Для этих целей существует, к примеру,
> > [...]
>
> ntpd умеет синхронизировать с чем угодно, с самим собой (RTC), с
> партнёрами по кластеру.
>
> server 127.127.1.2
> fudge 127.127.1.2 stratum 1
> peer 192.168.1.2
> peer 192.168.1.3
> ...
>
> Первый IP -- захардкоренный в сервере, синхронизация с внутренними часами.
>

Сборочница состоит из более чем одного узла и задача как раз в том, чтобы
синхронизировать их между собой. PTP позволяет это сделать без открытия
сетевых портов, в качестве клиента, читающего timestamp из сетевой карты
можно использовать и ntpd, и chrony.

Re: [devel] Q: trustworhtiness of chrony

[Leonid Krivoshein]

15.08.2018 11:52, Vitaly Kuznetsov пишет:
> On Tue, Aug 14, 2018 at 11:56 PM Leonid Krivoshein
> <klark.devel@gmail.com> wrote:
>> 14.08.2018 16:35, Vitaly Kuznetsov пишет:
>>> [...] Насколько я понимаю, сборочнице не так важно быть
>>> синхронизованной с внешним миром, гораздо важнее ей быть
>>> синхронизованной с самой собой. Для этих целей существует, к примеру,
>>> [...]
>> ntpd умеет синхронизировать с чем угодно, с самим собой (RTC), с
>> партнёрами по кластеру.
>>
>> server 127.127.1.2
>> fudge 127.127.1.2 stratum 1
>> peer 192.168.1.2
>> peer 192.168.1.3
>> ...
>>
>> Первый IP -- захардкоренный в сервере, синхронизация с внутренними часами.
>>
> Сборочница состоит из более чем одного узла и задача как раз в том, чтобы
> синхронизировать их между собой. PTP позволяет это сделать без открытия
> сетевых портов, в качестве клиента, читающего timestamp из сетевой карты
> можно использовать и ntpd, и chrony.

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

PTP всё же сетевой протокол, хоть и 2й уровень OSI. Мне не приходилось с 
ним работать. Судя по описаниям, для него крайне желательны выделенные 
каналы связи. Даже не обязательно скоростные. В условиях 
непредсказуемого дедлайна, характерного для сборочницы, вряд ли можно 
получить от PTP его преимущества. Но рассмотреть как вариант наряду с 
NTPD можно.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] Q: trustworhtiness of chrony

[Alexei Takaseev]

----- Исходное сообщение -----
> От: "Anton Farygin" <rider@basealt.ru>
> Кому: "ALT Linux Team development discussions" <devel@lists.altlinux.org>, "Andrey Savchenko" <bircoph@altlinux.org>
> Отправлено: Вторник, 14 Август 2018 г 19:56:48
> Тема: Re: [devel] Q: trustworhtiness of chrony

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

Будет ли сочтено ересью утверждение, что для систем под systemd уже нет смысла ни в chrony ни в openntpd, ибо есть
timesyncd? Вот как раз на нодах ceph ушел на него, ибо что ntpd, openntpd не обеспечивали 0.05с точности, регулярно
вывешивался варнинг про сбитое время нод.

Re: [devel] Q: trustworhtiness of chrony

[Anton Farygin]

16.08.2018 05:57, Alexei Takaseev пишет:
> ----- Исходное сообщение -----
>> От: "Anton Farygin"<rider@basealt.ru>
>> Кому: "ALT Linux Team development discussions"<devel@lists.altlinux.org>, "Andrey Savchenko"<bircoph@altlinux.org>
>> Отправлено: Вторник, 14 Август 2018 г 19:56:48
>> Тема: Re: [devel] Q: trustworhtiness of chrony
>> С нашим openntpd некоторые системы вообще не заводятся (ceph,
>> например),
>> т.к. там расхождение времени ещё более критично для нормального
>> функционирования, а ждать даже 10-20 минут пока поднимется файловая
>> система - мы не можем.
> Будет ли сочтено ересью утверждение, что для систем под systemd уже нет смысла ни в chrony ни в openntpd, ибо есть
> timesyncd? Вот как раз на нодах ceph ушел на него, ибо что ntpd, openntpd не обеспечивали 0.05с точности, регулярно
> вывешивался варнинг про сбитое время нод.

Это же только клиент, не сервер.

Re: [devel] Q: trustworhtiness of chrony

[Alexei Takaseev]

----- Исходное сообщение -----
> От: "Anton Farygin" <rider@basealt.ru>
> Кому: "ALT Linux Team development discussions" <devel@lists.altlinux.org>, "Alexei Takaseev" <alexei@taf.ru>
> Отправлено: Четверг, 16 Август 2018 г 12:55:55
> Тема: Re: [devel] Q: trustworhtiness of chrony
> 
> 16.08.2018 05:57, Alexei Takaseev пишет:
> > ----- Исходное сообщение -----
> >> От: "Anton Farygin"<rider@basealt.ru>
> >> Кому: "ALT Linux Team development
> >> discussions"<devel@lists.altlinux.org>, "Andrey
> >> Savchenko"<bircoph@altlinux.org>
> >> Отправлено: Вторник, 14 Август 2018 г 19:56:48
> >> Тема: Re: [devel] Q: trustworhtiness of chrony
> >> С нашим openntpd некоторые системы вообще не заводятся (ceph,
> >> например),
> >> т.к. там расхождение времени ещё более критично для нормального
> >> функционирования, а ждать даже 10-20 минут пока поднимется
> >> файловая
> >> система - мы не можем.
> > Будет ли сочтено ересью утверждение, что для систем под systemd уже
> > нет смысла ни в chrony ни в openntpd, ибо есть
> > timesyncd? Вот как раз на нодах ceph ушел на него, ибо что ntpd,
> > openntpd не обеспечивали 0.05с точности, регулярно
> > вывешивался варнинг про сбитое время нод.
> 
> Это же только клиент, не сервер.

Я так понимаю, для сборочных нод как раз нужен быстрый и надежный клиент.

Re: [devel] Q: trustworhtiness of chrony

[Michael Shigorin]

On Thu, Aug 16, 2018 at 12:58:14PM +0800, Alexei Takaseev wrote:
> > > Будет ли сочтено ересью утверждение, что для систем под systemd
> > Это же только клиент, не сервер.
> Я так понимаю, для сборочных нод как раз нужен быстрый и надежный клиент.

Там более важен быстрый и надёжный init. :)

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info