unset get_users
Сценарий имеет следующий вид:
$ pg deny.access
#!/bin/sh
#deny.access
trap "" 2 3
#откорректируйте следующую строку,
#если местоположение файла LOCKOUT.USERS изменено.
LOCKOUT=/apps/etc/lockout.users
MSG="Sorry $LOGNAME, your account has been disabled, ring the administrator"
MSG2="Sorry $LOGNAME, the system ls unavailable at the moment"
check_lockout ()
#check_lockout
#проверка наличия файла, содержащего имена для блокировки
{
if [ -r $LOCKOUT ] ; then
return 0
else
return 1 fi
}
get_users ()
#get_users
#чтение файла, если содержимое LOGNAME совпадавет с именем в lockout.users
#отбросьте его!
{
while read NAMES
do
case $NAMES in
\#*);; #игнорируйте комментарии
*)
#если кто‑либо попытается блокировать root,
#в этом сценарии ему это сделать не удастся
if [ "$NAMES"="root" ]; then
break
fi
if [ "$NAMES"="$LOGNAME" ]; then
# сообщение об отказе в регистрации
echo $MSG
sleep 2
exit 1
else
# нет совпадения, следующая итерация
continue
fi;;
esac
done < $LOCKOUT
}
if check_lockout; then
if grep 'all\>' $LOCKOUT >/dev/null 2>&1
then
#сначала проверьте, имеется ли слово "all". Если это слово
#присутствует, все, кроме root, должны держаться подальше
if [ "$LOGNAME" != "root" ]; then
echo $MSG2
sleep 2
exit 2
fi
fi
# обработка информации об обычных пользователях
get_users
fi
27.5. Сценарий logroll
Некоторые системные журнальные файлы увеличиваются довольно быстро. Становится затруднительным вручную уточнять размеры журнальных файлов и выполнять прокрутку определенного журнала (обычно, с помощью отметки даты). Поэтому назрела необходимость создания сценария для автоматизации этой процедуры. Сценарий выполняется с помощью утилиты cron, и если какой‑либо журнальный файл достигает определенного размера, осуществляется прокрутка данного журнала и создание нового журнального файла.
Этот сценарий может быть легко обновлен для работы с иными журнальными файлами. Например, при обработке системных журнальных файлов можно применить другой сценарий, который выполняется еженедельно и усекает журнальные файлы. Если необходимо просмотреть более ранние сообщения, нужно проверить резервную копию; при работе в 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. В задачу этого сценария входит успешный запуск и прекращение функционирования какой‑либо службы.
