Знакомство с Linux. Часть 14. Миграция с Red Hat Linux 7.3 на 9

Итак, продолжаем миграцию - с Red Hat Linux 7.3, как уже говорилось ранее, на тот же Red Hat, только 9. Напомню, почему именно я пришёл к такому решению: меня серьёзно удручили нежданно возникшие проблемы с отображением и вводом кириллицы, объявившиеся в оконном менеджере KDE, которым я предпочитаю пользоваться в Linux. Забегая вперёд, скажу: отчаявшись наладить пристойную русификацию в модернизированной системе, я проинсталлировал на другом компьютере RHL 9, что называется, с нуля, - и убедился: в "чистой" установке с кириллицей всё в полном порядке. Значит, есть смысл и на домашнем ПК систему переставить.

Так вот; самая крупная неприятность, которая поджидала меня в графическом режиме работы после апгрейда, - это отказ системы переключать раскладку клавиатуры с английской на русскую и обратно. Привычное нажатие Alt и Shift, посредством которого я переходил от кодировки к кодировке, больше не действовало. И конечно же, первое, что я сделал, - отправился в Центр управления KDE.


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


Прежде всего, следует поставить галочку в чекбоксе "Включить раскладки клавиатуры", затем выбрать основную раскладку, указать дополнительные (да, можно не одну дополнительную, а сколько заблагорассудится) и если потребуется, её вариант. Для русской раскладки, скажем, вариантов целых четыре - basic, typewriter, winkeys и phonetic. При этом можно задать правило, в соответствии с которым переключение раскладки будет срабатывать: глобально, в одном окне или во всех окнах, относящихся к данному приложению. Ну разве не удобно?


А в закладке "Параметры" - вообще раздолье. Здесь как раз можно назначить клавиши, переключающие раскладку, и даже сопроводить это переключение световым сигналом на самой клавиатуре - в данном случае, подсвечиванием индикатора Scroll Lock, который всё равно в современных системах не задействуется. Зато такое поведение чрезвычайно удобно для тех, кто до сих пор не овладел искусством десятипальцевой слепой печати. Светящийся (или нет) огонёк на периферии поля зрения обязательно будет заметен. В общем, ура! Выставляем необходимые параметры, нажимаем клавишу "Применить" и ожидаем, что всё заработает. Ведь, собственно, этот пункт меню оставался неизменным со времени установки прежней версии дистрибутива. И хотя системная локаль сменилась с KOI на UTF, разве должно это как-то отразиться на способе переключения клавиатурных раскладок?

А вот отражается. Каким именно образом - не представляю себе, но отражается. Я задал вопрос в списке рассылки пользователей последнего дистрибутива Red Hat, и быть может, получу на него ответ. Но в любом случае, ответ этот вряд ли будет иметь серьёзную практическую ценность. Ведь действительно, переход на UTF - это прогрессивно и хорошо, и если организовать его как следует - полной установкой с форматированием служебных разделов - то переключение с языка на язык будет производиться корректно. Проверено. Так давайте же не будем зацикливаться на этой досадной закавыке - на которой я, правду сказать, на недельку застрял, - и двинемся дальше. К новым горизонтам.

Для того же, чтобы горизонтов этих достичь, нам понадобится кое-что освоить. В частности - научиться создавать в Linux архивные файлы и сохранять их на внешних (по отношению к штатному винчестеру вашего ПК) носителях.

Ведь полная переустановка - полной переустановкой, а в каталоге /etc/ хранятся у нас уже несколько файлов, которые всё равно придётся приводить в соответствие с реалиями системы сразу же по завершении инсталляции. Это, к примеру, файл /etc/wvdial.conf, в котором содержатся параметры инициализации модема и необходимая для установки соединения с провайдером пара логин-пароль. Это /etc/fstab, где тщательно прописаны детали взаимодействия с чужеродными файловыми системами, каковому описанию мы уделили с вами уже достаточно времени. Это подкаталог /etc/X11/, хранящий параметры конфигурации X Window System - в том случае, если вам, как и мне, пришлось конфигурировать драйвер видеоадаптера вручную, с использованием загруженного с сайта провайдера пакета, ценность этих параметров по сравнению с установками умолчания многократно возрастает. Об /etc/passwd я даже просто не говорю.

Ну и самое любопытное: пользовательские директории. Ведь сберечь конфигурационные файлы нетрудно, благо в Linux в этом смысле всё устроено по уму. Достаточно заархивировать целиком текущий каталог /etc/ (как именно - сейчас разберёмся), разместить архив в той файловой системе, которая форматированию не подвергнется (например, /home/, - ведь пользовательские данные модернизировать вроде как незачем, верно?), затем провести переустановку, и те файлы в новом каталоге /etc/, которые будут нуждаться в переделке, заменить сбережёнными прежними. Всего-то и делов.

