Linux и UNIX: программирование в shell. Руководство разработчика
Linux и UNIX: программирование в shell. Руководство разработчика читать книгу онлайн
Данная книга является практическим руководством по программированию интерпретатора Bourne shell -cтандартного командного интерпретатора в UNIX, полностью совместимого с интерпретатором BASH shell в Linux. Книга предназначена для начинающих и опытных программистов и содержит множество полезных примеров, советов и подсказок. С ее помощью читатель сможет быстро научиться создавать shell–сценарии для реальных задач и ситуаций, возникающих в большинстве систем UNIX и Linux.
Внимание! Книга может содержать контент только для совершеннолетних. Для несовершеннолетних чтение данного контента СТРОГО ЗАПРЕЩЕНО! Если в книге присутствует наличие пропаганды ЛГБТ и другого, запрещенного контента - просьба написать на почту [email protected] для удаления материала
$ pg test_logger
#!/bin/sh
# test_logger
logger -p notice "`basename $0`: there are currently `who |wc -l` users on the system"
Запустим сценарий.
$ test_logger
Теперь отобразим содержимое файла сообщений.
$ tail /var/adm/messages
Jun 17 11:02:53 acers6 dave: test_logger:there are currently 15 users on the system
26.5.2. Использование команды logger в сценариях
Регистрацию сообщений лучше использовать в том случае, когда осуществляется безусловное прерывание выполнения одного из сценариев. Для регистрации этих типов сообщений просто включите команду logger в функции, выполняющие перехват сигналов при выходе из сценария.
В следующем сценарии очистки при получении любого из сигналов с номерами 2, 3 или 15 производится регистрация сообщения.
$ pg cleanup
#!/bin/sh
#cleanup
#очистка журнальных файлов системы
trap "my_exit" 2 3 15
my_exit () {
# my_exit
logger -p notice "`basename $0`: Was killed while cleaning up system logs..CHECK OUT ANY DAMAGE"
exit 1
}
tail -3200c /var/adm/utmp > /tmp/utmp
mv /tmp/utmp /var/adm/utmp
>/var/adm/wtmp
#
tail -10 /var/adm/sulog > /tmp/o_sulog
mv /tmp/o_sulog /var/adm/sulog
При просмотре файла сообщений можно заметить, что возникла проблема, связанная с выполнением сценария очистки.
$ tail /var/adm/messages
Jun 17 11:34:28 acers6 dave: cleanup:Was killed whilst cleaning up systemlogs.. CHECK OUT ANY DAMAGE
Помимо использования при работе с различными критическими сценариями, команду logger можно также применять для регистрации любых подключений удаленных пользователей к системе. Ниже приведен сегмент кода, регистрирующий пользователей, которые подключаются к системе с помощью последовательных линий tty0 и tty2. Этот фрагмент кода берет свое начало от одного из файлов /etc/profile.
TTY_LINE=`tty`
case $TTY_LINE in
"/dev/tty0") TERM=ibm3151 ;;
"/dev/tty2") TERM=vt220
#проверка пользователей, которым разрешен доступ к модемной линии
#
echo "This is a modem connection"
# modemf содержит регистрационные имена для допустимых пользователей
modemf=/usr/local/etc/modem.users
if [ -s $modemf ] then
user=`cat $modemf | awk '{print $1}' | grep $LOGNAME`
# если имя не содержится в файле, пользователь не допускается в систему
if [ "$USER" != "$LOGNAME" ]
then
echo "INVALID USER FOR MODEM CONNECTION"
echo " DISCONNECTING………"
sleep 1
exit 1
else
echo "modem connection allowed"
fi
fi
logger -p notice "modem line connect $TTY_LINE… $LOGNAME"
;;
*) TERM=vt220
stty erase '^h' ;;
esac
Команда logger является превосходным инструментальным средством, применяемым для регистрации информации в глобальных файлах сообщений системы.
26.6. Заключение
Благодаря использованию функции перехвата и сигналов реализуется изящное завершение выполнения сценариев. Возможность регистрации сообщений в системном журнальном файле обеспечивает пользователей и администраторов полезной информацией, облегчающей распознавание и устранение любых потенциальных проблем.
ГЛАВА 27
Небольшая коллекция сценариев
В настоящей главе содержатся примеры некоторых наиболее распространенных сценариев. Изучая их, можно заметить, что все они невелики по размеру и довольно просты. В этом и состоит преимущество использования сценариев; они не должны быть сложными и объемными, поскольку сценарии создаются с целью экономии времени пользователя.
Конечно, в состав данной главы неплохо было бы включить сценарий comet, выполняющий общую проверку баз данных. Но поскольку этот сценарий содержит более 500 строк, нецелесообразно включать его в эту небольшую книгу. Разаботка сценария comet началась еще пару лет назад. Тогда этот сценарий состоял не более чем из пяти строк. Но в ходе естественного процесса эволюции величина сценария существенно выросла. Приведем перечень сценариев, рассматриваемых в данной главе:
pingall
Сценарий, использующий записи из файла /etc/hosts для выполнения опроса всех хостов
backup_gen
Общий сценарий резервного копирования, который загружает заданные по умолчанию настройки
del.lines
Оболочка потокового редактора sed, выполняющая удаление строк из файлов
access deny
Утилита, реализующая запрет доступа для определенных пользователей при выполнении регистрации
logroll
Утилита, реализующая прокрутку журнального файла в случае, если он достигает определенного размера
nfsdown
Утилита, реализующая быстрый метод демонтирования всех каталогов nfs
27.1. Сценарий pingall
Еще несколько лет назад сценарий pingall представлял собой часть общего сценария отчета, который выполнялся по ночам. Этот сценарий опрашивает все хосты, записи о которых находятся в файле hosts.
Сценарий реализует просмотр файла /etc/hosts и разыскивает все строки, которые не начинаются с символа #. Затем цикл while считывает строки отфильтрованного текста. Для присваивания переменной addr значения первого поля отфильтрованного текста используется утилита awk. Затем с помощью цикла for по каждому найденному адресу отправляется запрос.
Ниже приводится сам сценарий.
$ pg pingall
#!/bin/sh
# pingall
# просмотр файла /etc/hosts и отправка запроса по каждому адресу
cat /etc/hosts | grep -v '^#' | while read LINE
do
ADDR=`awk '{print $1}'`
for MACHINE in $ADDR
do
ping -s -c1 $MACHINE
done
done
Сценарий pingall можно легко расширить и включить в него функции отчетов, связанные с другими сетевыми утилитами.
27.2. Сценарий backup_gen
Сценарий backup_gen приводится здесь вовсе не для иллюстрации методики резервирования каталогов. Этот сценарий является удачным примером совместного использования настроек, общих для нескольких сценариев.
Сценарий backup_gen предназначен для создания резервных копий. При выполнении сценария просматривается заданный по умолчанию файл конфигурации, который затем используется для резервирования системы. При желании пользователь может изменять настройки, заданные по умолчанию. Сценарий является отличным примером того, как различные сценарии могут применять одинаковые настройки или изменять их во время выполнения сценария. После запуска сценария выполняется проверка на наличие исходного файла (backup.defaults). Если этот файл не найден, сценарий завершается.
При выполнении сценария отображается заголовок экрана и настройки, заданные по умолчанию. Пользователю направляется запрос о том, требуется ли изменять какие‑либо настройки, заданные по умолчанию. Если ответ положителен, поступает запрос на ввод кода, применяемого для изменения необходимых настроек. Для ввода правильного кода пользователю предоставляются три попытки; если введен неверный код, используются настройки, заданные по умолчанию. При вводе корректного кода пользователь может изменить приведенные ниже настройки (значения, заданные по умолчанию, содержатся в квадратных скобках []):