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

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

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

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

Независимо от выбранной схемы процедуру управления журнальными файлами необходимо автоматизировать с помощью демона cron.

Операционную систему UNIX часто критикуют за противоречивость. Taк и есть на самом деле: загляните, например, в каталог журнальных файлов, и вы наверняка найдете несколько файлов с именами наподобие maillog, файлы вида ftp.log и даже что-нибудь вроде lpNet, lpd-errs или console_log. Мало того, что журнальные файлы имеют случайные имена, так они еще и разбросаны по различным каталогам и файловым системам.

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

Для того чтобы найти журнальные файлы, просмотрите тексты стартовых сценариев системы (/etc/rc*, /etc/red/* или /etc/init.d/*) и проверьте, включается ли регистрация при запуске демонов. В настоящее время большинство программ выполняет регистрацию посредством системы Syslog, которая рассматривается в параграфе 11.5. Загляните в текст конфигурационного файла /etc/syslog.conf системы Syslog, чтобы узнать, куда направляются данные.

У читателя может возникнуть искушение управлять всеми журнальными файлами по схеме "ротация плюс архивирование". Но есть два файла, которые трогать не следует: /var/adm/lastlog и /etc/utmp. В файле lastlog регистрируются данные о последнем входе в систему каждого пользователя. Это разреженный файл, где записи упорядочены по идентификатору пользователя. Размер файла будет меньше, если все идентификаторы находятся в узком диапазоне, однако этого невозможно добиться при наличии идентификатора пользователя root равного 0, и идентификатора пользователя nobody, равного -2 (65534). Не копируйте файл lastlog, иначе он займет все пространство на диске.

 

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

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

В Solaris самая беспорядочная коллекция журнальных файлов. Впрочем, если есть каталог /var/log, то найти эти файлы большого труда не составит. Вот некоторые из них:

• /var/log/*
• /var/cron/log
• /var/lp/logs/*
• /var/saf/_log
• /var/saf/zsmon/log
• /var/adm/{messages, aculog, sulog, vold.log, wtmpx}
• /var/adm/log/asppp.log

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