calculate+pxe, и все чтоб эта сборка работала (в т.ч. grub2, пароль root-а, ssh, хомяки пользователей НЕ В RAM-е и еще так по мелочи)

Привет всем.
Это продолжение и логическое развитие темы calculate pxe через grub2
После непродолжительных но упорных попыток найти способ полностью отказаться от hdd на рабочих станциях загружаемых по pxe потерпел фиаско поступил как “нормальный герой” и “пошел в обход”.
В поисках решения даже “партизанскую вылазку” сделал в это интернет-кафе(благо Goody - хозяин сего заведения, не очень близкий, но все-же старый знакомый, против не был), его решение довольно простое и надежное - но для нашей(моей) задачи не очень подходящее.
Но обо всем по порядку.
Во первых - какие задачи мы(я) ставим перед собой разрабатывая загрузку по pxe, а также с какими проблемами мы сталкиваемся:

  • Задача 1. Первая задача - имхо она же главная в любом проэкте Любые инфраструктурные изменения должны требовать *минимум расходов* (без фанатичной экономии).
    К примеру при переводе на pxe в идеале - должны освободиться жесткие диски, а там уже, если(когда) к работе системы претензий не будет, и руководство согласится что эти диски лежат на полке мертвым грузом, их можно будет “обменять на деньги” на любой тематической доске объявлений. И на вырученные деньги прикупить подходящий вам управляемый switch(ей богу, меня передергивает когда я вижу написанное свич) со столь желанной функцией . Однако на относительно дешевой памяти(относительно hdd) там где ее изначально мало - экономить с самого начала не стоит.
  • Задача 2. Уже непосредственно ДЛЯ ЧЕГО НАМ PXE. На всех машинах одновременно всегда должна быть актуальная версия всего необходимого софта.
    В свете постоянного попадания то одного то другого пакета из набора calculate (да и любого другого домашнего/офисного дистрибутива) в списки рассылки безопасности - довольно правильное желание.
    libpng / chromium / flash / изредка локальное несанкционированное повышение привилегий / LibreO иногда косячит - все это заставляет часто обновлять систему. Даже с упрощенной системой “запасных root-ов” как это сделано в кальке - это дополнительная работа, которая делается чаще всего в нерабочее время, что отрицательно сказывается на ЛИЧНОМ ВРЕМЕНИ СИСАДМИНА.
    Труд конечно создал из обезьяны человека, а из человека - китайца. Но админа Админа из человека сделала ЛЕНЬ.
  • Задача 3. она же Проблема 1. При потере связи с сервером системы загруженной по pxe БЕЗ кеширования squash-а на локальный ram-disk, dhcpcd вылетает и при появлении сети уже не берет IP.
    Полагаю тут проблема не столько в dhcpcd(который по идее уже в закеширован раме, и в доступе к /sbin не нуждается), сколько в его “обвязке” в виде /etc/dhcpcd.conf и /lib/dhcpcd/dhcpcd-{run~~,}hooks, которая похоже не кешируется (опять же~~ это надо проверить).
    Чем “лепить костыли” вроде пройтись touch по всему содержимому /lib и может /sbin (по идее - при обновлении времени изменения, эти файлы должны будут скопироваться в /mnt/scratch/workspace, который в tmpfs на локальной машине) что ЯВНО переглючит поведение системы при обновлении при помощи cl-builder, я предлагаю решение основанное на следующей задаче.
    Примечание: пока реализации нет, только идея.
  • Задача 4. (На первый взгляд противоречит Задаче 2, но это лишь на первый взгляд) Некоторым отделам/сотрудникам, для работы необходим специфичный софт (blender и inkscape для дизайнеров, qt-creator и eclipse - для программистов, supertuxkart для сис.админов), для других же, при использовании pxe - это лишняя нагрузка на сеть+память+проц (чтение бОльшего livecd.squashfs с сервака, а также распаковка и кеширование при навигации по нему). Даже при использовании pxe, необходимо предусмотреть либо загрузку разных сборок для разных отделов, либо одной минимальной(максимум двух - i686 и x86_64) НО ОЧЕНЬ ХИТРОЙ сборки (я выбираю этот способ), позволяющей при загрузке подключать в доп. слои (подобно режиму scratch) директории, либо squash-образы с установленным нужным софтом(кстати, /usr/portage - имхо тоже нечего делать в основном образе). Благо - aufs предусматривает подобные махинации.
    Примечание: пока это только мысли, реализация в разработке, но она косвенно даст много классных плюшек.
  • Задача 5. оно же Проблема 2. Ограничение возможностей локального пользователя. Дело в том, что при загрузке по pxe применяются шаблоны режима LiveCD, что дает возможность локальному пользователю легко получить root-а. Что в свою очередь может отрицательно повлиять на секрецию(слипнется) нижнего отдела ЖКТ обычного доменного пользователя.
    Возможность эта связана с тем, что в squash-е в /etc/inittab на первых 6-и консолях висит /bin/bashlogin (решено в шаблонах на сервере см. аттач).
    Также в /etc/sudoers группе wheel позволено получить root-а без авторизации(проследите кто у вас в домене в группе wheel)
    И напоследок - в режиме liveCD создается юзер guest в группe wheel, которому тут не место.(опять же - решается тривиально)
  • Задача 6. или Проблема 3. отсутствие пароля root-а, и как следствие - остановленный sshd. Решение смотрите в шаблонах по адресу client/domain в аттаче.
  • Задача 7. или Проблема 4. ограниченность RAM, и потребность в swap. Тут есть три пути:
    • использование compcache , и хоть в “News” и сказано… _
      > Dec 12, 09 - compcache is now in mainline -- it will be part of kernel 2.6.33.
      _ …как-то в ядре 3.* опцию CONFIG_RAMZSWAP я не отыскал, видимо выпилили.
      Если кто-то знает как его запилить в последние ядра, прошу дать знать. Очень хотелось бы иметь такое в системе.
    • При наличии локального харда - поиск и использование SWAP-директории. Я пока выбираю этот метод(ибо решается тривиально, см. шаблоны).
    • как реализовано в вышеупомянутом интернет кафе можно подключать nfs-блочное устройство как своп. Но это во первых небезопасно. И во вторых - требует приобретения дорогого гигабитного switch-а(противоречит Задаче 1), иначе это будет ООЧЕНЬ медленный swap. Даже не рассматриваю.
  • Задача 8. или Проблема 5. При запуске sshd закрытые ключи /etc/ssh/ssh_host_*key* генерируются по новому. Что нивелирует саму суть закрытых ключей(один раз при подключении по защищенному каналу, либо заведомо при отсутствии потенциального злоумышленника с возможностью прослушать/подменить трафик, мы сохраняем fingerprint ключа, и в дальнейшем при несовпадении его ssh матерится)
    Вижу несколько решений:
    • Клиент получает свой ключ с сервера. Поскольку злоумышленник может прослушать трафик, дальнейшее шифрование таким ключом является небезопасным.
    • Если есть локальный хард, и на нем найдена установленная калька, он монтируется в /mnt/root, и оттуда копируются ключи.(так у меня сделано в шаблонах)
    • Запись ключей в UEFI-bios . Есть узкие места:
      • в случае неправильной настройки небезопасно в случае загрузки с другого носителя(кстати, запуск С КАКИХ DHCP-серверов разрешен также настраивается в uefi)
      • Требует материнки с поддержкой данной технологии.
      • И главный минус - я пока без понятия каким инструментом это можно делать :wink: (ну не вручную же лазить в каждый биос)
  • Задача 9. или Проблема 6. /home находится в памяти. Даже при подключенном swap, это не правильно:
    • во первых - после каждой перезагрузки тяжелый профиль каждого пользователя будет полностью копироваться на локальную машину
    • во вторых - сколько бы swap-а не было, в 32-битной системе без включенного PAE, адресуемой памяти может быть не больше 3.5G. И tmpfs будет нехило отжирать из нее под статические редко используемые данные, оставляя меньше реально нуждающимся приложениям.
      Решается монтированием либо локального диска(пока я решил так), либо использованием шары на сервере для каждой машины в отдельности(так сделано в том самом кафе, и так в перспективе рассчитываю сделать я).
  • Задача 10. [получение имени хоста по DHCP]{.Не}(решено тут ) и недоступность логов загрузки служб через openrc, решения в аттаче в шаблонах по адресу builder/squash
    Эти обе задачи решил объединить, поскольку для их решения мало поместить шаблоны на сервере, необходимо пересобрать squashfs с применением этих шаблонов.