Но вот какая тонкость: переинсталлировав систему, мы ведь снова запустим графический режим и будем работать в нём. Настройки графического режима - расположение иконок на десктопе, значков программ на Панели управления и тому подобного - хранятся не где-нибудь, а в домашнем каталоге каждого пользователя. К примеру, для оконного менеджера KDE эти настройки будут располагаться в директории .kde/ у каждого из хотя бы раз запускавших данную оболочку пользователей. Файлы и каталоги, имена которых начинаются на точку, как правило, все являются такими хранилищами настроек. Сколько их создаётся потихоньку в домашних каталогах, можно узнать, исполнив команду ls с параметром -а - или задав шаблон вывода имён, первым символом которых является точка.


Страшновато? Все эти служебные файлы при любой модернизации системы плохи тем, что сохраняются в них, разумеется, настройки прежних версий программ. И хорошо, если совместимость обновлённого "софта" со старыми настройками разработчиками хоть как-то обеспечена. А если нет? Могут случиться неприятные вещи. Банальный пример: у меня на Панели управления в KDE размещались иконки наиболее часто используемых приложений. После переустановки и первого старта графической оболочки выяснилось, что половина иконок слетела - потому что сменились пути, ведущие к файлам.

Так что в идеале при переходе к существенно новой версии системы - как в нашем случае, с 7.3 на 9 - неплохо было бы и отведённый под /home/ раздел отформатировать. Вот с Red Hat 7.2 на 7.3, как сейчас помню, я перешёл без сучка, без задоринки. А тут - другой случай.

Итак, прежде всего, заархивируем важнейшую системную информацию - и содержимое своего домашнего каталога, если нужда в этом имеется. Каким образом? Лично я предпочитаю утилиту tar.


Прежде всего, имеет смысл оценить - насколько велик объём, который предстоит архивировать. Вдруг места на том разделе, где станет создаваться архив, попросту не хватит? Для такой оценки применяется утилита du, название которой происходит от выражения disk usage, "использование дискового пространства". Опция -s призывает программу выводить на печать общий объём исследуемого каталога, - в противном случае на экране появился бы длинный отчёт о размерах всех содержащихся в нём поддиректорий. Опция же -h, объединённая с предыдущей в единый ключ -sh, задаёт вывод размера каталога в "пригодной для чтения человеком" - human readable - форме. То есть не в единицах байт, что в случае длинных чисел довольно-таки неинформативно, а с применением условных сокращений. М - для мегебайт, К - для кило-, и так далее.

Убедившись, что исходный объём архивируемой директории не так уж велик, вызываем собственно утилиту архивирования - tar. Строго говоря, сама по себе tar (tape archive) в исходном варианте предназначалась для создания архивов на магнитной ленте. И всё, что она по умолчанию делает, - это превращает древовидную структуру каталога-мишени в один-единственный файл, пригодный для неторопливой последовательной записи на ленту. О том, что файл именно создаётся, говорит опция -c (create); имя файла определяется опцией -f, последней в блоке. Никто не заставляет вас приписывать к имени архива расширение .tar или ещё какое бы то ни было: система, если предложить ей распаковать архив обратно в дерево каталогов, сама определит, что это действительно архив (в чём можно убедиться при помощи знакомой нам команды file). Но для собственного удобства лучше, конечно, не забывать о "говорящих" расширениях.

Нам, конечно же, мало просто собрать все файлы архива воедино. Хочется его ещё и сжать, да покрепче. Для упаковки архивов в Linux принято использовать... нет, не RAR. И даже не ZIP - хотя команда

zip foo.zip foo

создаст из файла foo архив foo.zip, который с успехом можно будет распаковать давно ставшим кроссплатформенным стандартом ZIP'ом на компьютере под управлением любой операционной системы - Windows, MacOs и т. п. В Linux же чаще всего применяется сейчас утилита bzip2, реализующая очень качественный алгоритм упаковки. Как сказано в описании утилиты, "bzip2 compresses files using the Burrows-Wheeler block sorting text compression algorithm, and Huffman coding. Compression is generally considerably better than that achieved by more conventional LZ77/LZ78-based compressors, and approaches the performance of the PPM family of statistical compressors". Так оно и есть.

Чрезвычайно удобно то, что между bzip2 и tar перекинут незримый мостик. Задавая при сборке каталога в файл утилитой tar ключ -j, мы как раз и декларируем своё стремление одновременно со сборкой упаковывать его с применением bzip2. И файл пакуется! Вот почему, указывая его финальное имя после параметра -f, я приписал к нему расширения .tar.bz2. Такая форма записи сразу покажет мне впоследствии, что данный файл - сжатый архив tar. А добыть его обратно можно будет очень просто - директивой

