FreeBSD tips: periodic на службе сисадмина::Журнал СА 7.2009
www.samag.ru
     
Поиск  
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Сетевой агент
О журнале
Журнал «БИТ»
Информация для ВАК
Звезды «СА»
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Форум
Вакансии
Спроси юриста
Игры
Контакты
   
Слайд шоу  
Представляем работы Виктора Чумачева
Виктор Чумачев – известный московский художник, который сотрудничает с «Системным администратором» уже несколько лет. Именно его забавные и воздушные, как ИТ, иллюстрации украшают многие серьезные статьи в журнале. Работы Виктора Чумачева хорошо знакомы читателям в России («Комсомольская правда», «Известия», «Московские новости», Коммерсант и др.) и за рубежом (США, Германия). Каждый раз, получая новый рисунок Виктора, мы в редакции улыбаемся. А улыбка, как известно, смягчает душу. Поэтому смотрите на его рисунки – и пусть у вас будет хорошее настроение!
1001 и 1 книга  
20.09.2018г.
Просмотров: 324
Комментарии: 0
Байесовские модели

 Читать далее...

20.09.2018г.
Просмотров: 239
Комментарии: 0
Элегантный SciPy

 Читать далее...

20.09.2018г.
Просмотров: 265
Комментарии: 0
Олимпиадное программирование

 Читать далее...

20.09.2018г.
Просмотров: 195
Комментарии: 0
Akka в действии

 Читать далее...

19.03.2018г.
Просмотров: 3659
Комментарии: 0
Потоковая обработка данных

 Читать далее...

Дискуссии  
17.09.2014г.
Просмотров: 19014
Комментарии: 3
Красть или не красть? О пиратском ПО как о российском феномене

Тема контрафактного ПО и защиты авторских прав сегодня актуальна как никогда. Мы представляем ...

 Читать далее...

03.03.2014г.
Просмотров: 21427
Комментарии: 1
Жизнь под дамокловым мечом

Политические события как катализатор возникновения уязвимости Законодательная инициатива Государственной Думы и силовых структур, ...

 Читать далее...

23.01.2014г.
Просмотров: 30044
Комментарии: 3
ИТ-специалист будущего. Кто он?

Так уж устроен человек, что взгляд его обращен чаще всего в Будущее, ...

 Читать далее...


  Опросы

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 FreeBSD tips: periodic на службе сисадмина

Архив номеров / 2009 / Выпуск №7 (80) / FreeBSD tips: periodic на службе сисадмина

Рубрика: Администрирование /  Продукты и решения

СЕРГЕЙ СУПРУНОВ, инженер электросвязи широкого ИТ-профиля. В свободное время изучает FreeBSD и Python и пытается осмыслить свою нелюбовь к KDE

FreeBSD tips:
periodic на службе сисадмина

Вы всегда должны знать, что происходит во вверенной вам системе. В обычной жизни следить за событиями помогают газеты и интернет-сайты. Во FreeBSD такую роль играет подсистема periodic.

Система periodic ежедневно, еженедельно и ежемесячно поставляет информацию обо всех важных событиях, происходящих в операционной системе, но системные администраторы почему-то редко уделяют ей должное внимание.

$ grep periodic /etc/crontab

1 3 * * * root periodic daily

15 4 * * 6 root periodic weekly

30 5 1 * * root periodic monthly

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

Вывод скриптов в общем случае, как и подобает заданиям 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, произошедшие с момента последней проверки. Например, если за предыдущие сутки к серверу подключалась флешка, результат проверки может выглядеть следующим образом:

 

kernel log messages:

+++ /tmp/security.mc0L61TV 2009-06-08 21:14:25.000000000 +0400

+umass0: <Kingston DataTraveler 2.0, class 0/0, rev 2.00/1.10, addr 2> on uhub1

+da0 at umass-sim0 bus 0 target 0 lun 0

+da0: <Kingston DataTraveler 2.0 PMAP> Removable Direct Access SCSI-0 device

+da0: 40.000MB/s transfers

+da0: 984MB (2015232 512 byte sectors: 64H 32S/T 984C)

+GEOM_LABEL: Label for provider da0s1 is msdosfs/KINGSTON.

+umass0: at uhub1 port 2 (addr 2) disconnected

+(da0:umass-sim0:0:0:0): lost device

+(da0:umass-sim0:0:0:0): removing device entry

+GEOM_LABEL: Label msdosfs/KINGSTON removed.

+umass0: detached

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) и их резервное копирование.

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


Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru