Наверх
Меню
Новости
Статьи
twitter
Software
7 февраля 2007
2507
  Знакомство с Linux. Часть 13. Подготовка системы к переустановке  
 
Ссылки на предыдущие статьи цикла

Если бы в нашем сериале о Linux принято было сопровождать каждую главу зазывными заголовками с претензией на художественность, нынешнюю, юбилейную тринадцатую, я с наслаждением поименовал бы так: "Собираем вещички". Речь ни в коем случае не пойдёт о приостановке изучения системы. Нет-нет! Просто, поработав со свежеустановленной поверх предыдущей версией Red Hat Linux 9, я пришёл к твёрдому выводу: надо мигрировать. Полноценно мигрировать на "девятку", а не ограничиваться модернизацией. Причина - в том, как реализована в новом дистрибутиве от Red Hat поддержка русского языка.

Здесь я допущу небольшое лирическое отступление. Сторонники российских (а также украинских, белорусских и т. п.) дистрибутивов Linux приводят множество аргументов в поддержку того, почему предпочитаемые ими системы хороши именно для местного пользователя. Аргументов, априори вовсе не очевидных. Ведь зачастую в качестве основы для таких продуктов берётся известный дистрибутив международного класса (тот же Red Hat), в нём решаются силами местных программистов все вплоть до мельчайших проблемы с локализацией, иногда добавляются ещё несколько пакетов - и новинка для внутреннего рынка готова. Соответственно, если в одном из пакетов исходного дистрибутива выявляется уязвимость, то полноценная "заплатка" для дочернего, локального варианта Linux появится, очевидно, с некоторым запозданием. Так что хотя с точки зрения удобства пользования местные версии Linux выигрывают у исходных англоязычных, к ним можно предъявить некоторые претензии в области надёжности и устойчивости к атакам. И лично мне этот аргумент виделся очень существенным - до самого последнего времени. До того, как я принялся модернизировать Red Hat Linux 7.3 до девятой версии. Конец лирического отступления.

Знакомство с Linux. Часть 13. Подготовка системы к переустановке

Как известно, большой проблемой русского Интернета - и вообще компьютеризации Руси - была и остаётся неразбериха с кодировками кириллицы. Я не буду сейчас вспоминать, что было раньше и что стало потом, благо литературы по теме имеется масса. Сформулирую основное: в Windows-системах безраздельно царствует кодировка cp1251, Linux же и *NIX, включая всевозможные версии *BSD, до сих пор оставались вотчиной старой доброй KOI8-R. За долгие годы сторонники свободного ПО прекрасно научились справляться с этим, разработав множество удобных утилит для перекодировки - а широкая популярность веб-сервера Apache привела к тому, что множество страниц Рунета хранятся на поддерживающих сайты компьютерах именно в KOI8. Однако времена меняются: именно компания Red Hat, начиная с восьмой версии своего дистрибутива, сделала в системе стандартом универсальную кодировку UTF8.

Универсальность - это великолепно. Когда UTF8 войдёт во всеобщий обиход, проблемы со "странными значками", "закорючками", "вопросиками" и "квадратиками" в сообщениях исчезнут без следа. В одной и той же системе закодированы все алфавиты мира, включая азиатские, — имеется даже проект по внедрению в стандарт UTF египетских иероглифов, благо знакомест хватает. Но вот какая тонкость: светлые времена, о которых с восторгом повествуют поборники UTF, пока не наступили. И когда наступят - неясно. Точнее, ясно: ровно тогда, когда эту систему кодирования поднимет на щит Microsoft. А пока компания Red Hat решила, что раз будущее всё равно наступит, то незачем ждать его сложа руки. Нужно взять - и приблизить. Всё равно подавляющее большинство пользователей продукта компании англоязычны, а для них что UTF, что ASCII - по большому счёту, разницы нет.

Но для нас - есть, и притом существенная. Что нужно для полноценной работы с компьютером, пользователь которого является носителем отличного от английского языка? Точнее - языка, где для записи информации употребляются буквы, отличные от базовых 26 английских? Такому пользователю важнее всего возможность создавать документы на родном языке, без проблем открывать и читать уже созданные такие документы, и, конечно, свободно переключаться между универсальной и местной клавиатурными раскладками. Простейшие требования, верно? В Windows никому и в голову не приходит, что тут могут возникать какие-либо сложности.

