"Сделай сам"

"Сделай сам" — 2

2009-01-20

Просмотрев комментарии к своей заметке Причуды симбиоза, или снова "сделай сам" (спустя несколько месяцев после её опубликования), я был несколько озадачен... Если бы я представлял свой собственный livecd, то, разумеется, сначала выложил бы его образ в Сети. Если бы хотел обнародовать список патчей к какому-либо программному продукту, то хотя бы указал его версию (что особенно актуально для RIP, у которого бывает до пяти версий в месяц). И уж тем более я не искал "зачёт" для себя или, тем более, для Linux. Последний зачёт я сдал лет 30 назад, а принял — лет 20. Так что...

Иногда, наверное, стоит предварять материал сведениями о его назначении. Так, в вышеупомянутом случае заметка была адресована тем, кто захочет сам модифицировать livecd. А для этого нужно 1) уметь найти, что именно подлежит модификации; 2) определить как это "что-то" модифицировать. На мой взгляд, ничего трудного в этом нет. Но знание того, что есть "контекстный поиск" (пусть без grep, но хоть средствами mc) всё-таки требуется. Далее потребуются некоторые познания в bash-скриптинге и информация по поводу тех или иных используемых команд, но это-то, как раз, — "дело наживное". Было бы желание. А оно возможно только в двух случаях: если "очень нужно" или "интересно — спасу нет".

В отсутствие же упомянутых стимулов, рекомендуется ограничиться использованием существующих законченных решений. Как открытых, так и проприетарных. Смирившись при этом с тем обстоятельством, что производитель закрытого ПО не пойдёт навстречу вашим пожеланиям, если не будет уверен, что их выполнение может принести дополнительную прибыль, а разработчик открытого ПО обратит на них внимание, только если это будет ему интересно (в широком смысле). Случаи беззаветного альтруизма опускаем, как весьма немногочисленные (пусть: к сожалению).

Поскольку первую попытку "Сделай сам" (судя по комментариям) вполне успешной считать не приходится, то предпримем ещё одну. Благо, есть повод: некоторой организации потребовался livecd, с помощью которого обновляются/клонируются linux-станции. Как это происходит — дело "пятое", но некоторые "вводные" придётся перечислить:

livecd должен поддерживать максимально широкий спектр аппаратуры. Разумеется, речь идёт об устройствах хранения и адаптерах ethernet (а что ещё нужно для копирования по сети образов станций?);
системная локаль — koi8-r (это связано с необходимостью выполнения скриптов, загружаемых с серверов, работающих под koi8: некоторые из этих скриптов писались до распространения utf, да и нет никакой потребности у АСУТП-комплекса в переходе на utf);
поддержка SSH, NFS, HTTP протоколов.

Выбор прототипа

Заметка не имела бы в названии намёка на sequel, если бы в ней не шла речь опять о RIP. И в данном частном случае livecd Кента Роботти представляется оптимальным. "Технических" livecd много. Clonezilla лучше прочих справляется с клонированием дисков, PLoP хорош наличием в нём пары антивирусов (да простит меня Dr.Web, но, хоть сканер их и лучше многих, представленный недавно Linux-livecd оставляет желать лучшего), GParted, как нетрудно догадаться, ориентирован на манипуляции с разделами, IPFire и pfSense — "заточенные" firewall-ы, но ни один из проектов не обновляется так часто и не использует обычно самую "свежую" версию ядра, как это имеет место для RIP.

К сожалению, кажется, нужно сказать "имело место", поскольку недавно Кент Роботти заявил о прекращении поддержки проекта, о чём можно только пожалеть. Потому как, если первой предпосылкой успешности RIP-а были "здоровые корни" (RIP основан на Slackware), то второй — энтузиазм Кента, не знающего (не знавшего?) усталости в пересборке своего livecd всегда в соответствии с последней (как правило) версией ядра и включаемых продуктов.

Для данного частного случая (наилучшая поддержка контроллеров HDD и ethernet-адаптеров, "старые-добрые" средства сетевого взаимодействия, компактность) RIP практически идеален: никаких "заморочек" с аудио/видео, никаких user-friendly "рюшечек" — только необходимое для решения определённой задачи.

