Причуды симбиоза, или снова "сделай сам"

Сосуществование win- и *-nix машин в нынешнем мире — объективная реальность. Однако если в Сети, самим своим существованием в большой степени *-nix-ам обязанной, это как бы "само собой разумеется", то в секторе SOHO до недавнего времени было "в диковинку".

Распространение сетевых технологий, вездесущий Интернет, игры с "лицензионной чистотой" и, не в последнюю очередь, качество решений, основанных на open source, сделали своё дело: для офиса из десятка компьютеров персоналка с Linux, используемая в качестве файрвола, почтовика, файл-сервера или даже контроллера домена стала вполне обычным явлением.

Удивительно, если Linux используется для решения абсолютно Win-довых проблем. А как ещё назвать проблемы с учётными записями, fat/ntfs или отказом загрузки? Но и такое, как ни странно, случается. Собственного пристрастии к rescue-системам, построенным на Linux, я не скрываю. "О вкусах не спорят", но если в иной день вам случится столкнуться с десятком проблемных компьютеров, то вы, скорее всего, согласитесь, что и скорость загрузки, и нетребовательность к ресурсам, и отсутствие каких-либо пожеланий к видеоадаптеру — стоят отсутствия gui.

И совсем уже забавно, когда проблема не решается в рамках ms windows, но даже не является проблемой в Linux. Подобные ситуации не столь уж редки. Я вполне допускаю, что хороший win-администратор (себя я к таковым не отношу) справился бы с этой проблемой и под windows. Но только то ли таких уж совсем мало, то ли проблем на порядок больше, но поток "прибитых" windows-систем не оскудевает.

И ладно бы речь шла о мультизагрузке или ещё какой диковине, традиционно игнорируемой MicroSoft. Так нет же: приносят, скажем, винчестер, логические разделы которого в одночасье из ntfs превратились в raw. Разумеется, хозяин перебрал все предлагаемые windows gui-средства. Разумеется, я, прежде всего, убедился в корректности содержимого MBR/BR и воспользовался chkdsk и testdisk: никакого эффекта. Прежде чем передать многострадальный винчестер в руки всевозможных EasyRecovery и ZeroAssumption, я попробовал смонтировать те же разделы под Linux... и они оказались вполне читаемыми.

Если один и тот же раздел ntfs-3g — читает, а ms windows — нет, и даже не предлагает средств разрешения этой ситуации, то это уже не просто плохо, это уже вредительство какое-то, ей Богу. С них станется, впрочем... Интересно было бы узнать, насколько такая ситуация распространена, каковы её истоки и способы преодоления. Google более-менее внятно ответил только на первый вопрос: бывает. На дальнейшие поиски времени не было: надо клиенту информацию спасать. Далее — только об этом.

Сразу скажу, что загрузившись с livecd какого-нибудь Ubuntu 8.04 LTS, все разделы, созданные, а потом и разрушенные windows вы прочитаете. Но в том же 8.04 LTS нет многого, что входит обычно в состав rescue-дисков, таких, как RIP, CDLinux или SystemRescueCD. Сами же rescue-cd часто поддерживают только одну локаль, справедливо полагая, что при спасательных операциях не до "многоязычия". Оно-то, может, и справедливо, но, в данном частном случае, всю ересь, именованную клиентом в кириллице, мы не увидим.

Придётся быстренько "довести" текущий RIP до нужного состояния. "Давненько не брал я в руки шашку", как говорил один литературный персонаж. Делается это примерно так...

• Сначала определяем проблему. Незатейливое locale сообщает нам, что локаль у нас en_US, а чуть более изощрённое locale -a, говорит, что никаких других локалей в системе просто нет.
• Поскольку речь пойдёт о модификации livecd, то, прежде всего, превращаем последний в обычный каталог. Благо, о том, как это делается, обычно говорится в описании самого же livecd. Для RIP, в частности, это будет:

  cd root-livecd; gzip -dc ../rootfs.cgz | cpio -iumdv

  разумеется, каталог root-livecd должен существовать.
• Теперь определяем, как задаётся локаль: в /etc (а где же ещё?) ищем файл с подстрокой "en_US", меняем её на "ru_RU.UTF8". Локаль задали, осталось переписать содержимое соответствующего подкаталога. Обычно это подкаталог ru_RU.UTF8 в /usr/lib/locale. Данный подкаталог можно позаимствовать из любого современного дистрибутива.
• Поскольку неизвестно, что за шрифт используется в консоли rescue-cd, сразу дополняем его всенародно любимым terminus: помещаем файлы ter-k1??.psf.gz в каталог kbd/consolefonts. В RIP cам каталог kbd находится в /usr/share, но это — не догма. В RH и родственных он, например, находится в /lib. То есть: "ищите — и обрящете". Нужные файлы опять-таки — заимствуем. Для задания нужного шрифта там же в /etc ищем файл с подстрокой setfont (именно эта команда загружает консольный шрифт в подавляющем большинстве современных дистрибутивов) и редактируем его соответствующим образом.
• Если ваш rescue-cd не поддерживает в консоли мышь (как это имеет место в RIP), то стоит включить gpm: кто сказал, что мышь не нужна в консоли? "Тыкать" ею там действительно почти нечего, но как средство copy/paste — незаменима. Для RIP (как и для прочих эпигонов Slackware) это достигается "взведением" бита исполняемости у файла /etc/rc.d/rc.gpm. Последнее, кстати, потребуется и для файла /etc/rc.d/rc.font, который будет результатом поиска подстроки setfont (см. предыдущий параграф).
• Теперь можно проверить, что получается. Создаём из каталога образ initrd, который станет частью livecd. Для RIP это делается так:

  cd root-livecd; find . | bin/cpio -v -o -H newc | gzip -9 >../rootfs.cgz

  записываем livecd, загружаемся.
