Хочу предложить патч, родившийся в результате ковыряния в вопросе, описанном в http://lists.altlinux.org/pipermail/sisyphus/2005-October/071563.html Получилось несколько больше, чем планировалось. Смысл изменений в следующем. 1) На время выполнения ifup/ifdown создается лок файл в директории /var/lock/etcnet. Для таких целей: - Предотвращает одновременное выполнение ifup/ifdown для одного и того же интерфейса. Если 2 и более таких процесса вдруг запущены, то они теперь будут выполняться последовательно. - Наличие лок файла является для других заинтересованных процессов признаком, что поднятие/опускание интерфейса находится в процессе. Если кому-то нужен доступ к конкретному интерфейсу, то этот кто-то должен дождаться удаления лок файла прежде чем работать. 2) Добавлен скрипт /etc/net/scripts/ifconfig-ipv4 для возможности переконфигурирования интерфейса из командной строки по ходу работы. Например, когда руками или каким другим образом сломали таблицу маршрутизации для конкретного интерфейса, она может быть восстановлена из ipv4route без ifdown iface; ifup iface. Скрипт настраивает окружение и вызывает существующий /etc/net/scripts/config-ipv4 3) Добавлены скрипты /etc/ppp/ip-{up,down}.d/etcnet для лучшего интегрирования с pppd. - При поднятии интерфейса обеспечивается конфигурирование в соответствии с параметрами в конфигурационных файлах интерфейса, в частности ipv4route - При необходимости собственных скриптов ip-up/ip-down - вместо них все, что надо выполнить достаточно прописать в ifup-post/ifdown-pre скриптах в конфигурационном директории интерфейса. Собственно, это работало и раньше, НО только при выполнении ifup/ifdown. Если ppp интерфейс в ходе работы пересоздается, например когда pppd восстанавливает потерянное соединение в соответствии с опцией persist, то возникают проблемы (см. ссылку выше). Сам скрипт ip-up.d/etcnet работает следующим образом: проверяет, что интерфейс поднят через /etc/net (по ipparam, с которым запускается pppd и по наличию конфигурационного директория интерфейса), если нет, то выходит. Проверяет, не выполняется ли ifup/ifdown данного интерфейса (по наличию лок файла), если да, то выходит (ifup/ifdown сами все сделают). Потом лезет в конфигурационный директорий интерфейса и работает дальше.
Created attachment 1251 [details] Собственно патч Новые файлы /etc/net/scripts/ifconfig-ipv4 /etc/ppp/ip-{up,down}.d/etcnet должны быть executable
Спасибо, я посмотрю.
По поводу пункта 1: хорошая мысль, я раньше не знал, чем это реализовать. По поводу пункта 2: зачем ограничиваться IPv4? И наверное, лучше будет ifup изменить так, чтобы он для уже поднятого интерфейса проверял его соответствие конфигурации.
(In reply to comment #3) > По поводу пункта 2: зачем ограничиваться IPv4? Я этим ограничился _пока_, только лишь для решения наболевшей у меня конкретной проблемы с ppp интерфейсами (некоторыми) -- собственно пункт 2 можно считать побочным эффектом пункта 3 :) Что касается остального -- можно считать, что оно в состоянии вялотекущего TODO. На данный момент я сделал то, на что сам нарывался и смог некоторое время погонять-оттестить. > И наверное, лучше будет ifup изменить так, чтобы он для уже поднятого > интерфейса проверял его соответствие конфигурации. Совершенно согласен. Но раз уж я пока ограничился только IPv4, то возложить это сразу на ifup было бы не честно. Дабы ничего не сломать (одинаковых правил iptables к примеру не размножить)
> И наверное, лучше будет ifup изменить так, чтобы он для уже поднятого > интерфейса проверял его соответствие конфигурации. А вот еще осенило. Что все-таки не ifup, а отдельный скрипт (какой-нибудь ifcheck), который проверяет соответствие состояния интерфейса его конфигурации. Вот он пускай и восстанавливает состояние интерфейса. А еще ему опцию придумать, чтобы наоборот -- сохранял текущее состояние в конфигах... Ну и опцию -- просто докладывать про несоответствия (вспоминая service network status).
В патче ошибочка вышла. В пропатченных if{up,down} необходимо исправление: -trap 'rm -f "$IFACE_LOCK_FILE" ' EXIT SIGHUP SIGTERM SIGINT +trap 'rm -f "$IFACE_LOCK_FILE" ' EXIT
(1) пока не принимается, так как появляется зависимость на procmail
(In reply to comment #7) > (1) пока не принимается, так как появляется зависимость на procmail Плохо. Все остальное использует лок-файлы, которые этим (1) создаются. Чтобы отзависимости на procmail уйти, может вместо /usr/bin/lockfile свой скрипт аналогичный сочинить? Типа такого /etc/net/scripts/lockfile.sh: ----------------- #!/bin/bash test $# -ge 1 || exit 1 umask 333 while ! echo $$ > "$1" 2>/dev/null do sleep 1 done ----------------- Это только идея, если принимается, то я могу довести этот скрипт до ума. В таком виде он, например от рута не будет работать -- файл в любом случае перезапишется. Ну и надо какого-то системного пользователя завести (или назначить), которому лок-файлы будут принадлежать...
Created attachment 1316 [details] Скрипт /etc/net/scripts/lockfile.sh Этот скрипт можно использовать вместо /usr/bin/lockfile для ухода от зависимости на procmail. Он использует только утилиты из coreutils, на который уже есть зависимость. Дополнительно скрипту можно передавать в параметрах pid процесса, который будет записан в локфайл. Соответственно в пропатченных if{up,down} заменить: - /usr/bin/lockfile "$IFACE_LOCK_FILE" || exit 3 + ${SCRIPTDIR}/lockfile.sh -p $$ "$IFACE_LOCK_FILE" || exit 3
