Глава 3. Базовое администрирование UNIX

Содержание

Управление службами
Загрузка операционной системы
Системные службы
Мониторинг и журналирование
Резюме
Дополнительные материалы
Вопросы
Презентация
Управление программным обеспечением
Что включает в себя управление программным обеспечением
Способы управления программным обеспечением
Управление пакетами
Резюме
Дополнительные материалы
Вопросы
Презентация

Прошлые лекции были посвящены различным особенностям архитектуры UNIX, использованию этой операционной системы в локальной и сетевой работе, некоторым аспектам администрирования системы. В этой части речь пойдет о двух центральных задачах, встающих перед администратором любой UNIX-системы — об управлении службами и управлении программным обеспечением.

Управление службами

В этой лекции освещаются процесс загрузки UNIX-систем и запуск системных служб. Некоторые их них, такие как планировщик заданий или системный журнал, рассмотрены более подробно.

Загрузка операционной системы

Этапы загрузки системы

Презентация 7-01: этапы загрузки системы

Загрузку операционной системы можно разделить на несколько этапов. Начальный этап загрузки не зависит от того, какая операционная система установлена на компьютере, он в первую очередь связан с особенностями архитектуры используемого компьютера. Затем следуют этапы загрузчиков, которые также могут не относиться к определённым операционным системам, после чего инициализируется ядро операционной системы и производятся специфические только для этой ОС операции.

Рассмотрим загрузку операционной системы UNIX как следующую последовательность этапов (Рисунок 3.1, «Этапы загрузки ОС UNIX»):

Рисунок 3.1. Этапы загрузки ОС UNIX

Этапы загрузки ОС UNIX


досистемный загрузчик

Как правило, сразу после включения питания программа ПЗУ BIOS проводит тестирование оборудования, затем запускается досистемный загрузчик.

Задача этого этапа — определить (возможно, с помощью пользователя), с какого устройства будет идти загрузка, загрузить оттуда специальную программу-загрузчик и запустить её. Например, выяснить, что устройство для загрузки — жесткий диск, считать самый первый сектор этого диска и передать управление программе, которая находится в считанной области.

загрузчик первого уровня

Загрузчик первого уровня занимает обычно не более одного сектора в самом начале диска — в его загрузочной записи. Загрузочная запись диска (Master Boot Record) — первый сектор диска, в котором хранится таблица разделов и код системного загрузчика.

Ядро операционной системы имеет довольно сложную структуру — а значит, и непростой способ загрузки; оно может быть довольно большим и может располагаться в произвольной област диска, подчиняясь законам файловой системы (например, состоять из нескольких частей, разбросанных по диску). Учесть все это первичный загрузчик не в состоянии, поэтому его задача — определить, где на диске находится загрузчик второго уровня, загрузить его в память и передать ему управление.

загрузчик второго уровня

Вторичный загрузчик — уже более сложная программа с интерфейсом пользователя, который даёт возможность выбирать операционную систему или параметры загрузки ядра. Чтобы продолжить загрузку, необходимо иметь доступ к образу ядра, поэтому зачастую в код загрузчика включается поддержка файловых систем. Более простые загрузчики в процессе предварительной установки сохраняют адреса всех блоков диска, в которых располагается файл с образом ядра.

В любом случае вторичный загрузчик читает образ ядра в определённый адрес памяти и передаёт туда управление.

Большинство операционных систем имеют собственные загрузчики первого и второго уровней. Однако существуют и универсальные загрузчики, не привязанные к конкретной операционной системе, например GRUB.

инициализация ядра операционной системы

Как мы уже выяснили ранее, ядро — очень сложная программа, взаимодействующая с различным оборудованием, поэтому прежде чем начать работу с системой, ядро необходимо проинициализировать.

Этот этап специфичен для различных операционных систем. В UNIX-подобных системах при этом обычно выводится информация отладочного характера о ходе загрузке ядра.