Знакомство с Linux. Часть 13. Подготовка системы к переустановке

Строго говоря, до настоящего времени у меня никаких проблем с кодировками при использовании Red Hat Linux не возникало. Русификация и консоли, и графического режима (особенно в оконном менеджере KDE) была уверенно реализована, хорошо описана и тоже воспринималась как нечто само собой разумеющееся. Вот в Red Hat Linux 5.0, помнится, с этим дело обстояло не так просто... Но воды с той поры утекло немало, и всё было бы замечательно, если бы не возникшая перед нами сейчас необходимость: перейти при модернизации системы с версии 7.3, где в качестве русской кодировки по умолчанию применялась KOI8-R, на девятую версию с её прогрессивной UTF.

Загвоздка же в том, что при апгрейде многое в системе остаётся прежним. В частности, если вы активно работали с русским текстом в консольных редакторах (или сохраняли лог-файлы ICQ-клиентов вроде licq в домашней директории), прочитать записанный в KOI8-R текст теперь будет трудновато. К тому же, помимо перехода к UTF, начиная с версии 8.0, Red Hat "обкатывает" на пользователях ещё одно новшество: совмещение двух популярнейших оконных менеджеров, KDE и Gnome. Переработанный кудесниками в красных шапках графический интерфейс Bluecurve является синтезом наиболее сильных сторон обоих конкурирующих продуктов. (Поскольку оба продукта - свободно распространяемые и с открытым кодом, становится возможным, как видим, и такое непредставимое в мире бизнеса явление, как их жизнеспособная контаминация). Побочной стороной этого слияния является то, что - как в случае моей домашней системы - никуда не девшиеся прежние настройки оконного менеджера (именно в части управления раскладкой клавиатуры) начинают конфликтовать с новыми.

Суммирую: после апгрейда Red Hat Linux 7.3 до версии 9 я столкнулся с достаточно серьёзными сложностями в работе, которых - проводи я нормальную установку системы - попросту не возникло бы. Поэтому на сей раз мы рассмотрим, каким образом осуществить полноценную миграцию на новую систему. И начнём с самого начала.

С самого начала, сразу после первой перезагрузки, последовавшей за апгрейдом, в системной консоли стали наблюдаться, скажем так, некоторые несуразности. А именно: раньше при старте системы отдельные сообщения о запуске её компонент отображались с использованием кириллицы (и разумеется. В KOI). Что-то вроде
    Запускается sendmail [ OK ]
Теперь же вместо каждой из букв кириллицы на экране отображалась "у-умляут" - судя по всему, вследствие того, что в наследство "модернизированной" системе с UTF достались некоторые утилиты, всё ещё пытающиеся организовать вывод в KOI. Тем не менее, с латиницей всё было в порядке, и после запуска X Window System я с облегчением увидел, что отображение кириллицы (в заголовках окон, названиях разделов и программ в меню запуска и т. п.) там работает. За исключением маленькой детали: отказало переключение с русской клавиатуры на английскую и обратно.

Знакомство с Linux. Часть 13. Подготовка системы к переустановке

Нет, соответствующая опция из Центра управления KDE никуда не делась. Вот только, судя по всему, при слиянии KDE с Gnome в Red Hat получили продукт, не полностью совместимый с предшествующими "полноценными" версиями этих графических оболочек. По крайней мере - в данной конкретной области, связанной с локализациями, и в особенности с локализациями приложений. К тому же, прочесть элементарный текстовый файл, набранный когда-то в консоли кириллицей в KOI8-R, я уже не мог ни при помощи less, ни с использованием vi или cat.

