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

[Evgeny Sinelnikov]

21 июня 2009 г. 2:07 пользователь  (vpashka на gmail.com) написал:
>> Ну, так по мне, если вручную софт ставить, то и опцию ядра в lilo
>> прописать та же настройка. Один раз делается, при создании образа.
>>
>> Хотелось бы пояснения, что подразумевается под управлением? Где должны
>> лежать настройки? Для опций ядра - это lilo.conf.
> Практически все настройки ставятся из пакета.
> А по поводу конкретно udev, то управление при помощи опции ядра
> меня вполне устраивает...
>

Итого, сейчас startup-micro не содержит никаких частей для настройки
udev. Их можно добавить, я бы предложил оставить те же опции и ту же
семантику, что и в стандартном наборе скриптов. Там udev отключается
опцией noudev, иначе включается.

Второй вариант использования udev готов уже сейчас, посольку в
минимальном виде он входит в initramfs (по-старому в initrd). По
умолчанию, udev из initramfs выгружается, давая возможность запустить
системный из рута. Но, при указании опции use_initramfs_dev=1,
первично загруженный udev из initramfs не выгружается. В этом режиме я
проверял работу образа, поскольку /dev сейчас пуст, а наличие только
/dev/hdb* не давало возможности работать с устройствами из виртуалки
без ручной правки списка файлов устройств.

Здесь я бы обратил внимание не необходимость выбора того, какой udev
на нужен? системный или достаточно кусков от initramfs? первое гибче,
и обновляется надёжнее (apt-get upgrade, без необходимости
перегенерировать initrd после каждого обновления, даже если ядро не
обновлялось), второе проще в обновлении, гибче в настройке (поскольку
не зависимости от настроек прибитых в образе initramfs), но требует
поддержки со стороны startup-micro, а также очевидно замедляет процесс
загрузки, по сравнению с первым.

Кроме того, хотелось бы уточнить список устройств, которые должны
присутствовать в /dev/ в различных конфигурациях. Некоторые из файлов
устройств привязаны к спец. драйверам, вроде comedi. Они, вероятно,
могут понадобится и при использовании udev, поэтому нужны
соответствующие правила udev. В любом случае, при генерации образа,
было бы неплохо формировать полный список статических устройств,
которые необходимы.

>> > Нам udev в принципе не нужен. На контроллерах точно.
>> > А на граф. станции я не знаю. Нужно чтобы можно было подключить
>> >  иотключить, флэшку через usb. (Правда на данный момент для автодетекта
>> > используется самописный скрипт (на основе идей lav@)).
>>
>> Ну, udev, у нас в initramfs помещается... И ничего, работает. Потом
>> отключается... Ещё одна ручка может позволить его не отключать. Для
>> оптимально настроенной не интерактивной системы оно конечно не нужно.
>> Но, в общем случае, чтобы каждое обновление руками не делать и не
>> вспоминать как оно там было смысл определённый имеет.
> сказал выше...
>
>> > Я в принципе, "не очень за" генерирование системы.
>> > Хочется иметь готовый базовый образ, а потом уже,
>> > чтобы туда можно было зайти по ssh, и править всё-что надо..
>> > Ну собственно и заливать новую версию программ.
>>
>> Вопрос спорный, зависит от сложившегося порядка работы, и многих
>> особенностей, вроде расположения и удалённости объектов и уже
>> наработанного опыта их обслуживания.
>>
>> Так, что я тут не могу никак быть отправной точкой. Я бы генерировал,
>> но работаю над этим не я :)
> Нам сейчас, нужно чтобы был образ системы, который мы
> зальём на CF 512MB и там (без перегенерирования каждый раз),
> будем обновлять пакеты с НАШИМИ программами...
>

Сейчас mkimage-profiles-micro позволяет создать минимальный root для
будущей системы, в качестве startup используется startup-micro, в
который включены наши скрипты загрузки. Пароль рута устанавливается в
123456. Ставится std-def ядро. В файле packages профиля указываются
устанавливаемые в будущий root пакеты, в каталоге scripts находятся
скрипты, поправляющие и чистящие будущий root после установки пакетов.

После сборки архива root распаковывается командами:
$ cd /mnt/root #  где /mnt/root - будущий распакованный root
$ cpio -iv < mkimage-profiles-micro/micro.cpio

Далее нужно руками создать нужный набор статических файлов устройств,
сгенерировать необходимый mkinitramfs, установить загрузчик и т.д.

>
>>
>> >> В плане установки ip тоже не совсем понятно... откуда он
>> >> устанавливаться должен? В etcnet достаточно два файла задать
>> >> ipv4address и ipv4route для статики. Этого достаточно?
>> >
>> > Достаточно. Только ответный вопрос а нужен там etcnet? Он не тяжёл?
>>
>> При наличии rpm+apt он почти пушинка... Зависимости его стоит
>> проверить, но я не думаю, что там есть что-то емкое:
> Я в плане быстродействия при запуске. Не слишком он много,
> для нас лишнего, там анализирует, подгружает, парсит ?
>

Не должен он быть слишком тяжёл для простых настроек. Тяжёлые вещи в
нём нужно специально включать.

>
>> > Задача всего лишь поднять сеть...(даже собственно с заранее известными,
>> > драйвером и ip).
>>
>> Но на каждом же устройстве свой ip? Или каждый раз один и тот же? В
>> сети такая система обычно одна или может быть несколько?
> Просто для информации:
> В данном проекте, 12 контроллеров, каждый имеет свой заранее известный ip.
> На каждый контроллер ставятся общие пакеты, и конкретный пакет для
> данного контроллера...
>

Чтобы специальный пакет подходил с общим и, в частности, к скриптам
загрузки, нужно согласовать где и что хранится. Чтобы например при
обновлении общих пакетов файлы специальных не затирались. Мне, для
этого, достаточно взглянуть на специальный пакет.

>> >> Откуда должны браться настройки?
>> >
>> >  Возможно из устанавливаемого пакета. Для каждого контроллера свои.
>> > Но поначалу конечно настраиваются вручную, чтобы можно было достучатся,
>> > до контроллера...
>>
>> Ну, начальный этап можно разделить на два под этапа: установка и
>> настройка. Если и то, и другое как бы вручную, минимизировать объём
>> работы всё равно не мешает. Но при тиражировании образов всё равно
>> может быть не актуально. Тем не менее, если что-то на этом этапе можно
>> уже заранее подготовить, заявки на исправления профиля и startup
>> скриптов, а может быть и чего ещё, принимаются.
> Это понятно...
>
>>
>> Порядок работы с дополнительными пакетами не совсем понятен. Как ты это
>> видишь?
>
> Как обычно. На контроллере стоит система с apt-ом, настроенным на
> наш спец. репозиторий, откуда "полуавтоматически" ставится новые версии
> пакетов с НАШИМИ (повторю) программами. При этом, собственно базовая,
> часть системы уже не меняется...
>

Значит мы работаем на бранчах. 4.1, 5.0 и т.д. Верно?

-- 
Sin (Sinelnikov Evgeny)