Первым делом ядро занимается определением параметров вычислительной подсистемы компьютера: выясняет тип и быстродействие центрального процессора, объем оперативной памяти, объем и структуру кэш-памяти; делает предположение об архитектуре компьютера в целом и многое другое.

На следующем шаге ядро определяет состав и архитектуру всего аппаратного наполнения компьютера: тип и параметры шин передачи данных и устройств управления ими (контроллеров), список внешних устройств, доступных по шинам, настройки этих устройств — диапазон портов ввода-вывода, адрес ПЗУ, занимаемое аппаратное прерывание, номер канала прямого доступа к памяти и т. п.

Ядро на основании параметра, переданного ему загрузчиком, выбирает корневой раздел — файловую систему, содержащую будущий каталог / и его подкаталоги (для системной начальной загрузки важны каталоги /etc, /bin, и /sbin). Корневой раздел монтируется в качестве /. После этого ядро запускает первый процесс — init (по умолчанию, /sbin/init).

процесс init

С этого момента операционная система обеспечивает полноценную функциональность всем исполняющимся процессам. В UNIX первым запускаемым процессом является init, о котором сказано в следующем разделе.

Процесс init

Презентация 7-02: процесс init

Процесс init является обычным процессом операционной системы, однако он имеет некоторые особенности: его PID всегда равен 1, и процесс этот выполняется всё время, пока работает система.

В UNIX-системах init играет две важные роли:

  • производит инициализацию системы — как правило, для работы запущенного ядра не достаточно, нужно смонтировать все файловые системы, загрузить дополнительные драйверы устройств, запустить демоны и т. п.;

  • является родительским для всех процессов в системе — это является гарантией того, что в UNIX для любого процесса в любой момент времени будет существовать родительский процесс.

    Рисунок 3.2. Пример иерархии процессов в UNIX

    Пример иерархии процессов в UNIX


    Это обеспечивается тем, что в UNIX процессы создаются с помощью последовательного ответвления (системный вызов fork), а изначальной точкой ветвления является init.

Как правило, процесс init запускается из исполняемого файла /sbin/init и работает с некоторыми специфическими особенностями в различных UNIX-системах. Рассмотрим классификацию современных версий UNIX с точки зрения инициализации системы.

Конфигурационный файл init

Конфигурация процесса init описана в файле /etc/inittab. Ниже приведён пример такого файла.

Пример 3.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.

Различия в загрузке UNIX-подобных систем

Исторически различные версии UNIX восходят к двум системам: оригинальной UNIX компании AT&T (вплоть до версии System V) и BSD UNIX, созданной в университете Беркли. В них применялись различные принципы загрузки системы, так что современные версии UNIX по этому критерию можно разделить на:

  • наследники System V — так называемая UNIX System Group (USG-системы): AIX, Solaris, UnixWare, Linux (дистрибутивы RedHat, Mandriva, ALT Linux);
  • наследники BSD: семейство BSD, Linux (Slackware);
  • смешанные схемы: Linux (Debian, Gentoo).

Системы, наследующие System V

Презентация 7-03: уровни выполнения системы

Основным признаком этих систем является использование понятия уровня выполнения (run level) — одного из возможных режимов работы системы. Каждый уровень выполнения обозначается номером (от 0 до 6), часть номеров зарезервирована за стандартными уровнями выполнения. В любой момент времени система может находиться на одном из уровней выполнения — изменение режима работы производится с помощью вызова init с параметром, указывающим номер уровня выполнения, на который следует перейти.

Уровень 0

останов системы (halt) — работа системы должна быть прекращена;

Уровень 1

однопользовательский режим работы — система инициализирует минимум служб и даёт единственному пользователю (как правило, суперпользователю) без проведения аутентификации командную строку. Как правило, этот режим используется для восстановления системы;

Уровень 2

многопользовательский режим — пользователи могут работать на разных терминалах, вход в систему с процессом аутентификации;

Уровень 3

многопользовательский сетевой режим — в многопользовательский режим, в котором осуществляется настройка сети и запускаются различные сетевые службы;