Вроде рассмотрел все задачи и (проблемы Ставящие эти задачи).
То что на данный момент решено - доступно в этом аттаче attachment:templates.tar.bz2
Для удобства обсуждения (я надеюсь кому-то покажется эта тема интересной, и возможно будут мысли как усовершенствовать скрипты) прикладываю также все дерево каталогов единым текстовым файлом attachment:templates.diff (единственный вариант, до которого додумался, если есть мысли как стоило бы делать лучше-я весь внимание)

PS
Хотел как лучше - выложить текстом diff, чтоб можно было просмотреть его не скачивая, а оказалось, что этот движок считает diff бинарным файлом, и не позволяет его просмотреть. Если кто подскажет как оформить diff текстовиком - буду благодарен.

Вчера ковырял скрипты из genkernel calckernel.
Обнаружил для себя интересную функцию

<code class="bash">$ tail -n+965 /usr/share/genkernel/defaults/initrd.scripts |head -n17
cdupdate() {
    if [ "${CDROOT}" = '1' ]
    then
        if [ -x /${NEW_ROOT}/mnt/cdrom/cdupdate.sh ]
        then
            good_msg "Running cdupdate.sh"
            ${NEW_ROOT}/mnt/cdrom/cdupdate.sh
            if [ "$?" != '0' ]
            then
                bad_msg "Executing cdupdate.sh failed!"
                run_shell
            fi
        else
            good_msg 'No cdupdate.sh script found, skipping...'
        fi
    fi
}</code>

