Погружение в Salix

В главе двенадцатой, заключительной, я собрал всякого рода рецепты или шпаргалки для решения отдельных частных вопросов, возникающих при настройке и применении разных редакций Salix'а, и при установке в них дополонительных пакетов. Рецепты эти имеют силу и для сына его, Slackel'а. А некоторые могут быть использованы и в родительской Slackware. Порядок их в значительной степени случайный, определяется тем, в какой последовательности мне эти рецепты потребовались или вспомнились.

Искоренение кириллицы из домашнего каталога

В случае выбора русской локализации Salix'а и Slackel'а в домашнем каталоге пользователя, в соответствие со стандартом freedesktop.org, самопроизвольно возникают подкаталоги с кириллическими именами – Загрузки, Документы, Видео, и так далее. Тем, кто активно пользуется CLI для всякого рода файловых операций и тому подобных действий, это доставляет немало неудобств, заставляя в иксовых эмуляторах треминала постоянно переключать раскладку клавиатуры. А в «голой» консоли есть риск поначалу вообще увидеть квадратики вместо русских букв.

Так что искоренение каталогов с русскими именами – не проявление русофобии, а для многих – практическая необходимость. Благо делается это очень просто – одной командой:

$ LANG=C xdg-user-dirs-update --force

Вместо

LANG=C

LANG=POSIX

LANG=en_US

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

Доводка консольного режима: включение мыши в консоли

В Salix'е по умолчанию не включена служба консольной мыши –

gpm

$ sudo -i

Переходим в каталог

/etc/rc.d

# touch rc.gpm

и делаем его исполняемым:

# chmod a+x rc.gpm