Уровень 4

не имеет стандартного толкования и практически не используется;

Уровень 5

запуск графической подсистемы — в дополнение к уровню 3 производится также старт графической подсистемы X11 (см. Глава 9, Графическая подсистема UNIX), регистрация в системе осуществляется также в графическом режиме;

Уровень 6

перезагрузка системы — при включении этого режима останавливаются все запущенные программы и производится перезагрузка.

Таким образом, каждый переход на каждый уровень выполнения подразумевает выполнение определённого набора процедур инициализации и и определённый набор системных служб, которые должны выполняться на данном уровне. Конкретный список таких процедур и служб может быть задан администратором системы. Стартовые скрипты для каждого из уровней выполнения располагаются в каталоге /etc/rc.d.

На практике, в серверных системах обычно при старте системы используется 3-й уровень выполнения, в домашних — 5-й.

Системы, наследующие BSD

В этих системах традиционно используется линейная схема загрузки. Эта схема устроена намного проще (загрузка таких систем проходит намного быстрее — особенно на медленных машинах), но в силу той же простоты она оказывается сложнее в администрировании.

Инициализация системы осуществляется единым скриптом /etc/rc. В этом скрипте последовательно выполняются процедуры инициализации системы, запуска системных служб и т. п. Следом за ним выполняется скрипт /etc/rc.local, который служит для запуска всех локальных программ и настроек, установленных системым администратором сверх стандартного дистрибутива операционной системы.

При обновлении отдельных программ или изменении их настроек администратору приходится вручную править стартовые скрипты. Эти сложности привели к тому, что в современных BSD-системах внедряются более простые в администрировании схемы загрузки.

Системы со смешанной схемой загрузки

Некоторые современные UNIX-подобные системы (в частности, многие дистрибутивы Linux) предоставляют собственные схемы загрузки системы, сочетающие в себе достоинства обеих обозначенных выше схем.

Для примера можно рассмотреть схему, используемую в дистрибутивах Linux Debian и Gentoo. Вводится понятие программных уровней выполнения (software run levels) — которые могут создаваться и изменяться администратором системы.

Каждому уровню выполнения соответствует набор системных служб, которые будут запущены при переключении системы на этот уровень выполнения. По умолчанию используется один уровень исполнения — default.

Службы связаны между собой посредством зависимостей: к примеру, служба, монтирующая сетевые файловые системы, требует наличия настроенной сети, а значит зависит от службы конфигурации сети. Службы настройки сети, в свою очередь, зависят от службы, загружающей дополнительные модули ядра (например, драйвер сетевой карты). Следовательно, при загрузке системы сначала должна быть запущена служба, загружающая дополнительные модули ядра, затем настраивающая сеть и только затем — монтирующая сетевые файловые системы; при останове системы данные службы должны быть остановлены в обратном порядке.

Таким образом, можно построить дерево зависимостей служб друг от друга. При использовании такого дерева перезапуск системной службы будет приводить к перезапуску всех зависящих от нее служб.

Управление уровнями загрузки — какие программы необходимо запускать на кажом из них — производится аналогично System V-системам.

Системные службы

Презентация 7-04: системные службы

Системные службы (system services) — это программы, предоставляющие некоторую «услугу» (сервис) пользователям системы. Примером может быть служба, динамически создающая необходимые файлы устройств при обращении к ним (udevd) или служба системного журнала, которая рассортировывает по файлам журналов полученные от процессов системы сообщения о происходящих с ними событиях. Как правило, системные службы запускаются при загрузке системы. Каждой системной службе соответствует стартовый скрипт (init script) — специальная программа, осуществляющая запуск и останов демона или программы, которая и обеспечивает функциональность службы.

Запуск и остановка служб

В System V-системах стартовые скрипты находятся в директории /etc/init.d и принимают единственный стадартный параметр — одно из: «start», «stop», «restart». Таким образом, каждая служба может быть остановлена, запущена или перезапущена.