• С "голой" консолью всё в порядке, а вот mc в исполнении Кента Роботти с utf-8 что-то пока "не дружит". Если упомянутый файл-менеджер вам "дорог как память" (для меня это так и есть), то возвращаемся к каталогу root-livecd и переходим к следующему пункту.
• Заимствуем mc из дистрибутива, ориентированного на utf-8 в полной мере. RedHat или Ubuntu — что ближе. Кроме банального переписывания /usr/bin/mc почти наверняка потребуются кое-какие библиотеки. Какие — уточняем с помощью ldd ./mc (загружен livecd, а "находимся" в /usr/bin системы, из которой предполагаем портировать mc). Недостающие библиотеки и симлинки переписываем из "большой" системы в соответствующие подкаталоги root-livecd. Имеет смысл сравнить "ресурсы" mc: /etc/mc и /usr/share/mc: возможно, "большая" система предложит что-то сверх того, что уже есть в rescue-cd.
• Повторное создание rootfs и запуск livecd показывают, что теперь mc прекрасно читает именованные в кириллице каталоги на разделах ntfs. К сожалению, помимо ntfs под ms windows встречаются ещё и fat-разделы. Нужно сказать, что RIP создаёт при загрузке подкаталоги каталога /mnt — по одному на каждый обнаруженный при загрузке раздел и файл /etc/fstab, любезно освобождающий нас от знания опций монтирования. Так вот банальное mount /mnt/имя_устройства для fat-разделов оказывается недостаточным: многострадальная кириллица опять не видна.
• Монтирование тех же разделов с опцией utf8 проблему решает, но если это не требуется для разделов ntfs, то почему должно требоваться для fat? Нелогично. Правим Кента дальше. Всё тот же контекстный поиск на сей раз подстроки "NTFS" приводит нас к файлу /etc/rc.local. Оказывается, именно этот файл формирует /etc/fstab. Осталось к строкам, отвечающим за формирование строк для NTFS, добавить строки для FAT. А именно, после строк:

  if grep $device_name /tmp/devices | grep -q NTFS ; then
    echo "$device_name  /mnt/`echo $device_name | cut -b 6-`  ntfs-3g  defaults,noauto  0  0" >> /etc/fstab

  вставляем строки:

  elif grep $device_name /tmp/devices | grep -q FAT ; then
    echo "$device_name  /mnt/`echo $device_name | cut -b 6-`  auto defaults,noauto,utf8 0  0" >> /etc/fstab

• Задачу можно было бы считать решённой, если не вспомнить, что помимо "малого" варианта RIP, существует ещё и RIP-X, который включает в себя X-Window. Для последнего достаточно выполнения пунктов, обеспечивающих локаль ru_RU.UTF8 — всё остальное и так есть. "Остальное" — это шрифты с поддержкой utf-8 и симпатичный файл-менеджер emelfm. Учитывая, что RIP-X больше консольного RIP на какие-то 20MB, а загружается почти также быстро, варианты можно признать практически равноценными.
• Оказавшись в X-ах, невозможно не заметить, что помимо довольно дружественного emelfm, там предлагается gui же утилита монтирования. Анализ /root/.fluxbox/menu показывает, что за этой утилиткой скрывается простенький shell-скрипт /usr/bin/mumount. К сожалению, скрипт этот монтирует fat-разделы так же бездарно (в отношении кириллицы), как и /etc/rc.local Кента. Но что мешает исправить его, как это уже сделано с /etc/rc.local? Ничто, разумеется. После строк, обеспечивающих монтирование разделов ntfs:

  if grep $dev $TMP/tmpmsg2 | grep -q NTFS ; then
  if [ "$force" = "yes" ]; then
    ntfs-3g $dev /mnt/`echo $dev | cut -b 6-` -o force,rw 2>$TMP/error || error=yes
  else
    ntfs-3g $dev /mnt/`echo $dev | cut -b 6-` -o rw 2>$TMP/error || error=yes
  fi

  вставляем следующее:

  elif grep $dev $TMP/tmpmsg2 | grep -q FAT ; then
    mount $dev /mnt/`echo $dev | cut -b 6-` -o utf8 2>$TMP/error || error=yes

• Прочие проблемы, связанные с особенностями монтирования ntfs-разделов, ограничением прав при работе под X-Window и т.д. и т.п. обсуждать не буду. Предполагается, что у читателя общее знакомство с linux уже имеет место. Если же это не так, то начинать нужно с представления блочных устройств, единой файловой системы *-nix-ов, понятия монтирования и истории развития "многоязычия" в ОС от MicroSoft. Тоже интересно, но — в другой раз.

Вышесказанное показалось вам сложным? Сожалею. Мне — нравится. И не мне одному, кстати. Полчаса не самой скучной работы — и у меня на полке 40-МБ livecd, готовый помочь в преодолении множества компьютерных проблем в условиях болезненного пристрастия клиента к кириллице.