From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: To: ALT Linux Team development discussions , Andrey Savchenko References: <20180813112813.GA25532@gyle.altlinux.org> <20180813115904.GC19699@altlinux.org> <20180813152533.f5fc9b8a379dbe396f9e6845@altlinux.org> <20180813123243.GA20495@altlinux.org> <20180814143114.365690229320119998d2889d@altlinux.org> From: Anton Farygin Organization: BaseALT Message-ID: Date: Tue, 14 Aug 2018 14:56:48 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180814143114.365690229320119998d2889d@altlinux.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [devel] Q: trustworhtiness of chrony X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 11:56:49 -0000 Archived-At: List-Archive: List-Post: 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 минут пока поднимется файловая система - мы не можем.