Например, для перезапуска службы системного журнала необходимо выполнить команду /etc/init.d/syslogd restart.

Пример 3.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 — это позволяет сохранять порядок завершения служб всегда строго обратным порядку их запуска.

Для управления списком служб, которые должны запускаться на том или ином уровне выполненения, администратору систем типа System-V доступна специальная утилита chkconfig.

Какие бывают службы

Презентация 7-05: системные службы: примеры

В современных UNIX-системах существует множество служб, выполняющих самые разнообразные функции. Системная служба — достаточно высокоуровневое понятие, которое объединяет по меньшей мере два разных типа. Часть служб предполагает запуск демона, который затем постоянно выполняется вплоть до момента остановки службы. Другая часть служб представляет собой набор процедур (описанных в стартовом скрипте данной службы), которые необходимо выполнить при запуске и/или остановке службы. Службы второго типа часто служат для настройки каких-то функций самой операционной системы, например, загруки модулей или настройки сети.

Далее мы рассмотрим примеры служб, существующих в том или ином виде практически во всех UNIX-системах:

cron

системный плнировщик заданий — демон, запускающий определённые программы с заданными интервалами времени (подробнее см. «Служба планирования заданий»);

syslog

служба системного журнала — демон, организующий единый интерфейс для журналирования событий в системе (подробнее см. «Мониторинг и журналирование»);

network

служба инициализации сети — производит автоматическую настройку сетевых интерфейсов, таблицы маршрутизации и т. п. (см. «Настройка сети при загрузке системы»);

iptables

служба инициализации межсетевого экрана в Linux;

sshd, xinetd, ftpd

набор сетевых служб, запускающих разичные сетевые серверы (подборнее см. «Сетевые службы»);

sendmail

почтовый сервер — демон, обеспечивающий отправление и доставку почты по протоколу SMTP;

modules

служба, загружающая и инициализирующая дополнительные модули ядра;

local

служба, которая обычно запускается в последнюю очередь и позволяет администратору выполнять дополнительные процедуры при загрузке системы;

checkroot

служба, инициирующая проверку корневой файловой системы (с использованием утилиты, специализированной для типа файловой системы).

Рассмотрим более подробно некоторые из этих служб.

Служба планирования заданий

Презентация 7-06: служба планирования заданий

Одной из распространённых задач администрирования является запуск каких-то задач в определённое время с заданной периодичностью. В UNIX этой цели служит планировщик заданий cron.

За выполнением задач по расписанию следит демон, который обычно называется crond. Само расписание описывается в специальных конфигурационных файлах — есть расписание общесистемных задач (/etc/crontab), а также персональное расписание задач (файл crontab) для каждого пользователя. Всем ли пользователям дозволяется пользоваться выполнением задач по расписанию — определяет администратор системы; зачастую для этого пользователей включают в спецаильную группу (например, cron).

Конфигурация планировщика заданий

Каждое задание характеризуется следующими параметрами:

  • минуты, часы, дни, месяцы и дни недели, в которые производится запуск;
  • собственно задача — команда для исполнения.

В файле /etc/crontab эти параметры записываются следующим образом:

Пример 3.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 — в этом случае при записи файла будет проверена корректность синтаксиса файла crontab.

В приведённом примере файл /etc/crontab отражает механизм, встречающийся в современных UNIX-системах — каталоги /etc/cron.*. В каждом из них размещаются скрипты для каждой задачи, которые должны выполняться раз в день, раз в неделю, раз в месяц и т.д. соответственно. Такая схема облегчает администратору управление периодическими задачами: не нужно для каждой задачи вписывать отдельную строку и указывать особое время выполнения в файле crontab, достаточно определить периодичность выполнения задачи и добавить скрипт в соответствующий каталог. Редактировать crontab в такой ситуации нужно только если требуется изменить время выполнения периодической задачи.

Запуск программ

