Алексей Федорчук - Погружение в Salix

• Название: Погружение в Salix
• Автор: Алексей Федорчук
• Жанр: Программное обеспечение

Эта электронная книжка, aka e-book, посвящена дистрибутиву Salix – одному из «клонов» Slackware. Он интересен и сам по себе. Но также и тем, что среди всех потомков старейшего из выживших дистрибутивов он в наибольшей степени наследует особенности родительской системы. И потому знакомство с ним может рассматриваться (в том числе и) как самый быстрый и простой метод вхождения в мир Slackware. Ибо фраза «Если ты знаешь Slackware – ты знаешь Linux» до сих пор не потеряла своей актуальности.

Настоящая книжка не является руководством по Salix, Slackware или, тем более, по Linux'у вообще. Нет, это описание дистрибутив-специфических особенностей Salix'а – тех, которые показались мне интересными, и которые я задействовал в своей практической работе.

Основу книжки составили заметки о Salix на Блогосайте и цикл статей, размещённых на IBM developerWorks (содержание его здесь). Ныне они исправлены, дополнены и причёсаны, так что полного совпадения с материалами, ранее размещёнными на указанных ресурсах, нет.

Непосредственным стимулом к оформлению всех изложенных материалов послужило желание моего сына Виктора погрузиться в Salix самому и приобщить к нему сестру Ольгу. Так что им эта e-book'а и посвящается.

---

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

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

/dev/sdf1 /mount_point f2fs noauto,users,rw 0 0

Где /dev/sdf1 – первое устройство после подключённых постоянно. А точке монтирования нужно задать атрибуты принадлежности нужного пользователя. Причём сделать это обязательно после первого подключения устройства – в этот момент оно самопроизвольно становится принадлежащим root'у. Хотя установленная потом принадлежность пользователю в дальнейшем сохраняется. Об этом глюке я некогда писал. Судя по тому, что с тех пор прошёл год, бага приобрела статус фичи.

Тем не менее, после всего проделанного с устройством, несущим f2fs, можно работать почти нормально. Почти – потому что нет никакой гарантии, что оно будет найдено системой после отключения и повторного включения в том же сеансе. Это относится, кстати, и к nilfs2.

И ещё: при совместном использовании устройств с f2fs и nilfs нужно следить, чтобы первое было включено раньше второго, иначе, ясное дело, «буковки» не совпадут.

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

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

Поддержка ZFS

Включение поддержки ZFS было одним из первых моих деяний после установки Salix'а – все мои рабочие данные расположены на zpool'е, который должен быть доступен для всех установленных систем. Иначе они годились бы только «на посмотреть». Правда, я был уверен в успехе решения этой задачи, поскольку из сетевых материалов знал, что в Slackware поддержка ZFS on Linux в принципе существует, а Slackware и Salix – братья навек. Однако всё оказалось гораздо проще, и необходимые пакеты нашлись, не выходя из границ родных репозиториев.

Как и следовало ожидать, поиск по ключевому слову zfs в официальном репозитории результата не дал: бинарные модули для поддержки этой файловой системы имеют мали смысла, так как привязаны к версии ядра. Но зато среди слакбилдов легко обнаружился и zfs-on-linux.SlackBuild, и spl-solaris.SlackBuild. Кроме них, требуется также пакет kernel-headers (был установлен по умолчанию при начальной инсталляции) и исходники ядра той же версии, которая используется в системе. Так что для начала я определил таковую командой

$ uname -a

Linux salix 3.10.17 #2 SMP ...

После чего присвоил себе перманентные права администратора (далее они будут нужны постоянно)

$ sudo -i

и установил соответствующий пакет:

# slapt-get --i kernel-source-3.10.17-noarch-2

Обращаю внимание, что требуется именно uname -a, потому что uname -r не даёт номера сборки, который не менее важен.

Далее последовательно были собраны требуемые слакбилды – сначала:

# slapt-src -i spl-solaris

а затем

# slapt-src -i zfs-on-linux

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

Следующий шаг – подключение соответствующих модулей

# sudo modprobe zfs

и проверка результатов этого деяния:

# lsmod |grep zfs zfs 997378 5 zunicode 320867 1 zfs zavl 4875 1 zfs zcommon 32148 1 zfs znvpair 49518 2 zfs,zcommon spl 123549 5 zfs,zavl,zunicode,zcommon,znvpair

Перед импортом существующего пула я не забыл создать каталог – точку монтирования его datasets

# mkdir /home/data

и назначить для него «правильного хозяина»:

# chown -R alv:users data

Обращаю внимание: во всех используемых мной Linux-системах первый пользователь, то есть я, любимый, имеет UID 1000. Если в системах моего читателя это не так (например, есть дистрибутивы, присваивающие первому юзеру UID 500, возможно, существуют и другие варианты), то «право принадлежности» надо указывать в численном выражении. Что же до принадлежности группе и её GID, то в данном (моём) случае это рояля не играет: GID основной группы первого пользователя, как бы она ни называлась словами (users или username) во всех поих случаях равен 1000. Если это важно для читателя – следует учесть и этот фактор.

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

Теперь – самый ответственный момент, импорт существующего пула:

# zpool import -f data

Проверка показывает, что он прошёл успешно:

# zpool status pool: data state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM data ONLINE 0 0 0 sda3 ONLINE 0 0 0 sdb3 ONLINE 0 0 0

errors: No known data errors

Да ещё и все дейтасеты, входящие в пул, сами собой смонтировалсь куда надо:

# zfs mount data /home/data data/media /home/data/media data/other /home/data/other data/proj /home/data/proj data/vbox /home/data/vbox

Так что мой пул данных полностью пригоден к работе...

... увы, до перезагрузки системы. После которой ни малейших следов смонтированных файловых систем zpool'а мы не обнаруживаем. Хотя сам пул задействован, и команда zpool status возвращает правильный ответ, такой же, как раньше. Согласно ZFS on Linux FAQ, это ситуация достаточно обычная (в частности, с ней же я сталкивался в тестовых вариантах Ubuntu Trusty). И тот же документ (в том числе и в русском переводе) предлагает в каждом дистрибутиве, не входящем в его «белый список» (а Slackware в него не входит) решать её силами рук самих утопающих.

Будучи одним из представителей последних, я, конечно, легко решил её командой

$ sudo zfs mount -a

после которой все файловые системы в /home/data оказываются на своих местах. Однако это не дело – заниматься таким безобразием каждый раз после рестарта системы.

Процесс следует автоматизировать. Как? Теоретически рассуждая, разными способами. Я для начала избрал самый грубый, но простой, вспомнив о палочке-выручалочке каждого нерадивого слакварщика – файле /etc/rc.d/rc.local, в который можно запихать всё невпихуемое в другие места. По умолчанию он пуст, но я это быстро исправил, вписав туда строку

zfs mount -a

обеспечивающую монтирование всех файловых систем подключённого пула ZFS при старте системы. А для симметрии добавил в /etc/rc.d/rc.local_shutdown строку

zfs unmount -a

выполняющую обратную процедуру при выходе.

После этого проблем с доступом к файловым системам ZFS больше не наблюдалось. Правда, как легко догадается читатель, до обновления ядра – благо, автоматически оно обновляться не будет, так как входит в состав исключений. Однако если необходимость в пересборке или апгрейде ядра всё-таки возникнет – придётся также пересобрать модули zfs-on-linux и spl-solaris, сами собой они не соберутся.

Пара слов в заключение

А теперь пора вернуться к вопросу, поднятому в главе первой: для кого же предназначен Salix? Кому он может быть нужен? В ряде глав (например, восьмой и девятой), обращаясь к конкретным примерам, я не случайно акцентировал внимание на назначении пакетов, собираемых из слакбилдов: среди них в изобилии встречаются программы для научной работы, причём в самых различных областях, от молекулярной биологии до GIS. Поэтому думается, что Salix – это замечательный инструмент для научных работников. То есть тех, кто, с одной стороны, не хотел бы очень сильно отвлекаться от своей непосредственной деятельности, углубляясь в детали устройства системы. Но, с другой стороны, при необходимости не погнушался бы это сделать.

Приложение. Slackware: дополнительные репозитории

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

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

Репозиторий Slackware