Конфигурационные файлы

Выполнение действий по расписанию

Другой пример типичной для Linux службы, управляемой конфигурационным файлом, – демон cron ^{3Программисты имели в виду Хроноса, стихийное божество времени у древних греков. Уже сами греки часто называли так "владыку неба" титана Крона (отца богов-кронидов и, среди прочих, Зевса, который впоследствии отца и других титанов заключил в Тартар, и стал владыкой неба сам). У древних римлян и Крон и Хронос почитались под именем Сатурна, божества неумолимого времени.} , регулярно выполняющий в заданное время заданные действия. Время от времени в системе необходимо обновлять разнообразные файлы, например, базы данных антивирусов (вирусов в Linux нет, а антивирусы есть!), базу данных whatis или список всех доступных на чтение файлов системы, locatedb (поискать по этому списку можно командой locate ); нужно собирать статистику по работе системы, анализировать цельность системы (этим занимаются службы OSec, TripWire или AIDE) и производить множество других регулярных действий. Всем этим и занимается демон cron.

Конфигурационный файл демона cron называется /etc/crontab.

[root@localhost root]# cat /etc/crontab
 #minute (0-59),
 #|     hour (0-23),
 #|     |     day of the month (1-31),
 #|     |     |     month of the year (1-12),
 #|     |     |     |     day of the week (0-6 with 0=Sunday).
 #|     |     |     |     |     user
 #|     |     |     |     |     |     commands
 01     *     *     *     *     root    run-parts /etc/cron.hourly
 02     4     *     *     *     root    run-parts /etc/cron.daily
 22     4     *     *     0     root    run-parts /etc/cron.weekly
 42     4     1     *     *     root    run-parts /etc/cron.monthly

Первые пять полей этого файла определяют время запуска команды: минуту, час, число месяца, месяц и день недели. Символ "*" означает, что соответствующая часть даты не учитывается. Шестое поле – имя пользователя, от лица которого запускается команда, указанная в остальных полях строки. Так, в примере команда run-parts /etc/cron.weekly будет запускаться в 4 часа 22 минуты каждое воскресенье (нулевой день) любого числа любого месяца. Как видно из примера, обычно /etc/crontab невелик: чаще всего он состоит из почасового, подневного, понедельного и помесячного запуска специального сценария (в примере – run-parts ). Этот сценарий реализует упрощенную схему " .d ", он попросту запускает отсортированные в лексикографическом порядке^{4То есть в таком порядке, в котором они были бы расставлены в словаре. Причем цифры предшествуют алфавитным знакам, а между собой сортируются по возрастанию, от 0 до 9. Отсюда " 000anacron " – такое имя обеспечит, чтобы этот сценарий был выполнен самым первым.} сценарии из соответствующего каталога (например, из /etc/cron.daily ):

[root@localhost root]# ls /etc/cron.daily 
 000anacron logrotate makewhatis osec stmpclean updatedb

Вот что происходит каждый день на машине Мефодия: запуск anacron и "прокручивание" системных журналов (об этом речь пойдет далее), обновление базы whatis, проверка цельности системы с помощью osec, прореживание старых и неиспользуемых файлов в /tmp (утилита stmpclean ) и, наконец, обновление базы updatedb.

Пользователям системы можно разрешить иметь собственные расписания, также обрабатываемые демоном cron. Эти расписания имеют тот же синтаксис, что и crontab, только шестое поле ("user") в них отсутствует. Редактировать пользовательские таблицы рекомендуется с помощью команды crontab -e (чтобы не подсунуть демону синтаксически неверный файл). Сами таблицы могут храниться, в зависимости от версии и настроек cron, в /var/spool/cron/crontabs, /var/spool/cron, /var/cron/tabs или еще где-нибудь.

Служба anacron появилась в Linux-системах в то время, когда их начали активно использовать на персональных рабочих станциях. Такие станции, в отличие от серверов, не обязаны работать круглосуточно. Скорее всего, на ночь, на праздники и на время отпуска их выключают. Это значит, что все настройки cron надо менять в соответствии с графиком включений/выключений (иначе cron.daily никогда не выполнится в четыре часа ночи) – или запускать отдельную службу, которая будет выполнять некоторые задачи не по расписанию, а потому что их давно уже пора запустить^{5Название этого демона пародирует cron с намеком на анахронизм, то есть несвоевременность выполнения заданий.}. Дополнительно anacron рассчитывает запуск задач так, чтобы не перегрузить компьютер работой, если их накопилось слишком много. Конфигурационный файл anacron называется /etc/anacrontab.

"Прокручивание" системных журналов

Еще изучая работу syslog, Мефодий не расставался с мыслью, что файл, в котором записывается системный журнал, постоянно растет. Это значит, что каков бы ни был размер файловой системы /var, она в конце концов заполнится журналами под завязку – если как-то их не укорачивать. К сожалению, в Linux укоротить файл от начала, отрезав самые старые записи, нельзя, как нельзя и добавлять новые записи в начало файла. Эти операции легко реализовать с помощью копирования нужной области в новый файл и последующего переименования, но, во-первых, соблюсти атомарность таких составных операций нелегко, а во-вторых, они требуют вдвое больше места в файловой системе на время работы (и, стало быть, каких-то аварийных процедур на случай нехватки места).

