Содержание
Прошлые лекции были посвящены различным особенностям архитектуры UNIX, использованию этой операционной системы в локальной и сетевой работе, некоторым аспектам администрирования системы. В этой части речь пойдет о комплексном администрировании UNIX-систем – об управлении службами и управлении программным обеспечением.
В этой лекции освещяются процесс загрузки UNIX-систем и запуск системных служб. Некоторые их них, такие как планировщик заданий или системный журнал, рассматриваются более подробно.
Презентация 6-01: этапы загрузки системы
Загрузку операционной системы можно разделить на несколько этапов. Начальный этап загрузки не зависит от того, какая операционная система установлена на компьютере, он в первую очередь связан с особенностями архитектуры используемого компьютера. Затем следуют этапы загрузчиков, которые также могут не относиться к определённым операционным системам, после чего инициализируется ядро операционной системы и производятся специфические только для этой ОС операции.
Рассмотрим загрузку операционной системы UNIX как следующую последовательность этапов (Рисунок 6.1, «Этапы загрузки ОС UNIX»):
Как правило, сразу после включения питания программа ПЗУ BIOS проводит тестирование оборудования, затем запускается досистемный загрузчик.
Задача этого этапа – определить (возможно, с помощью пользователя), с какого устройства будет идти загрузка, загрузить оттуда специальную программу-загрузчик и запустить её. Например, выяснить, что устройство для загрузки – жесткий диск, считать самый первый сектор этого диска и передать управление программе, которая находится в считанной области.
Загрузчик первого уровня занимает обычно не более одного сектора в самом начале диска – в его загрузочном секторе (Master Boot Record).
Ядро операционной системы имеет довольно сложную структуру – а значит, и непростой способ загрузки; оно может быть довольно большим, и может располагаться неизвестно где на диске, подчиняясь законам файловой системы (например, состоять из нескольких частей, разбросанных по диску). Учесть все это первичный загрузчик не в состоянии, поэтому его задача: определить, где на диске находится загрузчик второго уровня, загрузить его в память и передать ему управление.
Вторичный загрузчик – сложная программа с интерфейсом пользователя, который даёт возможность выбирать опрерационную систему или параметры загрузки ядра. Загрузчик должен иметь доступ к образу ядра, поэтому в него включается поддержка файловых систем.
В любом случае вторичный загрузчик читает образ ядра в определённый адрес памяти и передаёт туда управление.
Большинство операционных систем имеют собственные загрузчики первого и второго уровней. Однако, существуют универсальные загрузчики, например GRUB.
Как мы уже выяснии ранее, ядро – очень сложная программа, взаимодействующая с различным оборудованием, поэтому прежде чем начать работу с системой, её необходимо проинициализировать.
Этот этап специфичен для различных операционных систем. В UNIX-подобных системах при этом обычно выводится информация о загрузке ядра отладочного характера.
Первым делом ядро занимается определением параметров вычислительной подсистемы компьютера: выясняет тип и быстродействие центрального процессора, объем оперативной памяти, объем и структуру кэш-памяти; делает предположение об архитектуре компьютера в целом и многое друго.
На следующем шаге ядро определяет состав и архитектуру всего аппаратного наполнения компьютера: тип и параметры шин передачи данных и устройств управления ими (контроллеров), список внешних устройств, доступных по шинам, настройки этих устройств – диапазон портов ввода-вывода, адрес ПЗУ, занимаемое аппаратное прерывание, номер канала прямого доступа к памяти и т.п..
Ядро на основании переданного ему параметра выбирает корневой
раздел – файловую систему, содержащую будущий
каталог /
и его подкаталоги (для системной
начальной загрузки важены каталоги
/etc
, /bin
,
и /sbin
). Корневой
раздел монтируется в
качестве /
. После этого ядро запускает свой
первый процесс – init (по
умолчанию, /sbin/init
).
С этого момента операционная система обеспечивает полноценную функциональность всем исполняющимся процессам. В UNIX первым запускаемым процессом является init, о котором сказано в следующем разделе.
Презентация 6-02: процесс init
Процесс init является обычным
процессом операционной системы, однако он имеет некоторые особенности: его PID
всегда равен 1
, и процесс этот работает всё время, пока
работает система.
В UNIX-системах init играет две важные роли:
производит инициализацию системы – как правило, для работы запущенного ядра не достаточно, нужно примонтировать все файловые системы, загрузить дополнительные драйверы устройств, запустить демоны и т.п.;
является родительским для всех процессов в системе – это является гарантией того, что в UNIX любой процесс имеет своего родителя.
Это обеспечивается тем, что в UNIX процессы создаются с помощью последовательного ответвления (системный вызов fork).
Как правило, процесс init запускается из исполняемого
файла /sbin/init
и является специфичным для различных
UNIX-систем. Рассмотрим примеры различных современных версий UNIX и их
классификацию с точкм зрения инициализации системы.
Исторически, различные версии UNIX наследовались от двух систем: оригинальной UNIX компании AT&T (вплоть до версии System V) и BSD UNIX, созданной в университете Беркли. В них применялись различные принципы загрузки системы, так что современные версии UNIX по этому критерию можно разделить на:
Презентация 6-03: уровни выполнения системы
Основным признаком этих систем является наличие уровня выполнения (run level) – одного из возможных режимов работы системы. Каждый уровень исполнения имеет свой номер – часть этих номеров стандартизована. В любой момент времени система может находиться в одном из них – изменение режима работы производится с помощью перезапуска init с указанным номером.
остановка системы (halt) – работа системы должна быть прекращена;
однопользовательский режим работы – система инициализирует минимум служб и даёт единственному пользователю (как правило, суперпользователю) без проведения аутентификации командную строку. Как правило, этот режим используется для восстановления системы;
многопользовательский режим – пользователи могут работать на разных терминалах, вход в систему с процессом аутентификации;
многопользовательский сетевой режим – в отличие от предыдущего уровня, осуществляется настройка сети и запускаются различные сетевые службы;
не имеет стандартного толкования и практически не используется;
запуск графической подсистемы – по сравнению с уровнем 3 производится также старт графической подсистемы X11 (см. Глава 7, Графическая подсистема UNIX), и вход в систему осуществляется уже в графическом режиме;
перезагрузка системы – при включении этого режима останавливаются все запущенные программы и производится перезагрузка.
Таким образом, каждый уровень системы подразумевает запуск определённого
набора программ, который может быть задан администратором системы. Стартовые
скрипты, соответствующие уровням выполнения располагаются в
директории /etc/rc.d
.
На практике, в серверных системах обычно при старте системы используется 3-й уровень выполнения, в домашних – 5-й.
В этих системах традиционно используется линейная схема загрузки. Эта схема устроена намного проще (загрузка таких систем проходит намного быстрее – особенно на медленных машинах), но зато более сложная в администрировании.
Инициализация сиситемы осуществляется единым
скриптом /etc/rc
. В этом скрипте прописаны
последовательные команды инициализации системы, запуска демонов и т.п.. Следом
за ним следует запуск скрипта /etc/rc.local
, который
служит для запуска всех локальных программ и настроек,
установленных системым администратором сверх дистрибутива операционной системы.
При обновлении отдельных программ или изменении их настроек админимтратору приходится вручную править стартовые скрипты. Эти сложности привели к тому, что в современные BSD-системы внедряются более легкие в администрировании схемы загрузки.
Некоторые современные UNIX-подобные системы (в частности, многие дистрибутивы Linux) предоставляют собственные схемы загрузки системы, сочетающие в себе достоинства обозначенных выше схем.
Для примера можно рассмотреть схему, используемую в дистрибутивах Linux Debian и Gentoo. Вводится понятие программных уровней выполнения (software run levels) – которые могут создаваться и изменяться администратором системы.
Каждому уровеню выполнения соответствует набор сервисов, которые будут. запущены при переключении системы на этот уровень выполнения. По умолчанию, используется один уровень исполнения – default.
Службы связаны между собой через так называемые зависимости: к примеру, служба, монтирующая сетевые папки, требует наличия сконфигурированной сети, а значит зависит от службы конфигурации сети. Службы конфигурации сети, в свою очередь, зависит от службы, загружающей дополнительные модули ядра (напрмер, драйвер сетевой карты).
Управление уровнями загрузки – какие программы необходимо запускать на кажом из них – производится аналогично System V-системам.
Конигрурация процесса init находится в
файле /etc/inittab
. Ниже приведён пример такого файла.
Пример 6.1. Пример файла /etc/inittab
# Default runlevel. id:3:initdefault: # System initialization, mount local filesystems, etc. si::sysinit:/sbin/rc sysinit # Further system initialization, brings up the boot runlevel. rc::bootwait:/sbin/rc boot l0:0:wait:/sbin/rc shutdown l1:S1:wait:/sbin/rc single l2:2:wait:/sbin/rc nonetwork l3:3:wait:/sbin/rc default l4:4:wait:/sbin/rc default l5:5:wait:/sbin/rc default l6:6:wait:/sbin/rc reboot # TERMINALS c1:12345:respawn:/sbin/agetty 38400 tty1 linux c2:2345:respawn:/sbin/agetty 38400 tty2 linux c3:2345:respawn:/sbin/agetty 38400 tty3 linux c4:2345:respawn:/sbin/agetty 38400 tty4 linux c5:2345:respawn:/sbin/agetty 38400 tty5 linux c6:2345:respawn:/sbin/agetty 38400 tty6 linux # What to do at the "Three Finger Salute". ca:12345:ctrlaltdel:/sbin/shutdown -r now # Used by /etc/init.d/xdm to control DM startup. x:a:once:/etc/X11/startDM.sh
Основными параметрами загрузки, задаемыми в этом файле, являются:
начальный уровень загрузки (строка с initdefault) – номер уровня выполения, в который переводится система при старте;
скрипты для запуска уровней исполнения – для каждого уровня (0 – 6) задаётся программа с аргуметами запуска, которая будет запущена в случае перевода системы на один из уровней выполнения;
настройки виртуальных терминалов – сколько необходимо инициализировать при старте системы, какую программу для этого использовать;
настройка ракции на нажатие Ctrl-Alt-Del – какую программу необходимо запустить при этом;
прочие настройки, специфичные для данной версии UNIX.
Презентация 6-04: системные службы
Системные службы – это программы, выполняющие в системе определённую функцию и, как правило, стартующие при запуске системы. Каждой системной службе соответствует стартовый скрипт – специальная программа, осуществляющая запуск демона или программы, которая и обеспечивает функциональность службы.
Таким образом, можно построить дерево зависимостей, и перезапуск одного скрипта будет приводить к перезапуску всех его потомков.
В System V-системах стартовые скрипты находятся в
директории /etc/init.d
и принимают единственный стадартный
аргумент – один
из: «start», «stop», «restart». Таким
образом, каждая служба может быть остановлена, запущена или перезапущена.
Например, для перезапуска службы системного журнала необходимо выполнить команду /etc/init.d/syslogd restart.
Пример 6.2. Пример перезапуска службы
desktop ~ # /etc/init.d/syslogd restart * Stopping syslog-ng ... [ ok ] * Starting syslog-ng ... [ ok ] desktop ~ #
Как правило, для управления службами необходимо обладать правами суперпользователя.
Службы используются в UNIX-системах, использующих System V-подобную схему загрузки системы. При этом каждому уровню выполнения соответствует набор служб, запускаемых при переключении на этот уровень.
В директории /etc/rc.d/
можно увидеть
директории rc0.d
, rc1.d
и
т.д. – по одной на каждый уровень выполенения. В этих директориях
содержатся ссылки на службы, которые будут запущены или остановлены при переходе на
соответствующий уровень выполнения.
Особый интерес представляют имена ссылок на стартовые скрипты служб: например,
/etc/rc.d/rc0.d/K60crond
и /etc/rc.d/rc3.d/S40crond, указывающие на один
скрипт /etc/init.d/crond службы системного журнала. Скрипт,
начинающийся с «K» соответствует останову службы,
а «S» – запуску. Числа, следующие перед именем службы
задают порядок запуска скриптов в директории. Например,
скрипт /etc/rc.d/rc3.d/S34syslogd будет запущен до
скрипта /etc/rc.d/rc3.d/S40crond, тогда
как /etc/rc.d/rc3.d/K60crond
до /etc/rc.d/rc3.d/K66syslogd. Можно заметить, что сумма
чисел для одной службы равна 100
– это позволяет
упорядочить все скрипты в порядке старта, обратном порядку завершения.
Для установления связи между службами и уровнями выполнения используется утилита chkconfig.
Презентация 6-05: системные службы: примеры
В современных UNIX-системах существует множество служб, выполняющих самые разнообразные функции. Часть служб связано с демонами, часть – с настройкой каких-то элементов операционной системы. Рассмотрим примеры служб, существующих в том или ином виде практически во всех UNIX-системах:
системный плнировщик заданий – демон, запускающий определённые программы с заданными интервалами времени (подробнее см. «Служба планирования заданий»);
системный журнал – демон, организующий единый интерфейс для журналирования событий в системе (подробнее см. «Мониторинг и журналирование»);
служба инициализация сети – производит автоматическую настройку интерфейсов, маршрутизации и т.п. (см. «Настройка сети при загрузке системы»);
служба инициализации межсетевого экрана в Linux;
набор сетевых служб, запускающих разичные сетевые серверы (подборнее см. «Сетевые службы»);
почтовый сервер – демон, обеспечивающий отправление и доставку почты по протоколу SMTP;
служба, загружающая и инициализирующая дополнительные модули ядра;
служба, которая обычно запускается в последнюю очередь и позволяет администратору стартовать дополнительные программы при загрузке системы;
служба, инициирующая проверку корневой файловой системы (с использованием утилиты, специализированной для типа файловой системы).
Рассмотрим более подробно некоторые из этих служб.
Презентация 6-06: служба планирования заданий
Одной из распространённых задач администрирования является запуск каких-то задач в определённое время с заданной периодичностью. В UNIX этой цели служит планировщик заданий cron.
Служба пранирования заданий состоит из демона, который обычно
называется crond и набора конфигурационных
файлов – для каждого из пользователей и общесистемного
/etc/crontab
.
Каждое задание характеризуется следующими параметрами:
В файле /etc/crontab
эти параметры записаны следующим
образом:
Пример 6.3. Пример файла /etc/crontab
0 * * * * rm -f /var/spool/cron/lastrun/cron.hourly 1 3 * * * rm -f /var/spool/cron/lastrun/cron.daily 15 4 * * 6 rm -f /var/spool/cron/lastrun/cron.weekly 30 5 1 * * rm -f /var/spool/cron/lastrun/cron.monthly */10 * * * * /usr/bin/test -x /usr/sbin/run-crons && /usr/sbin/run-crons */5 * * * * /usr/bin/vnstat -u 58 * * * * rdate -ncav ptbtime1.ptb.de
Каждая строка – отдельная планируемая задача. Первые пять столбцов соответствуют времени старта (точное время или промежуток, через косую), а последний – исполняемой команде.
Для изменения конфигурации планировщика можно просто отредактировать этот
файл и запустить команду crontab, но лучше пользоваться
этой командой с
параметром -e
: crontab -e.
В данном примере файла /etc/crontab
представлен механизм,
встречающийся в современных дистрибутивах –
директории /etc/cron.*
. В них располагаются исполняемые
файлы скриптов, который должны быть запущены раз в день, раз в неделю и т.п..
При этом администратору достаточно только добавить файл в соответствующую
директорию.
Демон crond в заданное время производит запуск
программы от имени соответствующего пользователя. Задачи
из /etc/crontab
запускаются от имени суперпользователя.
Демон планировщика контролирует результат выполнения запущенной программы и в случае ошибки может отправлять письмо пользователю или администратору системы.
В разных UNIX-системах существует несколько реализаций службы планирования заданий (например, dcron, fcron, anacron и т.п.), но все они реализуют описанную выше базовую функциональность.
Презентация 6-07: сетевые службы
В современных UNIX-системах существует множество сетевых служб, решающих самые разные задачи. Можно выделить несколько служб, которые используются чаще всего используются сетевыми администраторами.
Эта служба отвечает за запуск и останов демона sshd защищённого удалённого терминала. Такой сервер обычно запускается на всех машинах, для которых предполагается удалённый вход пользователей или администрирование.
sendmail – один из самых распространённых почтовых серверов. Он реализует Internet-протоколы, связанные с отправлением почты (в первую очередь SMTP) как в рамках локальной машины, так и через Internet. Даже если сервер не является почтовым, служба sendmail служит для передачи писам между пользователями системы.
inetd (и его более развитая версия xinetd) – это супер-сервер, объединяющий множество сетевых служб. По сути этот сервер выполняет роль транспорта для сетевых служб: слушает на заданом порту, при входящем соединении запускает новый процесс и перенаправляет стандартный ввод и вывод программы в tcp-соединение. При этом правила доступа, ограничение по числу параллельных соединений, журналирование и т.п. организуюся демоном inetd и настраиваются в его конфигурационных файлах.
Демон сетевой файловой системы NFS (Network File System), которая поддерживается в большинстве UNIX-систем.
samba – это набор служб по организации сетевого файлового хранилища на основе протокола CIFS, используемого в сетевых файловых системах MS Windows. Широко применяется при взаимодействии UNIX-серверов и клиентских машин под Windows.
bind (или named) – самый распространённый сервер доменных имён для UNIX.
Журналирование событий и их мониторинг – важнейшая задача администратора – не только в связи с поддержанием уровня безопаности сиситемы, но для анализа неисправностей. Журналирование является нормой для всех служб в системе и присутствует во всех версиях UNIX. Мониторинг пользователей – отдельная задача администрирования, реализованная в UNIX также на схожих с журналированием механизмах.
Презентация 6-08: служба системного журнала
Служба системного журнала состоит из следующих компонентов:
API системныж журналов являются частью стандартов POSIX и содержат функции по открытию журналов и добавлению сообщений в них, константы уровней и типов ошибок и т.п.. Программы обычно работают с этим API, не используя специфические возможности отдельно взятых демонов журналов, что обеспечивает высокий уровень переносимости программы в рамках POSIX-систем.
Процесс, запускаемый при старте системы и реализующий функциональность журналирования: получение сообщений от приложений, фильтрацию их и запись в файлы журналов.
/etc/syslog.conf
Конфигурация системного журнала является специфичной для каждого демона,
но обычно она содержит правила, согласно которым поступающие сообщения
фильтруются (какие из них можно отбросить, на какие обратить внимание и
т.п.), и указывает, в какие файлы нужно помещать журналируемую
информацию. Например, для всех сообщений, связанных с электронной
почтой, может использоваться файл с
именем maillog
. Другим интересным решением является
сохранение сообщений на другой машине в сети или даже автоматический
вывод их на принтер.
/var/log
Обычно все файлы журналов располагаются в
директории /var/log
и её поддиректориях.
Каждая запись в системном журанале содержит следующие стандартные параметры:
В конфигурационном файле по любому из этих параметров может производиться фильтрация. В файлах журналов параметры сохраняются в простом текстовом виде, что позволяет применять стандартные для UNIX механизмы поиска по текстовым файлам (например, grep) и упрощает процесс анализа событий.
Презентация 6-09: основные системные службы
Во многих UNIX-системах можно увидеть файлы системных журналов в директории
/var/log
со следующими названиями:
authlog
/ security
daemon
dmesg
maillog
/ mail
messages
xferlog
Некоторые системные службы (такие как
веб-сервер Apache) имеют свои собственные файлы
журналов. Располагаются они обычно в поддиректориях
директории /var/log
,
например /var/log/apache/
.
Презентация 6-10: ротация системных журналов
Файлы журналов преставляют собой простые текстовые файлы, которым в конец добавляются новые сообщения. Как правило, администратора интересует информация о событиях, произошедших не так давно относительно текущего момента – искать информацию в многомегабайтном журнале за последний год не так просто. Кроме того, при увеличении размеров файлов журналов они могут теоретически занять все свободное место на диске, так что администратору придётся очищать их время от времени.
Для решения этих проблем используется так называемая ротация журналов: процесс автоматического обновления файлов журналов – удаления и архивация старых файлов и создание новых.
Для каждого из файлов журнала можно задать следующее:
Журнал может обновляться по времени (например, раз в неделю или раз в месяц) или
по объёму (например, при достижении размера в 1 Мб). При этом старый файл
журнала сохраняется с именем имя_журнала.0
, а все
предыдущие версии журналов (за позапрошлую неделю и т.п.) переименовываются с
увеличением цифры на единицу. Например:
desktop ~ # ls -l /var/log/authlog* -rw-r----- 1 root wheel 47986 Feb 6 15:56 /var/log/authlog -rw-r----- 1 root wheel 77783 Feb 6 03:00 /var/log/authlog.0.gz -rw-r----- 1 root wheel 25395 Jan 30 03:00 /var/log/authlog.1.gz -rw-r----- 1 root wheel 46940 Jan 23 03:00 /var/log/authlog.2.gz -rw-r----- 1 root wheel 166844 Jan 16 03:00 /var/log/authlog.3.gz -rw-r----- 1 root wheel 68078 Jan 9 03:00 /var/log/authlog.4.gz -rw-r----- 1 root wheel 45941 Jan 2 03:00 /var/log/authlog.5.gz -rw-r----- 1 root wheel 95279 Dec 26 03:00 /var/log/authlog.6.gz -rw-r----- 1 root wheel 34083 Dec 19 03:00 /var/log/authlog.7.gz
В данном примере журналы аутентификации хранятся в течение восьми недель, при этом все старые файлы архивируются. Архивация может быть очень полезна для экономии места на диске.
Некоторые приложения требуют явного оповещения при обновлении файла журнала. Поэтому программы ротации обычно предоставляют возможность запуска утилиы до или после проведения обновления.
В операционной системе Linux для ротации журналов используется программа logrotate. В других UNIX-системах используются аналогичные, часто встроенные средства.
Презентация 6-11: мониторинг пользователей
Журналирование входа пользователей в систему ведётся вне службы системного
журнала, однако в директории /var/log
есть несколько файлов,
непосредственно связанных с мониторингом пользователей:
wtmp
lastlog
faillog
Все эти файлы имеют собственный двоичный формат, но также как и обычные файлы журналов подвергаются ротации.
Загрузка компьютера проходит в несколько этапов, часть из которых не зависит от установленной на машине операционной системы. Основным отличием операционная системы UNIX является запуск процесса init для инициализации системы.
Конкретика работы процесса init зависит от версии UNIX. Среди разновидностей init UNIX-систем выделяют два крупных класса, производных соответственно от AT&T System V и BSD UNIX.
Программы, запускаемые при старте системы, удобно представлять в виде системных служб. Службы могут соответствовать демонам, которые стартуют вместе с системой. Выделяют уровни загрузки системы, на каждом из которых существует свой набор запускаемых служб.
Среди основных служб можно выделить: службу планировщика (cron), различные сетевые службы, слуюжу системного журнала.
В UNIX работа с системными журналами стандартизована: заданы типы и уровней ошибок, расположение файлов журналов и т.п.. Большое значение при администрировании имеет ротация системных журналов.
Ключевые термины:досистемный загрузчик, загрузчик первого уровня, загрузчик второго уровня, init, уровень выполнения, однопользовательский режим, системная служба, планировщик заданий, системный журнал, ротация журналов