Привет всем.
Это продолжение и логическое развитие темы 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. Даже не рассматриваю.
- использование compcache , и хоть в “News” и сказано… _
-
Задача 8. или Проблема 5. При запуске sshd закрытые ключи
/etc/ssh/ssh_host_*key*
генерируются по новому. Что нивелирует саму суть закрытых ключей(один раз при подключении по защищенному каналу, либо заведомо при отсутствии потенциального злоумышленника с возможностью прослушать/подменить трафик, мы сохраняем fingerprint ключа, и в дальнейшем при несовпадении его ssh матерится)
Вижу несколько решений:- Клиент получает свой ключ с сервера. Поскольку злоумышленник может прослушать трафик, дальнейшее шифрование таким ключом является небезопасным.
- Если есть локальный хард, и на нем найдена установленная калька, он монтируется в /mnt/root, и оттуда копируются ключи.(так у меня сделано в шаблонах)
- Запись ключей в UEFI-bios . Есть узкие места:
- в случае неправильной настройки небезопасно в случае загрузки с другого носителя(кстати, запуск С КАКИХ DHCP-серверов разрешен также настраивается в uefi)
- Требует материнки с поддержкой данной технологии.
- И главный минус - я пока без понятия каким инструментом это можно делать (ну не вручную же лазить в каждый биос)
-
Задача 9. или Проблема 6. /home находится в памяти. Даже при подключенном swap, это не правильно:
- во первых - после каждой перезагрузки тяжелый профиль каждого пользователя будет полностью копироваться на локальную машину
- во вторых - сколько бы swap-а не было, в 32-битной системе без включенного PAE, адресуемой памяти может быть не больше 3.5G. И tmpfs будет нехило отжирать из нее под статические редко используемые данные, оставляя меньше реально нуждающимся приложениям.
Решается монтированием либо локального диска(пока я решил так), либо использованием шары на сервере для каждой машины в отдельности(так сделано в том самом кафе, и так в перспективе рассчитываю сделать я).
-
Задача 10. [получение имени хоста по DHCP]{.Не}(решено тут ) и недоступность логов загрузки служб через openrc, решения в аттаче в шаблонах по адресу builder/squash
Эти обе задачи решил объединить, поскольку для их решения мало поместить шаблоны на сервере, необходимо пересобрать squashfs с применением этих шаблонов.
Вроде рассмотрел все задачи и (проблемы Ставящие эти задачи).
То что на данный момент решено - доступно в этом аттаче attachment:templates.tar.bz2
Для удобства обсуждения (я надеюсь кому-то покажется эта тема интересной, и возможно будут мысли как усовершенствовать скрипты) прикладываю также все дерево каталогов единым текстовым файлом attachment:templates.diff (единственный вариант, до которого додумался, если есть мысли как стоило бы делать лучше-я весь внимание)