[devel] RFC: /etc/if{up,down}.d (was: Time servers)

[devel] RFC: /etc/if{up,down}.d (was: Time servers)

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 3324 bytes --]

Hello Michael,

On Wed, Jan 30, 2002 at 09:39:40AM +0200, Michael Shigorin wrote:
>
> Может, сделать инфраструктуру для подключения "фишек" для
> диалапщиков?  нечто вроде /etc/ppp/ppp.d или как-то так.

Тогда лучше уж /etc/if{up,down}.d для /sbin/if{up,down} --
не PPP единым жив человек.
Для разных интерфейсов сделать разблюдовку:
/etc/ifup.d/ppp/
/etc/ifup.d/eth/
/etc/ifup.d/0common/
-- последнее для общих скриптов, на которые делать симлинки из
   interface-specific каталогов.

Можно даже предусмотреть возможность уточнения номера устройства:

for d in /etc/ifup.d/*; do
    d="${d#/etc/ifup.d/}"
    if [ "${DEVICE#$d}" != "$DEVICE" ]; then
        RunExecutablesInDir "/etc/ifup.d/$d" "$DEVICE"
    fi
done

Таким образом, для ppp0 будут выполняться скрипты
сначала в /etc/ifup.d/ppp/, затем в /etc/ifup.d/ppp0/

Чтобы не засорять /etc, можно загнать всё это хозяйство в
/etc/sysconfig/network-scripts

> Задумка родилась пару недель назад, когда вырезал кому-то из
> своих /etc/ppp/ip-*.local нужные куски и подумал, до чего эта
> каша напоминает BSD init и rc.local :-/
> 
> Кандидатуры:
> [by ip-up]
> - firewall ?? (ToS и DENY -- но вопрос тонок)

А зачем, он и с отключенными интерфейсами хорошо живёт.

> - ntpd -q (if installed)
> - отправка почты (дернуть postfix) (*)
> - забор почты (дернуть все фетчмэйлы) (**)
> - отправка/забор ньюсов (fetchnews) (***)
> - DNS: хуки для максимально удобной подстановки forwarders (****)
> 
> [by ip-down]
> - firewall: вернуть на место (опять тонкий вопрос)
> - прибить fetchmail'ы, если связь грохнулась раньше их
> - --""--  fetchnews, --""--
> - DNS: back to local (if any)
> 
> Думаю, вариантов облегчить жизнь и добавить нужных и удобных фич
> тут много; просьба высказать мнения о таком обобщении.  В любом
> случае надеюсь вспомнить, когда после выпуска Master, надеюсь,
> начнется редизайн инсталера и настраивалок.
> 
> ---
> 
> (*) в идеале инфраструктура настройки при нахождении
> инсталером/настраивалкой _только_ модема или ответе, что именно
> таковой используется для выхода в инет (все равно спрашивают за
> default route), маленько изменять /etc/postfix/main.cf :
> 
> ---
> defer_transports = smtp

Это лучше не вписывать, лишь проверять наличие.
В мануале эта директива будет на красном месте :)

> ## и как намек -- это ж не автоматизируется совсем автоматически?
> # sender_canonical_maps = hash:/etc/postfix/sender_canonical
> ---
> 
> (**) или путем взаимодействия с fetchmail-daemon, или путем
> прямого запуска -- надо обнюхать и обдумать, это только _идея_.

А разве
[ -e "$USER_HOME"/.fetchmailrc ] && su -с fetchmail "$USER"
недостаточно для того, чтобы запустить/дёрнуть fetchmail?

> (***) плюс один-два файлика в leafnode; плюс, возможно,
> "настраивалка leafnode".
> 
> (****) у меня, например, локальный named держит зону для LAN и в
> то же время переключается в кэширующий и обращающийся к нужным
> forwarders при поднятии связи.

Вправлять forwarders в C-образный конфиг -- это чревато :-/
Хотя, если место для этого ровно одно и никаких иных forwarders не
может быть, то можно попробовать. Лучше для этого вставить
"магический" комментарий а-ля msec, и если такого комментария нет
-- ну его нафиг.

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org
___________
RADIO SHACK LEVEL II BASIC
READY
>_

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

[devel] Re: [mdk-re] RFC: /etc/if{up,down}.d (was: Time servers)

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 2205 bytes --]

On Wed, Jan 30, 2002 at 01:58:12PM +0300, Mikhail Zabaluev wrote:
> > Может, сделать инфраструктуру для подключения "фишек" для
> > диалапщиков?  нечто вроде /etc/ppp/ppp.d или как-то так.
> Тогда лучше уж /etc/if{up,down}.d для /sbin/if{up,down} --
> не PPP единым жив человек.
НУ я ж не против -- просто замотанный самую малость (вот, надо
было еще с утра Final fantasy посмотреть -- кстати, (!))...

> /etc/ifup.d/0common/
без 0? :)

> Чтобы не засорять /etc, можно загнать всё это хозяйство в
> /etc/sysconfig/network-scripts
Пожалуй что это уже обобщение следующего уровня 8-)

> > - firewall ?? (ToS и DENY -- но вопрос тонок)
> А зачем, он и с отключенными интерфейсами хорошо живёт.
И то ладно.  Но вообще раздача "быстрого инета" из коробки по
кнопке была бы тоже недурной......

> > defer_transports = smtp
> Это лучше не вписывать, лишь проверять наличие.
> В мануале эта директива будет на красном месте :)
Или так, или сяк; или в комментированном виде вставить...

> > (**) или путем взаимодействия с fetchmail-daemon, или путем
> > прямого запуска -- надо обнюхать и обдумать, это только _идея_.
> А разве
> [ -e "$USER_HOME"/.fetchmailrc ] && su -с fetchmail "$USER"
> недостаточно для того, чтобы запустить/дёрнуть fetchmail?
В первом разе его надо будет отпустить в background; кстати,
сейчас не соображу, но там могут быть некоторые нюансы насчет job
control...  вроде того, что ppp-on останется ждать fetchmail(s),
которые при обрыве связи будут висет на таймауте.

> Вправлять forwarders в C-образный конфиг -- это чревато :-/
Знаю.  Я лично не вставляю, а симлинк перебрасываю.  Но это _моя_
локальная специяика и тоже чревато.

Кстати, а нужен ли намед на рабочей станции?  Более легких и
(вроде) секьюрных кэшеров, чем BIND8, вроде есть некоторое
количество.

> Хотя, если место для этого ровно одно и никаких иных forwarders не
> может быть, то можно попробовать. Лучше для этого вставить
> "магический" комментарий а-ля msec, и если такого комментария нет
> -- ну его нафиг.
Или так....  Это было уже в порядке бреда -- слишком много своих
частностей голову забивает.  Но все же :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ http://visa.chem.univ.kiev.ua/~mike/

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [devel] RFC: /etc/if{up,down}.d (was: Time servers)

[Ivan Zakharyaschev]

	Hello!

Поддерживаю эту инициативу!

Вдобавок предлагаю вместо номеров интерфейсов pppN использовать имена.
Возможно, это не единственное решение проблемы, с которой я столкнулся,
но мне оно кажется самым удобным. А проблема в том, что в случае
нескольких ppp-соединений порядок их установления влияет на номер
интерфейса, а набор действий, которые нужно совершить, по смыслу
завясит, конечно же, не от порядка, а от того с кем установлена связь.

Например, два ppp-соединения: одно -- Inet dialup, другое -- связь с
notebook через последовательный порт. Порядок, в котором они появляются,
неопределен. (И неизвестно кому из них достанется ppp0, аа кому --
ppp1.)

Путаницы можно избежать, дав каждому соединению в /etc/ppp/peers/* имя с
помощью опции linkname (например, lap_link и inet_link). Запомнить
соответствия между номерами интерфейсов и именами соединений мне
помогает такая строчка в /etc/ppp/ip-up.local:

echo "$IFNAME" > "/var/run/ppp-$LINKNAME.iface"

(а в /var/run/ppp-$LINKNAME.pid pppd записывает свой PID). Это позволяет
потом легко манипулировать соединениями по имени. (Например, отработать
какой-нибудь /etc/netlink.d/inet_link/.)

На этом основная часть моего предложения закончено. Вот еще несколько
замечаний:

Одно и то же linkname можно давать нескольким разным peers одного типа,
с которыми может быть установлено соединение. Например, имя inet_link
могут иметь соединения с разными провайдерами через один модем -- все
равно Inet; хотя может и не стоит так делать: какие-то параметры могут
отличаться, например forwarders для named.

Несмотря на то, что c номерами eth* всё жестче, имена для них тоже могут
быть удобными (легче понимать, что за соединение).

Уровень управления соединениями по именам можно представить как более
высокий по отношению к уровню интерфейсов с номерами, устройств.

On Wed, 30 Jan 2002, Mikhail Zabaluev wrote:

> On Wed, Jan 30, 2002 at 09:39:40AM +0200, Michael Shigorin wrote:
> >
> > Может, сделать инфраструктуру для подключения "фишек" для
> > диалапщиков?  нечто вроде /etc/ppp/ppp.d или как-то так.
>
> Тогда лучше уж /etc/if{up,down}.d для /sbin/if{up,down} --
> не PPP единым жив человек.
> Для разных интерфейсов сделать разблюдовку:
> /etc/ifup.d/ppp/
> /etc/ifup.d/eth/
> /etc/ifup.d/0common/
> -- последнее для общих скриптов, на которые делать симлинки из
>    interface-specific каталогов.
>
> Можно даже предусмотреть возможность уточнения номера устройства:
>
> for d in /etc/ifup.d/*; do
>     d="${d#/etc/ifup.d/}"
>     if [ "${DEVICE#$d}" != "$DEVICE" ]; then
>         RunExecutablesInDir "/etc/ifup.d/$d" "$DEVICE"
>     fi
> done
>
> Таким образом, для ppp0 будут выполняться скрипты
> сначала в /etc/ifup.d/ppp/, затем в /etc/ifup.d/ppp0/



-- 
Best regards,
	Ivan Z.

[devel] Re: [mdk-re] RFC: /etc/if{up,down}.d (was: Time servers)

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

Hello Michael,

On Wed, Jan 30, 2002 at 03:46:25PM +0200, Michael Shigorin wrote:
>
> > /etc/ifup.d/0common/
> без 0? :)

0 - чтобы первым в ls и чтобы не мешалось с именами интерфейсов.

> > Чтобы не засорять /etc, можно загнать всё это хозяйство в
> > /etc/sysconfig/network-scripts
> Пожалуй что это уже обобщение следующего уровня 8-)

??

> > А разве
> > [ -e "$USER_HOME"/.fetchmailrc ] && su -с fetchmail "$USER"
> > недостаточно для того, чтобы запустить/дёрнуть fetchmail?
> В первом разе его надо будет отпустить в background; кстати,
> сейчас не соображу, но там могут быть некоторые нюансы насчет job
> control...  вроде того, что ppp-on останется ждать fetchmail(s),
> которые при обрыве связи будут висет на таймауте.

fetchmail по умолчанию сам уходит в background, после того как
разобрал конфигурацию и нашёл там poll.

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org
___________
"Ninety percent of baseball is half mental."
-- Yogi Berra

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

[devel] Re: RFC: /etc/if{up,down}.d (was: Time servers)

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 1493 bytes --]

Hello Ivan,

On Wed, Jan 30, 2002 at 10:44:23PM +0300, Ivan Zakharyaschev wrote:
>
> 	Hello!
> 
> Поддерживаю эту инициативу!
> 
> Вдобавок предлагаю вместо номеров интерфейсов pppN использовать имена.
> Возможно, это не единственное решение проблемы, с которой я столкнулся,
> но мне оно кажется самым удобным. А проблема в том, что в случае
> нескольких ppp-соединений порядок их установления влияет на номер
> интерфейса, а набор действий, которые нужно совершить, по смыслу
> завясит, конечно же, не от порядка, а от того с кем установлена связь.
> 
> Например, два ppp-соединения: одно -- Inet dialup, другое -- связь с
> notebook через последовательный порт. Порядок, в котором они появляются,
> неопределен. (И неизвестно кому из них достанется ppp0, аа кому --
> ppp1.)
> 
> Путаницы можно избежать, дав каждому соединению в /etc/ppp/peers/* имя с
> помощью опции linkname (например, lap_link и inet_link). Запомнить
> соответствия между номерами интерфейсов и именами соединений мне
> помогает такая строчка в /etc/ppp/ip-up.local:
> 
> echo "$IFNAME" > "/var/run/ppp-$LINKNAME.iface"

Надо проверить, но по-моему, в скриптах фигурируют два имени:
"физическое" имя интерфейса и то, что даётся как параметр ifup.

Менять цифры на буквы опасно, потому что может сломать что-то ещё.

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org
___________
Do you realize how many holes there could be if people would just take
the time to take the dirt out of them?

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [devel] RFC: /etc/if{up,down}.d

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 365 bytes --]

On Wed, Jan 30, 2002 at 10:44:23PM +0300, Ivan Zakharyaschev wrote:
> Поддерживаю эту инициативу!
А есть вариант вхождения в Мастер?  В том плане, что продолжать
думать и экспериментировать или пока "единица в уме"?

Насколько я понимаю, не стоит в последний момент?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ http://visa.chem.univ.kiev.ua/~mike/

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [devel] RFC: /etc/if{up,down}.d

[Ivan Zakharyaschev]

	Hello!

On Thu, 31 Jan 2002, Michael Shigorin wrote:

> On Wed, Jan 30, 2002 at 10:44:23PM +0300, Ivan Zakharyaschev wrote:
> > Поддерживаю эту инициативу!
> А есть вариант вхождения в Мастер?  В том плане, что продолжать
> думать и экспериментировать или пока "единица в уме"?
>
> Насколько я понимаю, не стоит в последний момент?

Я согласен, что не стоит в последний момент. А свои мысли высказал, раз
уж разговор об этом зашел.

-- 
Best regards,
	Ivan Z.

Re: [devel] Re: RFC: /etc/if{up,down}.d (was: Time servers)

[Ivan Zakharyaschev]

	Hello!

On Thu, 31 Jan 2002, Mikhail Zabaluev wrote:

> On Wed, Jan 30, 2002 at 10:44:23PM +0300, Ivan Zakharyaschev wrote:

> > Вдобавок предлагаю вместо номеров интерфейсов pppN использовать
> имена.
> > Возможно, это не единственное решение проблемы, с которой я
> столкнулся,
> > но мне оно кажется самым удобным. А проблема в том, что в случае
> > нескольких ppp-соединений порядок их установления влияет на номер
> > интерфейса, а набор действий, которые нужно совершить, по смыслу
> > завясит, конечно же, не от порядка, а от того с кем установлена
> связь.

> > Путаницы можно избежать, дав каждому соединению в /etc/ppp/peers/*
> имя с
> > помощью опции linkname (например, lap_link и inet_link). Запомнить
> > соответствия между номерами интерфейсов и именами соединений мне
> > помогает такая строчка в /etc/ppp/ip-up.local:
> >
> > echo "$IFNAME" > "/var/run/ppp-$LINKNAME.iface"

И в /etc/ppp/ip-down.local:

rm -f "/var/run/ppp-$LINKNAME.iface"

> Надо проверить, но по-моему, в скриптах фигурируют два имени:
> "физическое" имя интерфейса и то, что даётся как параметр ifup.

По-моему, тоже. Но мне кажется, это еще больше сбивает с толку: в одном
месте написано ppp1, а в другом видишь ppp0...

> Менять цифры на буквы опасно, потому что может сломать что-то ещё.

Но если заняться этим основательно, то можно и проверить, чтобы ничего
не сломалось.

-- 
Best regards,
	Ivan Z.

[devel] Re: RFC: /etc/if{up,down}.d (was: Time servers)

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 1499 bytes --]

Hello Ivan,

On Thu, Jan 31, 2002 at 11:41:42AM +0300, Ivan Zakharyaschev wrote:
>
> > > Вдобавок предлагаю вместо номеров интерфейсов pppN использовать
> > имена.
> > > Возможно, это не единственное решение проблемы, с которой я
> > столкнулся,
> > > но мне оно кажется самым удобным. А проблема в том, что в случае
> > > нескольких ppp-соединений порядок их установления влияет на номер
> > > интерфейса, а набор действий, которые нужно совершить, по смыслу
> > > завясит, конечно же, не от порядка, а от того с кем установлена
> > связь.
> 
> > > Путаницы можно избежать, дав каждому соединению в /etc/ppp/peers/*
> > имя с
> > > помощью опции linkname (например, lap_link и inet_link). Запомнить
> > > соответствия между номерами интерфейсов и именами соединений мне
> > > помогает такая строчка в /etc/ppp/ip-up.local:
> > >
> > > echo "$IFNAME" > "/var/run/ppp-$LINKNAME.iface"
> 
> И в /etc/ppp/ip-down.local:
> 
> rm -f "/var/run/ppp-$LINKNAME.iface"
> 
> > Надо проверить, но по-моему, в скриптах фигурируют два имени:
> > "физическое" имя интерфейса и то, что даётся как параметр ifup.
> 
> По-моему, тоже. Но мне кажется, это еще больше сбивает с толку: в одном
> месте написано ppp1, а в другом видишь ppp0...

Может быть, глобальный замысел состоит в том, чтобы использовать
ppp0:1, ppp0:2,... для разных настроек одного физического интерфейса?

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org
___________
Beauty seldom recommends one woman to another.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]