Linux и UNIX: программирование в shell. Руководство разработчика

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. В задачу этого сценария входит успешный запуск и прекращение функционирования какой‑либо службы.