архив
Zenwalk
Приобщение к Linux
2008-06-25
Интермедия 4.1. Zenpanel и конфиги: поиски корреляции
Настала пора, наконец, рассказать, почему я считаю Zenwalk одним из лучших дистрибутивов для изучения Linux'а вообще, и привести первые аргументы в пользу своей точки зрения.
В этой интермедии будет говориться об аргументе первом: однозначно устанавливаемой корреляции между действиями через Zenpanel и изменениями конфигурационных файлов.
Методика поиска корреляции следующая. Сначала на свободный рабочий стол выводим два окна: Zenpanel'и и терминальное (рис. 4_1.01)
Рис. 04_1.01. Полигон для изысканий
Далее в терминальном окне осуществляем поиск свежеизмененных файлов. Как правило, файлом (точнее, каталогом) с самым «свежим» временем последней модификации (атрибут mtime), будет каталог /etc/ntp (потому как служба точного времени всегда на посту). Таким образом, принимаем mtime этого каталога как своего рода временной репер.
Далее последовательно производим манипуляции с каждым из элементов панели, и после каждой такой попытки командой
$ find /etc/ -newer ntp 2> /dev/null
выявляем файлы, измененные в результате нашего последнего действия. Не всегда это будет однозначно ясно с первого взгляда, но тут в каждом конкретном случае нам на помощь придет здравый смысл.
Вообще команда find, предназначенная для поиска файлов по самым различным критериям, — штука очень мощная, и со временем мы поговорим о ней подробнее. А пока просто попробую расшифровать приведенную директиву.
Итак, find, как нетрудно догадаться, — имя команды, которая только и делает, что ищет файлы; на самом деле это не совсем так, но сейчас эту тему развивать неуместно.
Опция -newer предписывает находить в указанном каталоге (и его подкаталогах, поскольку команда find рекурсивна) файлы, модифицированные позднее, чем файл, указанный в качестве значения этой опции (эк загнул, ага?). В силу высказанных ранее резонов, значением этой опции выступает каталог /etc/ntp.
Ну а конструкция 2> /dev/null просто подавляет вывод сообщений об ошибках, перенаправляя их... не подумайте плохого, просто в файл устройства, в котором исчезает всё, как в бездонной бочке. Если вы опасаетесь, что при этом мы можем потерять чего-то важное — успокою, этого не случится. Потому что в данном контексте сообщения об ошибках будут носить примерно такой характер:
find: /etc/skel/.cache: Отказано в доступе
То есть сообщать нам, что к указанному файлу или каталогу доступ для простого юзера (а команду мы давали именно от его лица) закрыт — в некоторых случаях и такие сообщения способны загромоздить не один экран. И утрата их — потеря небольшая, абсолютно ничего полезного для нашей нынешней темы в них не содержится.
Итак, отрабатываем последовательно каждый элемент Zenpanel'и. Для начала запускаем команду find в приведенной выше форме, дабы убедиться, что ничего «моложе» /etc/ntp у нас нет. После чего через элемент Host and Domain меняем либо имя хоста, либо имя домена (на какое — не имеет значения). И, повторив нашу волшебную команду, обнаруживаем, что модификации подверглись следующие файлы:
./hosts ./hosts.old ./HOSTNAME.old ./HOSTNAME ./resolv.conf
Очевидно, что файлы /etc/*.old — это резервные копии предыдущих версий файлов /etc/hosts и /etc/HOSTNAME, которые, как и файл /etc/resolv.conf, собственно и содержат информацию о хосте и домене. В чём легко убедиться, просмотрев их, например, командой less.
Править что-либо в этих файлах при использовании DHCP нет необходимости (а в отношении /etc/resolv.conf и бесполезно — он всё равно будет переписан при рестарте). Так что двигаемся к следующему элементу.
Им, как мы помним, является System data. Повторяем процедуру с командой find, затем вносим изменения в дату (предположим, что в ночь с пятницы на понедельник наши системные часы остановились, и мы возвращаем текущие число, месяц и год). После чего обнаруживаем, что изменению подвергся файл /etc/adjtime. Каковой, впрочем, интереса для ручной правки не представляет.
Переходим к элементу Kernel modules и после той же процедуры — команды find и внесения изменений в список загруженных модулей, например, удаления ненужного на десктопе модуля battery, — обнаруживаем три новых измененных файла, /etc/sysctl.conf, /etc/rc.d/rc.modules и /etc/modprobe.d/blacklist. В первом ничего для нас интересного не видно. А вот второй представляет собой полный список доступных модулей, в котором имена неактивизированных модулей закрыты знаком комментария. Такой знак появился теперь и на имени того модуля, который мы только что отключили:
# /sbin/modprobe battery
Кроме того, имя этого модуля появилось и в файле /etc/modprobe.d/blacklist:
blacklist battery
Таким образом, делаем вывод, что для включения какого-либо модуля, надо снять ремарку с его имени в файле /etc/rc.d/rc.modules, а для отключения — напротив, таковую поставить. Правда, при этом не худо бы знать, что именно делает включаемый и отключаемый модуль, и не связан ли он зависимостями с другими — но это совсем отдельная история.
Теперь на очереди элемент Network proxy. Вызываем его в и соответствующие поля вписываем некие адреса прокси-серверов для http- и ftp-протоколов. После чего обнаруживаем очередной измененный файл — /etc/profile.d/proxy.sh. Изменения в котором сводятся к тому, что строки
export http_proxy='' export ftp_proxy=''
заменяются на такие:
export http_proxy='URL' export ftp_proxy='URL'
где URL — адреса прокси-серверов, которые мы вписали. То есть и такую процедуру при необходимости легко проделать вручную.
С элементом System time все аналогично установке системной даты. И изменению подвергается всё тот же файл /etc/adjtime, в коем нет смысла чего-либо править.
После включения или отключения стартовых сервисов через элемент Startup Services, как ни странно, не обнаруживается никаких следов свежих модификаций файлов в каталоге /etc или /etc/rc.d/. В чем дело — надеюсь разобраться со временем.
Действия над элементом Keyboard layout (например, замена раскладки ru-utf на us) приводят к изменению двух файлов — /etc/X11/xorg.conf и /etc/rc.d/rc.keymap. Каким издевательствам подвергается первый из них, мы уже проходили в главе 4, предшествовавшей данной интермедии.
А в файле /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 ru-utf.map fi
предпоследняя строка становится такой:
/usr/bin/loadkeys us.map
С элементом Terminal ничего интересного не происходит. Точнее, то, что с ним происходит, будет рассмотрено в соответствующей главе.
А вот при модификации элемента Video Configuration (как мы помним, он занимается совсем не этим, а сменой режимов авторизации) изменяется главный инциализационный файл системы — /etc/inittab/. В частности, если отказаться от авторизации в графическом режиме в пользу режима консольного, то в строке, устанавливающей runlevel по умолчанию и имеющей вид
# Default runlevel. (Do not set to 0 or 6) id:4:initdefault:
значение «4» изменится на «3»:
id:3:initdefault:
Про элементы Printing и Network Settings говорить особо нечего по причинам, изложенным в предшествующей главе.
Действия над элементом User Profiles по изменению каких-либо параметров учетных записей могут приводить к модификации файлов /etc/passwd, /etc/shadow и (или) /etc/group. Например, если мы поменяем пароль пользователя, изменению подвергнутся первые два файла. Впрочем, оценить этого мы не сможем: в указывается только основная группа пользователя., вопреки его имени, никаких паролей не содержится, все они — в файле /etc/shadow, где хранятся в односторонне зашифрованном виде, то есть в виде абракадабры из бессмысленного набора символов произвольной длины. А вот если внести изменение в групповую политику, например, сделать юзера имя_рек членом дополнительной группы wheel, то изменится только файл /etc/group — в /etc/passwd указывается только основная группа каждого пользователя (для реальных обычных пользователей это users).
И последний элемент — System Language. Изменение системной локали вызывает модификацию файла /etc/profile.d/lang.sh . Например, если при установке системы мы выбрали «бомжовскую» (выражение с одного из форумов) локаль koi6-r, а потом решили приобщиться прогрессу и сменить её на идеологически правильную utf8, то в этом сценарии строка
export LANG=ru_RU.koi8r
заменится такой:
export LANG=ru_RU.utf8
Подведем итоги. Zenpanel — очень удобный набор инструментов для выполнения многих настроек. Нов ряде случаев действительно быстрее и проще внести изменения непосредственно в конфигурационные файлы руками, в текстовом редакторе. Кандидаты на ручное редактирование следующие:
- /etc/rc.d/rc.modules — включение и отключение тех или иных модулей ядра;
- /profile.d/proxy.sh — задействование http- и ftp-прокси;
- /rc.d/rc.keymap — смена раскладки клавиатуры, позволяющая избежать побочного эффекта в виде уродования конфигурационного файла Иксов;
- /etc/inittab — смена runlevel по умолчанию;
- /etc/profile.d/lang.sh — смена системной локали.
Операции над пользовательскими аккаунтами, однако, лучше выполнять либо через Zenpanel, либо специальными утилитами типа useradd, usermod, passwd и так далее, во избежание возможных при ручном редактировании ошибок. Впрочем, дописать в некую группу нового члена в файле /etc/group вполне можно и вручную. А уж обнуление административного пароля в случае его утраты именно руками проще всего и выполнить.
Многие же параметры, такие, как имя хоста и домена, установка даты и времени, ни в какой модификации не нуждаются — ни в ручной, ни в инструментальной.