Демон crond в заданное время производит выполнение команд. Задачи из /etc/crontab запускаются от имени суперпользователя, задачи, определённые пользователем в своём конфигурационном файлe crontab, выполняются от имени соответствующего пользователя.

Демон планировщика контролирует результат выполнения запущенной программы и в случае ошибки может отправлять письмо пользователю или администратору системы.

В разных UNIX-системах существует несколько реализаций службы планирования заданий (например, dcron, fcron, anacron и т.п.), но все они реализуют описанную выше базовую функциональность.

Сетевые службы

Презентация 7-07: сетевые службы

В современных UNIX-системах существует множество сетевых служб, решающих самые разные задачи. Можно выделить несколько служб, которые чаще всего используются администраторами.

Служба sshd

Эта служба отвечает за запуск и останов демона sshd, который обеспечивает доступ к системе посредством защищённого удалённого терминала. Такой сервер обычно запускается на всех узлах, для которых предполагается удалённый вход пользователей или администрирование.

Служба sendmail

sendmail — один из самых распространённых почтовых серверов. Он реализует Internet-протоколы, связанные с отправлением почты (в первую очередь SMTP) как в рамках локальной машины, так и через Internet. Даже если узел не является почтовым сервером, служба sendmail служит для передачи писем между пользователями системы.

Служба inetd

inetd (и его более развитая версия xinetd) — это супер-сервер, объединяющий множество сетевых служб. По сути этот сервер выполняет роль транспорта для сетевых служб: слушает на заданом порту, при входящем соединении запускает указанный для этого порта процесс и перенаправляет стандартный ввод и вывод программы в tcp-соединение. При этом правила доступа, ограничение по числу параллельных соединений, журналирование и т.п. организуются демоном inetd и настраиваются в его конфигурационных файлах.

Служба nfs

Демон сетевой файловой системы NFS (Network File System), которая поддерживается в большинстве UNIX-систем.

Служба samba

samba — это набор служб по организации сетевого файлового хранилища на основе протокола CIFS, используемого в сетевых файловых системах MS Windows. Широко применяется при взаимодействии UNIX-серверов и клиентских машин под Windows.

Служба bind

bind (или named) — самый распространённый сервер доменных имён для UNIX.

Мониторинг и журналирование

Журналирование системных событий и их мониторинг — важнейшая задача администратора — не только в связи с поддержанием уровня безопасности сиситемы, но и для анализа неисправностей. Журналирование является нормой для всех служб в системе и присутствует во всех версиях UNIX. Мониторинг пользователей — отдельная задача администрирования, реализованная в UNIX также на схожих с журналированием механизмах.

Служба системного журнала

Презентация 7-08: служба системного журнала

Служба системного журнала состоит из следующих компонентов:

Системная функция syslog

Главной чертой журналирования в UNIX является то, что в стандартном случае приложение не делает запись в файл журнала напрямую, а вызывает специальную системную функцию (syslog()), в качестве параметров которой передаёт как само сообщение для записи в журнал, так и сопровождающие сведения: программа-источник сообщения, время события, приоритет и характер сообщения. Список необходимых параметров функции syslog() и допустимых значений для них составляет API системных журналов, которое является частью стандартов POSIX. Использование этого API программой делает ее независимой от конкретной реализации демона ведения журнала в системе, что повышает уровень переносимости программы между разными UNIX-системами.

Демон syslogd

Со стороны операционной системы основным компонентом, реализующим функциональность журналирования, является демон (syslogd), который осуществляет получение сообщений от приложений, фильтрацию их и запись в файлы журналов. Правила фильтрации и адреса доставки сообщений (имена файлов журналов) описываются в конфигурационном файле syslogd, /etc/syslog.conf.

То, что все сообщения проходят централизованную обработку, позволяет администратору системы гибко управлять отбором и группировкой сообщений в конкретные файлы журналов. Например, для всех сообщений, связанных с электронной почтой (вне зависимости от сообщившей программы), может использоваться единый файл maillog. Другим интересным решением является сохранение сообщений на другом узле в сети или даже автоматический вывод их на принтер.