tar -xjf etc.tar.bz2

где х - от extract, конечно же. Ещё одной удобной опцией рассматриваемой нами команды является -v, то есть verbose. При указании этой опции (блок директив будет выглядеть тогда как -cvjf) на экран по мере упаковки каждого из входящих в целевую директорию (и её подкаталоги) файлов будет выводиться соответствующая строчка. Это полезно для визуального контроля за процессом. Если же перед распаковкой архив хочется протестировать (или просто посмотреть - что там такое находится), имеет смысл указать в блоке директив опцию -t вместо -x.

Как видим, 17-Мбайтный архив сжался до двух с половиной "метров", то есть довольно-таки заметно. Чего и следовало ожидать - ведь в этой директории находятся текстовые файлы, главным образом. При упаковке директории домашней, в особенности заполненной картинками и музыкой, вряд ли стоит ожидать столь внушительного эффекта.

Другая важная опция tar, которую при создании Linux-архивов надо принимать во внимание, - p. Она позволяет сохранять в архиве не только сами файлы, но и сведения о правах доступа к ним, - так что после распаковки права окажутся в точности теми же, что и до архивации. Длинная опция (её следует записывать отдельно от блока однобуквенных директив) --same-owner заставит tar сберечь вдобавок и информацию о владельце каждого из сохраняемых файлов. О множестве других опций можно, понятное дело, узнать из страниц руководства по данной утилите.

И всё-таки, возвращаясь к проблеме архивации содержимого домашнего каталога (и вообще по-настоящему ценных для пользователя данных) скажу, что упаковка - сжатие - мне в данном случае представляется излишней. Хоть bzip2, под стать RAR, и позволяет извлекать информацию из "битых" архивов, лучше - на мой взгляд - хранить её в естественном виде, если имеется такая возможность. Вот если бы удалось просто взять и перекинуть все данные из домашней директории на CD-R или CD-RW, а после полной переустановки системы поместить их обратно, с сохранением всех прав доступа и владения!..

Отчего же нельзя? Всё возможно, если ваш ПК оснащён пишущим CD-приводом. Оснащён, правда ведь? Ну тогда за дело!

Самой главной командой будет для нас при записи компакт-диска утилита cdrecord. Надо учитывать, правда, что файловые системы CD (ISO 9660) и Linux (ext2) существенно различны, и простое копирование с носителя на носитель нам не подойдёт. Сперва надо будет преобразовать избранные данные в пригодный для записи вид. А в этом нам поможет утилита mkisofs - make ISO filesystem, как нетрудно расшифровать её наименование.

Итак: первое, что нам следует сделать, - это произвести на свет tar-сборку домашнего каталога. Я намеренно употребляю термин "сборка", а не "архив", чтобы подчеркнуть: сжимать информацию мы не будем, ради пущей её сохранности. Однако сборка всё же предпочтительнее записи на диск дерева каталогов. Стандарт ISO крайне чувствителен к сложностям организации файловой системы - длинным именам, некоторым последовательностям символов в названиях файлов и т. п. Поэтому проще будет упаковать пользовательский каталог tar'ом, задав опции сохранения всех прав и владений, после чего уже писать на CD один-единственный файл.

Благо что опций в этом случае придётся задавать минимум. А чтобы осознать, сколько при этом сбережётся энергии, полистайте страницы руководства mkisofs. Впечатляет.


Заполучив готовый iso-образ, пререйдём к записи архива на пустой CD. Поместите его в привод, и если вы впервые собираетесь заниматься этим под ОС Linux, установите для начала условный номер устройства в системе, на которое будет производиться запись. Сделать это можно, запустив cdrecord с опцией -scanbus: на экране будет отображён перечень всех доступных устройств. Важными для нас являются первые две разделённые запятой цифры, обозначающие рабочее устройство (в данном примере 0,0): эта информация понадобится прямо сейчас.


Не забудьте перейти в режим суперпользователя при записи CD! Создать iso-образ можно, разумеется, и от имени любого другого пользователя.


Запуск команды cdrecord приведёт к выводу на экран множества полезной информации (а если использовать опцию -v, то её будет ещё больше). У этой команды есть два абсолютно необходимых аргумента: параметр dev, задающий условный номер устройства на шине данных, и адрес файла образа. -eject в нашем примере позволяет выдвинуть лоток по окончании записи диска. На самом же деле опций можно задать множество - желающие могут с ними ознакомиться, как водится, на странице руководства по данной утилите.

Ну что же, цели определены, задачи поставлены, архивы - собраны. Теперь не страшно взять и поставить систему как полагается, с чистого листа. И заняться уже, наконец, изучением особенностей полноценной графической оболочки. А они есть, эти особенности! С удовольствием поговорю о них в следующий раз.