А затем в любимом текстовом редакторе (например, в

nano

#!/bin/sh # Start/stop/restart the GPM mouse server: export TEXTDOMAIN=slackware . gettext.sh

if [ «$1» = «stop» ]; then gettext «Stopping gpm..." echo /usr/sbin/gpm -k elif [ «$1» = «restart» ]; then gettext «Restarting gpm..." echo /usr/sbin/gpm -k sleep 1 /usr/sbin/gpm -m /dev/mouse -t imps2 else # assume $1 = start: gettext «Starting gpm:" echo «/usr/sbin/gpm -m /dev/mouse -t imps2" /usr/sbin/gpm -m /dev/mouse -t imps2 fi

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

gpm

Опция -t описывает протокол работы мыши – и, насколько я знаю, подходит для всех ныне существующих устройств этого класса, кроме, возможно, каких-то трекболов и трекпойнтов. Теперь после рестарта машины курсор мыши в виде прямоугольника появится во всех виртуальных консолях (а в Salix'е их всего три). Однако можно не дожидаться перезагрузки, а запустить службу

gpm

# /etc/rc.d/rc.gpm

После этого можно начать доведение до ума консольного режима, имея в руках такое мощное оружие, как мышиный copy and paste.

Доводка консольного режима: русификация вывода

Сразу после установки Salix'а символов кириллицы в консоли не увидеть, хотя на стадии инсталляции была установлена русскую локаль, что можно проверить так:

$ localeLANG=ru_RU.utf8 LC_CTYPE="ru_RU.utf8"LC_NUMERIC="ru_RU.utf8" LC_TIME="ru_RU.utf8" LC_COLLATE=C LC_MONETARY="ru_RU.utf8" LC_MESSAGES="ru_RU.utf8" LC_PAPER="ru_RU.utf8" LC_NAME="ru_RU.utf8" LC_ADDRESS="ru_RU.utf8" LC_TELEPHONE="ru_RU.utf8" LC_MEASUREMENT="ru_RU.utf8" LC_IDENTIFICATION="ru_RU.utf8" LC_ALL=

И, следовательно, вывод команд, где это возможно, должен выводиться по русски. Например, на команду

$ date

Должно последовать такое:

Cp мaй 7 17:01:36 MSK 2014

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

За загрузку консольных шрифтов отвечает файл

rc.font

/etc/rc.d

unicode_start ter-v16n

Это наследие давних времён зари юникодизации Linux-консоли, и ныне не работает. Так что смело удаляем её, а взамен вписываем такую:

setfont -v ter-v22b

где

-v

ter-v22b

/usr/share/kbd/consolefonts

b

Сделанного достаточно, в чём легко убедиться, запустив

rc.font

-v

3aгpyжaeтcя 512-cимвoл шpифтa 11x22 из фaйлa /usr/share/kbd/consolefonts/ter-v22b.psf.gz3aгpyжaeтcя юниĸoднaя тaблицa oтoбpaжeния...

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

date

Ещё раз повторяю: никаких дополнительных телодвижений, которые можно встретить в сетевых описаниях, типа старта/стопа режима

unicode

Terminus

LatArCyrHeb

LatGrkCyr

LatKaCyrHeb

Теперь для полноты счастья остаётся только обеспечивать и ввод символов кириллицы – например, чтобы комментировать свои конфиги и скрипты на языке родных осин. Этим делом ведает файл

/etc/rc.d/rc.keymap

#!/bin/sh# Load the keyboard map. More maps are in /usr/share/kbd/keymaps. if [ -x /usr/bin/loadkeys ]; then /usr/bin/loadkeys -u us fi

Здесь достаточно заменить английско-американскую раскладку

us

$ ls ls /usr/share/kbd/keymaps/i386/qwerty/ru*

Например, на такую:

if [ -x /usr/bin/loadkeys ]; then /usr/bin/loadkeys -u ruwin_cplk-UTF-8

Это русская раскладка для кодировки UTF-8, соответствующая варианту winkeys из Иксов, с переключением латиница/кириллица клавишей CapsLock. Тем же, кто когда-то учился печатать на пишущей машинке, и так и не смог привыкнуть к маразму под названием «вариант winkeys», могу предложить мою раскладку, соответствующую иксовому варианту Typewrite Legacy –

ru-type-legacy_cplk-UTF-8

rc.keymap

/usr/bin/loadkeys -u ru-type-legacy_cplk-UTF-8

Впрочем, ностальгия по временам, когда «Эрика даёт четыре копиии» – не единственная причина для применения применения этой «старомодной» раскладки: знаки препинания на нижнем регистре (инвертированно с цифрами) зело способствуют скорости печати. А для массового ввода цифири NumPad ещё не запретили.

Thunar и архивы

Описанная ниже проблемка возникает, вероятно, только при базовой установке Salix'а – в установке FULL всё необходимое имеется по умолчанию.

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

thunar-archive-plugin

$ sudo slapt-get -i thunar-media-tags-plugin

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

Просмотр каталога

/usr/libexec/thunar-archive-plugin

$ sudo slapt-get -i engrampa

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

tar

xz

gzip

bzip2

cpio

zip,

unrar

p7zip

slackbuilds

slapt-src

Thunar и права root’а

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

sudo

Благо, сделать это в Thunar'е не просто, а очень просто, без установки каких-либо дополнительных плагинов – достаточно обратиться к пункту его главного меню Правка -> Особые действия, отвечающему за дополнительные пункты меню контекстного, вызываемого щелчком правой кнопки мыши. По умолчанию в этом меню всего один дополнительный пункт – Открыть терминал:

Рисунок 12-1. Thunar: особые действия

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

Рисунок 12-2. Пример особого действия: открыть терминал

Однако имеющийся на ней зелёный плюсик, как легко догадаться, позволяет добавлять собственные особые действия произвольного назначения и количества. Ибо вызывает ещё одну панель с двумя вкладками. В поля первой заносятся имя действия, его описание и соответствующая команда:

Рисунок 12-3. Создание нового действия

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

Рисунок 12-4. Условия особого действия

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

Рисунок 12-5. Пример особого действия: редактирование файла от root'а

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

Рисунок 12-6. Выбор пиктограммы для нового действия

Во второй же вкладке сохраняем шаблон и отметку на текстовых файлах, как оно было по умолчанию.

Далее создаём пункт открытия каталога в Thunar'е от лица суперпользователя. Здесь всё столь же очевидно:

Рисунок 12-7. Редактирование действия: название, описание, команда

Только во второй вкладке отметку условия появления переносим на каталоги:

Рисунок 12-8. Редактирование действия: в контекстном меню для каталогов

И последнее – это открытие root'ового терминала:

Рисунок 12-9. Терминал с правами root'а

Здесь условием появления также будет каталог.

После этого контекстное меню при фиксации на имени файла приобретёт такой вид:

Рисунок 12-10. Контекстное меню для файла

А при фиксации на каталоге будет выглядеть так:

Рисунок 12-11. Контекстное меню для каталога

В любом случае после выбора одного из этих пунктов появится панель

gksu

Рисунок 12-12. Панель авторизации

gksu

После чего соответствующая программа (Thunar, текстовый редактор или терминал) будут открыты с правами администратора.

Как видите, в Thunar'е, в отличие от некоторых других файловых менеджеров (на которые не будем указывать пальцем) обеспечить доступ суперпользователя к файлам и каталогам гораздо быстрее, чем об этом рассказать.

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

~/.config/Thunar/uca.xml

Thunar и поиск файлов

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

Первое из таких средств – утилита Catfish, которая обнаруживается в системе после полной инсталляции Salix'а. А при выборе базовой установки её легко добавить посредством

$ sudo slapt-get -i catfish

Утилита Catfish – нечто вроде интегратора таких команд, как find (задействована по умолчанию), locate, slocate и любых других «искателей». Как её можно прикрутить к Thunar'у? С помощью всё того же волшебного пункта Правка -> Особые действия, добавив её вызов в контекстное меню. Для чего заполняется такая форма:

Рисунок 12-13. Редактированиедействия: Поиск

В качестве условия появления отмечается боксик Каталоги.

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

mate-search-tool

mate-utils

mate-desktop

$ sudo slapt-get -i mate-utils

А затем встраиваем

mate-search-tool

Рисунок 12-14. MATE Search меню Thunar'а

После чего отыскиваем в текущем каталоге нужный файл по его имени или маске:

Рисунок 12-15. MATE Search: поиск по маске имени

А дополнительно – и по входящему в него фрагменту текста:

Рисунок 12-16. MATE Search: поиск по тексту

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

find

grep

zsh

Thunar и Яндекс.Диск

Клиент Яндекс.Диска для Linux существует, насколько я знаю, только в rpm- и deb-виде, то есть в формат Salix'а не вписывается. Конечно, есть подозрение, что с помощью утилиты

rpm2tgz

Делается это действительно просто: запускается Thunar, через закладку боковой панели открывается Обзор сети и в адресной строке вместо нечленораздельного

network:///

davs://username@webdav.yandex.ru/

После этого следует запрос пароля на доступ к сервисам Яндекса – и всё: с Яндекс.Диском можно работать через Thunar как с обычным локальным носителем. Только немного медленней. В частности, он обещал вознести мои четыре «земных» гигабайта на яндексовое облако часов за десять-двенадцать. И обещание выполнил и перевыполнил...

Шпаргалки по установке пакетов: gThumb

В Salix'в качестве штатного вьювера графических файлов применяется Viewnior (а не Risretto, как я почему-то думал раньше), которую можно обнаружить в пункте Графика главного меню Xfce после полной инсталляции. Это замечательно простая и быстрая программа, имеющая даже некоторые функции редактирования – в частности, кадрирования изображений. Кроме того, она позволяет подключать и внешний графический редактор для более тяжёлых работ (по умолчанию – GIMP). Однако у неё нет таких важных для любого линуксописателя функций, как коррекция яркости/контрастности, а главное – масштабирования изображений. Согласитесь, что применять для этих целей GIMP несколько неоправданно.

Я с давних пор привык использовать во всех Gtk-системах программу gThumb. Она тоже в первую очередь предназначена для просмотра изображений, однако наделена теми самыми функциями, которых не хватает Viewnior'у. И потому сразу после первой установки Salix'а занялся её поисками. В репозитории бинарников gThumb не обнаружился, зато легко нашёлся в списке штатных слакбилдов:

$ slapt-src --search gthumb gthumb:3.2.4 - gThumb ( An image viewer )

Однако собрать этот пакет сразу командой

slapt-src

itstool

$ slapt-get --search itstool itstool-1.2.0-x86_64-1 [inst=нет]: itstool (Translate XML documents with PO files) itstool-2.0.2-noarch-1gv [inst=нет]: itstool (Translate XML documents with PO files)

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

$ sudo slapt-get -i itstool

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

itstool-2.0.2-noarch-1gv

$ sudo slapt-src --search gthumb

соберёт вожделенный вьювер-редактор без всяких проблем – по завершении процедуры он обнаружится в пункте Графика главного меню Xfce.

Шпаргалки по установке пакетов: GPRename

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

Снимок экрана - 25.04.2014 - 15:39:52.png

[название статьи]-[номер рисунка].png

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

Одна из таких утилит,

thunar-bulk-rename

В штатном репозитории Salix'а пакета с таким именем нет. Зато он обнаруживается среди его слакбилдов:

$=> slapt-src --search gprename gprename:5 - GPRename (A GTK2 batch renamer for files and directories)

Так что дело за малым – собрать его:

$=> sudo slapt-src -i gprename Следующие пакеты будут установлены: gprename Следующие зависимые слакбилды будут собраны и установлены: perl-libintl Продолжить? [y/N]

Приятно, что в данном случае зависимости пакета не приходится выискивать – они предлагаются к установке автоматом. И с этим предложением нужно просто согласиться. После чего программу можно вызвать из главного меню: Инструменты -> GPRename.

Шпаргалки по установке пакетов: Chromium

Единственным штатным браузером, устанавливаемых в ходе развёртывания системы, в Salix'е является Midori, медленный, мало функциональный и работающий часто, мягко говоря, не без нареканий. Правда, пользоваться им никто не неволит – в репозитории дистрибутива имеется FireFox, который без проблем устанавливается стандартным образом.

А вот Chromium'а нет ни в официальном репозитории бинарников, ни в списке штатных слакбилдов. Однако из этой ситуации есть два выхода: сложный и простой. Первый – зайти на величайший в мире слакбилдник SlackBuilds.org, где он легко находится поиском, а затем:

• скачать архив слакбилда

chromium.tar.gz

/tmp

• распаковать архив – после этого там образуется подкаталог

path2/chromium

• скачать в этот подкаталог архив исходников – в данном случае

chromium-31.0.1650.57.tar.xz

• присвоить файлу

path2/chromium/chromium.SlackBuild

$ sudo chmod a+x chromium.SlackBuild

• проверить, установлен ли пакет

yasm

$ sudo slapt-get -i yasm

• запустить слакбилд на исполнение:

$ sudo ./chromium.SlackBuild

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

Завершится сборка сообщением, что

Slackware package /tmp/chromium-31.0.1650.57-x86_64-1_SBo.tgz created.

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

$ sudo installpkg chromium-31.0.1650.57-x86_64-1_SBo.tgz

А затем новый браузер можно запустить из главного меню Xfce через Интернет -> Chromium.

Однако если избытка времени или терпения ждать нет, можно прибегнуть к простому способу: зайти на блог Эрика Хамелирса (Eric Hameleers), не менее известного как AlienBOB, или открыть его репозиторий. Где имеются регулярно обновляемые бинарнки Chromium'а, а также ещё много чего полезного, в частности, сборки LibreOffice и собственные разработки автора.

Шпаргалки по установке пакетов: Мультимедиа

Рецепт этой шпаргалки потребуется при установке Salix'а в варианте BASIC – в варианте FULL необходимости в большинстве описанных ниже действий не возникнет.

Для начала надо заметить, что ни малейшего Pulseaudio в Salix'е нет – управление звуком осуществляется через Alsa, и все необходимые для того пакеты в базовой установке присутствуют по умолчанию, остаётся только установить микшер:

$ sudo slapt-get -i xfce4-mixer

После этого я установил

mplayer2

mplayer

$ sudo slapt-get -i mplayer2

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

$ mplayer parh2/filename

или даже

$ mplayer parh2/*.mp3|*.flac

При желании к нему можно подобрать в официальном репозитории графический фронт-энд –

gnome-mplayer

smplayer

Шпаргалки по установке пакетов: выпадающий терминал Tilda

Некогда, с подачи Сергея Голубева, проникся я идеей выпадающих (drop-down) терминалов – тогда в виде Yakuake, ибо работал преимущественно в среде KDE. Проникся настолько, что почти перестал применять обычный эмулятор терминала: практически во всех случаях удобней оказывалось прибегнуть либо к терминальному окну, встроенному в файловый менеджер или текстовый редактор, либо вызвать терминал выпадающий.

Переключившись на рабочие среды, основанные на Gtk (Xfce, Unity, Cinnamon), я начал подыскивать аналогичные средства эмуляции терминального режима. Увы, с терминалами, встроенными в файловые менеджеры, оказалось плохо: плагины для Nautilus'а и Nemo или не работали, или выглядели отвратительно, а для Thunar'а таковых не имелось вообще. Зато с выпадающими терминалами выбор имелся – я опробовал Terra и Guake, в конце концов остановившись на последнем.

Начиная «погружение в Salix» с его средой Xfce по умолчанию, я был уверен, что в шесть секунд найду какой-нибудь «выпадающий» аналог. Не тут-то было: в репозиториях бинарных пакетов не обнаружилось ни одного знакомого имени, а среди слакбилдов имелись Yakuake (который, принадлежа среде KDE, совсем не гармонировал с «головной редакцией» дистрибутива) и YeahConsole, который сам по себе не столько терминал, сколько оболочка для таких программ, как XTerm, rxvt и так далее.

И тогда я вспомнил, что в одном из обсуждений темы выпадающих терминалов на Джуйке упоминался drop-down терминал Tilda, до которого у меня тогда руки так и не дошли. Наудачу набрав его имя в команде

$ slapt-src -s tilda

я с радостью обнаружил наличие его слакбидла:

tilda:0.9.6 - tilda (an FPS-style terminal)

Каковой и был немедленно установлен:

$ sudo slapt-src -i tilda

При первом запуске из главного меню Xfce (он попал в раздел Инструменты) появилась панель его конфигурирования:

Рисунок 12-17. Tilda: основные нсатройки

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

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

Рисунок 12-18. Tilda: настройка внешности

А во вкладке Сочетание клавиш устанавливается способ вызова терминала – по умолчанию почему-то это клавиша F1. Что я немедленно заменил на стандартную для программ такого рода клавишу F12:

Рисунок 12-19. Настройка вызова

После выполнения всех настроек Tilda наконец запускается в примерно таком виде:

Рисунок 12-20. Tilda: вид после запуска

Теперь остаётся только обеспечить её автозапуск, например, через главное меню: Настройки -> Сеансы и запуск -> Автозапуск приложений:

Рисунок 12-21. Tilda: внесение в автозапуск

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

Никаких других комбинаций клавиш, кроме вызова Tilda, установить нельзя. Но в её окне работают все стандартные для большинства терминальных программ хоткеи:

• Shift+Control+T – создание новой вкладки;

• Shift+Control+W – закрытие текущей вкладки;

• Control+PageUp – переход на предыдущую вкладку;

• Control+PageDown – переход на следующую вкладку;

• Shift+Control+C – копирование выеделнного фрагмента в буфер;

• Shift+Control+V – вставка содержимого буфера позицию курсора;

• Shift+Control+Q – выход из Tilda.

На этом функционал программы исчерпывается. Нельзя ни перемещать вкладки, ни давать им произвольные имена (например, нумеровать), нет возможности расщепления терминального окна. Однако свои основные функции – представить интерфейс командной строки в нужном месте и в нужное время, Tilda выполняет исправно и к тому же быстро.

Шпаргалки по установке пакетов: VirtualBox

Виртуальная машина входит для меня в категорию «необходимого и достаточного». С давних пор я привык использовать в этом качестве VirtualBox. Однако в официальном репозитории Salix'а его не обнаружилось, а версия из его же слакбилдов рассчитана только на 32-битные системы. Так что остаётся официальный сайт проекта, где и версия его обычно более новая. Правда, среди Linux-хостов среди представленных дистрибутивов пакета именно для Slackware не оказалось. Тем не менее, я решил, что в этом качестве должен сгодиться All distributions, версию которого для 64-битной архитектуры и скачал.

Дальше – всё как всегда, и как всегда очень просто. Сначала скачанному файлу надо придать бит исполняемости:

$ chmod a+x VirtualBox-4.3.10-93012-Linux_amd64.run

А затем эту исполняемость претворить в действительность:

$ sudo ./VirtualBox-4.3.10-93012-Linux_amd64.run

Обращая внимание на форму аргумента – в Salix'е по традиции текущий каталог не числится в умолчаниях значений переменной

PATH

Всё, можно запускать VirtualBox и создавать виртуальные машины. Нужно только проследить, чтобы имелась группа

vboxusers

Интерфейс Virtualbox'а основывается на библиотеке Qt, поэтому при первом запуске в среде Xfce он выглядит вполне отвратительно. Что исправимо легко: Главное меню -> Настройки -> Qt4 config, где для Qt-приложений устанавливается стиль, соответствующий настройкам рабочего стола Xfce. После чего Virtualbox выглядит так же, как и все остальные программы для этой среды.

Шпаргалки по установке пакетов: Komodo Editor

Полюбив с недавних пор Komodo Editor (далее – KE), применяемый в Mint'е, я озаботился его установкой и в Salix'е.Поиск готового пакета в репозиториях Salix'а и среди его Slackbuild'ов успехом не увенчался. Не обнаружился KE и ни в одном из дополнительных репозиториев для Slackware и её клонов (их список – в приложении). Однако оставался вариант установки бинарного пакета с официального сайта. Благо процесс этот прост и включает получение архива, распаковку его в любой временный каталог и запуск установочного сценария от имени пользователя или, как сделал я, администратора:

$ sudo ./install.sh

Благодаря последнему моменту при выборе каталога для установки KE есть возможность поместить его в

/opt/Komodo-Edit-8.5.4/

/opt/Komodo-Edit-8.5.4/lib/mozilla/komodo

/usr/local/bin/komodo

$ sudo ln -s /opt/Komodo-Edit-8.5.4/lib/mozilla/komodo /usr/local/bin/komodo

После этого KE под именем Editor самопроизвольно появяется в секции Разработка главного меню Xfce, откуда и запускается в последующем.

Для запущенного KE можно первым делом выполнить его русификацию его интерфейса. Пакет русификации усилиями Labogrado собран в виде расширения для KE — файла

localru-*-ko.xpi

Установка русификатора выполняется через меню KE: Tools -> Add-ons, что вызывает такую панель:

Рисунок 12-22. Komodo Editor: панель дополнений

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

Рисунок 12-23. Komodo Editor: выбор источника дополнений

А по выборе нужного файла в следующей панели нажимается кнопка Install Now:

Рисунок 12-24. Komodo Editor: установка дополнения

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

Dolphin и Root

В незапамятные времена, когда Konqueror был ещё чисто файловым менеджером, и на лавры браузера даже не замахивался, появилась в нём такая опция в контекстном меню – Edit as root для единимчного файла и Open as root для каталога. Было это, повторяю, очень давно, когда во всяких Nautilus'ах и Thunat'ах ничего продобного и в плагинах не было, не то что штатно. Хотя очень хотелось – отсюда в итоге и пошли всякие Nemo с Marlin'ами, да и особые действия в Thunar'е. А вот в самом Nautilus'е – тоже, конечно, хотелось, да кололось, потому там объявили эту фичу ненужной и народу зело вредящей.

Надо сказать, что в смутное время перехода KDE на 4-ю ветку, и замену Konqueror'а (который из лучшего файлового менеджера того времени превратился в посредственный браузер, а потом и вовсе вышел в тираж) Dolphin'ом фича запуска файлового менеджера, терминала или текстового редактора с правами root'а то исчезала, то вновь появлялась. Пока как штатная функция не пропала вовсе.

Но не пропало её дело. Оно воплотилось в плагине под названием Simple Root Actions Menu.Каковой и призван выполнять все указанные выше действия от имени и по поручению локальной администрации. А, как будет сказано ниже, ещё и некоторые другие.

Обрести этот плагин, казалось бы, просто. Для этого достаточно зайти в настройки Dolphin'а, перейти там в пункт Действия, нажать на длинную педаль Загрузить новые действия, отыскать среди кандидатов на загрузку вышеупомянутый SRAM (не подумайте плохого – это аббревиатура от названия плагина) и нажать на кнопку Установить:

Рисунок 12-25. Dophin: установка дополнений

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

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

Казалось бы, SRAM'ота, да и только? Отнюдь, если прочитать то, что пишет по этому поводу автор (там же, по кнопке Сведения). А пишет он, что его плагин (aka плазмоид) надо, кто бы мог подумать, инсталировать.

Так что вопрос придётся решать большей кровью, и на земле своей. То есть отправляться на kde-apps.org, отыскивать там плагин по ключевым словам

simple root actions menu

$ ./sram_install -s

Да ещё и прочитавши предварительно

README

Правда, в чтении

README

-s

Рисунок 12-26. Dophin: установка Simple Root Actions

Она абсолютно прозрачна. Замечу только, что по умолчанию предлагается подключить SRAM к файловым менеджерам Konqueror'у и Dolphin'у, а для редактирования задействовать KWrite и Kate. Но можно ограничиться в первом случае Dolphin'ом (тем более, что при базовой установке Salix'а с KDE Konqueror'а просто нет), а во втором – KWrite, поскольку Kate обычно используется для более серьёзных целей.

Так или иначе, но по завершении установки плагина в контекстном меню Dolphin'а действительно появится пункт Как root, а в нём – несколько подпунктов:

Рисунок 12-27. Dophin: вид меню после установки плагина

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

Поддержка f2fs и nilfs2

На этой странице речь пойдёт о поддержке в Salix'е двух файловых систем, специально предназначенных для твердотельных накопителей – nilfs2 и f2fs. Хотя обе они официально включены в ядро Linux достаточно давно (первая – с 2009 года, вторая – с 2012), ни та, ни другая пока не получили широкого распространения. И, насколько мне известно, штатно не поддерживаются инсталлятором ни одного из современных дистрибутивов, в том числе и инсталлятором Salix. И скоро станет понятно, почему. Однако, как будет видно из дальнейшего, включить их поддержку в нём можно.

Для начала легко убедиться в том, что ядро текущей версии Salix'а собрано с модульной поддержкой обеих интересующих нас файловых систем:

$ ls /lib/modules/3.10.17/kernel/fs/{nilfs2,f2fs} /lib/modules/3.10.17/kernel/fs/f2fs: f2fs.ko

/lib/modules/3.10.17/kernel/fs/nilfs2: nilfs2.ko

После этого соответствующие модули следует загрузить:

$ sudo modprobe nilfs2 $ sudo modprobe f2fs

И удостовериться в успехе этой операции:

$ lsmod | grep nilfs2 nilfs2 147232 0 $ lsmod | grep f2fs f2fs 141479 0

Для работы с любой файловой системой (создания, монтирования etc.) необходим соответствующий инструментарий, и героини моего сегодняшнего рассказа – не исключение. Для f2fs он в виде пакета легко находится в штатном репозитории:

$ slapt-get --search f2fs f2fs_tools-1.2.0-x86_64-1_SBo [inst=нет]: f2fs_tools (Userland tools for the f2fs filesystem)

И столь же непринуждённо устанавливается:

$ slapt-get --install f2fs_tools

А вот за инструментами для nilfs2 придётся лезть в слакбилды:

$ slapt-src --search nilfs nilfs-utils:2.1.5 - nilfs-utils (Utilities for NILFS)

Впрочем, и этот пакет собирается без всяких проблем:

$ sudo slapt-src -i nilfs-utils

Теперь с обеими файловыми системами можно работать – например, я отвёл под каждую из них по флешке объёмом 4 ГБ (больше свободных не было) на предмет последующего сравнения их быстродействия:

$ sudo /mkfs.nilfs2 -f -K /dev/sdf1 $ sudo /mkfs.f2fs -t 0 /dev/sdg1

В первой команде опция

-f

-K

-t 0

К слову – после включения поддержки наших героинь и установки надлежащего инструментария они появляются и в списке доступных для создания через Gparted:

Рисунок 12-28. Файловые системы f2fs и nilfs2 в меню GParted

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

/etc/modprobe.d/

nilfs2.conf

f2fs.conf

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

/etc/rc.d/rc.modules

/etc/rc.d/rc.modules-3.10.17

### Filesystem support ###

достаточно вписать такие строки:

/sbin/modprobe f2fs /sbin/modprobe nilfs2

чтобы всё стало замечательно.

Теперь, после рестарта машины, при подключении флешки с nilfs2 соответствующее ей устройство появляется в списке устройств файлового менеджера Thunar. То есть, казалось бы, может быть смонтировано обычным пользователем, верно?

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

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

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

/etc/fstab

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

Где

/dev/sdf1

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

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

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

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

Поддержка ZFS

Включение поддержки ZFS было одним из первых моих деяний после установки Salix'а – все мои рабочие данные расположены на

zpool

Как и следовало ожидать, поиск по ключевому слову

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

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

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

# 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

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

$ 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