Конфигурационный файл /etc/syslog.conf

Синтаксис конфигурационного файла может несколько изменяться в зависимости от конкретной реализации демона журналирования, присутствующего в UNIX-системе. Однако во всех реализациях конфигурационный файл представляет собой список правил вида «условие–имя файла», где условие — это параметры сообщения (приоритет, тип, и т.п.). В случае соответствия сообщения правилу, оно будет записано в файл, указанный в этом правиле.

Каждая запись в системном журанале содержит следующие стандартные параметры:

  • время события;
  • имя программы, идентификатор процесса;
  • тип программы или сообщения (например: AUTH, DAEMON, FTP и т.п.);
  • приоритет сообщения (ALERT, ERR, WARNING, INFO и т.п.);
  • текст сообщения.

Рассмотрим пример простого файла конфигурации системного журнала:

Пример 3.4. Пример файла /etc/syslog.conf

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
kern.*                                                  /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;		                /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  /var/log/maillog


# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 *


Данная конфгурация подразумевает вывод всех сообщений ядра в терминал пользователей, сообщения, связанные с почтой, сохранять в файле /var/log/maillog, связанные с аутентификацией, — в файле /var/log/secure, сообщения планировщика заданий — в файле /var/log/cron, тогда как все остальные сообщения отравлять в файл /var/log/messages.

В файлах журналов собощение записывается вместе со всеми параметрами в простом текстовом виде, что позволяет применять стандартные для UNIX механизмы поиска по текстовым файлам (например, grep) и упрощает процесс анализа событий.

Основные системные журналы

Презентация 7-09: основные системные службы

В UNIX-системах принято располагать все файлы журналов в каталоге /var/log и его подкаталогах. Во многих UNIX-системах можно обнаружить системные журналы со следующими названиями:

authlog / security
этот файл хранит сообщения, связанные с аутентификацией пользователей, ошибками входа в систему, изменением уровня доступа и т.д. (хранит в том числе сообщения с типом AUTH);
daemon
файл с сообщениями от системных служб (хранит сообщения с типом DAEMON);
dmesg
в Linux-системах в файле с таким именем обычно хранятся сообщения от ядра.
maillog / mail
сообщения о получении и доставке писем, этот журнал обычно ведётся почтовым сервером (хранит в том числе сообщения с типом MAIL);
messages
в этом файле обычно хранятся все сообщения, не попавшие в другие файлы журналов;
xferlog
здесь содержатся записи обо всех файлах, загруженных с данной машины (обычно актуально для FTP-серверов).

Некоторые системные службы (такие как веб-сервер Apache) имеют свои собственные файлы журналов. Располагаются они обычно в подкаталогах /var/log, например /var/log/apache/.

Ротация системных журналов

Презентация 7-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-системах используются аналогичные, часто встроенные средства.

Мониторинг пользователей

Презентация 7-11: мониторинг пользователей

Учет сеансов работы пользователей в системе ведётся вне службы системного журнала, однако по аналогии с общими системными журналами информация о сеансах работы пользователей записывается в несколько файлов в каталоге /var/log. В отличие от стандартных системных журналов, в этих файлах информация хранится в двоичном, а не в текстовом виде.

wtmp
Хранит информацию обо всех сеансах работы пользователя. Для просмотра информации из этого файла можно воспользоваться утилитой last.
lastlog
Для каждого из пользователей хранится время последнего входа в систему вместе с именем соответствующего терминала (и IP-адреса в случае сетевого входа в систему). Содержимое этого файла можно посмотреть с помощью утилиты lastlog. Обычно после входа пользователя в систему на его терминал выводится информация о предыдущем входе в систему, сохранённая в этом файле.
faillog
Для каждого пользователя хранит информацию о последней неудачной попытке входа в систему. Содержимое этого файла можно посмотреть с помощью утилиты faillog.

Все эти файлы подвергаются ротации по той же схеме, что и обычные файлы журналов.

