[Devel] задача по инит-скриптам

Пт Июн 19 02:21:06 MSD 2009

19 июня 2009 г. 0:39 пользователь  (vpashka на gmail.com) написал:
> 19 июня 2009, Evgeny Sinelnikov написал:
>> Здравствуйте,
>  Здравсвуйте..
>
>> Последнее, что там внешне осталось - это замена unionfs на aufs.
>>
>> Тем не менее у меня остаются сомнения относительно содержимого:
>> http://git.etersoft.ru/people/sin/packages/startup-micro.git/
>> Достаточно ли там всего?
> Это будет окончательно ясно только на реальном контроллере...
> Главное чтобы можно было доустановить/переустановить.

Вот это-то как раз и не даёт возможности сделать самому выводы...

>> По пожеланиям тоже есть несколько не ясностей:
>> - включение udev.
>> - чтобы список подгружаемых модулей был в отдельном файле
>> - чтобы ip брался из отдельного файла
>>
>> В текущих инит-скриптах udev сделан сделан наоборот, не включаемым, а
>> отключаемым. Для этого задаётся опция ядра noudev. Может и мы так
>> оставим?
> Так вроде как раз, сказано, чтобы включение и отключение было бы
> управляемым...
> мнн

Ну, так по мне, если вручную софт ставить, то и опцию ядра в lilo
прописать та же настройка. Один раз делается, при создании образа.

Хотелось бы пояснения, что подразумевается под управлением? Где должны
лежать настройки? Для опций ядра - это lilo.conf.

>> Кроме того опцию use_initramfs_dev=1 можно использовать, чтобы
>> оставить в системе udev от initramfs, который там стартует, а потом
>> отключается. Этим тоже можно воспользоваться.
>> Как лучше и удобнее - нужно уточнить... По мне так это всё костыли, но
>> без задачи куда-то их применить трудно оценить, какик из них лучше
>> подходят.
> Нам udev в принципе не нужен. На контроллерах точно.
> А на граф. станции я не знаю. Нужно чтобы можно было подключить  иотключить,
> флэшку через usb. (Правда на данный момент для автодетекта используется
> самописный скрипт (на основе идей lav@)).

Ну, udev, у нас в initramfs помещается... И ничего, работает. Потом
отключается... Ещё одна ручка может позволить его не отключать. Для
оптимально настроенной не интерактивной системы оно конечно не нужно.
Но, в общем случае, чтобы каждое обновление руками не делать и не
вспоминать как оно там было смысл определённый имеет.

Да, и стоит уточнить всё-таки:
- достаточно ли для граф. станции udev от initramfs?
По мне это вариант ущербный, но достаточно аргументировать пока я это
не могу - нужно смотреть.
- если недостаточно, но как включать/выключать? Устраивает ли опция
ядра nodev? Можно ли его тянуть по зависимостям везде, и отключать там
где нужно?

>> Список подгружаемых модулей можно задать в файле modules.micro, но при
>> этом нужно пересобирать каждый раз новую версию, если требуется
>> сменить список. В общем-то, как я понял, нужно, чтобы обновление
>> изменяло этот список. Так пойдёт? или это не то... ?
> Я в принципе, "не очень за" генерирование системы.
> Хочется иметь готовый базовый образ, а потом уже,
> чтобы туда можно было зайти по ssh, и править всё-что надо..
> Ну собственно и заливать новую версию программ.

Вопрос спорный, зависит от сложившегося порядка работы, и многих
особенностей, вроде расположения и удалённости объектов и уже
наработанного опыта их обслуживания.

Так, что я тут не могу никак быть отправной точкой. Я бы генерировал,
но работаю над этим не я :)

>> В плане установки ip тоже не совсем понятно... откуда он
>> устанавливаться должен? В etcnet достаточно два файла задать
>> ipv4address и ipv4route для статики. Этого достаточно?
> Достаточно. Только ответный вопрос а нужен там etcnet? Он не тяжёл?

При наличии rpm+apt он почти пушинка... Зависимости его стоит
проверить, но я не думаю, что там есть что-то емкое:
$ rpm -q --requires etcnet
setup >= 0:2.1.9-ipl18mdk
service
startup >= 0:0.9.3-alt1
grep
sed
iproute2
ifrename >= 28-alt5.pre10
chkconfig
etcnet-defaults = 0.9.9-alt1
coreutils
findutils
util-linux

