ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | [PATCH] locking for /etc/net | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | Yuriy Kashirin <yura> | ||||||
| Component: | etcnet | Assignee: | Mikhail Efremov <sem> | ||||||
| Status: | ASSIGNED --- | QA Contact: | qa-sisyphus | ||||||
| Severity: | enhancement | ||||||||
| Priority: | P2 | CC: | ldv, mike, rider, sem, shaba, vseleznv | ||||||
| Version: | unstable | ||||||||
| Hardware: | all | ||||||||
| OS: | Linux | ||||||||
| Attachments: |
|
||||||||
|
Description
Yuriy Kashirin
2005-11-17 14:32:34 MSK
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
|
