13146 2007-10-17 15:22:58 +0400 Прошу добавть в setup-bri возможность запуска из командной строки 2013-01-24 12:16:50 +0400 1 1 4 Development Sisyphus etcnet unstable all Linux NEW http://lists.altlinux.org/pipermail/devel/2007-September/063065.html P2 enhancement --- 13147 1 solo sem evg ldv rider sem shaba qa-sisyphus oldest_to_newest 56635 0 solo 2007-10-17 15:23:00 +0400 Прошу добавть в setup-bri возможность запуска из командной строки. Данная возможность реализована в etcnet-0.9.3-alt3.1 (см. <http://git.altlinux.ru/people/solo/packages/?p=etcnet.git;a=commit;h=4c13196debd81e628d38f33012310fb7d7de54e4>), отправленном в Daedalus. 56663 1 pilot 2007-10-17 21:04:20 +0400 Здесь также только патч на спекфайл. 56664 2 pilot 2007-10-17 21:07:13 +0400 Нашёл патч на setup-bri. Вы бы не могли описать задачу, которая решается таким кровавым способом? 56697 3 solo 2007-10-18 07:52:05 +0400 Задача автодобовления интерфейса поднятого сторонними средствами (не через etcnet) в бридж. У меня это используется для работы с veth* (см. <http://lists.altlinux.org/pipermail/sysadmins/2007-October/011963.html>): Мне понравилось работать с veth через бриджи. Алгоритм примерно такой: 1. Создаём бриджи (с IFUP_PARENTS=no, чтобы мог подниматься при отсутствии родителей), и все настройки делаем в них. 2. veth загоняем в нужные бриджи. 3. При поднятии VE -- реконфигурируем бриджи (дёргаем setup-bri) В данном случаи, основная поблема в том, что для пднятия veth ovz использует свои средства, со скриптами конфигурирования сети (etcnet, в даном случаи) никак не связанные. Единственное что можно -- вызвать свои скрипты после поднятия. Нужный функчионал (кроме возможности независимого запуска) в штатном setup-bri уже содержится. 56725 4 pilot 2007-10-19 01:28:17 +0400 Вы не поверите, но я вообще не использую виртуализацию. Может, объясните мне по шагам, как наглядно увидеть решаемую проблему? Инсталляция S4.0 у меня есть. 56732 5 solo 2007-10-19 12:40:32 +0400 Полная модель: 1. Поставить ovz ядро, vzctl и модули alterator`а для управления данным хозяйством (можно и без них, но так проще). 2. Создать тесовую VE, с id`om <veid> (используя любой шаблон). 3. Добавить в данную VE veth интерфейс: vzctl set <veid> --save --netif_add <ifname> 4. Стартануть VE, если это ещё не сделано. На данный момент в сестеме должен быть интерфейс вида veth<veid>.0 5. Создать бридж brd с IFUP_PARENTS=no и HOST='veth<veid>.0' и запустить его... Испытания: 1. В данный момент имеем: а) поднятый интерфейс veth<veid>.0 б) поднятый бридж brd, содержащий в себе veth<veid>.0 2. Останавливаем VE: vzctl stop <veid> Посли остановки имеем: а) фактическое отсутствие интерфейса veth<veid>.0 б) поднятый бридж brd, _не_ содержащий в себе veth<veid>.0 3. Запускаем VE: vzctl start <veid> Посли старта имеем: а) поднятый интерфейс veth<veid>.0 б) поднятый бридж brd, _не_ содержащий в себе veth<veid>.0 3.б -- это то самое, пути решения чего я и предлогаю... 56733 6 solo 2007-10-19 13:06:37 +0400 Как понимаю, причина данного поведения в следующем: 1. На уровне etcnet сами интерфейсы veth неописаны ни как: данная система неможет ими управлять. Простых путей добавить туда эту возможность я невижу -- veth, это внутренняя кухня OVZ, и всё управлене жёско завязанно на vzctl. 2. OVZ, в свою очередь -- неимеет понятия о бриджах, тунелях и пр.. Но оно может создавать/убивать veth интерфейсы... И vzctl можно обучить выполнять наперёд заданный скрипт после создания veth интерфейса (можно ли передать имя созданного veth как параметр данного скрита я непомню, но скорее всего можно). Сейчас (в #13147) я решаю данную проблему взаимодействия через скрипт veth-update_bri (см. <http://git.altlinux.ru/people/solo/packages/?p=vzctl.git;a=blob;f=scripts/veth-update_bri.in;h=4d3b6c7eca8477ff334f7e4799c4b0f0df1b216f;hb=2ad9a256e21f01deb5802d0475143f1cd5f4091b>), дёргающий setup-bri для активных бриджей. Но для этого мне нужно, чтобы setup-bri допускал запуск из стороннего скрипта. Если есть болие правельный путь -- готов подумать над его реализацией... 56743 7 pilot 2007-10-19 16:24:08 +0400 Итак, проблема заключается в том, что свежесозданный интерфейс свежесозданного контейнера приезжает в хост-систему, а там его никто не ждёт. Причём приехать и уехать он может в любой момент по велению высших сил. Мне кажется, что предложенная интеграция etcnet и ovz в этой ситуации пойдёт во вред обеим сторонам. Почему бы не ограничиться тем, что хост-система (в данном случае посредством etcnet) будет предоставлять готовый мост (набор мостов), а какой-то небольшой самостоятельный обработчик будет ловить приезжающие и уезжающие контейнеры и цеплять их куда им положено? Можно такой обработчик поместить в /etc/net/scripts. 56746 8 solo 2007-10-19 18:02:32 +0400 (In reply to comment #7) > Итак, проблема заключается в том, что свежесозданный интерфейс свежесозданного > контейнера приезжает в хост-систему, а там его никто не ждёт. Причём приехать > и уехать он может в любой момент по велению высших сил. Да. > Мне кажется, что > предложенная интеграция etcnet и ovz в этой ситуации пойдёт во вред обеим > сторонам. Прошу пояснить вашу мысль: мне не кажется, что предложенное изменение в скрипте setup-bri способно повредить etcnet (скорее наоборот: это дополнительный +, упрощающий интеграцию с другими системами). > Почему бы не ограничиться тем, что хост-система (в данном случае посредством > etcnet) будет предоставлять готовый мост (набор мостов), а какой-то небольшой > самостоятельный обработчик будет ловить приезжающие и уезжающие контейнеры и > цеплять их куда им положено? Можно такой обработчик поместить в > /etc/net/scripts. Выглядит несовсем логично: такой обработчик должен знать какой интерфейс в какой мост поместить. И это знание _полностью_ бедет дублировать информацию которую уже имеет etcnet (в конфигах мостов). При этом всплывут вопросы: 1. Как обрабатывать случаи противоречия данной инфы (и зачем допускать саму возможность их возникновения)? 2. Как обрабатывать случаи различия состава интерфейсов в мостах в зависимости от про etcnet`овского профиля? Для их решения, придётся слишком жёско привязывать обработчик к etcnet и дублировать часть etcnet`овской функциональности. Не думаю, что это правельно... На мой взгляд, болие логичным выглядит возможность каким либо образом сказать etcnet что-то типа: "Конфигурация сети изменилась. Действуй." PS: Может стоит перенести обсуждение в sysadmins@? 56747 9 pilot 2007-10-19 18:36:08 +0400 Забыл написать, что я предлагаю в /etc/net в конфигурации мостов не перечислять интерфейсы veth в списке HOST. Дублирования и конфликтов в этом случае не будет. 56748 10 solo 2007-10-19 18:46:05 +0400 (In reply to comment #9) > Забыл написать, что я предлагаю в /etc/net в конфигурации мостов не перечислять > интерфейсы veth в списке HOST. Дублирования и конфликтов в этом случае не будет. Как тогда обробатывать зависимость соства объединённых в мост veth от активного профиля etcnet? (Могу привести примеры ситуаций, когда такое желательно.) 56750 11 solo 2007-10-19 19:06:06 +0400 Дополню: Профили -- одна из главнейших фич etcnet, и я весьма хочу, чтобы получившиеся решение было с ними совместимо. (Хотя предложенное мной -- пока нет.) 56753 12 pilot 2007-10-19 20:05:18 +0400 Хотелось бы увидеть примеры, да. 56762 13 solo 2007-10-20 00:39:48 +0400 Простое преврощение ноута в небольшой сервер сети: несколько профилей соответствуют нескольким сетям и нескольким наборам запускаемых VE.