From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: To: devel@lists.altlinux.org References: <20140312213947.6a5d3bd3@sem.office.altlinux.ru> <20140313160116.2fe315cc@sem.office.altlinux.ru> From: Sergey Bolshakov Date: Thu, 13 Mar 2014 16:20:18 +0400 In-Reply-To: <20140313160116.2fe315cc@sem.office.altlinux.ru> (Mikhail Efremov's message of "Thu, 13 Mar 2014 16:01:16 +0400") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.5-b31 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Subject: Re: [devel] systemd & lo 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: Thu, 13 Mar 2014 12:20:45 -0000 Archived-At: List-Archive: List-Post: >>>>> "Mikhail" == Mikhail Efremov writes: > On Thu, 13 Mar 2014 15:41:50 +0400 Sergey Bolshakov wrote: >> >>>>> "Alexey" == Alexey Shabalin writes: >> >> > 12 марта 2014 г., 21:39 пользователь Mikhail Efremov написал: >> >> Hello! >> >> >> >> Как выяснилось, systemd сам поднимает и настраивает loopback интерфейс, >> >> к чему не готов наш etcnet. В результате настройки >> >> из /etc/net/ifaces/lo не применяются совсем. Никак ручек по управлению >> >> этим поведением в systemd не предусмотрено. Я надеялся, что в 210 >> >> появится возможность настройки, раз уж там настройку сети прикрутили, >> >> но там как было прибито гвоздями в коде, так и осталось. >> >> С этим надо что-то делать, варианты я вижу такие: >> >> - Оторвать это в systemd. Патч придется поддерживать, апстрим такое >> >> точно не примет. >> >> - Сделать костыль в виде service-файла, в котором опускать lo перед >> >> стартом network.service. Ну или прямо в network.service в >> >> ExecStartPre. >> >> - Добавить в etcnet какой-нибудь параметр CONFIG_FORCE для >> >> принудительной настройки интерфейса даже если он уже поднят. Но тогда >> >> интерфейс всегда будет настраиваться заново при повторном service >> >> network start. Хотя может это и не так страшно. >> >> >> >> Вопрос в первую очередь к shaba@ и sbolshakov@, что делать будем? >> >> >> >> > Чесно говоря, не знаю как лучше поступить. >> > Совсем вырезать настройку lo тоже неочень хорошо. Она используется в >> > настройках namespace(netns), и nspawn. Возможно это и никто сейчас не >> > использует, но лишаться этого тоже не хорошо. >> > Может лучше CONFIG_FORCE для etcnet? >> >> Прежде чем решить, что же лучше, мне бы хотелось уяснить, в чём >> проблема -- а именно, какие практические следствия того, что >> содержимое /e/n/i/lo не будет применяться. >> Что собственно теряем ? > Ну, в частности у нас давно уже в дистрибутивах туда кладется > resolv.conf с 127.0.0.1 в случае конфигурации bind как локального > резолвера. При переходе на systemd это вдруг перестает работать, что не > здорово. Также помнится тот же pilot@ когда-то в багзилле говорил о > том, что в конфигурации lo может быть не только 127.0.0.1 и в etcnet не > зря настройка lo сделана так же, как и настройка любого другого > интерфейса. > Вообще мне кажется очевидным, что если etcnet используется для > настройки сети, то вся конфигурация оттуда должна применяться, а не > как-то выборочно. И уж точно это не должно зависеть от того, какой init > используется. Дело не в init. Точно так же я могу вписать в cmdline ядра ip=<многобукв>, получить свой eth0 -- и быть уверенным, что он не переконфигурируется позже. --