Строго говоря, ничего удивительного: при инсталляции система вовсе не обязана каждую имеющуюся на винчестере запись в KOI (будь то рабочий текстовый файл или стандартное сообщение в локализованной ранее программе) переводить в UTF. Хотя... Быть может, вариант безболезненного апгрейда будет осуществлён в одном из наших местных дистрибутивов, берущих за основу продукты Red Hat? А может, он уже осуществлён, просто мне об этом ничего не известно? Знаю пока только, что очень хочу добиться нормального обращения с кириллицей именно в Red Hat Linux 9, и сейчас вместе с вами этого таки добьюсь. По крайней мере, в пределах, необходимых для дальнейшей полноценной и безболезненной миграции на полный UTF.

Разумеется, я не первым столкнулся с подобной проблемой: переход на UTF Red Hat произвела ещё в полугодичной примерно давности версии 8.0. И в качестве одного из возможных рецептов действий в такой ситуации гуру предлагают отказ от перехода как такового - иными словами, возвращение к использованию KOI. "Даунгрейд" одной из компонент системы, если можно так выразиться. Дабы избежать, в частности, неприятных последствий "выборочной" замены KOI на UTF.

Знакомство с Linux. Часть 13. Подготовка системы к переустановке

И всё-таки я предпочту другой путь, что, кстати, имеет смысл и для всех начинающих: осуществить грамотную миграцию на UTF и работать отныне уже с ней. Потому что за универсальной кодировкой всё-таки будущее. Но чтобы к этому будущему приблизиться, сперва нужно хоть как-то привести в порядок текущий вид отображения символов в консоли. Многие операции, связанные с сохранением данных, предпочтительнее производить под непосредственным личным контролем - "ручками", как говорят всё те же гуру. Для пущей уверенности, что всё сделано правильно.

Итак, прежде всего справимся с пренеприятнейшими "умляутами", заполонившими вместо русских букв нашу консоль. За то, какой именно набор символов используется при выводе консольных сообщений, ответственны несколько переменных окружения, задающихся в файле /etc/sysconfig/i18n. Название файла, кстати, - весьма остроумное сокращение от слова "internationalization": 18 - это число букв между начальной i и конечной n.

Знакомство с Linux. Часть 13. Подготовка системы к переустановке

Параметр LANG определяет так называемую локаль (locale) - режим, в котором работает выводящий символы на экран драйвер консоли. Здесь, как и можно ожидать после апгрейда системы, установлено значение "ru_RU.UTF-8". Тем не менее, среди поддерживаемых (SUPPORTED) кодировок наличествует и ru_RU.koi8r. Однако, как можно убедиться, в случае системных сообщений "по-русски" это не помогает. Можно предположить, что корректно будет обрабатываться вывод символов в том случае, если их кодировка чётко указана - средствами производящего вывод приложения, скажем (текстового редактора или ещё какого-либо). А со стороны системных приложений, русификация которых не была обновлена по сравнению с предыдущей версией, такого сюрприза консоль явно не ожидает. Дело ещё и в том, что переменная SYSFONT указывает не на бывший ранее привычным консольный русифицированный фонт (скажем, Cyr_a8x16), а на новомодную UTF-новинку latarcyrheb-sun16.

Как можно судить по наименованию данного системного шрифта, ему по силам отображать одновременно символы латинского, арабского, кириллическего и еврейского алфавитов. (Тут, правда, возникает закономерный вопрос - будет ли автоматически меняться направление письма при переходе с кириллицы на арабский, скажем, но пока это нас интересует чисто академически). Однако при попытке отобразить средствами данного шрифта закодированный в KOI текст ничего путного на экране видно не будет. Дополнительную путаницу вносит установка таблицы перекодировки символов (Application Character Map, ACM) для перевода входного потока символов во внутреннюю кодировку ядра - Unicode: SYSFONTACM="utf8". В общем, первое, что я сделал, это избавился от пережитков прошлого в виде упоминания о кодировке KOI, упорядочил задание переменной SUPPORTED и убрал сомнительный параметр SYSFONTACM. В итоге на консоль вернулись русские буквы там, где их выводили системные приложения.

Знакомство с Linux. Часть 13. Подготовка системы к переустановке

Правда, с несистемными приложениями - а именно, банальными текстовыми файлами в кодировке KOI - всё было не так просто. Ни элементарная команда cat, ни less, more или vi не в состоянии были отобразить на консоли в сколько-нибудь пригодном для чтения виде их содержимое.