Поэтому в Linux принят другой, существенно менее ресурсоемкий алгоритм, позволяющий избежать переполнения /var: так называемое "прокручивание" системных журналов. Суть алгоритма в следующем: когда настает пора укоротить журнал (например, раз в неделю или если файл журнала достиг определенного размера), этот файл переименовывают, и открывают новый пустой файл с тем же именем. Если хранить несколько (скажем, семь) переименованных старых файлов, с ними уже можно производить операцию "отбрасывания старого": самый старый – седьмой – файл удаляется, шестой переименовывается в седьмой, пятый – в шестой, и т. д. до первого (моложе которого только текущий журнал), который переименовывается во второй. Только тогда можно переименовать текущий журнал в "первый старый" и открыть новый. Получается очередь устаревающих файлов, пополняемая с одной стороны и усекаемая с другой.

Как правило, имя "первого старого" журнала получается путем добавления к имени журнала суффикса ".1", второго – ".2" и т. д.:

[root@localhost root]# ls -l /var/log/syslog/messages*
-rw-r----- 1 root adm 292654 Dec 15 14:01 /var/log/syslog/messages
-rw-r----- 1 root adm  34452 Dec 13 01:09 /var/log/syslog/messages.1.bz2
-rw-r----- 1 root adm  35892 Dec  6 09:38 /var/log/syslog/messages.2.bz2
-rw-r----- 1 root adm  60806 Nov 28 10:59 /var/log/syslog/messages.3.bz2
-rw-r----- 1 root adm  61063 Nov 21 10:47 /var/log/syslog/messages.4.bz2
-rw-r----- 1 root adm  60079 Nov 14 21:18 /var/log/syslog/messages.5.bz2

Прокручиванием системных журналов занимается утилита logrotate, которая тоже управляется и конфигурационным файлом /etc/logrotate.conf, и " .d "-каталогом /etc/logrotate.d/. Согласно настройкам, старые файлы можно сжимать упаковщиками bzip2 (как в примере) или gzip, можно задавать им определенные права доступа, можно посылать сигнал некоторой службе (чтобы она заметила подмену журнала, если она сама, а не syslogd занимается его пополнением) и т. п.

Конфигурационные файлы в домашнем каталоге

Немало конфигурационных файлов находится в домашнем каталоге пользователя. Этими файлами практически любая утилита может быть перенастроена по сравнению с обычным поведением, или поведением, задаваемым конфигурационным файлом из /etc. В Linux принято предоставлять пользователю возможность задавать профиль любого используемого им инструмента, начиная от простой утилиты и заканчивая графической подсистемой управления "рабочим столом" (см. об этом лекцию 15). Как правило, имена таких файлов или каталогов начинаются на " .", т. е. считаются скрытыми – для того, чтобы не засорять выдачу ls. Если пользователю нужно работать не со своими файлами, а именно с настройками, он всегда может применить ключ " -a " или " -A ":

methody@localhost:~ $ ls
 bin cat.info cat.stderr Documents examples grep.info textfile tmp
methody@localhost:~ $ ls -AF
 .alias        .bashrc    .emacs    .inputrc~      textfile .Xauthority
 .bash_history  bin/       examples/ .lpoptions     tmp/    .xsession.d/
 .bash_logout   cat.info   grep.info .pinerc       .viminfo
 .bash_profile  cat.stderr .i18n     .pyhistory     .vimrc
 .bash_profile~ Documents/ .inputrc  .pythonstartup .vimrc~
methody@localhost:~ $ rm .*~

Многие утилиты создают конфигурационный файл при запуске, если его в домашнем каталоге пользователя нет, поэтому со временем объем ls -A становится все больше. Файл .lpoptions задает параметры подсистемы печати, .pinerc – это настройки почтового клиента pine, .viminfo – файл истории команд редактора Vim, а файл .Xauthority и каталог .xsession.d управляют запуском графической подсистемы X11, описанной в лекции 15. Из файлов в примере некоторые вообще не являются "стандартными": так, .aliases и .i18n просто "втягиваются" стартовым командным сценарием bash, потому что упомянуты в нем явно; строго говоря, они могли бы называться и по-другому. Все конфигурационные, стартовые и прочие вспомогательные файлы принято делать скрытыми, даже если никаких требований к их названиям нет.

Файл .pythonstartup (настройки интерпретатора языка программирования Python) выполняется потому, что имя этого файла задано в переменной окружения PYTHONSTARTUP. Мефодию пришлось дописать строку PYTHONSTARTUP="/home/methody/.pythonstartup"; export PYTHONSTARTUP в ~/.bash_profile и "C-i": complete в ~/.inputrc, чтобы достраивание заработало и в этом интерпретаторе. Еще один файл, .pyhistory, используется в самом .pythonstartup:

methody@localhost:~ $ cat .pythonstartup 
 import atexit, os, readline, rlcompleter
 historyPath = os.path.expanduser("~/.pyhistory")
 def save_history(historyPath=historyPath):
  import readline
  readline.write_history_file(historyPath)
 if os.path.exists(historyPath):
  readline.read_history_file(historyPath)
 atexit.register(save_history)
 del os, atexit, readline, rlcompleter, save_history, historyPath

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