Linux и все, все, все... Статьи и колонки в LinuxFormat, 2006-2013

LinuxFormat #76 (февраль 2006)

В этой статье речь пойдет о семействе дистрибутивов Ubuntu, включающем, кроме эпонима, также Kubuntu и Edubuntu, а также несколько национально-специфических систем и сторонних разработок (среди которых недавно появилась разработка Google, Goobuntu).

Об Ubuntu и Kubuntu

Основатель этого семейства дистрибутивов – южноафриканец Марк Шаттлворт, один из разработчиков Debian и по совместительству – бывший глава бывшей Интернет-компании Thawte Consulting. Деятельность которой была столь успешна, что на закате эпохи dot-com'ов ее приобрела известная корпорация VeriSign за астрономическую сумму, сделавшую Марка весьма богатым человеком. После чего он повел себя не очень стандартным для акулы капитализма образом.

Что надлежит сделать порядочному человеку в случае нежданного богачества? Перво-наперво, «поделиться с пацанами». И каждый из бывших сотрудников Thawte Consulting получил премию – миллион рэндов (более US $100000). Во-вторых, следует осуществить голубую мечту своего детства. И Марк слетал в космос туристом, оказавшись в этом качестве вторым человеком в истории Земли. В-третьих, стоит подумать о тех, кому не повезло стать миллионерами. И Марк создает и финансирует несколько некоммерческих организаций – по развитию образования в Африке, помощи развивающимся странам, и так далее. И, наконец, вернуться к тому, с чего начинал – в данном случае в начале всех начал оказался Linux, на котором был построен бизнес компании Thawte. А посему Марк собирает команду для разработки собственного дистрибутива Linux. В основу которого, естественно, кладется Debian – собственно, Ubuntu и характеризуется как Debian с «человеческим лицом». Говорят, что само слово Ubuntu на одном из африканских языков означает нечто подобное нашему понятию гуманизм.

При создании дистрибутива была сразу четко определена его целевая аудитория. Сам Марк в интервью журналу Linuxformant на вопрос, для каких пользователей предназначен Ubuntu, отвечает, что Ubuntu ориентирован, с одной стороны, на тех, кто сам все знает и умеет, с другой – на тех, кто ничего о компьютерах не знает, знать не хочет, но готов положиться на знающих.

Забегая вперед, заметим, что представление об Ubuntu как о дистрибутиве для неспециалистов не далеко от истины – хотя ряд мелких недоработок (особенно в отношении локализации) не позволяет его пользователю обойтись совсем уж без знаний.

В двух словах, Ubuntu – это почти самый обычный Debian, использующий deb-формат пакетов и систему управления ими – apt, сохраняющий совместимость с огромным его пакетным репозиторием. Отличие от прародителя – во-первых, в том, что он комплектуется самыми свежими версиями пакетов. При этом разработчики декларируют полугодичный релиз-цикл для своего дистрибутива (и пока его придерживаются).

Вторая особенность Ubuntu – в том, что при инсталляции системы по умолчанию автоматически устанавливается и настраивается графическая среда GNOME. Но, поскольку это – лишь один из возможных пользовательских десктопов, немедленно был создан вариант дистрибутива, использующий в качестве рабочего окружения KDE. Который логично получил имя Kubuntu. Подчеркнем, что Ubuntu и Kubuntu – это одна и та же система, использующая общий репозиторий пакетов. И различия их проявляются только в комплектации инсталяционного CD или DVD. Третий же основной представитель семейства, Edubuntu – это Ubuntu, укомплектованный образовательными программами.

В Kubuntu (как и в Ubuntu) в качестве программы установки используется тот же Debian Installer, что и в последней (Sarge) версии материнского дистрибутива. Правда, несколько модифицированный. Если установка Debian выполняется в два этапа, разделенные рестартом машины (первый – разметка диска и установка базовых компонентов, второй – дополнительных пакетов и начальное конфигурирование), то вариант от Ubuntu – как бы в полтора: вся базовая установка и начальное конфигурирование совмещены в один этап, а после перезагрузки происходит только развертывание дополнительных пакетов (GNOME или KDE с соответствующими приложениями – для Ubuntu и Kubuntu, соответственно).

И еще одна важная особенность установщика Ubuntu: в ходе инсталляции по умолчанию не создается аккаунта суперпользователя, и в дальнейшем все действия по администрированию системы выполняются через программу sudo, sudoedit или штатными средствами GNOME или KDE – все они требуют для доступа к правам root ввода обычного пользовательского пароля. Правда, при установке в режиме эксперта root-аккаунт может быть создан – но в дальнейшем это повлечет некоторые сложности, так что начинающему пользователю лучше этого не делать.

Настройка доступа к репозиториям пакетов

По завершении установки пользователь получает в свое распоряжение почти готовую к использованию среду – локализованную (для Руси – локаль UTF8), с офисным пакетом (OpenOffice.org), коммуникационными, графическими и мультимедийными приложениями (таковыми выступают штатные средства GNOME или KDE). Но, к сожалению, именно «почти»: русификация нуждается в некоторой доработке, а использование мультимедийных приложений ограничено, по понятным лицензионным соображениям, только открытыми форматами (типа ogg). Исправление этих мелких и во многом вынужденных недоработок требует доустановки пакетов. И потому одно из первых, что потребуется начинающему пользователю – это освоение системы пакетого менеджмента Ubuntu. И здесь первый шаг – настройка доступа к репозиториям пакетов.

После обычной установки имеется доступ только к одному такому репозиторию – установочному CD или DVD. Но кое-какие компоненты можно получить только из репозиториев сетевых. Делается это с помощью программного комплекса apt.

Источники пакетов, получаемых через apt, описываются в специальном конфигурационном файле – /etc/apt/sources.list. После пользовательской установки по умолчанию он содержит строку вида

deb cdrom:[Kubuntu 5.10 _Breezy Badger_ – Release i386 (20051012)]/ breezy main restricted

плюс еще несколько закомментированных строк, распадающихся на отдельные секции. Формат каждой строки таков (рис. 1):

  • 

  • 

  • 

  • 

Нам они понадобятся все, включая и те, что являются как бы не совсем официальными (universe и multiverse). Так что достаточно просто снять комментарии со всех строк, начинающихся с deb и deb-src – не исключено, что некоторые пакеты придется строить из исходников.

Сделанного достаточно, чтобы доустанавливать пакеты из дистрибутива, не включенные в комплект установочного компакт-диска, а также получать все штатные обновления. За обновлениями же не вполне штатными (например, KDE последних версий) нужно следить на сайте http://www.kubuntu.org – там будут исчерпывающие указания по подключению дополнительных репозиториев.

Основы пакетного менеджмента

Теперь необходимо сначала сказать несколько слов о пакетах, используемых в Ubuntu и Kubuntu.

Cемейство дистрибутивов Ubuntu основывается на дистрибутиве Debian и наследует его формат пакетов (deb). Это – архивный файл, включающий скомпилированные исполняемые бинарники (и все необходимые им для работы компоненты), и так называемые управляющие файлы, в том числе описания зависимостей пакета.

В Debian и его клонах зависимости имеют несколько градаций: обязательные (depends), настоятельно рекомендуемые (recommends), рекомендуемые умеренно настойчиво (suggests). Первая градация – это обычные «жесткие» зависимости – пакеты, без которых установка и работа данного невозможна. Ну а настоятельно рекомендуемые и рекомендуемые просто – это две разновидности «мягких» зависимостей, добавляющих пакету те или иные необязательные, но полезные функции. Впрочем, таково субъективное мнение майнтайнера данного пакета – вполне возможно, что мнение пользователя будет иным.

В отношении средств управления пакетами в Kubuntu имеется богатый выбор. Однако в этой статье речь пойдет только о двух из них – dpkg и apt.

Команда dpkg сотоварищи

Команда dpkg – в ряде случаев простейший способ установить единичный пакет и сконфигурировать его, а также получить информацию о нем. Если нам необходимо установить единичный пакет, поступаем так:

$ sudo dpkg -i path2/packagename.deb

и дело в шляпе – через считанные мгновения пакет packagename.deb будет установлен.

В случае нарушения зависимостей dpkg выдаст сообщение об ошибке с полным перечнем того, какие пакеты нужно установить для ее устранения (в списке будут перечислены только обязательные зависимости). И достаточно все необходимые пакеты поместить в командную строку для того, чтобы они были установлены единой операцией.

Обратная процедура – удаление ненужных пакетов. Это делается двояко: команда

$ sudo dpkg -r packagename

удалит пакет, но сохранит настроечные его файлы, а команда

$ sudo dpkg -P packagename

произведет полную очистку системы от компонентов пакета. Правда, только если они не являются зависимостями других пакетов – в этом случае последует сообщение о невозможности удаления пакета и будет выведен список зависимостей, этому препятствующих.

Вообще-то dpkg – это целое семейство команд, включающее, кроме себя самой, еще несколько: dpkg-deb, dpkg-query и так далее. Один из представителей этого семейства, который так и называется - dpkg-reconfigure, служит цели переконфигурирования уже установленных пакетов. Делается это так:

$ sudo dpkg-reconfigure packagename

После этого вызывается диалоговая программа конфигурации – debconf, и ответы на серию более или менее тривиальных вопросов позволяют добиться желаемого результата.

Инструментарий apt

Набор apt (Advanced Packaging Tools) – это программный комплекс, охватывающий все стороны управления пакетами. Он включает в себя почти десяток команд, тесно переплетающихся друг с другом. Так, назначение команды apt-cache – в получении информации о пакетах, причем не только установленных на локальной машине, но и находящихся в сетевых репозиториях. Сведения эти берутся из локальной базы данных, создаваемой во время инсталляции системы, и в дальнейшем обновляемой с помощью apt-get:

$ sudo apt-get update

При этом устанавливается соединение со всеми репозиториями, перечисленными в файле /etc/apt/sources.list, и локальный кэш пакетов приводится в соответствие с их текущим состоянием.

Теперь можно произвести тотальное обновление системы:

$ sudo apt-get upgrade

При этом будет проведено сравнение версий установленных пакетов с обновленным их кэшем, выявит все, нуждающиеся в обновлении, скачает соовтетствующие версии из сети и заменит ими устаревшие пакеты. В случае, если новые версии повлекут за собой и новые зависимости – они также будут скачаны и установлены. Но перед этим будет выведен полный список пакетов, нуждающихся в обновлении, объем, который предстоит скачать, и потребный объем дискового пространства.

В некоторых случаях apt-get upgrade не сможет выполнить обновление каких-либо пакетов, о чем честно и сообщит. Причины этому могут быть разные – например, конфликт новых зависимостей пакетов. На сей случай имеется более радикальное средство – dist-upgrade. Именно к нему следует прибегнуть и при обновлении старой версии дистрибутива до нового релиза:

$ sudo apt-get dist-upgrade

Эта команда просто тотально перепишет все наличные пакеты их обновленными версиями, одновременно разрешая и новые их зависимости (вплоть до удаления конфликтующих пакетов).

Вот теперь можно взяться и за отдельные пакеты. Дистрибутивные deb-пакеты вовсе не совпадают с пакетами авторскими – они намного более дробные. Например, каждый из авторских пакетов KDE, типа kdenetworks или kdegraphics, делится на множество мелких монофункциональных deb-пакетов. И тут на помощь придет команда apt-cache search, которая в качестве аргумента воспринимает ключевое слово. И в ответ на команду вида

$ apt-cache search ftp

последует список всех пакетов, в описании которых фигурирует ключевое слово ftp.

Выявив нужный пакет, следует обратиться к команде apt-get install. посредством которой будет он благополучно скачан и установлен – со всеми обязательными (depends) зависимостями. Перед этим будет опять-таки выведен список подлежащих установке пакетов, объем скачиваемого материала и изменения в занятом дисковом пространстве. А также будет дан список пакетов, связанных с данным разными типами «мягких» зависимостей – пользователю останется только решить, нужны ли они ему.

Инструмент apt-get выполняет и удаление пакетов:

$ apt-get remove packagname

При этом настроечные файлы сохраняются – для их удаления требуется опция --purge, которая выполнит полную очистку системы от всех компонентов пакета.

Очень ценна опция -i, обеспечивающая инверсию действия операторов. То есть команда

$ sudo apt-get remove packagname -i

установит пакет packagename, а команда

$ sudo apt-get install packagname -i

напротив, удалит его. Что очень полезно при экспериментировании с большим количеством пакетов.

Если нужно собрать из исходников много пакетов, пересобрать систему целиком или требуется компиляция с какими-либо особыми условиями, следует прибегнуть к инструменту – apt-build. Это – отдельный пакет, который устанавливается обычными образом, и в ходе установки настраивается. Настройки включают: выбор степени оптимизации, облегченной (соответствующая флагу gcc -O1), средней (флаг -O2) или усиленной (-O3), указание дополнительных флагов gcc, если в них есть необходимость, опций для команды make, выбор процессора (Pentium, Pentium-4 и так далее). Если же для отдельных программ условия компиляции нужно изменить – apt-build можно переконфигурировать обычным образом:

$ sudo dpkg-reconfigure apt-build

Команда apt-build включает ряд операторов, таких, как update – обновление списка доступных пакетов, upgrade – сборка обновленных пакетов, world – полная пересборка всей системы. То есть инструмент apt-build, не смотря на сугубо пакетную природу использующих его дистрибутивов, имеет ничуть не меньшие возможности по индивидуалированной компиляции, чем система портов FreeBSD или аналогичные средства Source Based дистрибутивов Linux.

Kubuntu по русски

Дистрибутив, претендующий на «гуманное отношение к пользователям», должен в обязательно порядке уметь разговаривать с ними на родном их языке. в том числе и русском. И тут Ubuntu и Kubuntu в первом приближении выглядят терпимо: если в ходе установки выбрать русский язык и соответствующую ему страну, то есть Россию, то по завершении процесса мы получаем более-менее русифицированные Иксы с прогрессивной локалью UTF-8.

А вот в консоли дело обстоит из рук вон плохо: шрифт для вывода кириллических символов при старте машины автоматически не подгружается, а попытка ввести русские буквы приводит к появлению на экране вполне нечленораздельной абракадабры. Конечно, Kubuntu не ориентирован на использование в текстовом режиме. Однако и терпеть в консоли такое безобразие тоже не хочется. Так что давайте уж доведем до ума русификацию консоли.

Процедура эта достаточно просто выполняется вручную. Во-первых, обеспечиваем загрузку шрифта со встроенной таблицей sfm (screen font map): вызываем для редактирования необходимый конфиг

$ sudoedit /etc/console-tools/config

и вносим в него строки:

SCREEN_FONT_vc1=LatArCyrHeb-16 SCREEN_FONT_vc2=LatArCyrHeb-16 SCREEN_FONT_vc3=LatArCyrHeb-16 SCREEN_FONT_vc4=LatArCyrHeb-16 SCREEN_FONT_vc5=LatArCyrHeb-16 SCREEN_FONT_vc6=LatArCyrHeb-16

Загружаемый таким образом шрифт выглядит весьма убого, но его можно заменить шрифтами либо из пакета terminus-fonts, либо из коллекции с http://www.posix.ru/download.shtml (последние нужно поместить в каталог /usr/share/consolefonts/ вручную).

