[devel] systemd & lo

[devel] systemd & lo

[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@, что делать будем?

-- 
WBR, Mikhail Efremov

Re: [devel] systemd & lo

[Sergey Bolshakov]

>>>>> "Mikhail" == Mikhail Efremov <sem-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:

 > 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 в etcnet по умолчанию отличаются от того,
что делает systemd ? Или проблема в том, что с systemd теперь
нельзя нафантазировать в /e/n/i/lo ? 

-- 

Re: [devel] systemd & lo

[Sergey Y. Afonin]

On Thursday 13 March 2014, Sergey Bolshakov wrote:

> Или проблема в том, что с systemd теперь нельзя
> нафантазировать в /e/n/i/lo ?  

Я так понял, что да. И это не есть хорошо...

-- 
С уважением, Сергей Афонин
asy@altlinux.ru

Re: [devel] systemd & lo

[Sergey Y. Afonin]

On Wednesday 12 March 2014, Mikhail Efremov wrote:

> - Сделать костыль в виде service-файла, в котором опускать
>   lo перед стартом network.service. Ну или прямо в
>   network.service в ExecStartPre. 
 
Лучше как-то так, привязать к systemd. network.service - это
что-то systemd-шное ? Тогда в нём нормально выглядит такая 
доработка. 

-- 
С уважением, Сергей Афонин
asy@altlinux.ru

Re: [devel] systemd & lo

[Sergey Bolshakov]

>>>>> "Alexey" == Alexey Shabalin <a.shabalin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 не будет применяться.
Что собственно теряем ?

-- 

Re: [devel] systemd & lo

[Dmitriy L. Kruglikov]

On Thu, 13 Mar 2014 15:41:50 +0400
Sergey Bolshakov wrote:

SB> Прежде чем решить, что же лучше, мне бы хотелось уяснить, в
SB> чём проблема -- а именно, какие практические следствия того,
SB> что содержимое /e/n/i/lo не будет применяться.
SB> Что собственно теряем ?

Иногда бывало полезно, кроме 127.0.0.1, "подвесить" дополнительный адрес,
на котором будет дежурить какой-либо сервис.
Сейчас, я так понимаю, эта возможность теряется.
Не так, чтоб катастрофично, но нужно будет искать обходные пути.

-- 
Best regards,
 Dmitriy Kruglikov

Re: [devel] systemd & lo

[Sergey Bolshakov]

>>>>> "Dmitriy" == Dmitriy L Kruglikov <dmitriy.kruglikov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

 > On Thu, 13 Mar 2014 15:41:50 +0400
 > Sergey Bolshakov wrote:

 SB> Прежде чем решить, что же лучше, мне бы хотелось уяснить, в
 SB> чём проблема -- а именно, какие практические следствия того,
 SB> что содержимое /e/n/i/lo не будет применяться.
 SB> Что собственно теряем ?

 > Иногда бывало полезно, кроме 127.0.0.1, "подвесить" дополнительный адрес,
 > на котором будет дежурить какой-либо сервис.
 > Сейчас, я так понимаю, эта возможность теряется.
 > Не так, чтоб катастрофично, но нужно будет искать обходные пути.

Есть TYPE=dummy для странного, зачем же фокусничать с lo.

-- 

Re: [devel] systemd & lo

[Dmitriy L. Kruglikov]

On Thu, 13 Mar 2014 15:58:54 +0400
Sergey Bolshakov wrote:

SB> Есть TYPE=dummy для странного, зачем же фокусничать с lo.
Я не настаиваю, что это край как нужно.
Но донастроить уже имеющийся интерфейс мне тогда показалось удобнее, чем заводить новый дополнительный.

Других, более веских примеров "чего мы теряем", я пока придумать не смог.
Будут примеры, напишу еще.

-- 
Best regards,
 Dmitriy Kruglikov

Re: [devel] systemd & lo

[Sergey Y. Afonin]

On Thursday 13 March 2014, Sergey Bolshakov wrote:

> Есть TYPE=dummy для странного, зачем же фокусничать с lo.
 
Я бы не сказал, что независимый от реальных интерфейсов IP - что-то странное.
lo - привычно и очевидно. Но, честно говоря, что-то я про TYPE=dummy не думал.

-- 
С уважением, Сергей Афонин

Re: [devel] systemd & lo

[Mikhail Efremov]

On Thu, 13 Mar 2014 15:41:50 +0400 Sergey Bolshakov wrote:
> >>>>> "Alexey" == Alexey Shabalin <a.shabalin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
используется.

-- 
WBR, Mikhail Efremov

Re: [devel] systemd & lo

[Sergey Bolshakov]

>>>>> "Mikhail" == Mikhail Efremov <sem-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:

 > On Thu, 13 Mar 2014 15:41:50 +0400 Sergey Bolshakov wrote:
 >> >>>>> "Alexey" == Alexey Shabalin <a.shabalin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 -- и быть уверенным, что
он не переконфигурируется позже.

-- 

Re: [devel] systemd & lo

[Sergei Epiphanov]

В письме от 13 марта 2014 16:20:18 пользователь Sergey Bolshakov написал:
> Дело не в init. Точно так же я могу вписать в cmdline ядра
> ip=<многобукв>, получить свой eth0 -- и быть уверенным, что
> он не переконфигурируется позже.

В Вашем случае Вы сами конфигурируете интерфейс и можете изменить его 
параметры, а вот на lo Вы уже никак повлиять не можете.

-- 
С уважением, Епифанов Сергей

Re: [devel] systemd & lo

[Mikhail Efremov]

On Thu, 13 Mar 2014 17:03:41 +0400 Sergei Epiphanov wrote:
> В письме от 13 марта 2014 16:20:18 пользователь Sergey Bolshakov написал:
> > Дело не в init. Точно так же я могу вписать в cmdline ядра
> > ip=<многобукв>, получить свой eth0 -- и быть уверенным, что
> > он не переконфигурируется позже.
> 
> В Вашем случае Вы сами конфигурируете интерфейс и можете изменить его 
> параметры, а вот на lo Вы уже никак повлиять не можете.

Именно. Я же не предлагаю этот гипотетический CONFIG_FORCE включённым
для всех интерфейсов, только для lo. Это в случае, если вообще нужно
изменять etcnet, в чем я совсем не уверен. Возможно лучше выбрать
вариант 2, если ни у кого нет лучших идей.

-- 
WBR, Mikhail Efremov

Re: [devel] systemd & lo

[Sergey Bolshakov]

>>>>> "Mikhail" == Mikhail Efremov <sem-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:

 > On Thu, 13 Mar 2014 17:03:41 +0400 Sergei Epiphanov wrote:
 >> В письме от 13 марта 2014 16:20:18 пользователь Sergey Bolshakov написал:
 >> > Дело не в init. Точно так же я могу вписать в cmdline ядра
 >> > ip=<многобукв>, получить свой eth0 -- и быть уверенным, что
 >> > он не переконфигурируется позже.
 >> 
 >> В Вашем случае Вы сами конфигурируете интерфейс и можете изменить его 
 >> параметры, а вот на lo Вы уже никак повлиять не можете.

 > Именно. Я же не предлагаю этот гипотетический CONFIG_FORCE включённым
 > для всех интерфейсов, только для lo. Это в случае, если вообще нужно
 > изменять etcnet, в чем я совсем не уверен. Возможно лучше выбрать
 > вариант 2, если ни у кого нет лучших идей.

Собственно, я пытаюсь сказать следующее:
поведение etcnet 'не трогаем уже поднятый интерфейс'
существует давно, если не всегда, и я нахожу это правильным.
Обсуждаемая проблема (lo/resolv.conf, остальное лирика)
возникла из-за допущения, что никакие интерфейсы до
момента service network start не подняты -- довольно
рискованного допущения.
Теперь, мы можем либо сделать гипотетический FORCE
в etcnet, либо найти способ приткнуть этот lo/resolv.conf
в другое место (напр. /etc/resolv.conf.head или что там).
Безотносительно FORCE, я бы предпочёл решение, не
поощряющее трюки с/в lo (lo/* отличный от изкоробочного --
трюк).

-- 

Re: [devel] systemd & lo

[Mikhail Efremov]

On Thu, 13 Mar 2014 17:50:28 +0400 Sergey Bolshakov wrote:
> >>>>> "Mikhail" == Mikhail Efremov <sem-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:
> 
>  > On Thu, 13 Mar 2014 17:03:41 +0400 Sergei Epiphanov wrote:
>  >> В письме от 13 марта 2014 16:20:18 пользователь Sergey Bolshakov написал:
>  >> > Дело не в init. Точно так же я могу вписать в cmdline ядра
>  >> > ip=<многобукв>, получить свой eth0 -- и быть уверенным, что
>  >> > он не переконфигурируется позже.
>  >> 
>  >> В Вашем случае Вы сами конфигурируете интерфейс и можете изменить его 
>  >> параметры, а вот на lo Вы уже никак повлиять не можете.
> 
>  > Именно. Я же не предлагаю этот гипотетический CONFIG_FORCE включённым
>  > для всех интерфейсов, только для lo. Это в случае, если вообще нужно
>  > изменять etcnet, в чем я совсем не уверен. Возможно лучше выбрать
>  > вариант 2, если ни у кого нет лучших идей.
> 
> Собственно, я пытаюсь сказать следующее:
> поведение etcnet 'не трогаем уже поднятый интерфейс'
> существует давно, если не всегда, и я нахожу это правильным.
> Обсуждаемая проблема (lo/resolv.conf, остальное лирика)
> возникла из-за допущения, что никакие интерфейсы до
> момента service network start не подняты -- довольно
> рискованного допущения.

Это было допущение, что штатно сеть настраивается etcnet'ом, в том
числе и интрфейс lo. Любая ситуация, когда интерфейсы уже подняты при
старте сервиса network - это какая-то особая ситуация, вроде настройки
в cmdline ядра. Сейчас же с systemd lo всегда уже поднят.

> Теперь, мы можем либо сделать гипотетический FORCE
> в etcnet, либо найти способ приткнуть этот lo/resolv.conf
> в другое место (напр. /etc/resolv.conf.head или что там).

Да, nameserver 127.0.0.1 можно и в другое место записать, хотя не
хотелось бы, в /etc/net таким настройкам самое место.
Ну, будет проблема при обновлении со старых конфигураций с
переходом на systemd, можно пережить. Гораздо хуже, что настройка
интерфейса при загрузке и после рестарта сети происходит из разных мест
и может быть совсем разной. Это произойдет и с другими интерфейсами,
настроенными до сервиса network, не только с lo. Но, как я уже говорил,
это какая-то особая ситуация.
С lo же сейчас это происходит всегда. Значит надо либо принять решение,
что при использовании systemd настройка lo у нас штатно невозможна
ничем, кроме самого systemd, и выключать настройку lo в etcnet совсем с
помощью DISABLED=yes (как это делается для интерфейсов, управляемых
NetworkManager'ом), либо все-таки обеспечить возможность использования
etcnet для настройки lo.

> Безотносительно FORCE, я бы предпочёл решение, не
> поощряющее трюки с/в lo (lo/* отличный от изкоробочного --
> трюк).

Я не понимаю зачем запрещать людям настраивать lo так, как они хотят.

-- 
WBR, Mikhail Efremov

Re: [devel] systemd & lo

[Mikhail Efremov]

On Thu, 13 Mar 2014 16:01:16 +0400 Mikhail Efremov wrote:
> Вообще мне кажется очевидным, что если etcnet используется для
> настройки сети, то вся конфигурация оттуда должна применяться, а не
> как-то выборочно. И уж точно это не должно зависеть от того, какой init
> используется.

Сейчас ситуация даже еще хуже: если сделать рестарт сервиса network, то
конфигурация lo изменится в соответствии с конфигурацией в /e/n/i/lo.
А там может лежать тот же resolv.conf с 127.0.0.1. Если при этом bind
окажется выключен, то резовинга не будет. И заметить это можно только
после рестарта network, т.к. после загрузки конфигурация lo другая.

-- 
WBR, Mikhail Efremov

Re: [devel] systemd & lo

[Anton Farygin]

On 13.03.2014 17:43, Mikhail Efremov wrote:
> On Thu, 13 Mar 2014 16:01:16 +0400 Mikhail Efremov wrote:
>> Вообще мне кажется очевидным, что если etcnet используется для
>> настройки сети, то вся конфигурация оттуда должна применяться, а не
>> как-то выборочно. И уж точно это не должно зависеть от того, какой init
>> используется.
>
> Сейчас ситуация даже еще хуже: если сделать рестарт сервиса network, то
> конфигурация lo изменится в соответствии с конфигурацией в /e/n/i/lo.
> А там может лежать тот же resolv.conf с 127.0.0.1. Если при этом bind
> окажется выключен, то резовинга не будет. И заметить это можно только
> после рестарта network, т.к. после загрузки конфигурация lo другая.
>

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

IMHO надо или оторвать у systemd lo, или признать, что etcnet в 
конфигурации с systemd может вызвать опасные последствия и не ставить по 
умолчанию.

Re: [devel] systemd & lo

[Денис Смирнов]

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

On Wed, Mar 12, 2014 at 09:39:47PM +0400, Mikhail Efremov wrote:

> Как выяснилось, 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@, что делать будем?

Либо сделать переменную окружения, которую учитывает etcnet (чтобы если
запускается из systemd, то конкретно loopback интерфейс обрабатывался
особо).

-- 
С уважением, Денис

http://mithraen.ru/

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

Re: [devel] systemd & lo

[Alexey Shabalin]

12 марта 2014 г., 21:39 пользователь Mikhail Efremov <sem@altlinux.ru> написал:
> 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@, что делать будем?

Извиняюсь, что отвечаю не на последнее письмо в цепочке. Там решили,
что для извращений достаточно модуля dummy.
В перечисленных выше вариантах нет такого:
- перенести инициализацию lo из etcnet в rc.sysinit, а в etcnet
игнорировать любые настройки lo.
даже если у нас runlevel < 3, наличие интерфейса lo ничем не мешает.


-- 
Alexey Shabalin