Знакомство с Linux. Часть 13. Подготовка системы к переустановке

Знакомство с Linux. Часть 13. Подготовка системы к переустановке

Больше того - при попытке просмотреть содержимое подмонтированных vfat-разделов вместо русских букв в названиях файлов снова запестрели вопросительные знаки. Однако с этой напастью справиться было несколько проще. Я ведь знал, что изначально для их отображения применялась кодировка KOI!

Файл /etc/fstab я незамедлительно подправил - учитывая, что выводить символы на экран мне теперь надо в UTF.

Знакомство с Linux. Часть 13. Подготовка системы к переустановке

Затем потребовалось (чтобы не перезагружаться лишний раз) отмонтировать Windows-разделы, после чего снова присоединить их с использованием нового /etc/fstab. Делается это серией команд
    umount /mnt/c
    umount /mnt/d
    mount -a
Обратите, кстати говоря, внимание: опции для монтирования внешних носителей (CD и DVD) также включают у меня указание на то, что записанные там с применением кириллицы имена файлов следует воспринимать как набранные изначально в Windows-кодировке. Сделано это потому, что под Linux я никогда не использую кириллицу в наименованиях файлов и каталогов, а Windows-диски, напротив, читаю часто (взять хотя бы цифровые приложения к компьютерным журналам). Так что опасности ошибиться нет. Но в принципе, с этой опцией надо обращаться осторожно - и уж во всяком случае постоянно помнить, что она включена и работает.

Следующим шагом, который я совершил по пути тотального перехода на универсальную кодировку, стал перевод текстовых кириллических файлов в UTF. У вас, если ваше знакомство с Linux ещё не вошло в стадию активного увлечения, наверняка не так уж много ценной информации содержится в таком виде. А для меня очень важно было сохранить свои ICQ-логи. Которые программа licq, входящая с некоторых пор в стандартный комплект поставки дистрибутивов от Red Hat, хранит в виде как раз простых текстовых файлов в базовой системной кодировке. Стало быть, они мне после апгрейда оказались недоступны.

Напомню, что в случае Linux хранить чувствительную информацию в виде открытого текста не столь опрометчиво, как под Windows: системные установки по умолчанию блокируют доступ к содержимому вашей домашней директории кого бы то ни было (за исключением суперпользователя, конечно). И поскольку текст хранится в KOI, в данном случае мне нужно было всего лишь перекодировать его из исходного вида в UTF. Что я и сделал посредством утилиты с незамысловатым наименованием recode. Подробности, как водится, доступны по команде man recode.

Знакомство с Linux. Часть 13. Подготовка системы к переустановке

Лог-файлы ICQ-клиента licq хранятся в подкаталоге .licq/history/ , и все они - я это знал точно - кодированы именно в KOI. Поэтому для того, чтобы архив сделался снова доступным, достаточно было команды
    recode koi8-r..utf-8 .licq/history/*
Точно таким же способом я вернул себе возможность читать ещё несколько файлов с кириллическим текстом. Между прочим, как выяснилось при изучении соответствующей документации, в комплект поставки Red Hat Linux 9 входит-таки просмотрщик текста, позволяющий хоть как-то отображать не читаемую иными способами кодировку KOI. Эта программа называется lv, и если теперь вернуть наш тестовый файл в исходное состояние командой
    recode utf-8..koi8-r test.txt
то ни less, ни more прочесть его содержимое по-прежнему не позволят, а вот lv вместо кириллицы отобразит для каждой русской буквы определённое латинское соответствие.

Знакомство с Linux. Часть 13. Подготовка системы к переустановке

Когда-то давным-давно именно так выглядели в Linux-консоли почтового сервера, не поддерживавшей кириллицы в принципе, приходившие в KOI письма... Ах, молодость, молодость...

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


  Источник: fcenter.ru
 



Поделиться с друзьями:


Другие новости по теме
 
Вы не авторизованный пользователь. Чтобы воспользоваться всеми возможностями сайта, зарегистрируйтесь.
 

Комментарии

Добавление комментария
Ваше имя
Ваш Email
Код Включите эту картинку для отображения кода безопасности
обновить код
Введите код