Вызывает cdupdate.sh практически перед chroot-ом в real_root.
Набор команд из ash, практически стандартный:
grep sed все возможные(известные мне) опреации с переменными
Все, или почти все шаблоны на squashfs, можно перенести на этот уровень.
Как минимум, тем кого не греет мысль о пересборке образа ради включения нескольких полезных шаблонов на squash, а попробовать pxe хочется - можно полезные патчи не связанные с переменными calculate, перенести сюда.
Что я рассчитываю перенести для pxe:

* патч на /lib/dhcpcd/dhcpcd-hooks/30-hostname (см. раньше об этом)

* rc_logger=“YES” в /etc/rc.conf - Логи старта сервисов полезно иметь в файле

* Перенос настроек сплеша

cp -a /union/var/lib/layman/calculate/profiles/templates/install/1merge/cldg-themes/tty* /union/etc/splash/

В оригинале - это делается уже во время загрузки LiveCD образа по pxe, при первом наложении шаблонов на систему.
Соответственно виден либо сплеш зашитый в initrd, либо черный экран, либо логи старта сервисов.

  • Патч на /etc/shadow и /etc/inittab, и может еще какие правила безопасности. Пока я не трогал этой темы, но если прохаваный юзер перейдет в интерактивный режим запуска служб - он может просто отменить запуск client-а, и все те хитрые шаблоны не сработают.

* Задача 7. или Проблема 4. ограниченность RAM, и потребность в swap. Тут есть три пути:
**** использование compcache , и хоть в “News” и сказано…

Dec 12, 09 - compcache is now in mainline – it will be part of kernel 2.6.33.
…как-то в ядре 3.* опцию CONFIG_RAMZSWAP я не отыскал, видимо выпилили.

Похоже нашел

CONFIG_ZRAM:

Creates virtual block devices called /dev/zramX (X = 0, 1, ...).
Pages written to these disks are compressed and stored in memory
itself. These disks allow very fast I/O and compression provides
good amounts of memory savings.

It has several use cases, for example: /tmp storage, use as swap
disks and maybe many more.

See zram.txt for more information.
Project home: http://compcache.googlecode.com/

Symbol: ZRAM [=m]
Type  : tristate
Prompt: Compressed RAM block device support
  Defined at drivers/staging/zram/Kconfig:5
  Depends on: STAGING [=y] && BLOCK [=y] && SYSFS [=y]
  Location:
    -> Device Drivers
      -> Staging drivers (STAGING [=y])
  Selects: XVMALLOC [=n] && LZO_COMPRESS [=y] && LZO_DECOMPRESS [=y]

Также нашел:

CONFIG_ZCACHE:

Zcache doubles RAM efficiency while providing a significant
performance boosts on many workloads.  Zcache uses lzo1x
compression and an in-kernel implementation of transcendent
memory to store clean page cache pages and swap in RAM,
providing a noticeable reduction in disk I/O.
Symbol: ZCACHE [=m]
Type  : tristate
Prompt: Dynamic compression of swap pages and clean pagecache pages  Defined at drivers/staging/zcache/Kconfig:1
  Depends on: STAGING [=y] && (CLEANCACHE [=y] || FRONTSWAP)
  Location:
    -> Device Drivers
      -> Staging drivers (STAGING [=y])
  Selects: XVMALLOC [=y] && LZO_COMPRESS [=y] && LZO_DECOMPRESS [=y]

Второе кажется поинтереснее.

Буду экспериментировать.