Текст книги "Linux и UNIX: программирование в shell. Руководство разработчика"
Автор книги: Дэвид Тейнсли
сообщить о нарушении
Текущая страница: 22 (всего у книги 25 страниц)
Type Of Backup : $_TYPE
Log file of backup : $_LOGFILE
MAYDAY
}
get_code ()
{
#пользователи имеют 3 попытки для ввода правильного кода
#_CODE загружается из исходного файла
clear
header
_COUNTER=0
echo "YOU MUST ENTER THE CORRECT CODE TO BE ABLE TO CHANGE DEFAULT SETTINGS"
while :
do
_COUNTER=`expr $_COUNTER + 1`
echo -n "Enter the code to change the settings:"
read T_CODE
# echo $_COUNTER
if [ "$T_CODE"="$_CODE" ]; then
return 0
else
if [ "$_COUNTER" -gt 3 ]; then
echo "Sorry incorrect code entered, you cannot change the settings.." return 1
fi
fi
done
}
check_drivef() {
# перемотка ленты
mt -f /dev/$_DEVICE rewind > /dev/null 2>&1
if [ $? -ne 0 ]; then
return 1 else
return 0
fi
)
#========== main ==============
# чтение файла с параметрами
check_source
header
#отображение содержимого переменных show_settings
#уточнение у пользователя, желает ли он изменить настройки
if continue_prompt "Do you wish To Change Some Of The System Defaults" "Y"; then
# да, тогда введите имя
if get_code; then
# изменение параметров change_settings fi fi
# параметры получены, резервное копирование
if check_drive; then
echo "tape OK…."
else
echo "Cannot rewind the tape..is it in the tape drive ???"
echo "Check it out"
exit 1
fi
# что копировать
case $_TYPE in
Full|full)
BACKUP_PATH="sybase syb/support etc var bin apps use/local";;
Normal|normal)
BACKUP_PATH="etc var bin apps usr/local";;
Sybase|sybase)
BACKUP_PATH="Sybase syb/support";;
esac
# резервное копирование
cd /
echo "Now starting backup "
find $BACKUP_PATH -print | cpio -ovB -O /dev/$_DEVICE >> $_LOGFILE 2>&1
#если приведенная выше команда cpio не выполняется в системе,
#воспользуйтесь командой cpio, приведенной ниже
#find $BACKUP_PATH -print [ cpio -ovB > /dev/$_DEVICE >> $_LOGFILE 2>&1
#для получения дополнительной информации измените -ovB на -ovcC66536
if [ "$_INFORM"="yes" ]; then
echo "Backup finished check the log file" | mail admin fi
Файл backup.defaults содержит заданные по умолчанию настройки наряду с функцией continue_prompt. Ниже приводится содержимое файла.
$ pg backup.defaults
#!/bin/sh
#backup.defaults
#файл конфигурации, заданный по умолчанию, для сетевых резервных копий
#редактируете его на свой страх и риск!!
#
_CODE="comet"
_LOGFILE="/appdva/backup/log.`date +%y%m%d`"
_DEVICE="rmt0"
_INFORM="yes"
_TYPE="Full"
continue_prompt ()
#continue_prompt
#для вызова: continue_prompt "отображаемая строка"
default_answer ()
{
_STR=$1
_DEFAULT=$2
# проверка ввода корректных параметров
if [ $# -lt 1 ]; then
echo "continue_prompt: I need a string to display"
return 1
fi
while : do
echo -n "$_STR [Y.. N] [$_DEFAULT]:"
read _ANS
: ${_ANS:=$_DEFAULT]
if [ "$_ANS" = "" ]; then
case $_ANS in
Y) return 0 ;;
N) return 1 ;;
esac
fi # пользователь сделал выбор
case $_ANS in
y|Y|Yes|YES) return 0;;
n|N|No|NO) return 1;;
*) echo "Answer either Y or N, default is $_DEFAULT";;
esac
echo $_ANS
done
}
Ниже приводится поток вывода при отображении настроек, заданных по умолчанию, причем пользователя запрашивают, желает ли он изменить эти настройки:
Следующий поток вывода иллюстрирует процесс изменения значения для настроек, заданных по умолчанию. Здесь изменился тип резервного копирования, и когда сценарий проверяет ленточный накопитель, он обнаруживает определенные проблемы. Сценарий завершает работу с помощью кода завершения последней команды.
Tape Device: rmt0, rmt1, rmt3
Mail Admin: yes, no
Backup Type: full, normal, Sybase
Tape Device To Be Used For This Backup [rmt0]:
Mail Admin When Done [yes]:
Backup Type [Full]: Normal
Cannot rewind the tape..is it in the tape drive ???
Check it out
27.3. Сценарий del.lines
О данном сценарии часто заходит речь, когда разработчики вопрошают: "Где же команда sed, выполняющая повторное удаление пустых строк?" Именно для этой цели и создан этот небольшой сценарий.
Действительно, сценарий представляет собой оболочку для потокового редактора sed. Поскольку этот процесс применяется довольно часто, разработчики заинтересованы в подобном сценарии.
Сценарии интерпретатора shell не должны быть большими. Создание сценариев целесообразно, если при автоматизации задач экономится время пользователя.
Сценарий del.lines может обрабатывать один или несколько файлов. До того, как команда sed приступит к удалению всех пустых строк, проверяется наличие каждого файла. Поток вывода команды sed с помощью символов $$ направляется во временный файл. Затем файл перемещается обратно, заменяя исходный файл.
Чтобы просмотреть все имена файлов, применяется команда shift. Цикл while выполняется до тех пор, пока имеются обрабатываемые файлы.
Введите команду del.lines -help, в результате чего отобразится немного разреженная справочная строка. Желательно создать более удобную справочную конструкцию. Сценарий имеет следующий вид:
$ pg del.lines
#!/bin/sh
#del.lines
#сценарий получает имена файлов и удаляет из них все пустые строки
TEMP_F=/tmp/del.lines.$$
usage ()
{
# usage
echo "Usage :`basename $0` file [file..]"
echo "try `basename $0` -help for more info"
exit 1
}
if [ $# -eq 0 ]; then
usage
fi
FlLES=$1
while [ $# -gt 0 ] do
echo "..$1"
case $1 in
–help) cat << MAYDAY
Use this script to delete all blank lines from a text file(s)
MAYDAY
exit 0;;
*)FILE_NAME=$1
if [ -f $1 ]; then
sed '/^$/d' $FILE_NAME > $TEMP_F
mv $TEMP_F $FILE_NAME
else
echo "`basename $0` cannot find this file : $1"
fi
shift;;
esac
done
27.4. Сценарий access.deny
Чтобы пользователи не регистрировались в системе при введении необходимых обновлений, можно воспользоваться методом /etc/nologin, который доступен для большинства систем. Когда в каталоге /etc создается файл nologin, обычно применяется команда touch. И никто из пользователей, кроме пользователя root, не может зарегистрироваться.
Если данная система не поддерживает метод nologin, не все потеряно – можно создать подобный метод самостоятельно. Ниже показано, как это осуществить на практике.
В файл /etc/profile помещается следующий код:
if [ -f /etc/nologin ]; then
if [ $LOGNAME != "root" ]; then
echo "Sorry $LOGNAME the system is unavailable at the moment"
exit 1
fi
fi
Теперь, если требуется запретить регистрацию для всех пользователей, за исключением пользователя root, примените команду touch для создания в каталоге /etc файла nologin и удостоверьтесь, что все пользователи имеют право читать этот файл.
touch /etc/nologin chmod 644 /etc/nologin
Если необходимо вернуться к старому порядку, удалите файл nologin следующим образом:
rm /etc/nologin
Описанная методика используется для отключения всех пользователей, кроме пользователя root. Если нужно временно отключить некоторые учетные записи, можно обратиться к файлу /etc/passwd, а в качестве первого символа в поле пароля следует указать символ *. Однако такой подход применяется редко, и если пользователь недостаточно четко выполняет все действия, можно столкнуться с проблемами при работе всей системы.
Linux располагает утилитой, с помощью которой в файл login.access вводятся имена пользователей и групп. Этот файл предназначен для предоставления доступа к системе.
Рассмотрим версию утилиты под названием deny.access. Сценарий, который выполняется из файла /etc/profile, просматривает файл lockout.user. Этот файл включает имена пользователей, в регистрации которых вы не заинтересованы. Если в файле присутствует слово "all", доступ запрещается всем пользователям, кроме пользователя root.
Ниже приводится пример файла lockout.user. Этот файл может включать строки комментария.
$ pg lockout.users
#lockout.users
#поместите в этот файл имена пользователей по вашему усмотрению
#снятие системной блокировки
#Удалите из этого файла имена пользователей, чтобы пользователи могли
#вернуться назад.
#peter находится в долговременном отпуске и вернется в следующем месяце
peter
#lulu отсутствует две недели, вернется в конце месяца
lulu
dave
pauline
Рассмотрим, как функционирует сценарий. Сначала выполняется команда trap для игнорирования сигналов. Вследствие этого пользователь не может прервать выполнение сценария. Если имеется файл lock.users, сценарий продолжает выполняться. Первым делом проверяется наличие слова "alf" Если это слово присутствует, тогда не принимаются во внимание имена всех пользователей из данного файла. Не следует применять строку комментария для устранения влияния слова "all"; этот путь не приведет к успеху. Однако можно устранить из комментария имена пользователей.
Если обнаружена запись "all", блокируются имена всех пользователей, кроме пользователя root. Чтобы удостовериться в том, что найдено точное соответствие шаблону, применяют шаблон all> команды grep. На экран для пользователей системы выводится сообщение о том, что система в данный момент недоступна.
Основной функцией является функция get_users. Она реализует просмотр файла lockout.users, причем игнорируются все строки, начинающиеся с символа хэша. Выполняется сравнение имен и проверяется, что имя пользователя root не содержится в файле. В результате этого имя пользователя root блокируется.
Регистрационное имя пользователя, находящегося в текущий момент в системе, извлекается из переменной LOGNAME и сравнивается со значением переменной names. Переменная names сохраняет имя текущего пользователя из просматриваемого файла lockout.users. Если совпадение найдено, значение переменной LOGNAME отображается вместе с сообщением. Затем пользователь завершает работу сценария.
Этот сценарий выполнялся на нескольких машинах, которые охватывали до 40 пользователей. Во время процесса регистрации скорость выполнения сценария была довольно высока. Сценарий использовался с целью временной блокировки доступа для тех пользователей, которые отсутствовали более недели. Кроме того, доступ для отдельных пользователей блокировался ежедневно на определенное время, в течение которого обновлялись жизненно важные системы.
В файл /etc/profile следует поместить следующую строку. Эта строка может быть размешена в конце файла, тогда пользователи получат возможность просматривать это сообщение первым среди дополнительных сведений.
. /apps/bin/deny.access
Каталог /apps/bin является областью, где можно хранить все глобальные сценарии. Возможно применение другой области, однако при этом следует убедиться в том, что каждый пользователь может выполнить этот сценарий и воспользоваться каталогом, в котором он находится.
Если получено сообщение об ошибке "permission denied" ("разрешения нет"), значит, сценарий или каталог не имеют достаточного уровня разрешения.
В данном случае файл lockout.users находится в каталоге /apps/etc. Этот каталог можно изменить, поскольку ваша структура наверняка отличается от рассматриваемой. Поскольку файл является исходным, с помощью команды set можно просматривать код функции (но не фактический файл lockout.users). Если это затруднительно, примените команду unset для удаления функции после ее выполнения. Поместите команду unset непосредственно после обращения к сценарию в файл /etc/profile. Например:
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. В задачу этого сценария входит успешный запуск и прекращение функционирования какой‑либо службы.
Методика создания каталогов конфигурации уровня выполнения позволяет автоматизировать работу сценариев rc.scripts только при изменении уровня выполнения. Однако нельзя определить, запущены или остановлены все необходимые службы на уровне выполнения. Эта часть работы должна выполняться shell–программистом.
Уровни выполнения можно настраивать в соответствии с действительно выполняемыми службами, но данная тема в книге не рассматривается.
28.1. Определение наличия каталогов уровня выполнения
Каталоги, где хранятся сценарии rc.scripts (здесь фактически речь идет о ссылках, которые мы рассмотрим далее), имеют следующий вид:
/etc/rcN.d
или
/etc/rc.d/rcN.d
где N – число. Обычно это число равно семи, поскольку каталоги rcN. d нумеруются от 0 до 6. Однако в системе можно иметь несколько дополнительных каталогов типа rcS.d. Количество каталогов не столь важно; все рассматриваемые каталоги перечислены ниже.
$ pwd
/etc
$ ls -l
drwxr‑xr‑x
2
root
sys
1024
Dec
22
1996
rc0.d
drwxr‑xr‑x
2
root
sys
1024
Dec
22
1996
rc1.d
drwxr‑xr‑x
2
root
sys
1024
Dec
22
1996
rc2.d
drwxr‑xr‑x
2
root
sys
1024
Dec
22
1996
rc3.d
drwxr‑xr‑x
2
root
sys
1024
Dec
22
1996
rc4.d
drwxr‑xr‑x
2
root
sys
1024
Dec
22
1996
rc5.d
drwxr‑xr‑x
2
root
sys
1024
Dec
22
1996
rc6.d
drwxr‑xr‑x
2
root
sys
1024
Dec
22
1996
rcS.d
В Linux…
$ pwd
/etc/rc.d
$ ls
init.d rc.local rc0.d rc2.d rc4.d rc6.d
rc rc.sysinit rc1.d rc3.d rc5.d
Если команда cd применяется в одном из каталогов rcN.d, можно просмотреть и другие сценарии rc.scripts, связанные с этими каталогами.
$ pwd
/etc/rc.d/rc2.d
$ ls -1
lrwxrwxrwx
1
root
root
16
Dec 3
15:16
K87ypbind -> ../init.d/yd
lrwxrwxrwx
1
root
root
17
Dec 3
15:10
K89portmap -> ../init.d/p
lrwxrwxrwx
1
root
root
17
Dec 3
15:07
S01kerneld -> ../init.d/d
28.2. Уточнение текущего уровня выполнения
В этой главе не рассматриваются вопросы системного администрирования, однако shell–программист должен знать не только принципы функционирования сценариев rc.scripts, но также принципы их совмещения с каталогами конфигурации уровня выполнения. Для уточнения уровня выполнения примените команду:
$ who -r
run‑level 4 Apr 22 13:26 4 0 3
Число, расположенное после слов "run‑level" является текущим уровнем выполнения. Следующие за ним данные определяют время выполнения последней перезагрузки системы.
В Linux…
$ runlevel 2 3
В первом столбце указан уровень, на котором система находилась на предварительном этапе, а во втором столбце – текущий уровень, который в данном случае равен 3.
28.3. Ускорение работы с помощью файла inittab
Каталог уровня выполнения состоит из набора сценариев, более совершенных, чем службы. Слово "services" в этом контексте означает и демон, и приложение, и серверы, и подсистемы или процессы сценария. Во время загрузки системы вызывается процесс init (этот процесс является родоначальником всех остальных процессов). Одной из задач упомянутого процесса является определение запускаемых служб, а также определение уровня выполнения, заданного по умолчанию. Эти сведения можно получить, просматривая текстовый файл конфигурации под названием inittab, размещенный в каталоге /etc. Процесс init также использует этот файл для получения указаний по поводу загрузки определенных процессов. Если необходимо изменить этот файл, сначала создайте резервную копию. В случае повреждения файла или возникновения ошибок, приводящих к "деградации" системы, система не будет загружаться обычным образом; вам придется загружаться в однопользовательском режиме и устранять повреждения в файле.
Файл inittab включает поля, имеющие весьма лимитированный формат. Формат файла будет следующий:
id:rstart:action:process
Поле id имеет уникальное название, которое идентифицирует запись процесса,
Поле rstart содержит число, которое указывает, на каком уровне выполнения запускается процесс.
Поле action указывает процессу init, как рассматривать текущий процесс. Существует большое количество названий для поля action, но наиболее распространенными являются wait и respawn. Название wait означает, что начавшийся процесс ожидает завершения. Название respawn означает, что процесс начинается даже в том случае, если он еще не существует. Если же существует, то запускается заново в тот момент, когда он уже завершается.
Поле process содержит действительную команду для выполнения. Ниже приводится фрагмент файла inittab.
$ pg /etc/inittab
id:3:initdefault:
# Инициализация системы.
si::sysinit:/etc/rc.d/rc.sysinit
уровень выполнения 0 10:0:wait:/etc/rc.d/rc 0
уровень выполнения 1 11:1:wait:/etc/rc.d/rc 1
уровень выполнения 2 12:2:wait:/etc/rc.d/rc 2
уровень выполнения 3 13:3:wait:/etc/rc.d/rc 3
уровень выполнения 4 14:4:wait:/etc/rc.d/rc 4
уровень выполнения 5 15:5:wait:/etc/rc.d/rc 5
уровень выполнения 6 16:6:wait:/etc/rc.d/rc 6
Выполнение gettys на стандартных уровнях выполнения
1:12345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:234 5:respawn:/sbin/mingetty tty4
5:234 5:respawn:/sbin/mingetty tty0
6:2345:respawn:/sbin/mingetty ttyS1 vt100
Первая строка файла описывает уровень выполнения системы, заданный по умолчанию; ниже приводится уровень выполнения 3, который не является чем‑либо необычным.
Строки, которые начинаются числами 10—16, определяют запуск или прекращают выполнение сценариев уровней выполнения для определенных уровней выполнения. Например, рассмотрим следующую строку:
15:5:wait:/etc/rc.d/rc 5
В строке содержится следующая информация: если пользователь находится на уровне выполнения 5, сценарий /etc/rc.d/rc запускается с параметром 5. Это означает, что сценарий /etc/rc.d/rc выполняет все сценарии в каталоге /etc/rc.d/rc/rc5.d.
Последняя строка файла – уровни выполнения 2, 3, 4 и 5 -cвидетельствует о том, что процесс заново возрождается. То есть, процесс никогда не уничтожится (ну, по крайней мере, в течение одной секунды). Непрерывно отвергается процесс mingetty для последовательного порта tty$1. В данном случае в роли параметра используется ID терминала, который имеет значение vt100.
28.4. Переходим к уровням выполнения
Одной из последних задач процесса init, которая реализуется перед тем, как система «полностью запустится», является выполнение всех сценариев для уровня выполнения, заданного по умолчанию. Файл, осуществляющий эту задачу, называется либо /etc/rc.d/rc, либо /etc/rc.init. Роль этого сценария заключается в первоначальном уничтожении процессов для этого уровня, а затем – в установке процессов данного уровня.
Как процесс определяет, какие службы запускаются или прекращают выполнение? Файл rc или rc.init выполняет функции цикла for при обработке каждого сценария rc.script. Каждый сценарий rc.script запускается в каталоге rc3.d с помощью опции K, и ему передается параметр "stop". Затем аналогичный процесс поддерживается для всех сценариев rc.scripts, которые запускаются с помощью опции s, и им передаются параметры "start". Конечно, подобный процесс поддерживается при обращении к измененному уровню выполнения. Но, в отличие от каталога rc3.d, в данном случае обрабатывается каталог rcN.d, благодаря чему изменяется уровень выполнения N.
Сценарии, находящиеся в каталоге rcN.d, представляют собой только ссылки – фактические сценарии вызываются в другом месте. Эти сценарии располагаются в каталоге под названием /usr/sbin/init.d или /etc/init.d.
В Linux…
/etc/rc.d/init.d
В этом каталоге хранятся несколько сценариев, которые могут запускать иди прекращать функционирование служб. Имена этих сценариев формируются по системе rc.<что он делает>, где rc означает run command или run control. Некоторые системные администраторы называют эти сценарии "реально критическими" (really crucial). Ниже приводится листинг подобного файла.
$ ls
rc.localfs rc.halt rc.reboot rc.syslogd rc.daemon
Общий формат вызова сценариев rc.scripts будет следующим:
rename stop -oстанов службы rc.name start – запуск службы
Необязательными вызовами являются вызовы перезапуска и состояния. Любой другой вызов появляется в ответ на сообщение о применении, в котором содержится методика вызова сценария rc.script. Следует отметить, что эти сценарии можно вызывать вручную.
Итак, вы уже изучили, какие функции выполняет сценарий при вызове. Следующий этап – помещение сценариев в соответствующие каталоги rcN.d. Но сначала рассмотрим систему уровней выполнения.
28.4.1. Различные уровни выполнения
Существует семь уровней выполнения (табл. 28.1). Различные системы имеют на некоторых уровнях небольшие отличия.
Прежде чем размещать сценарий на различных уровнях выполнения, уточните, на каких уровнях эта служба должна запускаться или уничтожаться (если сценарий запускает и прекращает выполнение службы). Если решение принято, можно приступать к делу.
Таблица 28.1. Функции различных уровней выполнения
Уровень выполнения 0
Прекращает и останавливает целую систему
Уровень выполнения I
Отдельный пользователь или режим администрирования
Уровень выполнения 2
Многопользовательский режим; запускаются некоторые
сетевые службы. Ряд систем использует этот уровень как уровень выполнения в обычном режиме функционирования вместо уровня выполнения 3
Уровень выполнения 3
Обычный режим функционирования, применяется для всех сетевых служб
Уровень выполнения 4
Уровень определенного пользователя; применяйте этот уровень для настройки при выполнении
Уровень выполнения 5
Этот уровень имеет некоторые вариации в виде заданного по умолчанию режима X‑windows; в других случаях этот уровень применяется для перевода системы в режим поддержки
Уровень выполнения 6
Перезагрузка
28.4.2. Формат сценария уровня выполнения
Сценарии в каталогах rcN.d представляют собой все символические ссылки, которые сохраняют дублирование сценариев на нулевом уровне. Формат этих ссылок:
Snn.имя_сценария
или
Кnn.имя_сценария
где
S
Означает запуск процесса
K
Означает уничтожение процесса
nn
Является двузначным числом от 00 до 99, хотя некоторые системы характеризуются трехзначными числами от 000 до 999. При установлении ссылок на различные каталоги сохраняйте то же самое число. Например, если служба запускается в каталоге rc3.d и сценарий называется S45.myscript, то при запуске этой службы в каталоге rc2.d нужно убедиться, что сценарий также называется S45.myscript.
имя сценария
Является названием сценария, зависящим от типа системы. Может находиться в одном из файлов:
/usr/sbin/init.d /etc/rc.d /etc/init.d
Когда процесс init требует вызова сценариев rc.scripts, выполняется процесс уничтожения, начиная от самого большего и завершая самым меньшим числом К, т. е. К23.myscript K12.named. Запуск выполняется в диапазоне от самого меньшего до самого большего значения. Если вы работаете в системе Linux, числа К вызываются от самого большего до самого меньшего числа.
28.4.3. Инсталляция сценария уровня выполнения
Чтобы инсталлировать собственный сценарий rc.script, следует выполнить следующее:
• написать сценарий, который действительно удовлетворяет стандартам вызова;
• удостовериться, что сценарий действительно запускает или останавливает необходимую службу;
• разместить сценарий (в зависимости от системы( в каталоге /etc/init.d, /usr/sbin/init.d или в каталоге /etc/rc.d;
• cоздать ссылки во всех подходящих каталогах rcN.d, используя соответствующее соглашение о наименовании.
Ниже приводится сценарий, который запускает и прекращает выполнение приложения под названием rc.audit– Эта служба запускается на уровнях выполнения 3, 5 и 4 и уничтожается на уровнях выполнения 6, 2 и 1. При просмотре некоторых записей в каталогах rcN.d число 35 является зарезервированным, поэтому оно применяется в данном случае. Действительно, нет причин прекращать функционирование сценария, поэтому применяется число, которое уже использовалось.
Рассмотрим этот сценарий. Как можно заметить, простая конструкция case выполняет перехват параметров stop и start.
$ pg rc.audit
#!/bin/sh
#rc.audit start | stop
#сценарий запускает или прекращает выполнение
#контролирующего приложения zeega
#
case "$1" in
start)
echo -n "Starting the audit system…."
/apps/audit/audlcp -a -p 12
echo
touch /var/lock/subsys/rc.audit
;;
stop)
echo -n "Stopping the audit system…."
/apps/audit/auddown -k0
echo
rm -f /var/lock/subsys/rc.audit
;;
