Скрипт 30-setup-network.sh делает умолчательные настройки только для понятных интерфейсов. Последующий alterator-net-eth submit-ит только те интерфейсы для которых делались изменения. (имеет право). Соответственно, если не редактировать во время установки некоторые интерефейсы, то бриджи для них не создаются. То есть получается эдакая половинчатая конфигурация. Не будет ничего плохого, если для оставшихся интерфейсов создавать "пустую" конфигурацию без ip-адреса. P.S. Поглядев скрипт совершенно не понял откуда приезжает переменная BOOTPROTO. От propagator'a? Если да, то как это вяжется с тем что initinstall.d скрипт поднимает интерфейсы через dhcp? Есть шанс при "статическом режиме" пропагатора прописать автоматом IP адрес для интерфейса, который получил адрес динамически. P.P.S. не понятно почему в одном варианте BOOTPROTO используется alterator, а в другом всё делается вручную ;) Может быть всё-таки предпочесть везде ручной вариант?
(В ответ на комментарий №1) > Скрипт 30-setup-network.sh делает умолчательные настройки только для понятных > интерфейсов. s/понятных/поднятых/
и причём здесь я?
(In reply to comment #1) > Скрипт 30-setup-network.sh делает умолчательные настройки только для понятных > интерфейсов. А какие настройки делать для непонятных интерфейсов? > Последующий alterator-net-eth submit-ит только те интерфейсы для которых > делались изменения. (имеет право). > > Соответственно, если не редактировать во время установки некоторые интерефейсы, > то бриджи для них не создаются. То есть получается эдакая половинчатая > конфигурация. > > Не будет ничего плохого, если для оставшихся интерфейсов создавать "пустую" > конфигурацию без ip-адреса. Не попробуешь -- не узнаешь. Вообще эти брижди меня не очень радуют. > P.S. Поглядев скрипт совершенно не понял откуда приезжает переменная BOOTPROTO. > От propagator'a? Больше не откуда. > Если да, то как это вяжется с тем что initinstall.d скрипт > поднимает интерфейсы через dhcp? Есть шанс при "статическом режиме" пропагатора > прописать автоматом IP адрес для интерфейса, который получил адрес динамически. Вряд ли initinstall.d скрипт станет трогать статические интерфейсы. Ему это совершенно незачем. > P.P.S. не понятно почему в одном варианте BOOTPROTO используется alterator, а в > другом всё делается вручную ;) Может быть всё-таки предпочесть везде ручной > вариант? Рвньше всё делалось через альтератор, потом та часть, в которой альтератор перестал устраивать, переписали на ручной режим. Можешь исправить. :)
Есть другое предложение - бриджи создавать в процессе эксплуатации и только на тех интерфейсах, которые будут задействованы в mkve. В этом случае мы избавимся от обязательных бриджей на тех интерфейсах, которые никак не используются для виртуальных машин. И это само по себе очень даже неплохо.
(В ответ на комментарий №5) > Есть другое предложение - бриджи создавать в процессе эксплуатации и только на > тех интерфейсах, которые будут задействованы в mkve. Я сейчас обрадую ... Бриджи нужны ещё и openvpn ;)
(В ответ на комментарий №4) > (In reply to comment #1) > > Скрипт 30-setup-network.sh делает умолчательные настройки только для понятных > > интерфейсов. > > А какие настройки делать для непонятных интерфейсов? Просто eth/options с type, bridge с type и host. etcnet поднимет интерфейсы, но там не будет настроенной сети. > > Последующий alterator-net-eth submit-ит только те интерфейсы для которых > > делались изменения. (имеет право). > > > > Соответственно, если не редактировать во время установки некоторые интерефейсы, > > то бриджи для них не создаются. То есть получается эдакая половинчатая > > конфигурация. > > > > Не будет ничего плохого, если для оставшихся интерфейсов создавать "пустую" > > конфигурацию без ip-адреса. > > Не попробуешь -- не узнаешь. Вообще эти брижди меня не очень радуют. Меня тоже. Через бридж, как я понял недавно, не работает broadcast snmp, в результате cups не видит сетевых принтеров.
для openvpn бриджи не нужны. если они вдруг нужны, то это какой-то странный конфиг openvpn.
(В ответ на комментарий №8) > для openvpn бриджи не нужны. Нужны для определённой разновидности туннелей. Так что это никакой не странный конфиг ;)
Нет, Стас. Ты ошибаешься. я использую openvpn уже в течении трёх лет, и могу сказать точно, что бриджи с openvpn лучше не использовать - это приводит к необходимости поднимать ebtables между сетками (что бы не летал левый трафик), и всё это безобразие работает всегда не так, как хотелось бы. Да и конфиг в нашем etcnet становится совсем не тривиальным, особенно когда нужно поднять openvpn на интерфейсе, с которым потом и нужно сделать бридж. Даже для tap интерфейсов лучше всего использовать статические маршруты, это намного проще, и закрывает 99% всех потребностей в openvpn.
(В ответ на комментарий №10) > Нет, Стас. Ты ошибаешься. Давай спросим sem@.
Отложено на более поздний срок.