Отказ автора от поддержки своего livecd огорчает, но не пугает: опора на Slackware и вполне очерченный перечень используемых программ делает самостоятельный upgrade вполне возможным. Что же касается ядра (как наиболее динамично изменяющейся компоненты), то я и раньше частенько дополнял его предпочитаемой поддержкой framebuffer и некоторыми особенностями, связанными с локализацией. Поскольку ядро у RIP "каноническое" (в отличие от эпигонов Red Hat и Debian), то никаких особенных трудностей его пересборка не представляет.

Но это — дело будущего, а пока берём последнюю версию RIP (на момент написания заметки это оказалась версия 7.2) и — приступим.

"В начале была файловая система..."

Начинается всё с преобразования iso-файла в каталог, представляющий собой корневую файловую систему RIP. Разумеется, для этого сначала нужно извлечь из iso-файла компрессированный образ этой самой системы. Примонтировав его к какому-нибудь каталогу (mount ./RIPLinuX-7.2.grub.iso /mnt/iso -o loop), находим и переписываем куда-нибудь файл rootfsX.cgz. Потом получаем корневую файловую систему в каталоге, например, root-X. Делается это (в соответствии с рекомендациями самого Кента) командами:

cd root-X
gzip -dc ../rootfsX.cgz | cpio -iumdv

Всё это можно (и даже рекомендуется) делать непосредственно из-под загруженного RIP: в этом случае у вас будет гарантированно подходящая версия cpio.

Теперь — кириллица

В соответствии с прозвучавшими ранее рекомендациями, находим файл, определяющий текущую локаль. Для тех, кто испытывает затруднения с поиском файла, включающего в себя подстроку "en_US", отметим, что в RIP (точнее: в RIP версии 7.2) это файл /etc/profile.d/lang.sh. Искомая строка: "export LANG=en_US". Поменяв "en_US" на "ru_RU.koi8r", мы потребуем для каждой вновь открываемой сессии установки локали ru_RU.koi8r. Для того чтобы данное требование не было лишь декларативным, обеспечиваем эту возможность, переписав, подкаталог ru_RU.koi8r в каталог /usr/lib/locale. Подкаталог заимствуем из любого современного дистрибутива. На всякий случай (если будущий livecd предполагается использовать не только для обозначенной выше задачи) аналогично можно поступить с подкаталогом ru_RU.utf8.

Потом (если имеет место выраженная привязанность к terminus, иначе — это совсем не обязательно) копируем эти самые фонты для консоли (ter-k14?.pcf.gz и ter-k16?.pcf.gz) в каталог /usr/share/kbd/consolefonts. Туда же можно скопировать acm-файл, необходимый для определения соответствия 16-битных кодов символов фонта и 8-битного их представления в koi8-r. Я использую файл koi8-u.acm.gz, хотя и здесь "возможны варианты". В системе, откуда вы "портируете" фонты terminus, этот файл нужно искать в каталоге consoletrans (соседствующем, как правило, с каталогом consolefonts). В конечном счёте, не имеет значения, где будут находиться pcf/acm файлы, если путь к ним в нужном месте указать полным.

Консольный фонт и раскладка клавиатуры задаются у всех Slackware-подобных в файлах /etc/rc.d/rc.font и /etc/rc.d/rc.keymap соответственно. Признаком "активности при загрузке" для данных файлов является флаг "исполняемости". На этом этапе нас, однако, поджидает небольшое фиаско: консольный вывод оставляет желать лучшего, а консольный ввод не работает вообще. Такой эффект — не редкость при задании 8-битной локали в дистрибутивах, окончательно перешедших на utf-8.

Для преодоления неожиданно возникших трудностей придётся произвести некоторые "изыскания". Обратившись к какому-нибудь современному Red Hat-совместимому дистрибутиву (последние поддерживают 8-битные локали наряду с utf-8 вполне успешно) и проанализировав загрузочные скрипты, определяющие фонт и раскладу в консоли, обнаруживаем, что они используют парочку скриптов: /usr/bin/unicode_stop и /usr/bin/unicode_start. Заимствуем эти скрипты для исправления RIP. Поскольку скрипты эти используют для переключения режима консоли некоторые "магические" последовательности (echo -n -e '\033%@'), нам предстоит решить: выдавать эти последовательности на все наличные восемь консолей или выполнять эту операцию для каждой отдельной консоли в момент открытия сессии. Лично мне второе представляется более разумным. При открытии консольной сессии выполняется, как известно, файл /etc/profile; именно его и дополним нужными строками:

/usr/bin/setfont -v /usr/share/kbd/consolefonts/ter-k16n -m /usr/share/kbd/consolefonts/koi8-u.acm.gz
/usr/bin/unicode_stop

Ничего сложного: что за команды — выяснилось при просмотре скриптов инициализации, ключи — см. man setfont, а файлы мы же сами и записали.

Таким образом, /etc/rc.d/rc.font нам больше не нужен — снимаем с него признак исполняемости. А /etc/rc.d/rc.keymap — используем, задав в нём раскладку ru4 (CapsLock в качестве переключателя) строкой:

/usr/bin/loadkeys ru4.map

Если пристрастие к terminus распространяется и на X Window, то ничто не мешает добавить в каталог /usr/share/fonts подкаталог terminus, содержащий соответствующие pcf-фонты из дистрибутива, в котором они имеются. Добавлять стоит весь подкаталог (с файлами fonts.dir и fonts.scale). Не забудьте "напомнить" Х-ам, что этот каталог нужно рассматривать, как источник фонтов (строка FontPath "/usr/share/fonts/terminus" в секции "Files" файла /etc/X11/xorg.conf).

"Доводка"

Разумеется, можно активизировать gpm, расширить список фонтов (если предполагается всё-таки использовать X Window), определить свои элементы конфигурации (в данном случае это были файл /etc/hosts и /etc/fstab) и так далее, и тому подобное.

Настройки X Window — отдельная "история". В составе RIP имеется конфигуратор, но единственное, что он делает полезного — определяет драйвер для обнаруженного видеоадаптера. Принимая во внимание, каким небольшим числом драйверов обходится нынешняя X Window, мне кажется, что как раз драйвер можно определить и самому. А вот задать разрешение (особенно отличное от ряда 4:3), подстроить частоту кадровой развёртки (VertRefresh), определить дополнительную раскладку клавиатуры и переключатель для неё... ничего этого конфигуратор не делает. Более того: аннулирует все сделанные ранее изменения /etc/X11/xorg.conf, что на мой взгляд является уже полным безобразием. Так что разумнее, на мой взгляд, самому отредактировать вышеупомянутый файл: полсотни строк вполне "прозрачного" текста.

Поскольку используемый win-manager (а это fluxbox) не слишком балует пользователя обилием средств конфигурации десктопа, интерес может представлять также файл /etc/fonts/fonts.conf и файлы пользовательской настройки fluxbox (в данном случае /root/.fluxbox/*). Настройка fluxbox — довольно занимательное занятие, если ваши эстетические представления не совпадают с таковыми Кента.

Что касается моего частного случая, более затребованными оказались подкаталоги /mnt для соответствующих сетевых ресурсов (плюс соответствующие строки в /etc/fstab), файлы конфигурации mc (/root/.mc/*) и vim (/root/.vimrc) — редактора системы "по умолчанию". Но случай, действительно, "частный", так что желающим предлагается ориентироваться на собственные потребности.

Создание iso-образа из каталога в повторном описании, кажется, не нуждается.

Бонус

Как оказалось, сконфигурированная подобным образом консоль успешно отображает кириллицу в именах каталогов и файлов в примонтированных NTFS-разделах. Для монтирования рекомендуется скрипт /usr/bin/mumount (и соответствующая позиция меню в gui). Этого нельзя, к сожалению, сказать о разделах FAT. Тут, скорее всего, проще вернуться к utf-8 локали (если вы переписали подкаталог ru_RU.utf8, разумеется) и gui.

Может показаться странным, что при монтировании FAT-раздела в RIP не помогают известные опции монтирования. Ничего невероятного в этом нет: процесс монтирования (и отображения монтированной файловой системы) в большей степени определяется ядром, чем утилитой mount. Если ещё учесть, что man mount снабдит вас, вполне вероятно, информацией годичной и более давности, то трудности монтирования вполне вероятны. Кроме того, поддержка nls (native language support) в консоли определяется несколькими опциями ядра. Манипулируя этими опциями, вполне можно "добиться" невозможности отображения кириллицы, например. Что и случается, не так уж редко. Не расстраивайтесь, ничего не поделаешь: поддержка нативных языков не принадлежит к числу первоочередных требований при спасательно-административных операциях.