Bug 8509 - [PATCH] locking for /etc/net
: [PATCH] locking for /etc/net
Status: ASSIGNED
: Sisyphus
(All bugs in Sisyphus/etcnet)
: unstable
: all Linux
: P2 enhancement
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2005-11-17 14:32 by
Modified: 2013-08-15 20:03 (History)


Attachments
Собственно патч (6.10 KB, patch)
2005-11-17 14:35, Yuriy Kashirin
no flags Details | Diff
Скрипт /etc/net/scripts/lockfile.sh (1.07 KB, text/plain)
2005-12-27 12:29, Yuriy Kashirin
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-11-17 14:32:34
Хочу предложить патч, родившийся в результате ковыряния в вопросе, описанном в  
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 
сами все сделают). Потом лезет в конфигурационный директорий интерфейса и 
работает дальше.
------- Comment #1 From 2005-11-17 14:35:21 -------
Created an attachment (id=1251) [details]
Собственно патч

Новые файлы 
/etc/net/scripts/ifconfig-ipv4
/etc/ppp/ip-{up,down}.d/etcnet

должны быть executable
------- Comment #2 From 2005-11-17 16:00:10 -------
Спасибо, я посмотрю.
------- Comment #3 From 2005-11-25 17:32:44 -------
По поводу пункта 1: хорошая мысль, я раньше не знал, чем это реализовать.
По поводу пункта 2: зачем ограничиваться IPv4? И наверное, лучше будет ifup
изменить так, чтобы он для уже поднятого интерфейса проверял его соответствие
конфигурации.
------- Comment #4 From 2005-11-25 19:32:21 -------
(In reply to comment #3) 
> По поводу пункта 2: зачем ограничиваться IPv4? 
 
Я этим ограничился _пока_, только лишь для решения наболевшей у меня 
конкретной проблемы с ppp интерфейсами (некоторыми) -- собственно пункт 2 
можно считать побочным эффектом пункта 3 :) 
 
Что касается остального -- можно считать, что оно в состоянии вялотекущего 
TODO. На данный момент я сделал то, на что сам нарывался и смог некоторое 
время погонять-оттестить. 
 
> И наверное, лучше будет ifup изменить так, чтобы он для уже поднятого 
> интерфейса проверял его соответствие конфигурации. 
 
Совершенно согласен. Но раз уж я пока ограничился только IPv4, то возложить 
это сразу на ifup было бы не честно. Дабы ничего не сломать (одинаковых правил 
iptables к примеру не размножить) 
------- Comment #5 From 2005-11-25 23:24:13 -------
> И наверное, лучше будет ifup изменить так, чтобы он для уже поднятого   
> интерфейса проверял его соответствие конфигурации.   

А вот еще осенило. Что все-таки не ifup, а отдельный скрипт (какой-нибудь  
ifcheck), который проверяет соответствие состояния интерфейса его  
конфигурации. Вот он пускай и восстанавливает состояние интерфейса. А еще ему  
опцию придумать, чтобы наоборот -- сохранял текущее состояние в конфигах... Ну  
и опцию -- просто докладывать про несоответствия (вспоминая service network  
status). 
------- Comment #6 From 2005-11-29 14:03:17 -------
В патче ошибочка вышла. В пропатченных if{up,down} необходимо исправление:  

-trap 'rm -f "$IFACE_LOCK_FILE" ' EXIT SIGHUP SIGTERM SIGINT  
+trap 'rm -f "$IFACE_LOCK_FILE" ' EXIT  
------- Comment #7 From 2005-12-22 11:04:40 -------
(1) пока не принимается, так как появляется зависимость на procmail
------- Comment #8 From 2005-12-22 14:35:50 -------
(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 
----------------- 
 
Это только идея, если принимается, то я могу довести этот скрипт до ума. В 
таком виде он, например от рута не будет работать -- файл в любом случае 
перезапишется. Ну и надо какого-то системного пользователя завести (или 
назначить), которому лок-файлы будут принадлежать... 
------- Comment #9 From 2005-12-27 12:29:47 -------
Created an attachment (id=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