Во-вторых, устанавливаем юникодовскую раскладку клавиатуры (ru-utf, скачать ее можно здесь же: http://www.posix.ru/download.shtml):

$ sudo cp path2/ru-utf.kmap.gz /etc/console/boottime.kmap.gz

И после перезагрузки машины убеждаемся, что обрели способность к вводу символов кириллицы. Раскладка – для win-маркированных клавиш (то есть с нормальным расположением знаков препинания), переключение латиница/кириллица – по правому

Есть и другой способ русификации, более соответствующий Debian Way – установка и конфигурирование пакета console-cyrillic, что предлагается читателю в качестве самостоятельного упражнения.

Вторая проблема из числа локально зависимых, требующая решения, – проверка орфографии. С этим также некоторая напряженка. По умолчанию в этом качестве использует aspell – что естественно при юникодной локали (так как ispell с юникодом до сих пор не работает). Имеется и пакет с русским словарем для него, aspell-ru – но только для архитектуры i386. Для AMD64 же можно предложить два решения.

Первое – через http://rpmfind.net/ отыскать более-менее свежий rpm-пакет для архитектуры AMD64, установить alien – трансформатор пакетов из одного формата в другой и его посредством преобразовать rpm в deb:

$ fakeroot alien aspell-ru-0.99f7-2.x86_64.rpm

Каковой и устанавливается обычным образом:

$ sudo dpkg -i alien aspell-ru-0.99f7-2.x86_64.deb

Второе же решение – просто автоматом построить соответствующий deb-пакет посредством apt-build, после чего остается подключить его к любимому текстовому редактору или просто запускать из командной строки.

Борьба за мультимедиа

Все сказанное ранее относилось к любому из дистрибутивов семейства Ubuntu. Теперь же речь пойдет о специфике Kubuntu. В нем для проигрывания аудио штатно предназначена программа amaroK, а за воспроизведение видео отвечает универсальный медиаплейер Kaffeine. Сразу после установки, что называется, «из коробки», оба они в состоянии только запускать звуковые ogg-файлы, ни mp3, ни Real Audio их восприятию недоступны, как, впрочем, даже и банальные avi'шки домашнего производства.

Столь нехорошее поведение объясняется отсутствием движков и кодеков. И связано с лицензионными соображениями. Дело в том, что алгоритмы, на которых основываются программы воспроизводства аудио/видео (например, mpeg-кодирования) запатентованы в тех странах, законы которых признают патенты на алгоритмы (или, скажем, законы природы). И майнтайнеры дистрибутивов, ориентированных на международное распространение (а разработчики Ubuntu/Kubuntu именно к тому и стремятся), вынуждены с этим считаться.

Благо законы нашей Родины, вопреки Салтыкову-Щедрину, в такой глупости до сих пор замечены не были, и мы можем слушать музыку или смотреть кино, не чувствуя себя интеллектуальными преступниками. Остается только обеспечить свое право возможностью его использовать.

Для чего нам и потребуется устанавливать эти самые кодеки/движки. Возникает вопрос – какие? Для ответа придется прибегнуть к методу ползучего эмпиризма (рис. 2).

Сначала займемся звуком, воспроизводимом посредством amaroK. Посредством

$ apt-cache search amarok

смотрим, какие движки (engine) к нему можно подключить в принципе. Оказывается, следующие:

amarok-gstreamer – GStreamer engine for the amaroK audio player amarok-arts – aRts engine for the amaroK audio player amarok-engines – output engines for the amaroK audio player amarok-xine – xine engine for the amaroK audio player

Не буду тянуть кота за хвост – я остановился на варианте amarok-xine, дополненном пакетом akode-mpeg – ведь mpeg потребуется в любом случае. После чего amaroK начинает нормально играть не только mp3 и Real Audio, но и, в качестве бесплатного приложения, – классово чуждый WMA. Правда, Kaffeine – категорически отказывается что либо, кроме ogg-файлов – но все-таки основное его назначение – крутить видео. А этого он пока тоже делать не хочет.

Изучение вывода команды

$ apt-cache search kaffeine

приводит к заключению, что нужно установить gstreamer0.8-mpeg2dec – после этого начинается показ фильмов, содранных с VideoCD – но без звука. Ставлю gstreamer0.8-mad – после этого в них появляется звук. Но мои домотканные avi'шки по прежнему не прокручиваются. Последняя надежда – устанавливаю gstreamer0.8-ffmpeg. Теперь, наконец, начинают крутиться и они, так что эксприменты можно прекратить со спокойной душой.

LinuxFormat, #78 (апрель 2006)

Традиционно «толстые» компьютерные журналы разделяются на две части: блок новостей и, так сказать, «тело» журнала – собственно материалы номера. Оправдана ли такая организация в век тотальной интернетизации? В век, когда все, имеющие хоть какое-то подключение к Сети, получают интересующие их последние известия из онлайновых источников, новостные разделы даже компьютерных еженедельников выглядят сборником анекдотов с бородой Карла Маркса. Что же тогда говорить о «новостях» ежемесячников?

Так что же, ликвидировать новостные блоки? Отнюдь – это было бы политически неправильным. Увы – изрядная часть населения постсоветских пространств лишена прелестей Интернета, и Печатное Слово, пусть несколько устаревшее (да и доставленное, силами российской почты, с запозданием), для нее – единственный источник информации. А потому предлагается компромиссный вариант: заменить сборники анек… пардон, новостей – аналитическими их обзорами. Которые, давая достаточно сведений читателям, не имеющим подключения к Сети, в то же время не вызывали бы раздражения своей «бородатостью» у тех, кто таковое имеет. А в идеале – были бы просто интересны сами по себе. Конечно, составление таких обзоров – дело нелегкое, но оправдается повышением читательского внимания.

Теперь об основной части – статьях. Журнал, рассчитывающий на самоокупаемость (а в идеале – и на принесение прибыли) обязан ориентироваться на самые широкие пользовательские массы И потому должен содержать материалы нескольких градаций: для совсем начинающих, для «действующих» пользователей, и для тех, кто ставит своей задачей углубленное изучение каких-либо частных вопросов. Хорошо это или плохо – обсуждать не будем, такое «смешение жанров» на данном этапе развития Linux-прессы является необходимостью. Как показала трагическая кончина журнала «СУБД» (да и безрадостная судьба аккумулировавших его «Открытых систем»), специализированное издание «для профи» пока не имеет шансов выжить на постсоветском пространстве. С другой стороны, ориентация издания на «чайников» чревата потерей интереса к нему, как только «чайники» таковыми быть перестанут (а с помощью хорошего журнала это произойдет очень быстро).

Какой видится компоновка материалов? Возможны варианты: по степени «продвинутости» предполагаемого читателя, по тематике, в том числе и с выделением некоего центрального материала и его «системного окружения». Впрочем, я – категорический противник «темы номера», что приемлемо для еженедельника, но для ежемесячного издания смертельно: ведь если читателю не интересна именно эта тема номера, он на целый месяц лишается возможности что-либо почерпнуть из любимого журнала.

Формат большинства журналов общего назначения предполагает преимущественно двух- или, реже, четырехполосные статьи, что для глубокого изложения многих животрепещущих проблем явно недостаточно. Конечно, проблема эта для периодических изданий не решаема в принципе: увеличение объема статей повлечет за собой сужение тематики номера и риск утраты читательских симпатий. Однако некий компромисс тут возможен – в виде пролонгированных из номера в номер тематических циклов.

Для журнала тематики UNIX и Linux очень существенен общий дизайн – и здесь положение, в большинстве случаев, не удовлетворительное. Многоколоночная верстка, пришедшая из мира рекламно-развлекательной периодики, и терпимая в периодике, так сказать, литературно-повествовательной, оказывается проклятием в изданиях технического профиля. В нашем случае это относится в первую голову к командам и листингам. Писать без них серьезно про Linux и UNIX – это все равно, что писать про музыку без нот, или про живопись – без репродукций. Но – увы – длинные команды или содержимое конфигурационных файлов вписывается в облик страницы традиционного современного журнала ничуть не лучше, чем «парень в джинсах и кожаной куртке» – в интерьер ресторана для новорусского истеблишмента.

Я прекрасно понимаю, что общий дизайн издания определяется множеством привходящих факторов (в том числе и политических). Но и тут возможны варианты. Например, давать необходимые команды и листинги «внеформатными» врезками. Или – сделать онлайновое дополнение к журналу, которое содержало бы именно ту часть статей, которая подлежит использованию методом Cut&Paste. Такое дополнение, не дублируя содержание основного материала, будет способствовать его практическому использованию.

Second Open Source Forum Russia

LinuxFormat #81 (июль 2006)

Общекомпьютерные мероприятия, типа великих выставок современности, долгое время не баловали своим вниманием тематику Linux и Open Source. Правда, во времена почти былинные существовала ежегодная выставка UNIX Expo, которая, естественно, не могла пройти мимо Linux'а – именно на одной из этих выставок я приобретал свои первые дистрибутивы. Однако времена те канули в Лету вместе с дешевым долларом приснопамятным августом 1998 года.

Тем более неожиданным оказался всплеск выставочной активности фирм и организаций, связанных с Linux и Open Source, случившийся в прошлом, 2005, году, когда с апреля по сентябрь прошло сразу три мероприятия этой тематики – Open Source Forum Russia, LinuxWorld Russia и Linuxland на Софтуле-2005, в рамках которых, кромес собственно выставок, функционировали и конференции с докладами, в том числе и вполне академического типа. Массовость и представительность этих мерпориятий всяляли надежду, что они станут началом доброй традиции. И вдвойне радостно, что надежда эта оправдалась.

Первой ласточкой в текущем году, как и в году минувшем, стал Второй Российский Форум по Открытому коду (Second Open Source Forum Russia), проводившийся в рамках международной IT-выставки Interop, которая и сама по себе заслуживает нескольких слов.

Базой для проведения мероприятия выступил Международный выставочный центр «Крокус Экспо», расположенный на 66 километре МКАД – на внешней ее стороне. Что само по себе и не страшно. Тем более, что обещание выставочного транспорта от метро Тушинской и Планерной было выполнено – по крайней мере, в первом случае могу это засвидетельствовать лично. Однако добраться до места назначения оказалось задачей не вполне тривиальной: въезд на МКАД (и, в обратную сторону, съезд с нее), построенный во времена развитого социализма, на современные транспортные потоки отнюдь не расчитан. Сам по себе выставочный комплекс заслуживает только добрых слов. В частности и потому, что под сводами его в те дни удручающей жары царила прохлада. Да и выствочные площади ьыли организованы удобно и просторно.

Правда, собственно выставка к Open Source имела мало отношения. На ней не были представлены ни фирмы – майнтайнеры дистрибутивов, ни разработчики какого-либо открытого софта. Глубокое траление выставочных стендов позволило выявить в них лишь два классово близких компонента.

Первым был стенд российского представительства печально прославившейся в последние годы фирмы SCO. Которая, правда, не все свои силы тратила на судебные тяжбы, а еще и разрабатывала собственную версию UNIX – SCO OpenServer. Демо-версия которой, во искупление грехов, и предлагалась к свободной раздаче.

Вторым порадовавшим моментом был стенд журнала «Системный администратор», с традиционно обширным набором номеров – от старых, давно ставших библиографической редкостью, до последнего, июньского.

Собственно Second Open Source Forum Russia, проходивший 22 июня, собрал весьма представительный сомн докладчиков. В их числе были – и знаменитый Йон мэддог Холл (Jon maddog Hall), исполнительный директор Linux International, рассказывавший о распространении Linux в мире, и Ян Мердок (Ian Murdock), создатель дистрибутива Debian и первый лидер одноименного проекта, говоривший об соотношении открытых исходников, открытых стандартов и о том, как они влияют на окружающий мир. Содержанием доклада Азы Доцлера (Asa Dotzler) – одного из учредителей проектов Mozilla и Firefox, – был рассказ о том, как Firefox превратился в майнстрим современного развития WWW. Зив Сураски (Zeev Suraski), один из создателей PHP, поведал об интегрирующих возможностях, заложенных в последенй версии этого языка сценариев...

Надо отметить, что тема Linux и Open Source рассматривалась не только на специализированном форуме. Немалое внимание ей было уделено и в программе презентаций на стенде IBM, раворачивавшейся на протяжении 22 и 23 июня. Где, помимо ее собственных представителей, выступили докладчики от фирм Altlinux, ASPLinux, Novell, затрагивая вопросы безопасности, использования Linux в корпоративной среде, в настольных и мобильных системах, и многие другие.

LinuxFormat #82 (август 2006)

Марк Шаттлворт (Mark Shuttleworth) – один из немногих разработчиков Linux, известный за пределами мира Open Source. Во-первых, его знают как удачливого Интернет-предпринимателя, разбогатевшего на гребне волны dot-com'ов. Во-вторых, он стал вторым в истории Земли космическим туристом. И в-третьих, Марк – учредитель ряда фондов помощи слабо развитым странам, организаций создания образовательных программ в странах «Третьего мира» и тому подобных мероприятий.

Однако в мире Open Source Марк известен, разумеется, не этим. Здесь его знают как разработчика Debian – в прошлом, и как организатора разработки семейства дистрибутивов Ubuntu – в настоящем. В этом своем качестве он возглавляет фирму Canonical – именно она осуществляет финансирование разработки всего семейства, обеспечивает распространение дистрибутива и его коммерческую поддержку, а также ведет прочую организационную работу.

Надо сказать, что дистрибутивы семейства Ubuntu (кроме собственно Ubuntu, в его состав входят также Kubuntu, Xubuntu, Nubuntu и Edubuntu) за короткое время снискали себе немалую популярность. В частности, и потому, что бесплатно рассылаются по всему миру, в том числе – даже в нашу страну. В результате чего в России сложилось достаточно большое и весьма активное сообщество пользователей Ubuntu.

Поэтому известие о визите Шаттлворта в Россию (Москву и Петербург), проходившем 15-16 июня, заинтересовало в основном широкие массы узкого круга, связанного с UNIX, Linux и Open Source. Тем более, что в программу посещения обоих городов входила встреча с теми, кто эти круги представляет – московскими пользователями Ubuntu и Linux вообще, и с Петербургской LUG.

Московская встреча состоялась 15 июня в Институте философии РАН и организована была, насколько я знаю, фирмой Altlinux. Однако на ней я не присутствовал, и потому сказать ничего не могу. А вот на питерской – побывать довелось, о чем и рапортую.

Встреча с Петербургской LUG 16 июня была подготовлена фирмой Линуксцентр и учебным центром «Феникс». В зале последнего, расположенном на территории Географического факультета Санкт-Петербургского Университета, она и происходила. Программа мероприятия включала три пункта: выступление Марка, ответы на вопросы участников и – ну конечно же, какая встреча юниксоидов обойдется без пива? – нечто вроде фуршета.

Теоретически для участия во встрече требовалась предварительная регистрация. Однако на практике, к чести организаторов, дело оказалось гораздо проще: насколько я мог наблюдать, вход был свободный, никто ни с какими списками не сверялся, и в итоге в зале оказались все, того пожелавшие.

Надо отметить хорошее техническое обеспечение встречи. Аппаратура «Феникса» позволила выполнить аудио- и звукозапись всей встречи – не только выступления, но и впорсов, в том числе и с места. Именно обработка аудиозапсис (смею надеяться, литературная) легла в основу всего нижеследующего материала – в связи с чем выражаю свою признательность организаторам встречи.

Выступление

Выступление Марка осуществлялось на английском языке – он начал его заявлением, что по русски говорит плохо (хотя, по агентурным данным, делает это совершенно без акцента – да и сказанная по русски вводная фраза это подтверждала). Однако перевод выступления обеспечивал Дмитрий Дмитриев из компании Linux Ink, известный своими работами по русификации Red Hat/Fedora и разработкой русской версии Scientific Linux. Так что суть речи Марка была доступна даже тем, кто, подобно вашему покорному слуге, английский на слух воспринимает с трудом.

Для начала Марк рассказал историю своего приобщения к Linux, ставшую уже в анналах Open Source почти столь же хрестоматийной, как история про принтер Ричарда Столлмена или про терминальную программу Линуса Торвальдса. Один приятель дал Марку кучу дискет с дистрибутивом Slackware и шесть упаковок пива, сказав, что это – все, что нужно для освоения Linux. Правда, существует версия, упаковка была одна – с шестью бутылками. Однако я более склонен доверять переводу Дмитрия. Действительно, говоря по русски, без поллитры с Linux'ом тогда, лет десять назад, разобраться было проблематично. Так что вряд ли Марк в этом процессе обошелся даже шестью исходными упаковками...

Далее последовал рассказ о том, как зародилась идея дистрибутива Ubuntu, и об особенностях процесса его разработки. Здесь Марк подчеркнул, что одной из целей дистрибутива было – достижение гармонии между стабильностью и актуальностью включенного в состав софта. Первая задача достигается долговременной поддержкой стабильных релизов, выходящих через определенные промежутки времени (примерно полугодичные, хотя подготовка текущего релиза несколько затянулась), и на протяжении длительного (трех- или пятигодичного) периода пользующихся поддержкой. Вторая же задача осуществима за счет регулярных промежуточных обновлений, предназначенных для пользователей, желающих работать с самым современным софтом.

Затем в выступлении прозвучала очень интересная мысль. Мы, дистростроители, сказал, Марк, часто забываем, что наша роль меньше, чем роль тех ребят, которые собственно и разрабатывают те пакеты, которые включаются в дистрибутивы. И дистростроитель должны уважать их работу – в том числе и с помощью сообщений об ошибках, извещения о новых возможностях, включаемых в эти продукты майнтайнерами дистрибутивов, и тому подобными способами.

Логическим продолжением этой мысли было высказывание об аналогичных горизонтальных связях с другими дистростроителями. В первую очередь речь зашла, конечно, о взаимоотношениях с разработчиками Debian – материнской. по отношению к Ubuntu, системы. Но не отвергается и сотрудничество с иными майнтайнерами, такими, как команда разработчиков Fedora, с целью обмена модификациями ядра и пакетов.

Однако и тут Марк подчеркнул, что связи, так сказать, вертикальные – с разработчиками крупных программных пакетов, таких, как Gnome, KDE, Apache, MySQL, Postgress, и многие, многие другие – являются более важными. Потому что в конечном счете именно их работа обеспечивает успех или неуспех любого дистрибутива.

В этом контексте прозвучал и ответ на вопрос, который меня интересовал с первого дня знакомства с Ubuntu: почему для титульного дистрибутива семейства, ориентированного, в том числе, и на начинающего пользователя, в качестве пользовательского окружения был выбран Gnome, хотя, казалось бы, KDE справляется с этой ролью как минимум не хуже. Марк объяснил сделанный выбор тем, что в момент создания Ubuntu Gnome был более простой в использовании средой, нежели KDE. Когда же разработчики KDE, оценив концепцию дистрибутива, предложили вариант со своим десктопом, – родился Kubuntu.

Зашла речь, конечно, и о бизнес-модели, призванной сделать разработку дистрибутива коммерчески выгодной. Здесь интересен следующий момент: вместо создания единой централизованной компании фирма Canonocal, обеспечивающая финансирование разработки Ubuntu и обеспечение его поддержки, привлекает к сотрудничеству распределенные фирмы из разных стран – в настоящее время их более 300, – которые и осуществляют регионально-ориентированную поддержку.

Маленькое отступление: как известно, Ubuntu оказался очень продуктивным клоно-породителем. Помимо всего прочего, от него происходит несколько испанских вариантов дистрибутива, ориентированных на использование в провициальной администрации этой страны; создается впечатление, что скоро в Испании каждая провинция будет иметь свой вариант Ubuntu. Тонкий намек: не пойти ли и нашей стране по этому пути? В этом случае востребованной окажутся и услуги фирм, способных оказать квалифицированную поддержку...

Наконец, речь дошла и до схемы разработки открытого софта вообще и дистрибутива Ubuntu в особенности: о механизмах контроля версий и веток исходного кода, о методах совместной работы над документацией и ее переводами на разные языки – например, на санскрит (да, товарищи, в Ubuntu предусмотрена и такая локаль). Что, как было убедительно продемонстрировано, действительно, оказывается нынче ключевым моментом для любого проекта Open Source – как с технологической стороны, так и со стороны, если так можно выразиться, социальной. Впрочем, для открытых исходников эти аспекты оказываются связанными практически неразрывно – и это тоже прозвучало в выступлении Марка.

Действительно, ведь сам принцип разработки открытых исходников базируется на вовлечении в процесс максимально широкого круга лиц, к таковой в принципе способных – и это одна сторона вопроса. Другая же, оборотная, выливается в проблему эффективности контроля над изменениями, которая может обеспечить целостность системы разработки и защиту ее от повреждения некорректно написанными фрагментами кода. То есть, попросту говоря, все сводится к тому, чтобы система была «дуракоустойчивой» – и при этом чтоб никто из разработчиков не ушел обиженным...

Вопросы разработки тесно связаны с вопросами обучения. И в планы Canonical входит создание центров обучения, тестирования и сертификации специалистов, в том числе и в России.

Последняя часть доклада, как и положено, была посвящена планам на будущее, то есть разработке следующего релиза, носящего имя Edgy Eft, выход которого запланирован на ноябрь.

Вопросы и ответы

По окончании выступления последовали многочисленные вопросы, на которые давались весьма обстоятельные ответы. Приведу их здесь, поскольку они по содержанию могут составить предмет весьма развернутого интервью. Так сказать, в коллективном исполнении.

Вопрос: Мы видели очень интересный сервис для переводчиков, но он был весь на английском языке. Почему бы не сделать его мультиязычным? А то получается, что сапожники без сапог.

Ответ: Мы решили, что сам интерфейс не нужно переводить. Потому что очень часто подключаются Но некоторые части этой технологии имеет смысл локализовать. Например, это связано с обращениями по поддержке.

Вопрос: Многие компании сейчас завоевывают мир простыми средствами разработки. На сегодняшний день под Linux нет простых средств разработки. Каково Ваше видение простых интерфейсов разработчика?

Ответ: Разработчики Linux пошли довольно трудной дорогой – заново изобрести велосипед. То есть установить новые правила разработки, правила открытого и свободного программного обеспечения. Мы, конечно, не можем рассчитывать на поддержку и помощь со стороны тех людей, которых привлекают легкие правила. Если Вы хотите добиться изменения ситуации, Вы должны убедить сообщество, что такие вещи, как хорошая документация, красивый дизайн, простота использования – это важные и нужные вещи. Я не думаю, что многое из того, что используется сейчас в мире коммерческой разработки программного обеспечения будет портировано под Linux. В первую очередь мы увидим перенос серверных приложений и баз данных, таких, как Oracle, потому что на них есть реальный спрос. Десктопные же приложения, например, Photoshop, имеют под Linux свои аналоги, например, Gimp, и необходимости в их переносе нет. В любом случае, не следует думать, что кто-то это сделает за Вас.

Вопрос: я читал блог разработчика ядра Red Hat, который сказал, что у них очень много жалоб на то, что это работает в Ubuntu, но не работает в Fedora. Он сравнил ядра этих дистрибутивов, чтобы посмотреть на различия, и обнаружил в ядре Ubuntu много мелких дополнений, которые не были включены в главную ветку разработки ядра.

Ответ: ядро Ubuntu публикуется на сайте kernel.org, так что для разработчиков ядра очень легко переносить из него все дополнения в главную ветку. Как правило, эти исправления переходят из версии в версию, но не всегда добираются до новых версий. Бывают, конечно, и случаи, что разработчик торопится и просто забывает переслать свои исправления в главную ветку.

Вопрос: Можете ли Вы что-нибудь сказать относительно планов портирования Ubuntu на платформу Sparc?

Ответ: Долгое время существовало сообщество разработчиков вокруг портирования Linux на платформу Sparc, но оно не имело официальной поддержки. Однако многие пользователи хотели иметь Linux для Sparc. Так что мы сначала работали с этим сообществом, потом вышли на разработчиков собственно платформы. И теперь мы надеемся в скором времени включить в список поддерживаемых платформ Ubuntu.

Вопрос: В настоящее время многие крупные компании, в первую очередь Microsoft, стараются завоевывать умы молодежи своими проектами по образованию, стажировке, трудоустройству. Если у Canonical что-нибудь подобное или будет ли?

Ответ: Мне кажется, что такими вещами занимаются сообщества пользователей Linux вообще. Мы тоже считаем, что очень важно устанавливать контакты с пользователями. Но для меня самое главное, чтобы контакты происходили с людьми, которые что-то понимают в этом (смех в зале). Я думаю, что люди, сидящие в этом зале, имеют гораздо большее влияние на развитие IT, чем просто некая масса пользователей. Мы отдаем себе отчет, что начинаем с очень маленького сообщества, но это – очень образованные люди и очень эффективные.

Вопрос: Планируете ли Вы включать в релизы Ubuntu программное обеспечение, которое сделает его Enterprise Ready?

Ответ: В текущие релизы включаются программы, которые люди используют в первую очередь – почта, Интернет, связка Linux с Apache и базами данных. В частности, программа установки Ubuntu предусматривает инсталляцию готового Интернет-сервера. Тяжелые сервера приложений будут включаться в дистрибутив только в том случае, если это будет востребовано сообществом. Сообщество пока не нуждается в серверах приложений (гомерический смех в зале).

Вопрос: Не являясь разработчиком, я выбрал Ubuntu в качестве десктопа. Может быть, мой выбор неправилен, и надо было выбрать Xandros или Linspire? (смех в зале)

Ответ: Попробуйте их все – и решите, какой лучше подходит (гомерический смех в зале, переходящий в овацию).

Следует учитывать, что такие дистрибутивы, как Xandros, Linspire или, например, MEPIS включают в себя много коммерческого софта, не распространяемого свободно. Ubuntu же включает только свободный софт и при этом работает из коробки на новом «железе». Кроме того, у Ubuntu очень большое сообщество разработчиков, благодаря чему ошибки исправляются быстро.

Вопрос: В последней версии 6.06 есть прекрасная поддержка свежего «железа». Однако постоянно выходят новые устройства, видеокарты и так далее. В то же время для Ubuntu заявлена поддержка на пять года для десктопа и пять лет для сервера. Будет ли при этом обновляться ядро для включения поддержки новых устройств?

Ответ: Работа над текущим ядром будет продолжаться, и драйверы устройств из новых ядер будут по возможности портироваться в текущее ядро. Однако понятно, что в какой-то момент обратное портирование драйверов на ядро пятилетней давности окажется невозможной. И поэтому через какое-то время мы выпустим очередной релиз. И поэтому у человека будет всегда выбор – обновлять существующую версию или перейти на новую.

Вопрос: Есть ли у Вас планы по убеждению вендоров аппаратуры открывать код дайверов своих устройств. И что Вы предпочитаете – помогать вендорам писать драйвера под Linux или создавать собственные?

Ответ: Наша позиция в том, что мы сможем лучше поддерживать продукты, если будет и поддержка со стороны производителя. Как правило, вендоры будут заинтересованы в открытии своих спецификаций, если они уверены в важности для них этого рынка. Например, я и мои друзья предпочитаем продукцию Intel, потому что это открытая архитектура, для нее быстро появляются драйверы.

Вопрос: Как Вы оцениваете взаимоотношения между разработчиками GPL-программ и разработчиками закрытого софта? И есть ли какие-нибудь соображения по поводу BSD-лицензии, которая накладывает гораздо меньше ограничений в этом отношении?

Ответ: Если это Ваш проект, Вы можете использовать модель двойного лицензирования, выпустив две версии – одну под GPL, другую под коммерческой лицензией.

GPL более свободна, так как она защищает свободу софта, предоставляя его закрытие. Поэтому она предпочтительна для больших проектов

Если же Вы – разработчик небольшой программы и хотите наиболее широкого распространения своего кода, то BSD-лицензия может оказаться предпочтительней.

Вопрос: Я поставил Ubuntu только для того, чтобы отказаться от ворованного программного обеспечения. Как мне объяснить это моим друзьям? (смех и аплодисменты)

Ответ: Я не думаю, что нужно убеждать пользователей Windows перейти на Linux, но я ищу те самые моменты, которые покажут преимущества свободного софта.

Вопрос: Планируются ли добавления в Launchpad специально для переводчиков?

Ответ: Совершенствуются средства совместной работы переводчиков, и средства обсуждения новостей из переводов, в частности, нечто вроде «заметок на полях».

Вопрос: Полетели бы Вы в космос на корабле, все бортовые компьютеры которого работают под Ubuntu?

Ответ: Нет (смех и бурные аплодисменты).

Знаете, какая система работает на Союзе? Восьмибитный компьютер 70-х годов, с программами непосредственно в машинных кодах, с прямым программированием памяти, в котором нечему ломаться (бурные аплодисменты).

Интервью

В качестве завершающего штриха встречи планировалось, что Марк даст расширенное интервью для журнала LinuxFormat. Однако на большинство мыслимых вопросов ответы были получены или из выступления, или в ходе последующего обсуждения, и заставлять Марка повторять это в очередной раз было бы антигуманно. И потому все интервью свелось к обсуждению двух вопросов, показавшимся, во-первых, наиболее важными, а во-вторых, не прозвучавшим в основной части. В качестве интервьюера выступал ваш покорный слуга (хотя в итоге получилось совсем не интервью), роль переводчика исполнял Павел Фролов – генеральный директор компании Linuxcenter.

Сначала я поинтересовался мнением Марка на счет того, с какого конца следует подходить к пропаганде Open Source – снизу, со стороны ли пользователей-индивидуалов, в том числе домашних, или же сверху, от корпоративных потребителей IT. Иными словами, куда Linux придет раньше и с большим успехом, в дома, или в офисы? Ответ был достаточно дипломатичным – что не следует пренебрегать ни теми, ни другими; но в свете отмеченной ранее, во время ответов на вопросы, ориентации на «квалифицированное меньшинство», у меня сложилось впечатление, что Марк отдает предпочтение решениям корпоративным.

Второй же вопрос касался финансовой стороны открытых проектов: должны ли они стремиться к коммерческой самоокупаемости и прибыльности, или, подобно науке, образованию, искусству, в той или иной форме дотироваться обществом? На что Марк неожиданно ответил вопросом: – А Вы как думаете?

Будучи, некоторым образом, представителем науки, я, разумеется, ответил, что финансирование разработок Open Source должно осуществляться по тем же моделям, что и финансирование фундаментальной науки – то есть дотационными. На что Марк сказал: предположим, Вы написали программу чисто научного назначения. И Вам присылают к ней патч, никакого отношения к науке не имеющий, но делающей эту программу пригодной для коммерческого использования. Включите Вы его в свою программу, или нет?

Вопрос поставил меня несколько в тупик. Чуть подумав, я ответил – почему бы и нет? Ведь в сущности, наука для того и существует, чтобы ее результаты использовались. В том числе и в интересах бизнеса. Важно только, чтобы наука сама не становилась при этом бизнесом. На чем примерно и был достигнут консенсус.

Вот такое странное интервью получилось...

В заключение отмечу, что встреча прошла, как говорится, в тёплой и дружественной, я бы сказал – неформальной, обстановке. Не обошлась она без «раздачи слонов» – наклеек Ubuntu и последнего номера журнала Linuxformat. А лично меня она навела на некоторые мысли, которыми я надеюсь поделиться с читателями в самое ближайшее время.

LinuxFormat #112 (декабрь 2008, DVD-версия)

В LXF108 была опубликована колонка, озаглавленная просто: «Какой Linux изучать?». В этой статье я готов предложить дальнейшее развитие заявленной в ней темы.

Самой модной темой для обсуждений в российском сообществе в последнее время стало повсеместное внедрение Linux в школах, вузах, на производстве... да разве всё перечислишь? Судя по тому, что одно из российских зеркал сайта www.kernel.org расположено на сервере perespim.ru, не за горами и внедрение этой ОС в сфере, так сказать, интимной. Желающих убедиться прошу сюда: http://kernel.perespim.ru/pub/linux/; кстати, вопреки присказке, что «быстро хорошо не бывает», зеркало вполне шустрое.

Так что ответ на вопрос, кого учить Linux, более или менее ясен: всех. Сложнее с ответом на другой вопрос: а кто будет учить? Ибо повсеместное внедрение Linux требует знания предмета, как минимум, от тех, кто это внедрение будет осуществлять. А здесь наблюдается напряжёнка: наша страна за годы существования этой ОС не вырастила достаточного количества специалистов – их еще самих предстоит обучить.

Это выводит нас на третий вопрос: а какому именно Linux следует учить будущих гуру – внедренцев этой системы в масштабе страны (а то, глядишь, и в мировом)? А может, их вообще следует учить FreeBSD или, скажем, DragonFly BSD?

Применим фильтры

На www.distrowatch.com на сегодняшний день зарегистрировано около 350 активно развиваемых дистрибутивов (включая полторы дюжины BSD-систем), плюс еще пара сотен проектов, которые тоже нельзя не учитывать: реанимация давно, казалось бы, умерших начинаний – отнюдь не редкость в мире Open Source. Но все ли они одинаково полезны для информационного здоровья будущих Linux-гуру?

Сконцетрируемся всё-таки только на активно развивающихся проектах, в рамках того же Distrowatch'а разделяемых на два десятка категорий . Среди них для начала отфильтровываем узкоспециализированные решения: кластерные, восстановительные, security-системы; все они предназначены для тех, кто «уже умеет» (и, главное, знает, для чего ему они нужны).

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

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

При всей моей любви к BSD-системам, их пока тоже придется исключить из числа кандидатов. Причин тому много, и останавливаться на них здесь я не стану – будем считать это просто волюнтаристским решением.

Наконец, на заключительном этапе можно отобрать просто малоизвестные дистрибутивы. Не потому, что они плохи сами по себе: просто по ним, как правило, трудно найти информацию в достаточном количестве. А информационное обеспечение – далеко не последний критерий выбора системы, которую должны осваивать будущие внедренцы...

Но и после такого многоступенчатого отбора список кандидатов остаётся более чем обширным. Правда, и мнений относительно того, как сделать окончательный выбор, оказывается не намного меньше. Тем не менее, наиболее распространенных точек зрения – две. Согласно первой, будущие гуру должны учиться на наиболее дружественных к пользователю системах, таких, как Fedora и прямые клоны Red Hat, вроде CentOS или Scientific Linux (о самом RHEL тут речи нет из-за дороговоизны технической поддержки, да и ненужности её в данной ситуации), SUSE, Ubuntu, Mandriva, ALT Linux – тем более, что некоторые из них уже пустили корни в российских школах. Список неполон, но его уже достаточно, чтобы было над чем задуматься.

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

Во-вторых, большинство «дружественных пользователю» систем буквально напичканы инструментами для настройки всего и вся, призванными облегчить жизнь администратора. И до определенного предела они эту роль выполняют. Но при этом освобождают от знания механизмов, скрытых под красивым GUI, а сами являются настолько дистрибутив-специфичными, что блестящее знание Yast из SUSE мало чем поможет при работе с клонами Red Hat. А ведь мы помним, что речь идёт об обучении будущих «внедренцев» – и какой именно дистрибутив они будут внедрять, заранее неизвестно.

Вторая точка зрения, явным или неявным образом, гласит: будущих гуру надо учить по «методу большого болота» – системам типа Slackware, Gentoo, Arch. Причины очевидны:

  • 

  • 

  • 

Оборотная сторона медали такова: а многие ли пользователи без предварительной подготовки смогут выбраться? Причём не будем забывать еще об одном, очень важном, моменте: когда мы говорим об обучении будущих Linux-гуру, речь идёт в первую очередь о их самообучении: насколько мне известно, в централизованном порядке их, в отличие от конечных пользователей, образовывать не собираются. А значит, самообучение им придётся совмещать с решением сиюминутных практических вопросов.

А вот к этому-то дистрибутивы данного типа не очень пригодны. Каждый, кто имел дело со Slackware, Gentoo и подобными, подтвердит, что в них всё легко и просто. Но лишь после того, как на настройку и индивидуализацию системы затрачены должные усилия, причём не всегда совместимые с немедленной практической работой.

И потому выскажу третью точку зрения: учить надо систему, обеспечивающую поэтапное вступление в мир Linux, в которой сочетаются легкость развертывания «пользовательских» дистрибутивов и возможность углублённого изучения системы. И как минимум один дистрибутив, отвечающий этим условиям, есть: Zenwalk Linux (www.zenwalk.org). Доказательство чего автор надеется представить ниже.

Почему Zenwalk?

Испокон веков установка дистрибутивов Linux сводилась к следующим обязательным действиям:

  • 

  • 

  • 

  • 

  • 

Причём пункты 1, 2 и 4 по сути своей были одинаковы во всех дистрибутивах: независимо от внешнего оформления, за ними скрываются те же утилиты и файлы. Некоторая индивидуальность проявлялась в развертывании системы, правда, зачастую все сводилось к альтернативе: попакетный выбор компонентов, с учетом или без учёта зависимостей или установке неких предопределённых наборов – по назначению (сервер, рабочая станция) или по окружению (KDE, GNOME и т.п.). Были, конечно, и более или менее сбалансированные сочетания обоих вариантов, но двоичность подхода от этого не менялась...

До тех пор, пока на рубеже тысячелетий не появились дистрибутивы с «безальтернативными» инсталляторами, в которых устанавливался некий готовый набор утилит и приложений внутри фиксированного окружения. Что, с одной стороны, позволяло получить готовую «из коробки» систему с ограниченным, но достаточным для начала набором приложений и пусть не идеальными, но разумными настройками. С другой же – лишало пользователя какой-либо возможности выбора на стадии установки.

Одним из пионеров данного направления был Vector Linux, потомок Slackware. Уже в его первой версии, вышедшей в июне 2000 года, была реализована концепция безальтернативной установки интегрированной рабочей среды (KDE) с фиксированным набором пользовательских приложений, необходимых и, более или менее, достаточных для решения стандартных задач дома и в офисе.

В дальнейшем эта концепция нашла свое воплощение в таких дистрибутивах, как MEPIS, Corel Linux (ныне Xandros) и Lindows (позднее Linspire, ныне слившийся с Xandros). Очень последовательно она проводится в Ubuntu и его бессчётных производных. Характерно, что в основе всех их лежит Debian – его система управления пакетами оказалась наиболее благоприятной для реализации «безальтернативной» установки.

На извечный вопрос, хороша или плоха безальтернативная установка, однозначный ответ дать, естественно, нельзя. Ограничение свободны выбора пользователя, если подходить к этому с абстрактных позиций – это безусловное «плохо», но зададим встречный вопрос: всегда ли пользователь, особенно начинающий, может ею распорядиться? Каждого, кто вспомнит свои муки при выборе одного из наличных текстовых редакторов, браузеров или почтовых клиентов при первой установке любого полнофункционального дистрибутива, охватят далеко не смутные сомнения. Ибо муки буриданова осла меркнут пред ними: ведь тому надлежало выбрать лишь из двух охапок сена, а не полудюжины их.

Таким образом, на первый план выходит качество реализации «безальтенративного» дистрибутива и чувство меры у его разработчиков. В Vector Linux, помнится, меня удивило изобилие функционально дублирующих друг друга приложений, что выглядит непозволительной роскошью для одного CD. Программы KDE в Vector часто заменялись их Gtk-аналогами, и не всегда более функциональными.

Ubuntu куда более последователен: дистрибутив-эпоним содержит только программы, основанные на Gtk и библиотеках GNOME, Kubuntu – на Qt и kdelibs, Xubuntu – немногочисленные собственные плюс затыкающие прорехи приложения Gtk/GNOME. Однако, и здесь есть излишества. К чему включать локали и шрифты для языков, о существовании которых, за пределами круга их носителей, мало кто слышал? Причем без простой возможности от них избавиться...

На фоне своих собратьев Zenwalk Linux выглядит квинтэссенцией «безальтернативного» подхода, причём направленного на максимальное упрощение и облегчение системы – как в установке, так и в изучении, и в использовании. Начинается это с выбора рабочей среды – Xfce, самой быстрой и легкой среди интегрированных. Да, недостаточно нагруженной функционально в сравнении с GNOME/KDE (некоторые сказали бы, функционально не перегруженной, подобно им), но зато пригодного к практической работе сразу после установки. Настройки, собранные в единой панели, немногочисленны и предельно прозрачны.

Недостаток собственных приложений Xfce компенсируется сторонними программами. При этом последовательно проводится три принципа комплектования дистрибутива.

Первый и главный таков: одна задача – одна программа. Никаких функционально дублирующих друг друга утилит и приложений в штатном составе дистрибутива вы не найдете.

Второй принцип – единство графического инструментария: все приложения (не считая тех немногих, которым требуются собственные библиотеки Xfce) используют исключительно Gtk.

И, наконец, третье: включённые в дистрибутив приложения совсем не обязательно самые функциональные в своём классе, но всегда – самые легкие, самые простые в освоении и использовании.

В Zenwalk абсолютно нет тяжелых, узкоспециализированных приложений, а также программ, которые принято относить к категории профессиональных (за исключением GIMP – но он сколько-нибудь функциональных легких аналогов не имеет). Предполагается, что задача авторов дистрибутива – обеспечить пользователю «место для жизни», а уж подбором того, что ему требуется для профессиональной деятельности, он займётся сам.

Далее, Zenwalk, будучи потомком Slackware, наследует простоту и прозрачность её внутреннего устройства: при наличии минимального опыта и навыка, в настройку любых параметров можно вмешаться вручную. Однако эти самые минимальные опыт и навык нужно еще приобрести, не так ли? И тут на помощь начинающему пользователю приходит графическое средство сквозной настройки системы – Zenwalk Panel.

Здесь читатель вправе обвинить меня в противоречии собственному утверждению, что графические инструменты затеняют суть процесса настройки. Возразить на это легко: Zenwalk Panel как раз и являет собой исключение из этого правила. Потому что, свято следуя принципу «одна иконка – один параметр» похоже, она позволяет легко установить корреляцию между выполненными через графический интерфейс действиями и изменениями конфигурационных файлов. То есть представляет собой своего рода лабораторную модель для отработки навыков настройки и приобретения необходимого опыта, позволяющего в дальнейшем вмешиваться в этот процесс руками.

Третья особенность Zenwalk – его средства управления пакетами. Как известно, отличительная особенность Slackware – это отсутствие средств контроля зависимостей, отслеживание которых возлагается на пользователя. Что, конечно, способствует его образованию, но поначалу может показаться сложноватым (да и не только поначалу – удержать в памяти зависимости многочисленных пакетов не очень легко).

Так вот, средства управления пакетами дистрибутива Zenwalk избавляет вас от этой докуки. Собственно, средство это одно, но существует в двух ипостасях: утилиты командной строки netpkg и её графической оболочки xnetpkg. Они взаимодополняют друг друга: одни действия удобнее выполнять из командной строки, другие – из графического интерфейса.

Кстати, всё, что было сказано об аскетичности подбора ПО, касалось только штатного дистрибутива, распространяемого в виде ISO-образа. В сетевых репозиториях проекта доступно если и не всё изобилие свободных программ, то изрядная его часть, включая KDE, GNOME и большинство их приложений, несколько оконных менеджеров для тех, кто не любит интегрированных сред, OpenOffice.org, Seamonkey, и множество других.

Конечно, «запас» пакетов в репозиториях Zenwalk далеко не столь обширен, как у Gentoo, Debian или даже Arch Linux. Однако он восполним самыми различными способами.

Во-первых, кроме официального репозитория проекта, поддерживается так называемый пользовательский (ZUR – zur.zenwalk.org), пополнение которого обеспечивается сообществом.

Во-вторых, Zenwalk сохраняет двоичную совместимость со Slackware, и потому остро недостающие пакеты можно поискать в его официальных репозиториях или на сайтах вроде www.linuxpackages.net.

В-третьих, никто не отменял и традиционного способа пополнения личной коллекции пакетов – сборки из исходных текстов. Причем это можно сделать не только для себя, но и поделиться с другими: скомпилируйте пакет по всем правилам Zenwalk, со служебными файлами, содержащими необходимую метаинформацию, в том числе и о зависимостях, и разместите его в ZUR для тестирования. Если пакет окажется корректно собранным и востребованным, он имеет шанс войти и в состав репозитория официального.

Как видно, пользователь Zenwalk имеет достаточно возможностей для индивидуализации своей системы: он может полностью сменить рабочее окружение как в сторону облегчения (перейдя на какой-либо из легких оконных менеджеров), так и в сторону многофункциональности (мигрировав на KDE или GNOME), доустановить дополнительные пакеты, не отягощая себя размышлениями об их зависимостях, выполнять регулярное обновление как отдельных пакетов, так и системы в целом.

При этом, в отличие от дистрибутивов семейства Ubuntu, пользователь Zenwalk не привязан столь жестко к набору пакетов, установленному при первичной инсталляции. Если в Ubuntu удаление, скажем, ненужных шрифтов и локалей связано с изрядными трудностями, вплоть до полной потери работоспособности системы, то в Zenwalk можно легко убрать почти любой пакет, входящий в штатный набор. Впрочем, как мы увидим дальше, у пользователя есть и другой путь иметь в своей системе только заведомо нужные ему компоненты.

Zenwalk: знакомимся ближе

Если мне удалось убедить вас в том, что Zenwalk – штука стоящая, есть смысл познакомиться с ним дистрибутивом поближе.

Как уже было сказано, Zenwalk является одним из клонов Slackware, старейшего из ныне живущих дистрибутивов Linux. Возникнув в середине 2004 года под названием Minislack, своё нынешнее имя он получил на втором году жизни, в августе 2005.

Создатель дистрибутива, Жан-Филипп Гийомен [Jean-Philippe Guillemin], ставил своей целью создать компактную и быструю систему, сочетающую гибкость Slackware с простотой установки и настройки, легкостью актуализации и наращивания. Он оказался не одинок в своих намерениях, и постепенно вокруг Zenwalk сложилась и команда основных разработчиков, и сообщество пользователей. Совместными усилиями они обеспечивают как регулярное обновление базовой системы, при неуклонном следовании исходным принципам в отношении её компактности, так и наращивание массива дополнительных приложений.

Zenwalk не имеет фиксированного релиз-цикла, однако новые версии выходят не по мере готовности, а скорее по необходимости, при обновлении ключевых комопнентов системы, таких, как ядро, Xfce и так далее. Периодичность выхода релизов варьируется от одного-двух до трех-четырёх месяцев. В каждый момент времени сосуществует две ветки системы – current, то есть текущая стабильная, и snapshot – находящийся в процессе разработки прототип будущего релиза.

Ветвь current распространяется в следующих вариантах:

  • 

  • 

  • 

  • 

Все варианты ветки current в промежутках между релизами обновляются лишь косметически, преимущественно в отношении безопасности и при возникновении нештатных ситуаций (типа памятной многим смены протокола ICQ). При необходимости в более глубоких модификациях, как уже говорилось, просто выпускается новый релиз.

Ветвь snapshot как таковая в виде образов дисков не распространяется. Перейти на неё можно, установив стандартную или core-редакцию и выбрав после этого соответствующий репозиторий как источник пакетов для утилиты netpkg. В отличие от стабильного релиза, она обновляется постоянно, что в ряде случаев может вызвать некоторые проблемы.

Например, в момент, когда пишутся эти строки, происходит активная разработка Xfce версии 4.5 и связанные с ней пакеты обновляются чуть ли не ежедневно, причём не всегда согласованно. Это иногда приводит к комическим эффектам, например, обновлению базовой части Xfce без соответствующей корреляции с библиотеками, на которых она основывается. Хотя такие коллизии легко разрешаются посредством «мануальной терапии», совсем начинающего пользователя они могут несколько обескуражить.

Поэтому использование ветки snapshot рекомендуется только тем, кто хочет быть на самом острие прогресса – текущая стабильная ветка содержит достаточно свежие версии пакетов, способные удовлетворить практические запросы большинства пользователей без всяких дополнительных осложнений.

Думаю, сказанного было достаточно для оценки дистрибутива Zenwalk как вполне целостного и законченного решения, в равной степени пригодного как для начинающих (но любопытствующих) пользователей, так и для пользователей многоопытных, которые уже вволю наигрались в игры с перекомпиляцией ядра, глобальными пересборками системы и прочими развлечениями записных линуксоидов. Впрочем, ветка snapshot способна удовлетворить и авантюрную жилку.

Не случайно тотемом (или, если угодно, талисманом) дистрибутива Zenwalk выбран дельфин – самое умное и быстрое животное планеты, прославленное в легендах и былях также своим дружелюбием к человеку. Желающим убедиться в этом могу рекомендовать книгу «Белый лоцман» Петра Бобева. Она не переиздавалась в нашей стране много лет, но при желании без труда отыскивается в Сети.

И на прощание

Ознакомившись с вышеизложенным, читатель вправе задаться вопросом: если дистрибутив Zenwalk такой умный, то почему он такой бедный (пользователями)?

Ответить легко: вследствие недостаточной информированности о нем его потенциальных пользователей. Ибо до недавнего времени источников сведений о Zenwalk, особенно на русском языке, было немного.

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

LinuxFormat, #125 (декабрь 2009)

Многие, чьё знакомство с Red Hat и его клонами пришлось на 90-е годы, надолго сохранили предубеждение и против формата их пакетов, и против утилиты управления оными. Конечно, дать команду rpm -ihv – проще, нежели собрать нужный пакет из исходников. Однако, в сравнении с портами FreeBSD, с одной стороны, и с Debian'овским APT'ом – с другой, она приобретала вид вполне бледный.

Но всё течёт, всё меняется – и ныне rpm-based дистрибутивы располагают развитыми системами пакетного менеджмента, работающими как в текстовом, так и в графическом режиме. В настоящей заметке мы остановимся на двух из них – yum и PackageKit на примере использования в дистрибутиве Fedora.

Незнаменитый yum

Yum – система управления rpm-пакетами и их репозиториями, предлагающая автоматическую установку, обновление и удаление пакетов и пакетных групп с автоматическим контролем зависимостей. По механизму действия и функциональности она сходна с системой APT, разработанной для Debian. Однако если последний получил в последние годы широкую известность – не в последнюю очередь благодаря популярности Ubuntu, а также тому, что усилиями сначала Connectiva, а затем Altlinux широко распространился за пределами родного дистрибутива, – то yum остаётся малоизвестным. Однако yum, с одной стороны, по своим возможностям управления rpm-пакетами ничуть не уступает утилитам семейства apt для deb-пакетов, а с другой, используется достаточно широко: эта система принята в качестве основной в Fedora, RHEL и их прямых и косвенных потомках.

Аббревиатура yum интерпретируется как Yellow dog Updater, Modified, то есть Обновитель Yellow dog Модифицированный. Однако его связь с одноимённым дистрибутивом – портом Red Hat на архитектуру Power, не совсем прямая. Его пакетный менеджер, именовавшийся YUP, послужил основой для Сета Видала (Seth Vidal), при написании yum для дистрибутива Red Hat. Символично и дословное его значение (yum – по английски конфетка) – его можно трактовать так, что эта система в состоянии сделать конфетку даже из такого… не самого приятного продукта, как пакеты в формате RPM. Yum быстро получил признание среди ряда клонов Red Hat, в частности, был принят в качестве штатного менеджера пакетов в ASPLinux. Однако в самом Red Hat он долго конкурировал с apt-rpm, и развитие yum’а одно время только силами команды ASPLinux и осуществлялось. Однако в конце концов он утвердился в RHEL и его клонах (CentOS, Scientific Linux), в Fedora и в Yellow Dog.

Система yum включает в себя собственно одноимённую утилиту, набор дополнительных утилит (yum-utils) и многочисленные плагины, в виде самостоятельных пакетов расширяющие функциональность главной программы.

Запускается yum одноимённой командой, требующей указания субкоманды (возможно, с опциями последней), и, в ряде случаев, аргументов в виде имени пакета или группы пакетов, что в общей форме выглядит так:

$ yum subcommand [arguments] —[options]

Команда yum без указания субкоманды выведёт краткую справку касаемо последних и их опций. Аналогичный результат будет получен посредством субкоманды

$ yum help

А указание имени субкоманды в качестве аргумента, например, так

$ yum help install

выведет краткие сведения о её назначении.

Субкоманды yum’а определяют одно из действий, которое команда должна выполнить – установку или удаление пакета, вывод информации о нём, поиск пакетов и так далее. Обычно назначение субкоманды легко угадывается из её названия и (или) краткой характеристики в выводе help’а.

Все субкоманды yum можно разделить на две группы. Первая связана с поиском пакетов и получением информации о них, вторая – с манипуляциями пакетами и группами. В составы первой группы наиболее употребимы:

  • 

  • 

  • 

Все субкоманды первой группы могут исполняться от лица обычного пользователя. Во второй группе субкоманд наиболее важны:

  • 

  • 

  • 

  • 

Все субкоманды второй группы для своего исполнения требуют прав администратора. Отдельно надо сказать о субкоманде shell – она запускает собственную интерактивную командную оболочку yum’а, в сеансе которой можно оперировать уже просто его субкомандами, аргументами и опциями, пуская главную команду yum.

Рис. 1. Yum с его интерактивной оболочкой

Исполнение любой субкоманды начинается с синхронизации локальной базы пакетов с базами репозиториев. Затем происходит проверка зависимостей – и по её результатам выводится итог: сколько пакетов, включая зависимости, должно быть установлено, обновлено или удалено, их имена, подлежащий скачиванию объем информации. И запрашивается подтверждением на выполнение операции. Опции yum довольно многочисленны, привязаны как к главной команде, так и к отдельным субкомандам. Исчерпывающую справку о них можно получить через

$ man (8) yum

В состав пакета yum-utils входит серия утилит, запускаемых как самостоятельные команды, со своими опциями. Полный их список можно получить из

$ man yum-utils

Важнейшей из этих команд является package-cleanup, предназначенная для получения сведений о непорядках в локальной базе данных пакетов и их устранения. Она имеет несколько опций. Например,

$ package-cleanup —problems

выведет список нарушенных зависимостей, а с помощью команды

$ package-cleanup —leaves

можно вывести список пакетов, от которых не зависят никакие другие компоненты.

Плагины, в отличие от утилит, не запускаются как самостоятельные команды, а встраиваются по умолчанию в команду yum, добавляя ей новые функции. По умолчанию в RFRemix устанавливаются следующие плагины:

  • 

  • 

  • 

Эффективное использование yum требует некоторых мероприятий по настройке, включающих:

  • 

  • 

  • 

За настройки собственно yum отвечает файл /etc/yum.conf – он содержит общие параметры для этой утилиты в формате:

название=значение

Значение может быть булевым (0 – запрещено, 1 – разрешено), численным – от 1 и до... разумного предела (значение 0 равносильно отключению) или символьным – например, путь к каталогу или список пакетов; в последнем случае значения разделяются пробелами. По умолчанию yum.conf выглядит так:

  • 

  • 

  • 

  • 

  • 

  • 

  • 

  • 

  • 

Кроме перечисленных, существует ещё немало параметров настройки yum. Так, очевидно, что опция installonly_limit имеет смысл только при наличии списка запрещённых к обновлению пакетов. Он задаётся параметром

installonlypkgs=pkgname1 pkgname2 ... pkgname#

Есть возможность и задать список пакетов, для которых запрещено как обновление, так и инсталляция, что иногда требуется при использовании проприетарных пакетов:

exclude=pkgname1 pkgname2 ... pkgname#

Полезной может оказаться параметр skip_broken – он заставляет пропускать установку пакетов с нарушенными зависимостями.

Параметр recent нужен для субкоманды list с одноимённой опцией: он устанавливает срок, в течении которого добавленные в репозиторий пакеты считать новыми.

Что очень раздражает в yum – это синхронизация метаданных о репозиториях, происходящая каждый раз при его запуске с любой субкомандой – даже от лица пользователя, когда реально кэш метаданных обновлён быть не может. Такая ситуация изменяется параметром metadata_expire, которому можно дать то значение, которое покажется разумным. Или вписать строку

metadata_expire=never

И тогда обновление кэша метаданных будет производиться только по запросу.

Обратимся к плагинам. Они устанавливаются точно так же, как и любые другие пакеты. Соответствующие каждому из установленных плагинов конфигурационные файлы располагаются в каталоге /etc/yum/pluginconf.d и имеют имена, по которым легко догадаться, к какому из плагинов относится любой конфиг.

Большинство плагинных конфигов предельно просто и содержит единственную строку, разрешающую его подключение:

enabled=1

В конфиге плагина presto можно запретить локальное кэширование дельт, раскомментировав параметр

keepdeltas = false

А можно определить, что же считать дельтой. Например, параметр

minimum_percentage = 95

указывает, что если изменённая часть пакета составляет 95% или менее от цельного, то будет скачиваться она, если же больше – загрузится пакет целиком.

Чтобы настраивать параметры доступа к репозиториям, их необходимо сначала подключить. Подключение «левых» репозиториев не сложно: вся метаинформация о любом репозитории, пригодном для эксплуатации yum’ом, собрана в виде обычного rpm-пакета, который может быть обычным же образом установлен. Вся загвоздка в том, что пакет этот хранится внутри собственного, ещё не подключённого, репозитория, и потому yum’ом установлен быть не может.

Так что нам придётся добраться до нужного пакета, описывающего репозиторий, в Сети, скачать его, установить с помощью команды rpm, а затем уже обеспечить доступность репозитория.

Рассмотрим эту процедуру на примере подключения репозитория для пакетов флэш-плейера. Для этого заходим на официальный сайт Adobe, в пункте Download отыскиваем строку Get flash player, и из выпадающего списка Select version to download… выбираем YUM for Linux, какой (в виде файла adobe-release-i386-1.0-1.noarch.rpm) и скачиваем. Затем даём команду

# rpm -Uhv adobe-release-i386-1.0-1.noarch.rpm

По её успешном исполнении в каталоге с конфигами репозиториев можно будет увидеть новый файл adobe-linux-i386.repo. Одновременно он станет доступным для обновляющих манипуляций командой

# yum update

Подключить новый репозиторий можно и совсем вручную. Проделаем эту операцию для репозитория (почти) ежедневных сборок браузера Chromium от Тома Колловея: создадим в каталоге /etc/yum.repos.d файл chromium.repo и впишем в него такие строки:

[chromium] name=Google Chrome baseurl=http://spot.fedorapeople.org/chromium/F$releasever/ enabled=1 gpgcheck=0

Надеюсь, мне удалось показать, что yum делает употребление rpm-пакетов абсолютно безвредным. В случае же напряжённых отношений с командной строкой для управления rpm-пакетами можно обратиться к графической утилите PackageKit, речь о которой пойдёт в следующем разделе.

PackageKit – кит пакетного менеджмента

Если yum всегда оставался в тени Debian'овского APT'а, то о графической надстройке PackageKit говорят ещё меньше. Хотя она не является чем-то специфическим для rpm-based дистрибутивов: её можно прикрутить к пакетам любого формата в любых дистрибутивах, вплоть до Archlinux и Gentoo.

Система PackageKit распадается на серию бэк-эндов для работы с конкретными менеджерами пакетов и интерфейсные надстройки.

Бэк-энды PackageKit предполагают работу с такими системами, как yum, apt, smart и так далее, вплоть до pacman. Интерфейсом к ним служат

При инсталляции в Fedora по умолчанию устанавливается бэк-энд для yum и фронт-энд gnome-packagekit (при выборе в качестве рабочей среды KDE он заменяется на kpackagekit). Но в репозиториях доступны пакеты поддержки apt и smart, а также консольный клиент pkcon.

Пакетные менеджеры, поддерживаемые системой PackageKit, имеют обычно собственный развитый инструментарий для управления пакетами из командной строки (не исключение и Fedora, как мы видели в заметке про yum). Поэтому консольная утилита pkcon представляет интерес только своей теоретической универсальностью – она одинакова в любых дистрибутивах, поддерживающих PackageKit, так что задерживаться на ней не будем.

Графическая ипостась PackageKit в виде субпакета gpk-application запускается из главного стартового меню, в зависимости от используемой среды, через пункты Приложения -> Установка и удаление программ (GNOME) или Администрирование -> Установка и удаление программ (Xfce). Причём сделать это можно от лица обычного пользователя – пароль администратора будет запрашиваться по ходу дела, при необходимости выполнения действий, требующих соответствующих полномочий. После запуска перед нами появляется окно следующего вида:

Рис. 2. PackageKit – общий вид

Переключаясь в левом фрейме окна на соответствующие пункты, в правом можно видеть список всех пакетов – как установленных, так и доступных в репозиториях. Списки пакетов и коллекций можно фильтровать по:

  • 

  • 

  • 

  • 

По умолчанию никакая фильтрация не проводится.

Свободное поле с кнопкой Find рядом прямо так и провоцирует выполнить поиск некоего пакета. Каковой осуществляется по совпадению (не чувствительно к регистру) не только в именах пакетов, но и в их описаниях. В результате в выводе будет список всех пакетов, имеющих хоть какое-то отношение к искомому.

Для выделенного пакета доступно его краткое описание и формальные данные – принадлежность к группе, лицензия, объем подлежащего скачиванию архива и репозиторий, из которого пакет будет получен.

Более подробную информацию о пакете можно получить через меню Selection. Так, пункт Get file lists выведет список файлов и путей к ним в том виде, в котором они будут установлены в системе. Пункт Depends on даст список его зависимостей. А пункт Required by – список пакетов, которые зависят от выбранного.

Для установки найденного пакета достаточно пометить его и нажать кнопку Применить. После этого некоторое время будут проверяться зависимости пакета, список которых выводится в специальной панели.

Рис. 3. Вывод списка зависимых пакетов

Нажатие кнопки Установить повлечёт за собой скачивание пакета вместе со всеми его зависимостями, из распаковку и инсталляцию. Кнопка Отмена вызовет отказ от установки не только зависимостей, но и выбранного пакета.

Если всё идёт как надо, после описанных выше манипуляций мы будем иметь в системе установленный работоспособный пакет. Что и предлагается проверить в панели сообщения об успехе инсталляции – на ней имеется кнопка Запустить, которая вызывает старт свежеустановленной программы.

Однако нельзя исключить ситуации, что в ходе проверки зависимостей будут выявлены ошибки – как правило, они связаны с конфликтом версий пакетов, от которых зависит устанавливаемый. И единственное, что тут можно сделать – открыть вывод More details, тупо просмотреть его и закрыть панель ошибок. Выбранный пакет при этом, разумеется, установлен не будет.

Удаление пакетов происходит аналогично – только в обратном порядке:

  • 

  • 

  • 

Подчёркиваю необходимость очень внимательного изучения списка удаляемых зависимостей: они могут оказаться весьма неожиданными. Так, удаление пакета, установленного не индивидуально, а в составе какой-либо группы или коллекции (особенно при инсталляции), может нечувствительно вызвать снос половины системы.

PackageKit в 12-й версии Fedora получит (за счёт отдельных плагинов) такие дополнительные возможности, как автоматическая установка пакетов по щелчку на имени файла в браузере или из командной строки – в ответ на сообщение command not found.

Все действия по установке и удалению пакетов (а также тотальному обновлению системы, о чём будет говориться позднее) через PackageKit фиксируются в специальном лог-файле – /var/log/yum.log; как явствует из названия, он не специфичен для этой системы, а отражает действия через менеджер пакетов yum. Однако gnome-packagekit предоставляет удобную форму визуализации его содержимого, вызываемую через пункты меню System -> Software log, где показываются: дата действия и его характер (установка, обновление или удаление), имя совершившего его пользователя и приложения (субпакета в составе gnome-packagekit):

Рис. 4. Журнал установки, обновления и удаления пакетов

Однако по хорошему, прежде чем заниматься установкой или удалением пакетов, не худо выполнить некоторые подготовительные действия.

Первое из них – проверить доступные репозитории, те самые, которые подключались на стадии установки, что делается через меню System -> Software sources. Скорее всего, все нужные источники пакетов из числа официальных для Fedora вообще и Russian Fedora в частности уже включены, но лишний раз убедиться в этом не мешает.

Затем имеет смысл обновить систему – через пункт меню System -> Refresh package lists, который сначала приведёт список доступных пакетов в актуальное (и соответствующее подключённым репозиториям) состояние, а затем предложит список пакетов, могущих быть обновлёнными, с которым остаётся только согласиться.

И теперь обновление будет выполнено, если не произойдёт ошибки —. хотя нельзя исключить и последнего варианта. В этом случае придётся обратиться к командной строке и yum’у.

Пунктами меню Software sources и Refresh package lists вызывают самостоятельные субпакеты, входящие в gnome-packagekit – gpk-repo и gpk-update-viewer, соответственно. Но они могут быть запущены автономно, через главное стартовое меню среды – Система -> Администрирование -> Источники программ/Обновление программ.

Из сказанного можно сделать вывод, что PackageKit в своей графической ипостаси – простое и удобное в обращении средство управления пакетами, функционально сходное с Synaptic’ом для deb-пакетов. В сравнении с последним он производит впечатление более медлительного. Однако это связано не с ним самим, а с rpm-форматом и базами данных для yum, требующими скачивания существенно большего объёма метаинформации. Второй недостаток PackageKit – трудность определения причин возникновения ошибок как при установке конкретного пакета, так и тотального обновления системы. Это я отнёс бы к некоторой недоработанности системы PackageKit в целом – ведь по сравнению с Synaptic’ом она ещё очень молода.

Однако и в нынешнем своём виде PackageKit пригоден для повседневного использования в сфере управления пакетами, если не выходить за пределы штатных ситуаций – при их возникновении yum нам в руки.

openSUSE LiveCD: нетривиальная установка

LinuxFormat, #162 (октябрь 2012)

Большинство современных дистрибутивов Linux распространяется в двух основных вариантах: в виде образов оптических дисков, служащих исключительно для установки системы, и в виде образов LiveCD/DVD, предназначенных как для знакомства с ней, так и и для последующей инсталляции. Не исключение тут и openSUSE, официальный набор образов которой включает:

  • 

  • 

  • 

О последних и пойдёт речь в настоящей статье.

Вступление

Среди записных линуксоидов, вне зависимости от используемого дистрибутива, существует несколько пренебрежительное отношение к установке системы с «живых» дисков: обычно считается, что этот метод предназначен для совсем начинающих пользователей, устанавливающих свой первый в жизни Linux. Пользователям же с опытом должно применять альтернативные установочные носители.

Это мнение имеет под собой основания: в большинстве случаев при установке с LiveCD возможности пользователя вмешаться в этот процесс минимальны или напрочь отсутствуют. Результатом же такой установки является точная копия образа «живого» диска со всеми его умолчальными настройками и заранее предопределённым набором приложений. А поскольку в отношении последних предпочтения составителей LiveCD наверняка не на 100% совпадают с предпочтениями пользователя «со стажем», в дальнейшем ему придётся затратить немало времени на индивидуализацию своей системы.

Однако инсталляция openSUSE с LiveCD оказывается исключением из общего правила. И предоставляет не меньше возможностей по индивидуализации системы, нежели установка с полного DVD или «сетевого» диска. А в отношении настроек – даже больше. Как это оказывается возможным – и будет предметом настоящей статьи.

Как уже было сказано, официально в рамках проекта распространяется два варианта LiveCD – с KDE и GNOME в качестве рабочих сред, каждый в сборках для 32-битной и 64-битной архитектур. В силу личных предпочтений автора дальнейшее изложение проводится на примере KDE-LiveCD – но пользователи GNOME вполне могут применить те же приёмы при установке своего любимого десктопа.

Официальные LiveCD в отношении версий ядра, рабочих сред и приложений точно соответствуют установочному DVD на момент выхода текущего релиза. Однако существуют и периодические «верстовые» (Milestomes) сборки, предназначенные для тестирования релиза будущего. По своему наполнению они идентичны официальным, однако версии этого наполнения повышаются «от столба к столбу». В промежутках же между «верстовыми столбами» с периодичностью примерно раз в неделю собираются «саженные столбики» – снапшоты текущего состояния подготавливаемого релиза. Разумеется, за стабильность «вестовых» и особенно «саженных» сборок никто не ручается, и использование их для «рабочих» инсталляций не рекомендуется.

Кроме официальных LiveCD, существует большое количество неофициальных их вариантов. Например, для KDE это версии с «чистым» KDE 4.X (то есть в оригинальном оформлении проекта KDE), и с ностальгическим KDE 3.5.10. Сборки LiveCD с прочими рабочими средами – XFce, LXDE, Enlightenment – также имеют статус неофициальных.

Live-среда: запуск

Работа в Live-режиме, будь то знакомство с системой или её установка, начинается с загрузки с соответствующего носителя. В ходе её весьма желательно выбрать русский язык интерфейса. Правда, для Live-среды она мало чего даст, ибо на 700 Мбайт вместить полную поддержку даже основных языков, как это имеет место быть на DVD, довольно сложно, а ожидать предпочтения русскому от интернационального дистрибутива было бы опрометчиво. Но в случае последующей инсталляции она будет унаследована установленной системой – хотя в ходе её придётся мириться со смесью нижегородского с оксфордским. Но зато в дальнейшем для окончательной русификации потребуется куда меньше телодвижений.

Из меню загрузчика следует, что можно либо загрузить Live-среду, из которой, как мы скоро увидим, будет доступна опция установки, либо непосредственно приступить к инсталляции. В данный момент нас интересует как раз первый вариант. Почему он является предпочтительным – станет ясным из дальнейшего изложения.Никаких дополнительных опций, вроде настройки сети, Live-вариант загрузки пока не предусматривает – этим можно будет заняться уже непосредственно в «живом» режиме. Так что нажимаем Enter на первом пункте главного меню и через некоторое время видим рабочий стол KDE.

Первая наша цель – ознакомиться с возможностями Live-режима. Однако делать это лучше в комфортной обстановке, что для меня, например, подразумевает в первую очередь шрифты, подходящие для глаз, для кого-то – иные параметры внешнего вида. Чем мы для начала и займёмся. Впрочем, те, кого внешний вид среды по умолчанию устраивает, могут спокойно пропустить следующий раздел.И ещё важное предупреждение: знакомство с LiveCD – занятие довольно медленное и печальное. Ибо привод компактов нынче не самое быстрое устройство хоранения данных, а кэширование его содержимого в оперативную память (даже если её более чем вдоволь) в openSUSE не предусмотрено.

Подготовка Live-режима

Дабы привести рабочий стол Live-среды в соответствие если и не со своими эстетическими идеалами , то хотя бы с физическими возможностями восприятия, отправляемся в стартовое меню главной управляющей панели, где выбираем пункт Configure desktop (я предупреждал, что с Великим и Могучим в Live-среде будет напряжонка) и по открытии окна настройки параметров щёлкаем по иконке Applications Appearance. В развернувшейся панели слева выбираем пункт Fonts, а справа жмём на кнопку Adjust all fonts.

Теперь отмечаем «птицами» боксики Font и Size и выбираем подходящие гарнитуру и кегль, сверяясь с образцом в нижней части окошка. Выбрав подходящий вариант, в панели шрифтов, включаем режим anti-aliasing'а в соответствие со своим визуальным восприятием. Каковое, впрочем, будет получено только впоследствие, после перезапуска сеанса (ни ни в коем случае не системы – это убёт все сделанные настройки). Однако перед этим я подгоняю управляющую панель к размеру, воспринимаемому моими глазами. Для чего щёлкаю на ней правой кнопкой мыши, в контекстном меню выбираю пункт Panel Options, а затем – Panel Settings. После чего, ухватившись мышью за кнопку Height, тащу её вверх до получения удовлетворительного результата.

Вот теперь в первом приближении дело с настройкой можно считать законченным – остаётся только перезапустить сеанс KDE и авторизоваться заново, введя в качестве логина значение linux, а поле для ввода пароля оставить пустым. После чего рабочий стол KDE загрузится снова – но уже с применением всех сделанных ранее настроек.

Настройка окружения администратора

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

Так что последний штрих в подготовке к дальнейшей работе – это настройка «административного окружения». Для чего следует запустить ту же самую программу конфигурирования десктопа, но уже от лица суперпользователя. Самый простой способ сделать это – с помощью комбинации клавиш Alt+F2 вызвать командную строку минитерминала, в которой и надлежит ввести

kdesu systemsettings

где

kdesu

После этого мы получаем доступ к настройкам десктопного окружения суперпользователя, где следует проделать все действия по настройке шрифтов – точно так же, как это было описано в предыдущем разделе.

Предвижу резонное замечание: зачем возиться с настройками окружения пользователя и администратора, если все эти действия будут иметь силу только для текущего Live-сеанса? Столь же резонно возражу. Во-первых, не такие уж это сложные действия, чтобы пренебречь комфортом в ходе знакомства с LiveCD и установки. А во-вторых, и главных, не пропадёт ваш скорбный труд по настройке пользовательского и административного окружения. Почему? Пусть это пока остаётся Военной Тайной.

Преамбула к установке

На знакомстве с Live-средой я останавливаться не буду. Замечу только, что это самая обычная среда KDE, с набором типовых её приложений – достаточно обширным, так что начинающему пользователю есть где порезвиться. Однако занятие это наскучит ему достаточно скоро. Не в последнюю очередь и потому, что все они не блистают быстродействием в условиях «живого» режима. И тут пользователю захочется посмотреть на те же приложения во всей красе – в инсталлированном виде. Наступает психологический момент для установки системы.

Установка openSUSE – дело не шести секунд. Конечно, в Live-режиме это время можно скрасить рядом приятных и полезных занятий. Так, те, кто ещё не наигрался в игрушки, имеют все условия, чтобы резаться, скажем, в Reversi или раскладывать пасьянсы, каковых немного больше, чем вдоволь. Люди же серьёзные могут почитать материалы официального сайта проекта, в том числе и на русском языке. Благо, для этой цели в Live-режиме имеется целых два браузера.

Конечно, для этого хорошо бы иметь и соединение с Интернетом. Если провайдер обеспечивает DHCP-подключение, всё просто: сеть волшебным образом поднимется сама собой. Однако в данном варианте не фатально будет и любое иное подключение: в нашем распоряжении есть рабочий Network Manager, который, при всех его недостатках, позволит настроить и VPN-, и DSL-, и WiFi-соединение. Ибо нет таких настроек, которые не могли бы выполнить большевики-линуксоиды, и сеть, тем или иным способом, будет поднята. Так что никаких препятствий к повышению своего образовательного уровня не будет.

Так что возможность занять время установки делами разной степени полезности – это первый довод в пользу установки системы из Live-среды, а не методом «лобового напора».

Однако чтение материалов, как я уже сказал, – занятие для серьёзных людей. Люди же несерьёзные, вроде автора этих строк, предпочтут провести время установки за непринуждёнными беседами, например, в Джуйке. И на первый взгляд их ожидает облом: в Live-среде ни малейшего Jabber-клиента не найти и следов.

Однако это решается легко: если Jabber-клиента в системе нет, его следует установить. На вопрос как? ответить очень легко: либо с помощью консольной системы zypper, либо посредством модуля управления программами универсальной системы YaST2 в графическом режиме. Оба способа – предмет отдельной тему. Здесь лишь отмечу, что во втором случае и пригодились нам настройки «административного окружения», ибо YaST2 запускается от лица суперпользователя.

Так что возможность читать документацию и поговорить с приятными собеседниками online – это второй довод в пользу инсталляции openSUSE из Live-среды. Правда, те самые серьёзные люди поставят это в упрёк: мол, не стоит ради пустопорожнего трёпа городить огород с установкой дополнительных приложений. На что у меня есть два возражения:

Так что Kopete может оказаться далеко не единственным кандидатом на установку. Так, не помешает установить в Live-среде и пакеты русификации, такие, как

kde4-l10n-ru

kde4-l10n-ru-data

kde4-l10n-ru-doc

libreoffice-l10n-ru

Наконец, самое интересное: пакеты можно не только устанавливать в Live-среду, но и удалять из неё – и после инсталляции на диск их не будет! Здесь я «отдельно, с большим наслажденьем» удаляю немало того, что полагаю лишним на «живом» диске, в частности, всю мультимедиа – но и это дело личных предпочтений.

Таким образом, Live-среда даёт ничуть не меньше возможностей для индивидуализации системы, нежели выборочная установка с DVD или по сети. И даже больше: потому что никто не в силах запретить подключение, наряду со штатными, также и сторонних репозиториев, в том числе содержащих так называемые не вполне свободные программы (типа мультимедийных кодеков), которые при других раскладах установки приходится доустанавливать впоследствии.

Таким образом, третий довод в пользу установки из Live-режима – безграничные возможности по индивидуализации системы. Причём реализуются все эти возможности, что называется, малой кровью: пользователь может полностью избавиться от заботы о зависимостях как при установке пакетов, так и при их удалении.

Последнее представляется мне особенно ценным: сколько я ни занимался установкой с индивидуальным выбором пакетов как в openSUSE, так и в более иных дистрибутивах, и как бы ни старался вычеркнуть из предлагаемого разблюдовника мне лично ненужные компоненты, всё равно половина из них пролазила в инсталлированную систему в качестве чьих-то родственников зависимостей.

При установке же с openSUSE LiveCD от всего лишнего можно избавиться радикально. Потому как предварительно можно должным образом настроить YaST или отредактировать конфигурационный файл zypper‘а, в зависимости от того, что используется для удаления и установки пакетов.

Четвёртый довод в пользу установки в Live-режиме по сравнению с прямой инсталляцией: возможность выполнять её в визуально приятном окружении, о чём говорилось в предыдущем разделе.

Есть и пятый довод, но и он пока останется Маленьким Секретом, который я раскрою под занавес.

Дабы при удалении пакетов вместе с ними удалялись и их ставшие ненужными зависимости (если они больше нигде не задействованы), при использовании zypper'а следует отредактировать файл /etc/zypp/zypp.conf, а именно: снять символ комментария со строки

# solver.cleandepsOnRemove = false

и заменить значение

false

true

При использовании же модуля управления пакетами YaST2 тот же эффект достигается включением в меню Параметры пункта Удалять ставшие ненужными зависимости.

Чтобы при установке пакетов они тянули за собой только обязательные зависимости, не затрагивая так называемых рекомендованных, в файле /etc/zypp/zypp.conf следует снять символ комментария со строки

# solver.onlyRequires = false

и заменить значение

false

true

Та же цель в модуле управления пакетами YaST2 достигается включением в меню Параметры пункта Игнорировать рекомендованные пакеты для уже установленных пакетов.

Однако торопиться с отключением установки рекомендованных пакетов не следует. Ибо в число оных входят и языково-зависимые пакеты, о которых говорилось ранее. Так что, вместо того чтобы устанавливать их попакетно, достаточно при отключённом игнорировании рекомендованных пакетов выполнить операцию тотального обновления системы командой zypper up или через YaST2. Результатом будет полная русификация системы.

Установка

И вот настал решительный момент щелкнуть мышью по иконке Install на предмет заняться установкой системы. Она начинается с панели приглашения к оной. После приглашения можно видеть отличительные особенности инсталляции в Live-режиме:

  • 

  • 

  • 

Впрочем, ни об одной из этих опций особо жалеть не стоит – все эти вопросы можно решить другими методами. Так что сразу после приглашения переходим к определению часового пояса, где можно также скорретировать время и включить синхронизацию с серверами NTP.

Стадия выбора рабочего стола при Live-установке пропускается. Что естественно – выбор этот делается в тот момент, когда диск с соответствующей средой (KDE или GNOME) ставится на закачку.

Так что следующим номером нашей программы будет разметка диска – возможности установщика openSUSE в этой области поистине необъятны, так что здесь мы на них задерживаться не будем, это должно быть предметом отдельного разговора. Далее создаётся аккаунт обычного пользователя, после чего выводится итоговая панель Live Installation Settings (то, что в русском переводе интерфейса типовой установки обозвали Параметрами установки).

Не ищите здесь секции индивидуального выбора пакетов: её здесь нет. Да и не нужна она, ибо все необходимые пакеты мы имели возможность установить «вживе» ещё до запуска инсталлятора.

Теперь по нажатии кнопки Install будет запрошено подтверждение этого судьбоносного решения. А дальше процесс разметки диска, создания и монтирования файловых систем, а также собственно установки пойдёт сам по себе.

А пока он идёт – ответим на вопрос, как нам удалось устанавливать и удалять пакеты, да так, что сделанные в Live-среде изменения сохранятся в инсталлированной системе. Хотя, казалось бы, после перезагрузки они должны были бы бесследно исчезнуть. Для чего дождёмся в окне инсталлятора окончания разметки диска и расправы с файловыми системами. После чего текущим действием будет одно-единственное – копирование корневой файловой системы (Copying root filesystem).

Вот вам и разгадка Военной Тайны. Ибо где расположена корневая файловая система Live-среды? Правильно, в оперативной памяти. А куда инкорпорируются исполняемые файлы, библиотеки и прочие компоненты установленных в ходе Live-сеанса пакетов? В корневую файловую систему. А откуда изымаются компоненты пакетов удаляемых? И где отражаются изменения, выполненные в общесистемных конфигах? Опять таки, всё это модификации корневой файловой системы – точнее, её образа в оперативной памяти.

Так что в процессе установки с LiveCD не происходит ни развёртывания образов метапакетов, ни попакетной распаковки индивидуально выбранных пакетов. В сущности всё дело сводится к переносу текущего слепка оперативной памяти на целевой носитель. И потому на нём по завершении установки все изменения, сделанные в Live-среде до запуска инсталлятора, сохранятся в неприкосновенности. В этом и заключается сила описанного метода – насколько мне известно, не имеющего аналогов в более иных дистрибутивах Linux.

Итоги установки

Вот теперь можно и переключится на Джуйку. Одна беда – за время наблюдений за процессом установки и размышлений о его сути установка-то и закончилась. Что неудивительно: ведь копирование образа из оперативной памяти на современный винчестер – дело достаточно быстрое, куда быстрее, чем распаковка пакетов и распределение их компонентов по ветвям файлового древа. Так что очень скоро мы увидим предложение перезагрузить машину – немедленно или когда угодно позднее.

Торопиться с перезагрузкой мы не будем. Ибо пора раскрыть Маленький Секрет пятого довода в пользу установки из Live-режима: это возможность сохранения пользовательских настроек рабочей среды. Причём за настройки для административного аккаунта можно не волноваться: поскольку каталог

/root

А вот пользовательские настройки среды были сделаны для временного пользователя с именем linux, и его домашний каталог

/home/linux

Однако никто не запрещает нам скопировать конфиги уходящего в небытие пользователя linux‘а, например, на флэшку, а затем перенести их в установленную систему. Или сразу поместить их в

/mnt_point/home/username

mnt_point

Файлы, подлежащие копированию, – это в первую очередь конфиги KDE (

/home/linux/.kderc

/home/linux/.kde4/share/config/kopeterc

Вот теперь можно и перезагрузиться. Установка в Live-режиме не предполагает отказа от автоматического конфигурирования системы. Каковое и происходит сразу после её рестарта. И завершается появлением умолчального рабочего стола KDE.

Впрочем, вид его не совсем умолчальный. Беглый взгляд на главное меню показывает, что оно стало русифицированным, утратило пункты, соответствующие удалённым пакетам и, напротив, в его закоулках мы найдём приложения, установленные ранее в Live-сеансе. А шрифты и главная панель сохраняют тот вид, который мы придали им перед установкой.

Заключение

Из всего сказанного выше можно сделать вывод, что установка с LiveCD – отнюдь не обязательно прерогатива совсем начинающих пользователей Linux'а. Конечно, для них такая инсталляция as is обеспечивает максимально быстрое развёртывание системы, содержащей необходимый для начала работы минимум приложений. Но если затратить некоторое время на настройку и наращивание возможностей Live-среды, то систему эту можно сделать и актуальной, и индивидуализированной. Причём существенно более простыми методами, чем при ручном выборе пакетов при установке с DVD или NET-диска.

Правда, этот метод можно рекомендовать только пользователям с достаточным опытом работы в других дистрибутивах. Ибо устойчивые предпочтения в отношении рабочего окружения и прикладного софта у них наверняка уже сложились, и что им надо получить в итоге – они сами знают. Так что, для достижения неизменно превосходного результата им потребуется только знакомство со специфической для openSUSE системой управления пакетами.

Правда, следует оговорить, что способ этот подходит только тем, кто отдаёт предпочтение средам KDE 4 или GNOME 3, потому что официальных LiveCD с другими десктопами просто нет. Что же до неофициальных – они обычно выходят с некоторой (а иногда и значительной) задержкой относительно текущего релиза. Хотя и эта проблема в принципе решаема – но с существенно большими затратами времени и сил. Так что любителям Xfce, LXDE или, тем более, оконных менеджеров проще прибегнуть к установке с полного DVD или диска для сетевой инсталляции.

ZFS on Linux: практика применения

LinuxFormat, #165-166 и #167 (январь и февраль 2013).

Настоящая статья посвящена практическому использованию ZFS в Linux. Оно рассмотрено на примере openSUSE, хотя почти всё из сказанного применимо и к любым другим дистрибутивам – все дистроспецифические детали оговорены явным образом.

Обзор возможностей

Прежде чем погружаться в вопросы, связанные с ZFS, читатель, вероятно, хотел бы убедиться в том, что это стоит делать. То есть – ознакомиться с возможностями, которые она ему предоставляет.

Для начала – немного цифр. В отличие от всех предшествовавших файловых систем и систем размещения данных, ZFS является 128-битной. То есть теоретическое ограничение на её объём и объёмы её составляющих превышают не только реальные, но и воображаемые потребности любого пользователя. По выражению создателя ZFS, Джеффа Бонвика [Jeff Bonwick], для её заполнения данными и их хранения потребовалось бы вскипятить океан. Так, объём пула хранения данных (zpool – максимальная единица в системе ZFS) может достигать величины 3×1023 петабайт (а один петабайт, напомню, это 1015 или 250 байт, в зависимости от системы измерения). Каждый пул может включать в себя до 264 устройств (например, дисков), а всего пулов в одной системе может быть тоже не больше 264.

Пул может быть разделён на 264 наборов данных (dataset – в этом качестве выступают, например, отдельные файловые системы), по 264 каждая. Правда, ни одна из таких файловых систем не может содержать больше 248 файлов. Зато размер любого файла ограничивается опять же значением в 264 байт. Количество таких ограничений можно умножить. Как уже было сказано, они лежат вне пределов человеческого воображения и возможностей. И привожу я их только для того, чтобы вселить в пользователя уверенность: ни он сам, ни его внуки и правнуки в реальности не столкнутся c ограничениями на размер файловой системы или отдельного файла, как это бывало при использовании FAT или ext2fs.

Так что перейду к особенностям ZFS, наиболее интересным, по моему мнению, десктопному пользователю. Здесь в первую очередь надо отметить гибкое управление устройствами. В пул хранения данных можно объединить произвольное (в обозначенных выше пределах) число дисков и их разделов. Устройства внутри пула могут работать в режиме расщепления данных, зеркалирования или избыточности с подсчётом контрольных сумм, подобно RAID’ам уровней 0, 1 и 5, соответственно. В пул можно включать накопители, специально предназначенные для кэширования дисковых операций, что актуально при совместном использовании SSD и традиционных винчестеров.

Пул хранения становится доступным для работы сразу после его создания, без рестарта машины. В процессе работы дополнительные диски или разделы, в том числе и устройства кэширования, могут как присоединяться к пулу, так и изыматься из его состава в «горячем» режиме.

Пул хранения может быть разделён на произвольное количество иерархически организованных файловых систем. По умолчанию размер их не определяется, и растёт по мере заполнения данными. Это избавляет пользователя от необходимости расчёта места, потребного под системные журналы, домашние каталоги пользователей и другие трудно прогнозируемые вещи. С другой стороны, не запрещено при необходимости и квотирование объёма отдельных файловых систем – например, домашних каталогов отдельных излишне жадных пользователей.

Файловые системы ZFS также доступны для размещения на них данных сразу после создания, никаких специальных действий по обеспечению их монтирования не требуется. Создание файловых систем внутри пула – процесс предельно простой: разработчики стремились сделать его не сложнее создания каталогов, и это им вполне удалось. Но при этом составляющие пула остаются именно самостоятельными файловыми системами, которые могут монтироваться со своими специфическими опциями, в зависимости от назначения.

Среди других возможностей ZFS, интересных настольному пользователю, можно упомянуть:

  • 

  • 

  • 

  • 

В общем, даже если не говорить об быстродействии ZFS (а оно весьма высоко, особенно в многодисковых конфигурациях), перечислять её достоинства можно очень долго. Так долго, что поневоле успеваешь задаться вопросом: а есть ли у неё недостатки?

Разумеется, есть. Хотя большая их часть – скорее особенности: например, ограничения при добавлении или удалении накопителей в пуле, или отсутствие поддежки TRIM.

По большому счёту для пользователя Linux’а у ZFS обнаруживается два кардинальных недостатка: некоторая усложнённость её использования, обусловленная юридическими факторами, и высокие требования к аппаратуре.

Первый недостаток если не ликвидирован, то сглажен трудами Брайана Белендорфа [Brian Behlendorf] со товарищи и майнтайнерами прогрессивных дистрибутивов вкупе с примкнувшими к ним независимыми разработчиками. Аппаратные же претензии ZFS мы сейчас и рассмотрим.

Аппаратные потребности

Итак, ZFS предоставляет пользователю весьма много возможностей. И потому вправе предъявлять немало претензий к аппаратной части – процессору (изобилие возможностей ZFS создает на него достаточную нагрузку), оперативной памяти и дисковой подсистеме.

Впрочем, претензии эти отнюдь не сверхъестественные. Так, процессор подойдёт любой из относительно современных, начиная, скажем, с Core 2 Duo. Минимальный объём памяти определяется в 2 ГБ, с оговоркой, что применение компрессии и дедупликации требуют 8 ГБ и более.

Сама по себе ZFS прекрасно функционирует и на одиночном диске. Однако в полном блеске показывает себя при двух и более накопителях. В многодисковых конфигурациях рекомендуется разнесение накопителей на разные контроллеры: современные SSD способны полностью загрузить все каналы SATA-III, и равномерное распределение нагрузки на пару контроллеров может увеличить быстродействие.

К «железным» претензиям добавляются и притязания программные. В первую очередь, ZFS on Linux требует 64-битной сборки этой ОС, поскольку в 32-разрядных системах действует ограничение на адресное пространство физической памяти. Кроме того, в конфигурации ядра должнв быть отключена опция CONFIG_PREEMPT. Поэтому, например, в openSUSE ZFS может использоваться с ядром kernel-default, но не kernel-desktop, каковое, вопреки названию, устанавливается по умолчанию при стандартной настольной инсталляции.

Если вас привлекли достоинства ZFS и не устрашили её «железные» аппетиты, самое время опробовать её в деле. Что потребует знакомства с некоторыми специфическими понятиями.

Терминология

Центральным понятием ZFS является пул хранения данных [zpool]. В него может объединяться несколько физических устройств хранения – дисков или дисковых разделов, причём первый вариант рекомендуется. Но не запрещено и создание пула из одного диска или его раздела.

Каждый пул состоит из одного или нескольких виртуальных устройств [vdev]. В качестве таковых могут выступать устройства без избыточности (то есть всё те же диски и/или их разделы), или устройства с избыточностью – зеркала и массивы типа RAID-Z.

Зеркальное устройство [mirror] – виртуальное устройство, хранящее на двух или более физических устройствах, но при чётном их количестве, идентичные копии данных на случай отказа диска,

RAID-Z – виртуальное устройство на нескольких устройств физических, предназначенное для хранения данных и их контрольных сумм с однократным или двойным контролем чётности. В первом случае теоретически требуется не менее двух, во втором – не менее трёх физических устройств.

Если пул образован устройствами без избыточности (просто дисками или разделами), то одно из vdev, соответствующее ему целиком, выступает в качестве корневого устройства. Пул из устройств с избыточностью может содержать более одного корневого устройства – например, два зеркала.

Пулы, образованные виртуальными устройствами, служат вместилищем для наборов данных [dataset]. Они бывают следующих видов:

  • 

  • 

  • 

  • 

Наборы данных пула должны носить уникальные имена такого вида:

pool_name/path/[dataset_name][@snapshot_name]

Пулы и наборы данных в именуются по правилам пространства имён ZFS, впрочем, довольно простым. Запрещёнными символами для всех являются символы подчёркивания, дефиса, двоеточия, точки и процента. Имя пула при этом обязательно должно начинаться с алфавитного символа и не совпадать с одним из зарезервированных имён – log, mirror, raidz или spare (последнее обозначает имя устройства «горячего» резерва). Все остальные имена, в соответствие с демократическими традициями пространства имён ZFS, разрешены.

А вот об именах физических устройств, включаемых в пул, следует сказать особо.

Модели именования устройств

В современном Linux’е использование для накопителей имён «верхнего уровня», имеющих вид /dev/sda, не является обязательным, а в некоторых случаях и просто нежелательно. Однако правила менеджера устройств udev позволяют определять и другие модели идентификации накопителей. В частности, штатными средствами дисковой разметки openSUSE предусмотрены варианты идентификации по:

  • 

  • 

  • 

  • 

А с полным списком вариантов идентификации блочных устройств можно ознакомиться, просмотрев имена подкаталогов в каталоге

/dev/disk

С идентификацией по метке тома и по UUID, вероятно, знакомо большинство читателей. И к тому же в пространстве имён ZFS они не используются. А вот с идентификацией by-path и by-id нужно познакомиться поближе.

Модель именования by-path использует имена устройств, привязанные к их положению на шине PCI и включающие номер шины и канала на ней. Имя дискового устройства выглядит примерно так:

pci-0000:00:1f.2-scsi-0:0:0:0

Дисковые разделы маркируются добавлением к имени устройства суффикса part#. Модель именования by-path идентифицирует устройства вполне однозначно, и особенно эффективна при наличии более чем одного дискового контроллера. Однако сами имена и устройств, и разделов описываются довольно сложной для восприятия последовательностью. Да и в большинстве «десктопных» ситуаций модель эта избыточна.

Модель идентификации by-id представляет имена носителей информации в форме, наиболее доступной для человеческого понимания. Они образованы из названия интерфейса, имени производителя, номера модели, серийного номера устройства и, при необходимости, номера раздела, например:

ata-SanDisk_SDSSDX120GG25_120823400863-part1

Таким образом, все компоненты имени устройства в модели by-id определяются не условиями его подключения или какими-то правилам, а задаются производителем и жестко прошиты в «железе». И потому эта модель является наиболее однозначной для именования устройств. А также, что немаловажно, строится по понятной человеку логике. Не случайно именно она принята по умолчанию в инсталляторе openSUSE.

Какую из моделей именования устройств выбрать для данного пула – зависит от его назначения и масштабов. Имена «верхнего уровня» целесообразно применять для однодисковых пулов (особенно если в машине второго диска нет и не предвидится, как обычно бывает в ноутбуках). Они же, по причине простоты и удобопонятности, рекомендуются для экспериментальных и разрабатываемых пулов. И очень не рекомендуются – во всех остальных случаях, так как зависят от условий подключения накопителей.

Этого недостатка лишена модель by-id: как пишет Брайан, при её использовании «диски можно отключить, случайно смешать и подключить опять произвольным образом – и пул будет по-прежнему корректно работать». Как недостаток её рассматривается сложность конфигурирования больших пулов с избыточностью. И потому она рекомендуется для применения в «десктопных» и «квартирных» (типа семейного сервера) условиях.

Для больших (более 10 устройств) пулов из дисков, подключённых к нескольким контроллерам, рекомендуется идентификация by-path. Однако в наших целях она громоздка и избыточна.

Наконец, ZFS on Linux предлагает и собственную модель идентификации – /dev/disk/zpool, в котором именам by-path ставятся в соответствие уникальные и осмысленные «человекочитаемые» имена, даваемые пользователем. Модель эта рекомендуется для очень больших пулов, каковых на настольной машине ожидать трудно.

Так что дальше я буду использовать имена «верхнего уровня», говоря об абстрактных или экспериментальных ситуациях, и об именах by-id, когда речь зайдёт о практических примерах применения ZFS.

Включение поддержки ZFS

Для практического использования ZFS on Linux перво-наперво необходимо обеспечить её поддержку в вашем дистрибутиве – ибо по причинам, описанным в предыдущей статье, сама собой она не поддержится ни в одном Linux’е.

Как это сделать, зависит от дистрибутива. В Сети можно найти подробные инструкции для Ubuntu и Gentoo, которые легко распространяются на клоны обеих систем. Не столько инструкции, сколько руководства к самостоятельному действию имеются на сайте проекта ZFS on Linux для абстрактных RPM- и Deb-based дистрибутивов. Я же расскажу о том, как это делается в openSUSE релизов 12.1 и 12.2.

Как вы наверняка догадались, ZFS не поддерживается в openSUSE ни «искаропки», ни в официальных репозиториях. Но зато в репозиториях неофициальных, так называемых «домашних», пакеты её поддержки представлены аж в двух экземплярах: в mUNIX9 и в ghaskins. Точные их адреса легко найти через систему OBS (Open Builging System) по ключевому слову zfs.

Какому из репозиториев отдать предпочтение – вопрос спорный. Первые свои опыты с ZFS on Linux я проводил, основываясь на пакетах из mUNIX9. И они прошли без всяких осложнений, хотя и велись в сугубо экспериментальном режиме. Однако к моменту понимания, что эта система для меня – «всерьёз и надолго», последняя тогда версия zfs имелась только в репозитории ghaskins. Однако его использование требует некоторых дополнительных манипуляций.

Кроме того, в репозитории ghaskins на данный момент имеются пакеты только для openSUSE релизов 12.1 и 12.2. Репозиторий же mUNIX9 охватывает все актуальные ныне версии SLE и openSUSE. включая Tumbleweed и Factory.

Различаются репозитории и набором пакетов. В ghaskins, кроме «рабочих» модулей zfs и spl для ядра default, можно видеть массу отладочных их сборок (рис. 1).

В репозитории mUNIX9 с этим существенно скромнее – имеются модули только для ядра default и для xen (рис. 2)

Так что окончательный выбор я предоставляю читателю. Но на какой бы репозиторий он ни пал, его следует подключить. И сделать это можно любым из трёх способов. Первый – с помощью zypper’а:

# zypper ar -f [URL] [Name]

Второй способ – через модуль Репозитории... центра управления YaST2 посредством кнопки Добавить (рис. 3):

выбора пункта Указать URL (рис. 4):

и ввода необходимых значений в поля Имя репозитория и URL (рис. 5):

Наконец, третий способ, для самых ленивых – отыскать пакеты zfs, spl и сопутствующие через OBS и прибегнуть к «установке в один клик». В этом случае подключение репозиториев будет совмещено с установкой пакетов.

В первых двух же вариантах после подключения репозитория надо будет установить (с помощью zypper’а или модуля управления пакетами YaST’а) следующее (пример дан для репозитория mUNIX9, но из ghaskins потребуются те же компоненты):

Возможно, не вредным окажется и пакет zfs-test. А вот zfs-dracut, предназначенный для создания initrd с поддержкой ZFS, несмотря на его потенциальную нужность, установить не удастся: требуемый для него пакет dracut в openSUSE пока не поддерживается.

Следует учесть, что при использовании ядра kernel-desktop (а скорее всего, так оно и есть) пакет zfs-kmp-default потянет за собой и соответствующее ядро kernel-default. Пункт загрузки которого будет внесён в меню GRUB, но не будет отмечен как умолчальный – этим надо озаботиться самому.

И, наконец, при использовании пакетов из ghaskins потребуется, скорее всего, сделать в каталогах /etc/init.d/rc3.d и /etc/init.d/rc5.d символические ссылки на файл /etc/init.d/zfs. Иначе файловые системы ZFS, к созданию которых мы приближаемся, не будут автоматически монтироваться при старте и размонтироваться при останове системы.

При использовании репозитория mUNIX9 эти действия будут нечувствительно выполнены в ходе установки пакетов.

Вот теперь можно приступать к применению ZFS в мирных практических целях.

Создаём простой пул

Освоив ранее основные понятия, мы научились понимать ZFS. Для обратной же задачи – чтобы ZFS понимала нас – нужно ознакомиться с её командами. Главные из них – две: zpool для создания и управления пулами, и zfs для создания и управления наборами данных. Немного, правда? Хотя каждая из этих команд включает множество субкоманд, с которыми мы со временем разберёмся. Очевидно, что работу с ZFS следует начинать с создания пула хранения. Начнём с этого и мы. В простейшем случае однодисковой конфигурации это делается так:

# zpool create tank dev_name

Здесь create – субкоманда очевидного назначня, tank – имя создаваемого пула (оно обычно даётся в примерах, но на самом деле может быть любым – с учётом ограничений ZFS), а dev_name – имя устройства, включаемого в пул. Каковое может строиться по любой из описанных ранее моделей. И, чтобы не повторяться, напомню: все команды по манипуляции с пулами и наборами данных в них выполняются от лица администратора.

В случае, если в состав пула включается один диск, и второго не предвидится, можно использовать имя устройства верхнего уровня – например, sda для цельного устройства (обратим внимание, что путь к файлу устройства указывать не нужно). Однако реально такая ситуация маловероятна: загрузка с ZFS проблематична, так что как минимум потребуется раздел с традиционной файловой системой под /boot (и/или под корень файловой иерархии), так что команда примет вид:

# zpool create mypool sda2

Однако если можно ожидать в дальнейшем подсоединения новых накопителей и их включения в существующий пул, то лучше воспользоваться именем по модели by-id, например:

# zpool create mypool ata-ata-ST3500410AS_5VM0BVYR-part2

Очевидно, что в случае однодискового пула ни о какой избыточности говорить не приходится. Однако уже при двух дисках возможны варианты. Первый – создание пула без избыточности:

# zpool create mypool dev_name1 dev_name2

где dev_name1 и dev_name1 – имена устройств в принятой модели именования. В приведённом случае будет создано нечто вроде RAID’а нулевого уровня, с расщеплением [stripping] данных на оба устройства. Каковыми могут быть как дисковые разделы, так и диски целиком. Причём, в отличие от RAID0, диски (или разделы) не обязаны быть одинакового размера:

# zpool create mypool sdd sdf

После чего никаких сообщений не последует. No news – good news, говорят англичане; в данном случае это означает, что пул был благополучно создан. В чём можно немедленно убедиться двумя способами. Во-первых, в корневом каталоге появляется точка его монтирования /mypool. А во-вторых, этой цели послужит субкоманда status:

# zpool status mypool

которая выведет нечто вроде этого:

pool: mypool state: ONLINE scan: none requested config:

NAME STATE READ WRITE CKSUM mypool ONLINE 0 0 0 sdd ONLINE 0 0 0 sdf ONLINE 0 0 0

errors: No known data errors

А с помощью субкоманды list можно узнать объём новообразованного пула:

# zpool list mypool NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT mypool 18,9G 93K 18,9G 0% 1.00x ONLINE -

Легко видеть, что он равен сумме объёмов обеих флэшек, если «маркетинговые» гигабайты пересчитать в «настоящие».

К слову сказать, если дать субкоманду list без указания аргумента – имени пула, то она выведет информацию о всех пулах, задействованных в системе. В моём случае это выглядит так:

# zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT mypool 18,9G 93K 18,9G 0% 1.00x ONLINE - tank 199G 20,8G 178G 10% 1.00x ONLINE -

Обращаю внимание, что даже чисто информационные субкоманды вроде list и status требуют прав администратора.

Разумеется, два пула в одной, да ещё и настольной, машине – излишняя роскошь. Так что пул, созданный в экспериментальных целях, подлежит уничтожению, что делается с помощью субкоманды destroy:

# zpool destroy mypool

После чего он пропадёт из списка пулов. А что можно сделать с пулом до его уничтожения, увидим со временем.

«Избыточные» пулы

Избавившись от ставшего ненужным пула, рассмотрим второй вариант – создание пула с зеркальным устройством. Создаём его из двух накопителей одинакового объёма:

# zpool create -f mypool mirror sdf sdg

Проверка показывает, что итоговый пул, как и следовало ожидать, равен объёму одного накопителя:

# zpool list mypool NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT mypool 3,72G 91,5K 3,72G 0% 1.00x ONLINE -

При различии объёмов больший диск будет «обрезан» до объёма меньшего.

Полное зеркалирование любыми, по моему мнению, в настольных условиях – роскошь непозволительная: банальные бэкапы данных проще и надёжнее. Тем не менее, не исключаю, что некоторая избыточность на уровне проверки контрольных сумм может оказаться не лишней, да и не столь накладна. Так что давайте посмотрим и на третий вариант пула из более чем одного устройства – RAID-Z.

Теоретически виртуальное устройство с одинарным контролем чётности, как уже говорилось, можно создать при наличии двух устройств физических. Однако практически это оказывается накладно, особенно если устройства не одинакового размера. Поэтому задействуем под него три накопителя:

# zpool create mypool raidz sdd sdf sdg

что даст нам следующую картину:

# zpool list mypool NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT mypool 11,1G 205K 11,1G 0% 1.00x ONLINE -

Впрочем, как мне кажется, в настольных условиях не стоит выделки и эта овчинка.

Пул кэшируемый

И, наконец, последний вариант организации пула из более чем одного устройства – создание пула с кэшированием. Для чего создаём из двух устройств простой пул без избыточности и подсоединяем к нему устройство для кэша:

# zpool create mypool sdd sdf cache sdg

Очевидно, что устройство для кэширования не должно входить в пул любого рода – ни в простой, ни в избыточный. Что мы и видим в выводе субкоманды list:

# zpool list mypool NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT mypool 18,9G 82K 18,9G 0% 1.00x ONLINE -

где никаких следов его обнаружить не удаётся. Если же появляются сомнения, а подключилось ли оно на самом деле, обращаемся к субкоманде status, которая покажет беспочвенность наших опасений.

Как я уже говорил в обзоре возможностей ZFS, подключение устройства кэширования имеет смысл при наличии большого традиционного винчестера (или винчестеров) и относительно небольшого SSD, которое и играет роль дискового кэша.

О некоторых опциях команды zpool

Команда zpool поддерживает ещё множество субкоманд, предназначенных для экспорта и импорта пула, добавления к нему устройств и изъятия оных, и так далее. Но сейчас я расскажу о некоторых опциях, которые могут оказаться необходимыми при создании пула.

Одна из важный опций – -f: она предписывает принудительное выполнение данной операции и требуется, например, при создании пула из неразмеченных устройств.

Полезной может оказаться опция -n. Она определяет тестовый режим выполнения определённой субкоманды, то есть выводит результат, например, субкоманды zpool create без фактического создания пула. И. соответственно, сообщает об ошибках, если таковые имеются.

Интересна также опция -m mountpoint. Как уже говорилось, при создании пула по умолчанию в корне файловой иерархии создаётся каталог /pool_name, который в дальнейшем будет точкой монтирования файловых систем ZFS. Возможно, что это окажется не самым лучшим местом для их размещения, и, как мы увидим в дальнейшем, это несложно будет изменить. Но можно задать каталог для пула сразу – например, /home/data: это и будет значением опции -m. Никто не запрещает определить в качестве такового и какой-либо из существующих каталогов, если он пуст, иначе автоматическое монтирование файловых систем пула в него окажется невозможным.

Наконец, нынче важное значение приобретает опция ashift=#, значением которой является размер блока файловой системы в виде степеней двойки. По умолчанию при создании пула размер блока определяется автоматически, и до некоторого времени это было оптимально. Однако затем, с одной стороны, появились диски так называемого Advanced Format, с другой – получили распространение SSD-накопители. И в тех, и в других размер блока равен 4 КБ, хотя в целях совместимости по-прежнему эмулируется блок в 512 байт. В этих условиях автоматика ZFS может работать некорректно, что приводит к падению производительности пула.

Для предотвращения означенного безобразия и была придумана опция ashift. Значение её по умолчанию – 0, что соответствует автоматическому определению размера блока. Прочие же возможные значения лежат в диапазоне от 9 для блока в 512 байт (29 = 512) до 16 для 64-килобайтного блока (216 = 65536). В интересующем нас случае четырёхкилобайтного блока оно составляет 12 (212 = 4096). Именно последнее значение и следует указать явным образом при создании пула из винчестеров AF или SSD-накопителей.

Создание файловых систем

Пулы хранения представляют собой вместилища для наборов данных, для манипуляции которыми предназначена вторая из главнейших команд – zfs. Самыми важными наборами данных являются файловые системы, к рассмотрению которых мы и переходим.

Для создания файловых систем предназначена субкоманда create команды zfs, которая требует единственного аргумента – имени создаваемой ФС и обычно не нуждается ни в каких опциях:

# zfs create pool_name/fs_name

Внутри пула можно создавать сколь угодно сложную иерархию файловых систем. Единственное условие – родительская файловая система для системы более глубокого уровня вложенности должна быть создана заблаговременно. Ниже я покажу это на конкретном примере создания файловых систем внутри каталога /home – наиболее оправданное место для размещения наборов данных ZFS.

Начну я немножечко издалека. При стандартной установке openSUSE не обойтись без создания учетной записи обычного пользователя, и, следовательно, в каталоге /home будет присутствовать по крайней мере один подкаталог – /home/username.

Смонтировать же файловую систему ZFS в непустой каталог невозможно, и, значит, мы не можем сразу прибегнуть к опции -m для определения «постоянной прописки» создаваемого пула.

Поэтому для начала делаем для пула «прописку» во временной точке – пусть это будет традиционный /tank:

# zpool create -o ashift=12 tank ata-SanDisk_SDSSDX120GG25_120823400863-part3 ata-SanDisk_SDSSDX120GG25_120823402786-part3

Теперь создаём файловую систему для будущего домашнего каталога:

# zfs create tank/home

А внутри же неё – необходимые дочерние ветви, как то:

# zfs create tank/home/alv

которая потом заменит мой домашний каталог – в нём я не держу ничего, кроме конфигурационных файлов;

# zfs create tank/home/proj

это файловая система для моих текущих проектов, и так далее.

Как и было обещано разработчиками ZFS, процедура ничуть не сложнее, чем создание обычных каталогов. Благодаря этому файловые системы можно легко создавать по мере надобности, для решения какой-либо частной задачи. И столь же легко уничтожать их, когда задача эта выполнена. Что делается таким образом:

# zfs destroy pool_name/fs_name

Использовать субкоманду destroy следует аккуратно: никакого запроса на подтверждение при этом не будет. Правда, и уничтожить файловую систему, занятую в каком-либо текущем процессе, можно только с указанием опции -f, а файловую систему, содержащую системы дочерние, не получится убить и таким образом.

Ни в какой специальной операции монтирования новообразованные файловые системы не нуждаются – оно происходит автоматически в момент их создания, о чём свидетельствует следующая команда:

$ mount | grep tank tank/home on /tank/home type zfs (rw,atime,xattr) tank/home/alv on /tank/home/alv type zfs (rw,atime,xattr) tank/home/proj on /tank/home/proj type zfs (rw,atime,xattr) ...

Для обеспечения монтирования файловых систем ZFS при рестарте машины не требуется и никаких записей в файле /etc/fstab: это также происходит само собой, совершенно нечувствительно для пользователя. Правда, если для файловой системы ZFS определить свойство mountpoint=legacy, то с ней можно управляться и традиционным способом.

Как и для обычного каталога, объём каждой файловой системы ничем не лимитирован, и в момент создания для любой из них потенциально доступно всё пространство пула, которое равномерно уменьшается по мере разрастания файловых систем. На данный момент в моей системе это выглядит так.

Казалось бы, для тех же целей можно ограничиться обычными каталогами. Однако в наборах данных ZFS мы имеем дело с полноценными файловыми системами, для которых могут быть установлены индивидуальные свойства, аналогичные опциям монтирования файловых систем традиционных. Чем мы сейчас и займёмся.

Файловые системы: устанавливаем свойства

При создании файловая система ZFS получает по умолчанию определённый набор свойств, во многом сходный с атрибутами традиционных файловых систем, определяемыми опциями их монтирования. Полный их список можно получить командой

# zfs get all fs_name

Свойств этих очень много, однако далеко не все они представляют для нас интерес. Важно только помнить, что любое из свойств каждой файловой системы можно поменять с помощью субкоманды set и её параметра вида свойство=значение. Причём изменение свойств для материнской системы рекурсивно распространяется на все дочерние. Однако для любой последней свойства можно изменить в индивидуальном порядке. Что я сейчас и проиллюстрирую на примерах.

Так, абсолютно лишним представляется свойство atime, то есть обновление времени последнего доступа к файлам. Оно, во-первых, снижает быстродействие, с другой – способствует износу SSD-накопителей (правда, нынче и то, и другое чисто символичны). Так что отключаем это свойство для всех файловых систем:

# zfs set atime=off tank/home

Аналогичным образом расправляемся и со свойством xattr:

# zfs set xattr=off tank/home

А вот дальше можно заняться и индивидуализацией. Как я уже говорил, в момент создания файловые системы ZFS «безразмерны». Если это не подходит, для них можно установить квоты. Однако я этого делать не буду – в моём случае это приводит к потере половины смысла ZFS. А вот зарезервировать место для критически важных каталогов, дабы его не отъела, скажем, мультимедиа, известная своей прожорливостью, будет не лишним. И потому я для файловых систем tank/home/proj и tank/home/alvустанавливаю свойство reservation. Для файловой системы проектов оно будет максимальным:

# zfs set reservation=10G tank/home/proj

Для остальных ограничусь более скромным гигабайтом резерва.

Далее, поскольку данные в файловой системе tank/home/proj для меня действительно важны, и шутить с ними я склонен даже гораздо меньше, чем с дамами, предпринимаю дополнительные меры по их сохранности путём удвоения числа копий (по умолчанию оно равно 1):

# zfs set copies=2 tank/home/proj

А для данных не столь важных – тех, что часто проще скачать заново, нежели отыскать на локальной машине, можно выполнить и обратную операцию – отказаться от подсчёта контрольных сумм:

# zfs set checksum=off tank/home/media

Для файловых систем, содержащих хорошо сжимаемые данные (например, для моего домашнего каталога, где лежат одни dot-файлы), можно включить компрессию:

# zfs set compression=on tank/home/alv

Я этого не делал: экономия места получается грошовая, а нагрузка на процессор и расход памяти, как говорят, очень приличные. Однако это свойство целесообразно включать в системах с огромными логами, если выделить под них файловую систему в пуле ZFS.

При желании для некоторых файловых систем (например, того же домашнего каталога) можно отключить такие свойства, как exec, setuid, devices – легко догадаться, что результат будет аналогичен указанию опций монтирования noexec, nosuid, nodev для традиционных файловых файловых систем. И, разумеется, для файловых систем, изменение которых нежелательно, можно придать свойство readonly.

Все необходимые свойства файловых систем желательно установить до их наполнения контентом, ибо многие из них (например, компрессия) обратной силы не имеют.

О перемонтировании

После создания файловых систем и задания всех необходимых их свойств наступает психологический момент для перемонтирования их по месту «постоянной прописки» – то есть в каталог /home. Что потребует некоторых подготовительных действий.

Поскольку предполагается, что все новообразованные файловые системы должны быть полностью доступны обычному пользователю (то есть мне, любимому), перво-наперво следует изменить атрибуты из принадлежности – ведь создавались они от имени администратора и принадлежат юзеру по имени root. Для чего даю команду:

# chown -R alv:users /tank/home/*

Теперь нужно скопировать конфиги из каталога /home/alv в /tank/home/alv:

# cp -Rp /home/alv/.* /tank/home/alv/

не забыв про опцию -p для сохранения атрибутов.

Все предыдущие операции можно было выполнять, получив права администратора с помощью команды su (или, при желании, sudo). Причём где угодно – в текстовом виртуальном терминале или в терминальном окне Иксового сеанса (например, в konsole KDE). Теперь же потребуется переавторизоваться в «голой» консоли.

Монтирование файловых систем ZFS в каталог с любым содержимым невозможно, так что требуется очистить каталог /home от следов прежней жизнедеятельности пользователя таким образом:

# rm -Rf /home/alv

При хоть одном активном пользовательском процессе в ответ на это последует сообщение об ошибке. Так что, возможно, перед этим придётся убить все реликтовые процессы, запущенные в Иксах от имени пользователя. Сначала выявляем их командой

# ps aux | grep alv

обращая внимание на идентификаторы процессов (PID). А затем последовательно мочим их в сортире:

# kill -9 ####

Выполнив все указанные действия, определяем для набора данных tank/home свойство mountpoint, что и осуществит перемонтирование:

# zfs set mountpoint=/home tank/home

Теперь остаётся только с помощью команды ls убедиться, что в /home появились новые подкаталоги с нужными атрибутами:

drwxr-xr-x 26 alv users 48 Sep 23 14:27 alv/ drwxr-xr-x 18 alv users 18 Sep 22 02:28 proj/ ...

А команда

# mount | grep /home

покажет нам новые точки монтирования файловых систем:

tank/home on /home type zfs (rw,noatime,noxattr) tank/home/alv on /home/alv type zfs (rw,noatime,noxattr) tank/home/proj on /home/proj type zfs (rw,noatime,noxattr) ...

Как я уже говорил выше, при использовании пакетов из репозитория mUNIX9 на этом дело с подготовкой файловых систем ZFS к практической работе можно считать законченным: при перезагрузке машины все они будут благополучно смонтированы в автоматическом режиме. Пакеты же из ghaskins потребуют ещё одного деяния – создания в каталогах /etc/init.d/rc3.d и /etc/init.d/rc5.d символических ссылок на файл /etc/init.d/zfs.

Вместо заключения

За чертой статьи остались многие вопросы применения ZFS, в частности, экспорта и импорта пулов, совместного использования наборов данных в разных дистрибутивах Linux’а (и, возможно, не только его), создания снапшотов и клонов, восстановления после сбоев. Очень интересно изучить проблему размещения на ZFS корня файловой иерархии и возможность загрузки с неё. Однако надеюсь, что рассказанное на предыдущих страницах позволит читателю оценить достоинства ZFS как универсальной комплексной системы размещения данных. Полагаю, что приведённых сведений будет достаточно и для начала практической работы с ней.

Оглавление

Вступление 1

Колонки 1

2006 1

Новый инсталлятор Debian 1

Процессор Cell и его роль в Linux-революции 2

Open Source: разработчики и спонсоры 2

Kubuntu в роли пасынка? 3

Xubuntu: в благородном семействе прибыло 3

Desktop’изация BSD 4

Семь шагов Linux-дистрибуции 4

LinuxWorld 2006 5

На злобу дня, или Oracle vs Red Hat 5

Будущее Open Source: коммерциализация или сайентификация? 6

2007 6

Скорость загрузки системы: путь на пользовательский десктоп? 6

Debian или Kebian? 6

Linux на Cell: уже реальность? 7

Дети капитана Патрика 8

CRUX – крестоносец идеи 8

Обновление Debian-семейства 9

Мир изменился… 9

Не спрашивай, что ты сделал для Linux’а… 10

SCO’тский вопрос 10

ZFS: конец файловым проблемам? 11

Mandriva на Руси: второе нашествие Бонапарта? 11

Linux и творческая интеллигенция 12

2008 12

Поэзия – Linux’у 12

Nexenta, или еще раз о жирафе Анюте 13

Семинары, семинары… 13

Сделайте мне … хорошо 13

Как вас теперь называть? 14

Ханс Рейзер: точка в деле? 14

Безальтернативность: всегда ли это плохо? 15

Какой Linux учить? 15

LinuxFormat: юбилей в троичном счислении 16

Xfce: назад в будущее? 16

FreeBSD на десктопе 17

Пердем – персональный демон 17

2009 18

Серенада солнечной долины… 18

Файловая система btrfs: Linux-ответ ZFS? 18

Тётя Ася или дядя Джаббер? 19

Нет OEM’ным ОС? 19

Debian GNU/kFreeBSD: знает ли мсье толк в извращениях? 20

Мир без солнца 20

Будут ли машины большими? 21

NILFS выходит из тени 21

Btrfs – ждём стабилизации? 21

Куда развиваться свободному софту? 22

Феномен Juick’и 22

Русская Fedora: первый год жизни 23

GNOME Shell: всё для блага человека 23

2010 24

Дистрибутив Linux: кто он сегодня? 24

Пингвины пишут своими шрифтами 24

Обновления системы: нужны ли они народу? 25

Конец «камнестроения»? 25

Неттопия на практике 25

Незнаменитый офис 26

Fedora в новой сфере? 26

Нативная ZFS для Linux и будущее btrfs 27

Памяти советской геологии 27

KDE 3: реанимация или гальванизация? 28

Судьба OpenSolaris: бессмертна ли мафия? 28

Линуксоид как высшая ступень эволюции Homo sapiens 29

RFRemix 14: сбытие мечт? 29

2011 29

Как читать Linuxformat 29

Парадокс линуксописательства 30

Linux от Oracle 30

ОС Barrelfish: рыбозасолочный цех 31

Linux и OCR – братья на век 31

Куда катится мир? 32

Волхвы-то кричали с того и с сего 32

Linux в «верхнем» образовании 33

О LUG’ах и горе Верблюд 33

Снова Open Source в науке 34

Дети мага Мандрейка 34

Как завладеть миром? 35

2012 35

Куда казаку податься? 35

PCLinuxOS в отечественной редакции 36

Очень грустная колонка… 36

Гибридное видео, или мичуринцы из NVIDIA 36

Блеск openSUSE 37

openSUSE: и на на солнце бывают пятна 37

Во славу Гомера 38

Нативная ZFS – Linux’у! 39

Бич свободных лицензий 39

openSUSE 12.2: детектив вокруг релиза 40

OpenSUSE: первый шаг к релизу 12.3 40

Юстируем шрифты 40

2013 41

О причинах systemd’изации 41

Возвращаясь к PCLinuxOS 41

Немножко о DragonFly… 42

Файловая система для SSD 42

Роман-предупреждение 43

Монотеизм или дуализм? А может – язычество 43

Песнь о потомках Sid’а 44

Куда идёт Kubuntu? 44

Mir или не Mir, вот в чём вопрос 45

Заработать на FOSS: маечки или ехать? 45

Дорога к Mir’у 46

Слово о Cinnamon’е 46

Статьи 47

Ubuntu и Kubuntu: гуманистический Linux 47

Об Ubuntu и Kubuntu 47

Настройка доступа к репозиториям пакетов 48

Основы пакетного менеджмента 49

Команда dpkg сотоварищи 49

Инструментарий apt 50

Kubuntu по русски 51

Борьба за мультимедиа 52

Linux-пресса на Руси: Вопросы истории 53

Идеальный журнал 56

Second Open Source Forum Russia 57

Марк Шаттлворт в Петербурге 58

Выступление 59

Вопросы и ответы 61

Интервью 63

Снова aptitude: режим командной строки 64

Zenwalk Linux: не его ли учить? 68

Применим фильтры 68

Почему Zenwalk? 70

Zenwalk: знакомимся ближе 72

И на прощание 74

Управление rpm-пакетами: нынче не то, что давеча 74

Незнаменитый yum 74

PackageKit – кит пакетного менеджмента 78

openSUSE LiveCD: нетривиальная установка 82

Вступление 82

Live-среда: запуск 83

Подготовка Live-режима 84

Настройка окружения администратора 84

Преамбула к установке 84

Установка 87

Итоги установки 87

Заключение 88

ZFS on Linux: практика применения 89

Обзор возможностей 89

Аппаратные потребности 90

Терминология 91

Модели именования устройств 91

Включение поддержки ZFS 93

Создаём простой пул 96

«Избыточные» пулы 97

Пул кэшируемый 98

О некоторых опциях команды zpool 98

Создание файловых систем 99

Файловые системы: устанавливаем свойства 100

О перемонтировании 101

Вместо заключения 102