в etcnet есть одна проблема: * невозможно остановить интерфейс штатными средствами, если ранее он был отмечен disabled * невозможно остановить firewall через efw ( да и штатными средствами тоже), если ранее он был отключен через config_fw = no.
деструктор всегда должен работать, то есть если я говорю чему-то "стоять", а оно "идёт", то наверное стоит всё-таки остановить. В противном случае в конфигураторах приходится делать пляски с конфигами: сначала останавливать, а потом уже менять параметры.
> В противном случае в конфигураторах приходится делать пляски с конфигами: > сначала останавливать, а потом уже менять параметры. Для изменения некоторых параметров именно такой способ является единственно правильным. Расскажи, в каких именно ситуациях текущее поведение является проблемным.
1. Мне самому не нравится то, что у меня efw не работает без опции. Уберу, наверное, вроде ничего плохого не произойдет. 2. Не всегда stop уместен, он может делать что-то такое, что не должен делать, если перед этим не было start, роутинг менять, например, или модули ядра выгружать. Можно придумать некий force stop для тех, кто знает, что делает.
(In reply to comment #2) > > В противном случае в конфигураторах приходится делать пляски с конфигами: > > сначала останавливать, а потом уже менять параметры. > > Для изменения некоторых параметров именно такой способ является > единственно правильным. Расскажи, в каких именно ситуациях текущее > поведение является проблемным. > Получаю команду на изменение параметров интерфейса. Один из параметров Disabled yes. Обычно после изменения параметров логично сделать ifdown/ifup (кстати очень хочется ifreload), но если этот интерфейс получил параметр disabled, то он остаётся висеть ибо не может не опуститься. Гораздо удобрнее чтобы ifdown положил интерфейс, но ifup уже отказался его поднимать обратно. Возможно иногда хочется иметь не то чтобы "disabled", но "frozen" интерфейсы, которые не реагируют на ifup/ifdown. Но это всё-таки уже совсем другая история. Аналогично с iptables. После изменения параметров делаю efw reload, в результате имею что несмотря на моё желание firewall продолжает висеть ибо не может остановиться. То есть это поведение противоестественно. Это как будто зависший процесс, который я не могу убить. Что в результате приходится делать: распознавать что один из параметров хочет загасить интерфейс или firewall и гасить его.
(In reply to comment #3) > 1. Мне самому не нравится то, что у меня efw не работает без опции. Уберу, > наверное, вроде ничего плохого не произойдет. > 2. Не всегда stop уместен, он может делать что-то такое, что не должен делать, > если перед этим не было start, роутинг менять, например, или модули ядра > выгружать. Можно придумать некий force stop для тех, кто знает, что делает. Если stop для disabled firewall может сделать что-то непоправимое, значит что-то не хорошо в архитектуре, значит надо более чётко проставлять state системы, хотя бы в каком-нибудь внутреннем файле.
(In reply to comment #4) > (In reply to comment #2) > > > В противном случае в конфигураторах приходится делать пляски с конфигами: > > > сначала останавливать, а потом уже менять параметры. > > > > Для изменения некоторых параметров именно такой способ является > > единственно правильным. Расскажи, в каких именно ситуациях текущее > > поведение является проблемным. > > > > Получаю команду на изменение параметров интерфейса. Один из параметров > Disabled yes. Обычно после изменения параметров логично сделать ifdown/ifup (кстати > очень хочется ifreload), но если этот интерфейс получил параметр disabled, то он > остаётся висеть ибо не может не опуститься. Гораздо удобрнее чтобы ifdown > положил интерфейс, но ifup уже отказался его поднимать обратно. > > Возможно иногда хочется иметь не то чтобы "disabled", но "frozen" интерфейсы, которые > не реагируют на ifup/ifdown. Но это всё-таки уже совсем другая история. > > Аналогично с iptables. После изменения параметров делаю efw reload, в результате > имею что несмотря на моё желание firewall продолжает висеть ибо не может > остановиться. > > То есть это поведение противоестественно. Это как будто зависший процесс, > который я не могу убить. > > Что в результате приходится делать: распознавать что один из параметров > хочет загасить интерфейс или firewall и гасить его. Задача усложняется, если у меня сначала отдельно готовится конфигурация, а потом отдельно коммитится. Мне нужно, до "коммита" сверять новую конфигурацию со старой и останавливать интерфейс.
И всё же. Почему не рассматривать любой "сеанс" конфигурации любого отдельно взятого интерфейса как последовательность "остановка, изменение конфигов, старт"? Она покрывает все возможные случаи. Разработчику её просто реализовать, а пользователю --- понять.
(In reply to comment #7) > И всё же. Почему не рассматривать любой "сеанс" конфигурации любого отдельно > взятого интерфейса как последовательность "остановка, изменение конфигов, > старт"? Она покрывает все возможные случаи. Разработчику её просто > реализовать, а пользователю --- понять. > Это не совсем безопасно. Да и есть определённые привычки. Ну вот человек зашёл на интерфейс - сеть встала. Он остался на интерфейсе, задумавшись, сеть так и остановлена, пакеты не ходят. Интерфейс грохнулся - сеть осталась остановленной. Одно время был у нас apt-pipe, который блокировал работу apt/rpm. Блокировка - аналог опущенной сети. Пользователи нам очень много доброго сказали за Compact 3.0 ;)
Поясню. Последовательность "остановка-изменение-запуск" решает задачу актуализации некоторого конфига для некоторого интерфейса. Эта задача возникает не тогда, когда пользователь начинает рассматривать конфигурацию одних интерфейсов или изменять конфигурацию других, а тогда, когда он принимает решение "вот с этим отдельно взятым интерфейсом я законил, готово". Если этот момент явно обозначен некоторой кнопкой "к исполнению", тогда исполнение пресловутой последовательности будет ожидаемым действием.
(In reply to comment #7) > И всё же. Почему не рассматривать любой "сеанс" конфигурации любого отдельно > взятого интерфейса как последовательность "остановка, изменение конфигов, > старт"? Она покрывает все возможные случаи. Разработчику её просто Нелогичность поведения stop можно обнаружить и без изменения конфигов: стартуем профиль с enabled ифейсом, а потом он вопреки ожиданиям не опускается -- https://bugzilla.altlinux.org/show_bug.cgi?id=18413 .
текущему поведению, хорошему или плохому, более десяти лет.