Элементом настройки здесь вероятно стоит сделать свой -
etcnet-defaults-micro - поскольку, etcnet-defaults - это виртуальный
пакет.

Вот так это выглядит на десктопе:

$ rpm -ql etcnet-defaults-desktop-0.9.9-alt1
/etc/net/options.d/50-ALTLinux-desktop
$ cat /etc/net/options.d/50-ALTLinux-desktop
# Don't redefine type-specific options such as USE_IFPLUGD here. Use
/etc/net/ifaces/default/options-*.
RESOLV_POSTIN_CMD=/sbin/update_chrooted
RESOLV_POSTIN_ARGS=conf
ALLOW_UNKNOWN=on
SILENT_REMOVABLES=yes
DHCP_CLIENT=/sbin/dhcpcd
DHCP_TIMEOUT=30
DHCP_GRACE_TIME=2
DHCP_HOSTNAME=localhost
BRCTL=/sbin/brctl

> Задача всего лишь поднять сеть...(даже собственно с заранее известными,
> драйвером и ip).

Но на каждом же устройстве свой ip? Или каждый раз один и тот же? В
сети такая система обычно одна или может быть несколько?

>> Откуда должны браться настройки?
>  Возможно из устанавливаемого пакета. Для каждого контроллера свои.
> Но поначалу конечно настраиваются вручную, чтобы можно было достучатся,
> до контроллера...

Ну, начальный этап можно разделить на два под этапа: установка и
настройка. Если и то, и другое как бы вручную, минимизировать объём
работы всё равно не мешает. Но при тиражировании образов всё равно
может быть не актуально. Тем не менее, если что-то на этом этапе можно
уже заранее подготовить, заявки на исправления профиля и startup
скриптов, а может быть и чего ещё, принимаются.

Порядок работы с дополнительными пакетами не совсем понятен. Как ты это видишь?

>> В общем мне не совсем понятен порядок работы, чтобы улучшить
>> init-скрипты. Если startup-micro сейчас всех устраивает, то как он
>> будет использоваться? Одна сборка в большом репозитории под разные
>> виды задач (мне это кажется предпочтительным)? Тогда не получиться
>> обновлением этого пакета что-то менять... Но так делать и не стоит.
>> Проще добавлять функциональность доп. пакетами, а базовый расширять
>> обрабатываемыми каталогами, в которые складываются частные настройки.
>
> Генерировать каждый раз образ, мне не кажется удачным.
> Это может понадобится только в случае смены железа или системы...
> (это редкая ситуация).
> А так, создаётся один раз "минимальная система", а дальше копирование
> при помощи dd...

При наличии железа, это может быть и удобно, но для тестов на
виртуалках dd - не лучший вариант. Проще сгенерировать установленный
образ, чем заниматься ручным копированием из чрута в образ и обратно.
Я обошёлся хитрым двойным losetup на один и тот же файл - один для
виртуалки, второй для mount -oloop нужного раздела...

К тому же непонятно как использовать dd для образов размера более, чем
несколько гигабайт. Место может потребоваться больше, чем свободно на
винте. Метрики в mbr пробиты и как тут быть непонятно. При наличии
железа, достаточно залить первое несколько гигабайт и нормально, а без
железа пока не нашёл удобных средств эмуляции.

> Это всё-таки АСУ, конкретное не меняющееся железо.
> Поэтому надо один раз под него оптимизировать систему и она больше
> меняться не будет.

До следующего обновления... Ну, спорный это вопрос, Всё равно что-то
меняют... Только, чем дальше, тем больше боясь сломать.
Восстановить-то неоткуда... У генерации нет такого недостатка.
Накладных расходов первоначально больше, поддержка требуется по мере
использования, зато результаты всегда повторяемы.

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

> Изменяемая часть, это только пакеты с новой версией
> программ управления. Соответственно это должно быть легко.
> (на данный момент это либо apt-get или rpm -Uhv через ssh)

Пакеты с новой версией и это уже совсем другая система.

> Что касается самой системы, то к ней основное требование - надёжность.
> Потому: readonly, rw-в памяти, никаких логов, monit и т.п.
> Плюс к этому ещё важна - скорость загрузки.

Здесь я всё понял... Будем уточнять вопрос по aufs.

-- 
Sin (Sinelnikov Evgeny)