* [devel] [Fwd: [#211319] FAILED srpm=libappstream-glib-0.7.12-alt1.src.rpm] @ 2018-08-13 11:52 ` Yuri Sedunov 2018-08-13 11:59 ` Dmitry V. Levin 0 siblings, 1 reply; 20+ messages in thread From: Yuri Sedunov @ 2018-08-13 11:52 UTC (permalink / raw) To: ALT Linux Team development discussions У кого-то часы отстают? ... 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [devel] [Fwd: [#211319] FAILED srpm=libappstream-glib-0.7.12-alt1.src.rpm] 2018-08-13 11:52 ` [devel] [Fwd: [#211319] FAILED srpm=libappstream-glib-0.7.12-alt1.src.rpm] Yuri Sedunov @ 2018-08-13 11:59 ` Dmitry V. Levin 2018-08-13 12:14 ` Yuri Sedunov 2018-08-13 12:25 ` Andrey Savchenko 0 siblings, 2 replies; 20+ messages in thread From: Dmitry V. Levin @ 2018-08-13 11:59 UTC (permalink / raw) To: ALT Devel discussion list [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [devel] [Fwd: [#211319] FAILED srpm=libappstream-glib-0.7.12-alt1.src.rpm] 2018-08-13 11:59 ` Dmitry V. Levin @ 2018-08-13 12:14 ` Yuri Sedunov 2018-08-13 12:25 ` Andrey Savchenko 1 sibling, 0 replies; 20+ messages in thread From: Yuri Sedunov @ 2018-08-13 12:14 UTC (permalink / raw) To: devel В Пн, 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [devel] [Fwd: [#211319] FAILED srpm=libappstream-glib-0.7.12-alt1.src.rpm] 2018-08-13 11:59 ` Dmitry V. Levin 2018-08-13 12:14 ` Yuri Sedunov @ 2018-08-13 12:25 ` Andrey Savchenko 2018-08-13 12:32 ` [devel] Q: trustworhtiness of chrony Dmitry V. Levin 1 sibling, 1 reply; 20+ messages in thread From: Andrey Savchenko @ 2018-08-13 12:25 UTC (permalink / raw) To: ALT Linux Team development discussions [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* [devel] Q: trustworhtiness of chrony 2018-08-13 12:25 ` Andrey Savchenko @ 2018-08-13 12:32 ` Dmitry V. Levin 2018-08-13 12:40 ` Anton Farygin ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Dmitry V. Levin @ 2018-08-13 12:32 UTC (permalink / raw) To: ALT Devel discussion list [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [devel] Q: trustworhtiness of chrony 2018-08-13 12:32 ` [devel] Q: trustworhtiness of chrony Dmitry V. Levin @ 2018-08-13 12:40 ` Anton Farygin 2018-08-13 12:44 ` Alexey V. Vissarionov 2018-08-14 11:31 ` Andrey Savchenko 2018-08-14 13:35 ` Vitaly Kuznetsov 2 siblings, 1 reply; 20+ messages in thread From: Anton Farygin @ 2018-08-13 12:40 UTC (permalink / raw) To: ALT Devel discussion list 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [devel] Q: trustworhtiness of chrony 2018-08-13 12:40 ` Anton Farygin @ 2018-08-13 12:44 ` Alexey V. Vissarionov 2018-08-13 12:46 ` Anton Farygin 0 siblings, 1 reply; 20+ messages in thread From: Alexey V. Vissarionov @ 2018-08-13 12:44 UTC (permalink / raw) To: ALT Linux Team development discussions [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [devel] Q: trustworhtiness of chrony 2018-08-13 12:44 ` Alexey V. Vissarionov @ 2018-08-13 12:46 ` Anton Farygin 0 siblings, 0 replies; 20+ messages in thread From: Anton Farygin @ 2018-08-13 12:46 UTC (permalink / raw) To: ALT Linux Team development discussions, Alexey V. Vissarionov 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> > > Только вот почему-то это всё стало плохо работать с какого-то времени. Раньше было лучше. Но ещё остался актуальным вопрос со скоростью старта сервера. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [devel] Q: trustworhtiness of chrony 2018-08-13 12:32 ` [devel] Q: trustworhtiness of chrony Dmitry V. Levin 2018-08-13 12:40 ` Anton Farygin @ 2018-08-14 11:31 ` Andrey Savchenko 2018-08-14 11:56 ` Anton Farygin 2018-08-14 12:12 ` Dmitry V. Levin 2018-08-14 13:35 ` Vitaly Kuznetsov 2 siblings, 2 replies; 20+ messages in thread From: Andrey Savchenko @ 2018-08-14 11:31 UTC (permalink / raw) To: ALT Linux Team development discussions [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [devel] Q: trustworhtiness of chrony 2018-08-14 11:31 ` Andrey Savchenko @ 2018-08-14 11:56 ` Anton Farygin 2018-08-16 2:57 ` Alexei Takaseev 2018-08-14 12:12 ` Dmitry V. Levin 1 sibling, 1 reply; 20+ messages in thread From: Anton Farygin @ 2018-08-14 11:56 UTC (permalink / raw) To: ALT Linux Team development discussions, Andrey Savchenko 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 минут пока поднимется файловая система - мы не можем. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [devel] Q: trustworhtiness of chrony 2018-08-14 11:56 ` Anton Farygin @ 2018-08-16 2:57 ` Alexei Takaseev 2018-08-16 4:55 ` Anton Farygin 0 siblings, 1 reply; 20+ messages in thread From: Alexei Takaseev @ 2018-08-16 2:57 UTC (permalink / raw) To: ALT Linux Team development discussions ----- Исходное сообщение ----- > От: "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с точности, регулярно вывешивался варнинг про сбитое время нод. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [devel] Q: trustworhtiness of chrony 2018-08-16 2:57 ` Alexei Takaseev @ 2018-08-16 4:55 ` Anton Farygin 2018-08-16 4:58 ` Alexei Takaseev 0 siblings, 1 reply; 20+ messages in thread From: Anton Farygin @ 2018-08-16 4:55 UTC (permalink / raw) To: ALT Linux Team development discussions, Alexei Takaseev 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с точности, регулярно > вывешивался варнинг про сбитое время нод. Это же только клиент, не сервер. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [devel] Q: trustworhtiness of chrony 2018-08-16 4:55 ` Anton Farygin @ 2018-08-16 4:58 ` Alexei Takaseev 2018-08-16 16:33 ` Michael Shigorin 0 siblings, 1 reply; 20+ messages in thread From: Alexei Takaseev @ 2018-08-16 4:58 UTC (permalink / raw) To: ALT Linux Team development discussions ----- Исходное сообщение ----- > От: "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с точности, регулярно > > вывешивался варнинг про сбитое время нод. > > Это же только клиент, не сервер. Я так понимаю, для сборочных нод как раз нужен быстрый и надежный клиент. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [devel] Q: trustworhtiness of chrony 2018-08-16 4:58 ` Alexei Takaseev @ 2018-08-16 16:33 ` Michael Shigorin 0 siblings, 0 replies; 20+ messages in thread From: Michael Shigorin @ 2018-08-16 16:33 UTC (permalink / raw) To: devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [devel] Q: trustworhtiness of chrony 2018-08-14 11:31 ` Andrey Savchenko 2018-08-14 11:56 ` Anton Farygin @ 2018-08-14 12:12 ` Dmitry V. Levin 2018-08-14 12:25 ` Andrey Savchenko 1 sibling, 1 reply; 20+ messages in thread From: Dmitry V. Levin @ 2018-08-14 12:12 UTC (permalink / raw) To: ALT Devel discussion list 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [devel] Q: trustworhtiness of chrony 2018-08-14 12:12 ` Dmitry V. Levin @ 2018-08-14 12:25 ` Andrey Savchenko 0 siblings, 0 replies; 20+ messages in thread From: Andrey Savchenko @ 2018-08-14 12:25 UTC (permalink / raw) To: ALT Linux Team development discussions [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [devel] Q: trustworhtiness of chrony 2018-08-13 12:32 ` [devel] Q: trustworhtiness of chrony Dmitry V. Levin 2018-08-13 12:40 ` Anton Farygin 2018-08-14 11:31 ` Andrey Savchenko @ 2018-08-14 13:35 ` Vitaly Kuznetsov 2018-08-14 21:56 ` Leonid Krivoshein 2 siblings, 1 reply; 20+ messages in thread From: Vitaly Kuznetsov @ 2018-08-14 13:35 UTC (permalink / raw) To: ALT Linux Team development discussions On Mon, Aug 13, 2018 at 2:32 PM Dmitry V. Levin <ldv@altlinux.org> wrote: > > Кто-нибудь читал исходный код chrony, > что этот исходный код представляет из себя по сравнению с openntpd, > им вообще можно пользоваться там, где нужно минимизировать риск > исполнения произвольного кода? > Chrony рекоммендуется к использованию по умолчанию в RHEL7, но я хотел написать о другом. NTP - не единственный протокол синхронизации времени. Насколько я понимаю, сборочнице не так важно быть синхронизованной с внешним миром, гораздо важнее ей быть синхронизованной с самой собой. Для этих целей существует, к примеру, протокол PTP поддерживаемый большинством современных серверных сетевых карт. Как клиент можно использовать тот же chrony. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [devel] Q: trustworhtiness of chrony 2018-08-14 13:35 ` Vitaly Kuznetsov @ 2018-08-14 21:56 ` Leonid Krivoshein 2018-08-15 8:52 ` Vitaly Kuznetsov 0 siblings, 1 reply; 20+ messages in thread From: Leonid Krivoshein @ 2018-08-14 21:56 UTC (permalink / raw) To: devel 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [devel] Q: trustworhtiness of chrony 2018-08-14 21:56 ` Leonid Krivoshein @ 2018-08-15 8:52 ` Vitaly Kuznetsov 2018-08-16 0:58 ` Leonid Krivoshein 0 siblings, 1 reply; 20+ messages in thread From: Vitaly Kuznetsov @ 2018-08-15 8:52 UTC (permalink / raw) To: ALT Linux Team development discussions 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [devel] Q: trustworhtiness of chrony 2018-08-15 8:52 ` Vitaly Kuznetsov @ 2018-08-16 0:58 ` Leonid Krivoshein 0 siblings, 0 replies; 20+ messages in thread From: Leonid Krivoshein @ 2018-08-16 0:58 UTC (permalink / raw) To: devel 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2018-08-16 16:33 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-08-13 11:52 ` [devel] [Fwd: [#211319] FAILED srpm=libappstream-glib-0.7.12-alt1.src.rpm] Yuri Sedunov 2018-08-13 11:59 ` Dmitry V. Levin 2018-08-13 12:14 ` Yuri Sedunov 2018-08-13 12:25 ` Andrey Savchenko 2018-08-13 12:32 ` [devel] Q: trustworhtiness of chrony Dmitry V. Levin 2018-08-13 12:40 ` Anton Farygin 2018-08-13 12:44 ` Alexey V. Vissarionov 2018-08-13 12:46 ` Anton Farygin 2018-08-14 11:31 ` Andrey Savchenko 2018-08-14 11:56 ` Anton Farygin 2018-08-16 2:57 ` Alexei Takaseev 2018-08-16 4:55 ` Anton Farygin 2018-08-16 4:58 ` Alexei Takaseev 2018-08-16 16:33 ` Michael Shigorin 2018-08-14 12:12 ` Dmitry V. Levin 2018-08-14 12:25 ` Andrey Savchenko 2018-08-14 13:35 ` Vitaly Kuznetsov 2018-08-14 21:56 ` Leonid Krivoshein 2018-08-15 8:52 ` Vitaly Kuznetsov 2018-08-16 0:58 ` Leonid Krivoshein
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git