Резюме

Презентация 7-12: резюме

Загрузка компьютера проходит в несколько этапов, часть из которых не зависит от установленной на машине операционной системы. Основным отличием операционной системы UNIX является запуск особого процесса (init), который управляет режимом работы системы (инициализация, останов и т.д.).

Конкретика работы процесса init зависит от версии UNIX. Среди разновидностей init UNIX-систем выделяют два крупных класса, производных соответственно от AT&T System V и BSD UNIX. Основное различие — понятие уровня выполнения, которое присутствует только в классе System V.

Процедуры, постоянно выполняемые в том или ином режиме работы системы или однократно выполняемые при смене режима удобно представлять как системные службы. Это понятие используется в System V системах, где для каждого уровня выполнения определяется список служб, которые должны выполняться на этом уровне.

Среди основных служб можно выделить: планировщик заданий (cron), различные сетевые службы, службу системного журнала.

В UNIX работа с системными журналами стандартизована: заданы типы и уровней ошибок, расположение файлов журналов и т.п. Большое значение при администрировании имеет ротация системных журналов.

Ключевые термины: досистемный загрузчик, загрузчик первого уровня, загрузочная запись диска, загрузчик второго уровня, init, уровень выполнения, однопользовательский режим, системная служба, планировщик заданий, системный журнал, ротация журналов

Дополнительные материалы

  1. Курячий Г.В. Операционная система UNIX. — М.: Интуит.Ру, 2004. — 292 с.: ил.

Вопросы

  1. Из каких этапов состоит загрузка операционной системы UNIX?
  2. Какую роль выполняет процесс init в UNIX?
  3. Для чего служит файл /etc/inittab?
  4. Что такое уровень выполнения системы? Какие уровни выполнения выделяют в UNIX-системах, наследующих System V?
  5. Что такое системные службы? Как организованы системые службы в UNIX-системах, наследующих схему загрузки UNIX System V?
  6. Каким образом производится автоматический старт служб в UNIX-системах, наследующих UNIX System V?
  7. Приведите примеры служб? Какие функции выполняет каждая из них?
  8. Какой самый маленький и самый большой период запуска задачи с помощью стандартной службы планировщика cron?
  9. Приведите примеры сетевых служб в UNIX.
  10. Из каких компонентов состоит системный журнал в UNIX? Чем обусловлено такое разделение?
  11. Что такое ротация системных журналов и почему она необходима?
  12. Какие средства мониторинга действий пользователей есть в UNIX? Приведите примеры утилит и связанных с ними системных журналов.

Презентация

Рисунок 3.3. Презентация 7-01: этапы загрузки системы

Презентация 7-01: этапы загрузки системы


Рисунок 3.4. Презентация 7-02: процесс init

Презентация 7-02: процесс init


Рисунок 3.5. Презентация 7-03: уровни выполнения системы

Презентация 7-03: уровни выполнения системы


Рисунок 3.6. Презентация 7-04: системные службы

Презентация 7-04: системные службы


Рисунок 3.7. Презентация 7-05: системные службы: примеры

Презентация 7-05: системные службы: примеры


Рисунок 3.8. Презентация 7-06: служба планирования заданий

Презентация 7-06: служба планирования заданий


Рисунок 3.9. Презентация 7-07: сетевые службы

Презентация 7-07: сетевые службы


Рисунок 3.10. Презентация 7-08: служба системного журнала

Презентация 7-08: служба системного журнала


Рисунок 3.11. Презентация 7-09: основные системные службы

Презентация 7-09: основные системные службы


Рисунок 3.12. Презентация 7-10: ротация системных журналов

Презентация 7-10: ротация системных журналов


Рисунок 3.13. Презентация 7-11: мониторинг пользователей

Презентация 7-11: мониторинг пользователей


Рисунок 3.14. Презентация 7-12: резюме

Презентация 7-12: резюме








На главную









Радио для всех
©
Научно-популярный образовательный ресурс


Создать сайт бесплатно