 |
|
|
|
FreeBSD tips: periodic на службе сисадмина
FreeBSD tips: Вы всегда должны знать, что происходит во вверенной вам системе. В обычной жизни следить за событиями помогают газеты и интернет-сайты. Во FreeBSD такую роль играет подсистема periodic. Система periodic ежедневно, еженедельно и ежемесячно поставляет информацию обо всех важных событиях, происходящих в операционной системе, но системные администраторы почему-то редко уделяют ей должное внимание. $ grep periodic /etc/crontab
Время исполнения подобрано таким образом, чтобы минимизировать «пересечение» с другими заданиями. Для большинства серверов, работающих круглосуточно, эти значения достаточно удачны, но если ваша система используется только в рабочее время или же на ночь приходится пик нагрузки, то расписание имеет смысл пересмотреть. Вывод скриптов в общем случае, как и подобает заданиям cron, направляется соответствующему пользователю по электронной почте (по умолчанию это root; указать другого можно в переменной MAILTO crontab-файла, но это скажется на всех заданиях из /etc/crontab). Однако при необходимости это нетрудно изменить – в /etc/periodic.conf для каждого обрабатываемого каталога можно указать параметр вида <ИмяКаталога>_output, например: daily_output="admin" weekly_output="amsand@rambler.ru" monthly_output="/var/log/monthly.log" myscripts_output="" Все «умолчальные» параметры сосредоточены в /etc/defaults/periodic.conf, для внесения изменений в поведение подсистемы предназначен файл /etc/periodic.conf (изначально отсутствует). Конфигурационные параметры группируются по именам каталогов и скриптов, к которым относятся – если вывод того или иного сценария вас не вполне устраивает, загляните в /etc/defaults/periodic.conf, возможно, его работу можно будет подстроить под ваши потребности. Как ни странно, но многие удовлетворяются возможностями, заданными по умолчанию, а иногда и вообще не задумываются о возможности подстроить periodic под свои задачи и тем самым повысить эффективность использования инструмента. Конечно, параметры по умолчанию работают неплохо, и для некоторых систем они действительно будут оптимальными. Но в общем случае индивидуальная подстройка periodic имеет смысл, и мы рассмотрим все возможности, предоставляемые этим инструментом. Начнём с рассмотрения скриптов, представленных в /etc/periodic/daily. 100.clean-disks Этот скрипт удаляет все файлы, имена которых соответствуют заданным шаблонам (по умолчанию это [#,]*, .#*, a.out, *.core, *.CKP и .emacs_[0-9]*) и возраст которых больше заданного в параметре daily_clean_disk_days числа дней. По умолчанию не выполняется, и особой нужды в ежедневном выполнении я не вижу. Хотя у вас может быть по-другому. 110.clean-tmps Удаляет все «временные» файлы (по умолчанию из /tmp, задаётся переменной daily_clean_tmps_dirs), старше указанного возраста (daily_clean_tmps_days), кроме соответствующих шаблонам, указанным в daily_clean_tmps_ignore. По умолчанию не выполняется, но если используемое вами ПО часто «забывает» подчищать за собой временный каталог, то имеет смысл включить выполнение этого файла, установив в /etc/periodic.conf переменную daily_clean_tmps_enable в YES. 120.clean-preserve Удаляет старые файлы из /var/preserve, куда редактор vi в давние времена сохранял служебные файлы при аварийном завершении работы (например, при разрыве соединения) для последующего восстановления. По умолчанию выполняется, что несколько странно, так как «бэкапные» файлы vi уже давненько пишет в /var/tmp/vi.recovery, а изменить каталог /var/preserve, кроме как прямым редактированием сценария, нельзя. Рекомендую этот скрипт отключить. 130.clean-msgs Очищает устаревшие msgs-сообщения (см. man msgs). Утилита msgs позволяет пользователям системы оставлять короткие сообщения всем остальным пользователям и читать такие сообщения. То есть играет роль доски объявлений. По умолчанию выполняется, но если вы не используете механизм msgs-сообщений, то нет смысла каждую ночь впустую вызывать скрипт, так что установите daily_clean_msgs_enable в NO. 140.clean-rwho Очищает каталог /var/rwho – в нём накапливается информация, собираемая демоном rwhod. Этот демон собирает рассылаемую другими машинами UNIX-сети информацию, аналогичную той, которую возвращает команда who (аптайм, средняя загрузка, список подключенных пользователей). По умолчанию выполняется, но, поскольку такие доверительные отношения между машинами сети сейчас редко встречаются, скорее всего, смысла в этом сценарии на большинстве систем нет. 150.clean-hoststat Sendmail в процессе своей работы может собирать статистику доступности хостов, чтобы не тратить время на попытки соединиться с теми, которые недавно были недоступны. Эта статистика со временем устаревает и начинает впустую расходовать память и место на диске. Задача скрипта заключается в вызове утилиты purgestat, которая очищает устаревшие данные. По умолчанию выполняется, но если вы не используете Sendmail, то в запуске этого скрипта не будет особого смысла. 200.backup-passwd Копирует в /var/backups файлы master.passwd и group из каталога /etc. С одной стороны, такое копирование создаёт дополнительную «точку ответственности» для администратора, но с другой – позволяет восстановить случайно испорченные файлы, являющиеся жизненно важными для работы системы. По умолчанию выполняется. 210.backup-aliases Ещё один пример копирования важных файлов. На этот раз в /var/backups будет сохраняться /etc/mail/aliases. По умолчанию выполняется. 300.calendar Запускает утилиту calendar с ключом -a, которая обрабатывает файлы «календарей» всех пользователей и отсылает им по электронной почте сегодняшние и завтрашние задачи. По умолчанию не выполняется, и разработчики планируют удалить эту функцию из periodic, предлагая при необходимости использовать задания cron непосредственно. 310.accounting Выполняет ротацию acct-файлов в /var/account. Учёт процессов (см. man acct(2)) позволяет сохранять в файл статистику всех запускавшихся процессов, такую как число вызовов процесса, израсходованное им процессорное время, среднее число операций ввода-вывода и т.п. По умолчанию выполняется, но, учитывая, что сбор подобной статистики на «боевых» серверах выполняется нечасто, над необходимостью выполнения этого сценария стоит задуматься. 330.news Когда-то предназначался для запуска сценария /etc/news.expire сервера новостей. В базовой системе я уже давно news-сервера не наблюдаю, тем не менее по умолчанию этот сценарий выполняется (если в /etc/periodic.conf выставить daily_show_badconfig в YES, то ежедневно вы будете получать сообщение об отсутствии файла /etc/news.expire; по умолчанию сообщения об ошибках не отсылаются). Однозначно нужно отключать (задав конфигурационной переменной daily_news_expire_enable значение NO). 400.status-disks Этот сценарий выводит информацию о состоянии локальных файловых систем (выполняя команду «df -l -h») и о последних дампах. Очень полезно для контроля за свободным пространством на дисках. Кроме того, позволяет обнаружить «лишние» файловые системы (скажем, забытую флешку или диск с резервной копией). По умолчанию выполняется. 404.status-zfs Выводит информацию о состоянии пулов ZFS. По умолчанию не выполняется, но если вы используете ZFS, то имеет смысл выставить в /etc/periodic.conf параметр daily_status_zfs_enable в значение YES. 405.status-ata-raid Возвращает данные о статусе RAID-контроллеров (по результатам вывода утилиты atacontrol). По умолчанию не выполняется. 406.status-gmirror, 407.status-graid3, 408.status-gstripe, 409.status-gconcat Эти скрипты выводят информацию о состоянии соответствующих дисковых массивов, управляемых подсистемой GEOM. По умолчанию не выполняются. 420.status-network Выводит результат работы команды «netstat -i», позволяя контролировать состояние интерфейсов на момент выполнения скрипта (интерфейсы, находящиеся в состоянии down, будут отмечены звёздочкой «*»), а также число переданных и принятых пакетов, в том числе ошибочных. По умолчанию выполняется. 430.status-rwho Выводит информацию о времени непрерывной работы (uptime) машин UNIX-сети, которую собирает rwhod. По умолчанию выполняется, но по тем же причинам, о которых шла речь при обсуждении сценария 140.clean-rwho, на большинстве систем он фактически не нужен. 440.status-mailq Скрипт выполняет команду mailq, возвращающую информацию о почтовой очереди. Выставив переменную daily_status_mailq_shorten в YES, вы будете получать сводную статистику вместо информации по каждому сообщению в очереди. По умолчанию выполняется. 450.status-security Это своего рода «мета-скрипт» для запуска заданий из /etc/periodic/security. Как вы видели, в заданиях cron присутствуют вызовы только для daily, weekly и monthly, поскольку проверка безопасности предполагается как ежедневное задание. Можно было бы все security-сценарии разместить и непосредственно в daily, но разработчики приняли решение, что для такой ответственной задачи лучше выделить отдельный каталог. Вы тоже вполне можете использовать этот приём для выполнения «пакетных» задач. 460.status-mail-rejects Этот сценарий выполняет анализ почтового лог-файла (/var/log/maillog) и выводит статистику по отклонённым письмам (с указанием причины). Вывод группируется по хостам-отправителям и сортируется в порядке убывания числа отклонённых соединений. Параметр daily_status_mail_rejects_logs задаёт число «архивных» файлов, полученных в ходе ротации (maillog.0.bz2 и т.д.), которые также будут обрабатываться. Если ротация почтовых логов в вашей системе выполняется ежедневно, имеет смысл выставить данный параметр в 0 (по умолчанию используется значение 3), чтобы не обрабатывать одни и те же данные несколько раз. Если вы используете другую политику ротации (например, по достижении определённого размера файла), подберите число обрабатываемых файлов таким образом, чтобы полностью охватить все логи, накапливаемые за сутки (если, конечно, для вас достоверность информации представляет какую-то ценность). По умолчанию выполняется. 470.status-named Выбирает из файлов /var/log/messages записи процесса named, сообщающие о той или иной ошибке (failed, REFISED), а также о пересылках зон (transfer). По умолчанию выполняется. 480.status-ntpd Выводит список известных NTP-серверу соседей (peer). По умолчанию не выполняется, но если стабильная работа системы времени для вас важна, можете включить эту проверку. 500.queuerun Запускает обработку почтовой очереди (командой «sendmail -q»). По умолчанию выполняется, но подумайте о его отключении, если используете другой почтовый сервер. Недельные задачи носят в основном сервисный характер: 310.locate Проводит обновление базы locate (утилитой /usr/libexec/locate.update). База позволяет выполнять быстрый поиск файлов в системе, не прибегая каждый раз к глобальному просмотру всех каталогов. Периодическое обновление необходимо, чтобы поддерживать базу в актуальном состоянии. По умолчанию выполняется, но если возможности locate вам не требуются или создаваемая утилитой locate.update нагрузка на файловую систему нежелательна даже раз в неделю, запуск этого сценария можно отключить. 320.whatis Аналогично предыдущему сценарию, этот скрипт поддерживает в актуальном состоянии базу whatis (которая осуществляет контекстный поиск по содержимому man-страниц). По умолчанию выполняется, однако если состав man-страниц меняется редко (что верно для большинства рабочих серверов), то имеет смысл вызов скрипта отключить, а обновление базы whatis выполнять по мере необходимости вручную. 330.catman Выполняет переформатирование man-страниц (командой catman). По умолчанию не выполняется, и на большинстве систем необходимости в нём не возникает. 340.noid Ищет файлы и каталоги, не принадлежащие ни одному из пользователей и групп. По умолчанию не выполняется, хотя в некоторых случаях (особенно при обновлении ОС до другой версии) может быть полезным для поиска «осиротевших» файлов. 400.status-pkg Выводит список установленных пакетов, требующих обновления. По умолчанию не выполняется. Однако, если ваша система настроена на автоматическое обновление коллекции портов (например, по cron с помощью portsnap), то данная информация может быть полезна – установите в /etc/periodic.conf переменную weekly_status_pgk_enable в YES. Ежемесячно в текущих версиях FreeBSD исполняется только один сценарий: 200.accounting Он собирает статистику по использованию пользователями процессорного времени. По умолчанию выполняется, но на большинстве серверов особой необходимости в этом нет. Разве только в порядке соц. соревнования – кто из администраторов сильнее нагружает систему? И, наконец, наиболее важный каталог – security (все сценарии по умолчанию выполняются, так что я не буду указывать это отдельно): 100.chksetuid Скрипт проверяет изменения в составе файлов, для которых установлен бит suid или sgid. Поиск выполняется утилитой find по всем файловым системам, кроме смонтированных с опцией nosuid или noexec, результат сравнивается с предыдущим значением (обычно сохраняется в /var/log/setuid.today). Обнаруженные отличия отправляются администратору. И хотя такой поиск довольно сильно может нагружать файловую подсистему, лучше от него не отказываться. Впрочем, если вы ведёте аудит безопасности другими средствами, проверку можно отключить. 200.chkmounts Сравнивает текущий список смонтированных систем (возвращаемый командой «mount -p») со вчерашним списком, сохранённым в /var/log/mount.today. 300.chkuid0 Проверяет наличие в master.passwd пользователей с идентификатором 0, отличных от root и toor. Поскольку права суперпользователя определяются именно нулевым значением UID, а не символьным именем, такая проверка позволяет выявить опасные опечатки (или «чёрный ход», оставленный взломщиком или предыдущим администратором). 400.passwdless Ищет пользователей с пустыми паролями. 410.logincheck Проверяет права на файл login.conf (должен принадлежать пользователю root и группе wheel). 500.ipfwdenied, 510.ipfdenied, 520.pfdenied Эти три скрипта выводят информацию о запрещающих правилах пакетных фильтров (соответственно ipfw, ipf и pf), изменившихся с момента предыдущей проверки. 550.ipfwlimit Выводит список правил ipfw, по которым были превышены заданные лимиты. 700.kernelmsg Отображает изменения вывода dmesg, произошедшие с момента последней проверки. Например, если за предыдущие сутки к серверу подключалась флешка, результат проверки может выглядеть следующим образом:
800.loginfail Выводит информацию обо всех ошибках входа в систему, зафиксированных в /var/log/auth.log за прошедшие сутки. 900.tcpwrap Возвращает предупреждения системы TCP Wrappers, найденные в файлах /var/log/messages. Помимо рассмотренных сценариев в каталогах daily, weekly и monthly вы найдёте файлы 999.local. Их назначение – запуск скриптов /etc/daily.local, /etc/weekly.local и /etc/monthly.local соответственно. По умолчанию эти скрипты отсутствуют, но если хотите запускать свои команды вместе с другими periodic-задачами, вы можете их создать. Например, чтобы ежедневно получать данные о доступности некоторого сервера и среднем времени передачи пакетов к нему, можно создать файл /etc/daily.local следующего содержания: Ну и, безусловно, вы всегда можете поместить в /etc/periodic/* свои собственные скрипты (хотя для этого всё же рекомендуется использовать каталоги /usr/local/etc/periodic/*). Пример В заключение приведу пример своего файла /etc/periodic.conf (только не нужно рассматривать его как эталон – ваши потребности могут отличаться от моих): daily_clean_preserve_enable="NO" daily_clean_msgs_enable="NO" daily_clean_rwho_enable="NO" daily_accounting_enable="NO" daily_news_expire_enable="NO" daily_status_rwho_enable="NO" daily_status_disks_df_flags="-l -h -i" weekly_locate_enable="NO" weekly_whatis_enable="NO" weekly_noid_enable="YES" weekly_status_pkg_enable="YES" То есть я отключил все сценарии, которые мне не нужны (или периодический запуск которых неэффективен), включил контроль «осиротевших» файлов (noid_enable), поскольку часто экспериментирую, в т.ч. и с учётными записями. Также включил еженедельный вывод информации о статусе установленных пакетов. Ну и добавил флаг «-i» для утилиты df (по умолчанию 400.status-disks запускает её как df -l -h), чтобы получать также и данные о свободных индексных дескрипторах (inode). Всё остальное остаётся по умолчанию (согласно /etc/defaults/periodic.conf). Как видите, по умолчанию periodic выполняет много лишнего (хотя это и не смертельно), так что желательно вдумчиво подходить к её настройке. Это позволит вам регулярно получать массу полезной (и только полезной) информации о жизнедеятельности ваших серверов. Так что, устанавливая новую систему, не ленитесь уделять подсистеме periodic пару минут. Приложение Локальные задания periodic Некоторые сторонние программы используют систему periodic в своих целях. Например, postgresql при установке из Портов помещает в /usr/local/etc/periodic/daily файл 502.pgsql. В зависимости от настроек (которые выполняются, как и для остальных periodic-сценариев, в /etc/periodic.conf) этот скрипт ежедневно может выполнять дефрагментацию баз данных (командой vacuumdb) и их резервное копирование. Так что, устанавливая ту или иную программу, обращайте внимание и на этот момент – чтобы не было сюрпризов в виде резко подскакивающей нагрузки на систему в неудачное время или пропажи архивных файлов, которые вы собирались неспешно обработать в конце месяца. |
СЕРГЕЙ СУПРУНОВ, инженер электросвязи широкого ИТ-профиля. В свободное время изучает FreeBSD и Python и пытается осмыслить свою нелюбовь к KDEКомментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
