Чтение онлайн

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

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

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

Сценарий выполняется с помощью утилиты cron два раза в неделю; при этом создается резервная копия файла с указанием временной метки. Поэтому при возникновении проблем можно быстро отследить выполненные действия.

$ pg logroll

#!/bin/sh

#logroll

#усечение журнальных файлов, размеры которых более MARK

#может использовать и для почтовых ящиков?

#максимальный размер журнального файла 4096 к

BLOCK_LIMIT=8

MYDATE=`date +%d%m`

# список журнальных файлов для проверки…ваш список может быть другим!

LOGS="/var/spool/audlog /var/spool/networks/netlog /etc/dns/named_log"

for LOG_FILE in $LOGS

do

if [ -f $LOG_FILE ]; then.

# определение размера блока

F_SIZE=`du -a $LOG_FILE | cut -f1`

else

echo "`basename $0` cannot find $LOG_FILE" >&2

#можно выйти здесь, но следует убедиться, что проверены все

#журнальные файлы

continue

fi

if [ "$F_SIZE" -gt "$BLOCK_LIMIT" ]; then

#копирование журнального файла и присоединение к нему даты в формате ddmm

cp $LOG_FILE $LOG_FILE$MYDATE

#создание нового пустого журнального файла

>$LOG_FILE

chgrp admin $LOG_FILE$MYDATE

fi

done

27.6. Сценарий nfsdown

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

Если везде смонтированы удаленные каталоги, не следует рассчитывать на то, что процесс демонтирования nfs будет выполнен в ходе перезагрузки. Желательно выполнять все вручную; кроме того, такой подход экономит время.

При выполнении сценария (на всех компьютерах) демонтируются все каталоги nfs, что позволяет довольно быстро выполнить перезагрузку.

Сценарий содержит список компьютеров, на которых находятся монтировки nfs. Этот список обрабатывается с помощью цикла for. Во время обработки с помощью команды df для каждого хоста запускается утилита grep. Смонтированные каталоги nfs имеют вид:

machine: remote_directory

Данная строка присваивается переменной nfs_machine. Затем эта переменная применяется при выполнении команды unmount. Соответствующий сценарий имеет вид:

$ pg nfsdown

#!/bin/sh

# nfsdown

LIST="methalpha accounts warehouse dwaggs"

for LOOP in $LIST

do

NFS_MACHINE=`df -k | grep $LOOP | awk '{print $1}'`

if [ "$NFS_MACHINE" != "" ]; then

umount $LOOP

fi

done

27.7. Заключение

Рассмотренные в этой главе сценарии в течение длительного времени используются автором книги. Как уже упоминалось, сценарии не должны быть объемными и сложными, поскольку они создаются с целью экономии рабочего времени пользователя.

ГЛАВА 28

Сценарии уровня выполнения

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

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

В главе рассматриваются следующие темы:

• уровни выполнения;

• способы создания сценариев rc.scripts;

• методы внедрения сценариев rc.scripts на различных уровнях выполнения;

• запуск приложений с помощью файла inittab.

Благодаря созданию сценариев уровня выполнения обеспечивается повышенная степень гибкости при управлении системой. Для запуска или останова приложения на определенном уровне выполнения нужно инсталлировать сценарий уровня выполнения (его еще называют rc.script).

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

Методика создания каталогов конфигурации уровня выполнения позволяет автоматизировать работу сценариев rc.scripts только при изменении уровня выполнения. Однако нельзя определить, запущены или остановлены все необходимые службы на уровне выполнения. Эта часть работы должна выполняться shell–программистом.

Уровни выполнения можно настраивать в соответствии с действительно выполняемыми службами, но данная тема в книге не рассматривается.

28.1. Определение наличия каталогов уровня выполнения