Анализ информации, собранной в логах, также позволяет установить причины ошибок в работе сервера. Из них можно узнать, какие файлы были получены от сервера, какие из них не были найдены, какие скрипты не выполнились правильно и т.д. Ручной анализ записей в этих дневниках имеет смысл в принципе только в случае поиска причины ошибок сервера. Статистический анализ, состоящий в наблюдении за распределением нагрузки сервера в определенные промежутки времени, и генерирование рапортов использования сервера и его ресурсов производятся автоматически аналитическими программами домена.

Имеющиеся по умолчанию установки дневников сервера HTTP и FTP (Xitami пригоден и для выполнения функций сервера FTP) можно изменить, выбирая на административной панели команду Logging. Администратор сервера может изменить как локализацию (расположение), так и тип генерируемого файла дневника, а также так называемую цикличность, то есть время, по истечении которого лог закрывается, и дальнейшая запись продолжает вестись в новом дневнике.

• pure-ftpd – Pure-FTPd FTP server
• openssl – Secure Socket Layer (SSL) binary and related cryptographic tools
• libssl-dev – SSL development libraries, header files and documentation

Установка

Для начала мы все это установим. Так как имеющиеся сборка pure-ftpd в репозитариях Debian нам не подходит (нет поддержки openssl), будем устанавливать его из исходников.

# sudo aptitude source pure-ftpd

Исходные коды получены, но перед тем как перейти в каталог, поставим дополнительные пакеты, такие как OpenSSL и библиотеки к нему.

# sudo aptitude install openssl
# sudo aptitude install libssl-dev

Cоздадим самоподписывающиеся цифровой сертификат по алгоритну RSA c 1024-битным ключем:

sudo openssl req -x509 -nodes -newkey rsa:1024 -keyout
/etc/ssl/private/pure-ftpd.pem -out /etc/ssl/private/pure-ftpd.pem

Теперь перейдем в каталог с исходными кодами Pure-FTPd и запустим конфигуратор с нужными для нас ключами:

./configure –with-rfc2640 –with-puredb –with-tls
–with-certfile=/etc/ssl/private/pure-ftpd.pem –with-ftpwho –with-altlog

Теперь расмотрим каждый параметр. Кто за что отвечает:

• –with-rfc2640 – использовать спецификацию rfc2640 для работы "кодировки на лету"
• –with-puredb – для аутентификации и авторизации использовать свою БД (puredb)
• –with-tls – включаем поддерку SSL/TLS
• –with-certfile – использовать сертификат с указанного места
• –with-ftpwho – опция необходимая для утилиты мониторинга ftpwho
• –with-altlog – используем журналирование

И откомпилируем пакеты командами:

# make && make install

Настройка Pure-ftpd

Итак начнем настройку. Цифровые сертефикаты мы уже сделали, теперь займемся puredb, создадим ее и наполним пользовательскими учетными записями.

Для начала нам нужна отдельная группа

# groupadd ftpgroup

Создадим реального системного пользователя, под правами которого будут работать наши виртуальные пользователи ftp.

# useradd -m -g ftpgroup -d /dev/null -s /etc ftpuser

• -m – автоматически создавать папку пользователя;
• -g – использовать gid (group indentificator). У нас ftpgroup;
• -d – указывает домашнюю папку пользователя. В нашемслучаии в некуда (/dev/null);
• -s – указывает на используемую оболочку (shell);

И последнее, конечно же, указываем имя пользователя ftpuser

Проверим, создан ли пользователь

# getent passwd ftpuser
ftpuser:x:1003:1005::/dev/null:/etc

Создадим виртуального пользователя

# sudo pure-pw useradd valek -u ftpuser -d /home/ftpusers/valek

• useradd – имя пользователя, например valek;
• -u – uid реального системного пользователя ftpuser
• -d – домашний каталог

Проверим это дело

# sudo cat /etc/pureftpd.passwd
valek:$1$v5nQVd80$11quL9FgRbL37knEcxIK80:1003:1005::/home/ftpusers/valek/./::::::::::::

# sudo pure-pw show valek

Login : valek
Password : $1$v5nQVd80$11quL9FgRbL37knEcxIK80
UID : 1003 (ftpuser)
GID : 1005 (ftpgroup)
Directory : /home/ftpusers/valek/./
Full name :
Download bandwidth : 0 Kb (unlimited)
Upload bandwidth : 0 Kb (unlimited)
Max files : 0 (unlimited)
Max size : 0 Mb (unlimited)
Ratio : 0:0 (unlimited:unlimited)
Allowed local IPs :
Denied local IPs :
Allowed client IPs :
Denied client IPs :
Time restrictions : 0000-0000 (unlimited)
Max sim sessions : 0 (unlimited)

И создаем базу данных

# sudo pure-pw mkdb

На этом мы закончили. Осталось только запустить pure-ftpd в режиме демона.

sudo ./pure-ftpd -4 -A -B -j -U 022:022 -l puredb:/etc/pureftpd.pdb

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

Например, сетевая плата.
Встроенный код Basic Input/Output System знает обо всех устройствах, которые располагаются на материнке. Например, о жестких дисках, контроллере IDE, контроллере клавиатуры, портах (параллельных и последовательных), плате сетевого адаптера. SCSI-адаптеры, в свою очередь, знают лишь о тех устройствах, которые подключены напрямую к ним. Справедливости ради стоит отметить, что за последние годы необходимость вмешательства оператора сошла до минимума, поскольку сложные взаимодействия, лежащие между устройствами при их совместной работе, были упорядочены и стандартизированы.
Если сравнивать разные поколения ПК, то можно заметить, что код BIOS становится все более интеллектуальным. Ведь современные машины позволяют входить в режим конфигурирования уже на старте загрузки. Для этого достаточно нажать на пару клавиш. Их названия чаще всего видны на экране. Делается это для избавления от копания в документации.
Режим конфигурирования позволяет выбирать устройство, с которого произойдет загрузка. Несмотря на то, что выбор этот нельзя назвать большим. Как правило, последовательность загрузки такова – дисковод для гибких дисков – для CD-ROM дисков – для жесткого диска. Но в некоторых BIOS загрузку нельзя начать с первого жесткого диска IDE или дисковода для CD-ROM. SCSI-адаптеры также могут быть распознанными.

После того как персональный компьютер определился с выбором устройства для загрузки, происходит считывание первых пятисот двенадцати байтов с диска. Данная часть диска имеет название ГЗЗ, или главной загрузочной записи. Она содержит ту программу, которая оповещает ПК о местонахождении программы вторичной загрузки на том или ином разделе диска.
Находящаяся в главной загрузочной записи стандартная программа дает машине указание – вычленить загрузчик операционной системы из первого дискового раздела.

В свою очередь, в ОС Линукс поддерживаются программы более высокого уровня сложности. Они совместимы со многими ядрами и системами.

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

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

Но мы отвлеклись. Команды sulogin требует ввода пароля суперпользователя. В случае успешной идентификации система запускает командную оболочку, определенную в переменной PATH для root (в большинстве дистрибутивов это оболочка Борна — bash (Borne Again Shell) или sh). Если вы не хотите производить авторизацию суперадминистратором, нажмите сочетание клавиш Ctrl+D, и система продолжит процесс загрузки в многопользовательском режиме.

В режиме single user система отвечает на команды практически таким же образом, что и в обычном, многопользовательском, режиме. Но есть и отличия. В частности, в дистрибутивах, основанных на Debian, в Mandriva и в SuSE в однопользовательском режиме по умолчанию монтируется только корневой раздел, а остальные пользователю предлагается подключить самостоятельно.
Однопользовательский режим очень удобен для восстановления работоспособности упавшей системы, но в то же время это и огромная уязвимость любой ОС Linux, поскольку до сих пор в большинстве дистрибутивов для входа в систему в режиме single user по умолчанию не требуется ввода пароля. Соответственно, злоумышленник, получивший доступ к локальной машине, может легко загрузиться в режиме наивысших привилегий и сделать с системой все, что захочет. Поэтому следует сразу же после установки системы запрещать любой вход в нее без ввода пароля. Справедливости ради стоит заметить, что если злоумышленник получает доступ в помещение с машиной, то от ОС уже мало что зависит. Снять жесткий диск и загрузиться с Live-CD/LiveUSB на другом компьютере, ему уже ничто не помешает. Но облегчать ему работу не стоит.

Ряд дистрибутивов в режиме одного пользователя монтирует системный каталог только в режиме чтения. В этом есть определенное неудобство: часть программ, записывающих свои временные данные в каталог /tmp, не сможет полноценно функционировать. Поэтому для запуска, к примеру, текстового редактора vim, необходимо в ручном режиме размонтировать и снова смонтировать в режиме чтения и записи системный каталог. Для этого нужно в однопользовательском режиме набрать команду mount -о rw, remount /.
В дистрибутивах семейства Red Hat (RHEL, Fedora, CentOS и других) при загрузке в single user режиме перед приглашением к авторизации процесс init попытается примонтировать все файловые системы в компьютере. Данное решение, с одной стороны, является достаточно привлекательным, однако с другой, при каких-либо ошибках в архитектуре файловой системы может стать источником проблем.

В ходе автоматической загрузки ОС запускает команду fsck, которая служит для проверки корректности состояния файловой системы и, при необходимости, автоматического восстановления ее до непротиворечивого состояния. В single-режиме данная команда автоматически не запускается, поэтому для коррекции файловых систем команду придется вводить самостоятельно.
После завершения работы командой оболочки однопользовательского режима ОС продолжает загрузку, меняя режим на многопользовательский.
Следующий шаг загрузки — выполнение rc-сценариев запуска. На этом этапе систему уже можно считать загруженной. Сценарии — это обыкновенные скрипты, которые запускаются демоном init в зависимости от настроек системы.
После того, как init запустит все сценарии, и они отработают, выполнив все записанные в них команды, загрузку системы можно считать законченной. Однако войти в систему все еще невозможно. Для того чтобы операционка предложила пользователю авторизоваться в системе, необходим запуск процесса getty, который будет следить за командами в терминале.
При запуске системы в графическом режиме кроме getty процесс init запускает процессы регистрации пользователей: xdm, gdm или kdm.

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

Особенности начальной загрузки системы

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

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

После включения питания выполняется специальный загрузочный код, хранящийся в постоянном запоминающем устройстве. Этот код запускает ядро системы. Ядро проверяет состояние аппаратных компонентов, после чего запускает демон с идентификатором № 1, носящий название init.

Между запуском init и появлением приглашения к авторизации в системе проходит период, во время которого происходит проверка и монтирование существующих файловых систем и запуск демонов системы. Данные задачи выполняются посредством сценариев интерпретатора команд. Эти сценарии по порядку обрабатываются демоном init. Часто в литературе можно встретить именование сценариев rc-файлами – по имени их префикса. История префикса, являющегося аббревиатурой словосочетания «run command» уходит в далекие шестидесятые годы XX века, к операционной системе CTSS. В настоящее время это название является пережитком и оставлено только по традиции. Содержание и структура сценариев интерактивной загрузки зависит от конкретной системы. В дальнейших статьях мы планируем рассмотреть сценарии загрузки подробнее.
Операционные системы семейства Линукс обладают одним важным свойством, касающимся загрузки — она может выполняться как в автоматическом режиме, так и вручную (пользователем машины).

В автоматическом режиме участия человека не требуется: ядро проводит все процессы загрузки самостоятельно. В ручном режиме инициализация проходит автоматически до определенного этапа, после чего управление передается пользователю. Данный этап носит название «однопользовательского режима» (single user). В данном режиме большая часть демонов (системных процессов) еще не начали работу, и авторизоваться другим пользователям системы нельзя.
В обычном режиме система загружается в полностью автоматическом режиме. Пользователю системы необходимо просто нажать на кнопку питания и ждать, когда Linux пригласит его ввести имя и пароль. Тем не менее, если вы хотите разбираться в системе, вам нужно не только знать, что происходит во время обычной загрузки, но и при необходимости загрузить Linux вручную. Ручная загрузка требуется в том случае, если в системе возникают неполадки, мешающие автоматической инициализации. В таком случае, система передает управление оператору (человеку сидящему за терминалом). Подобное может произойти, например, при нарушении целостности файловой системы или при ошибках в конфигурации сетевого адаптера.

Шаги загрузки

Как правило, процесс загрузки систем на основе Linux состоит из шести основных шагов, среди которых:

• загрузка ядра;
• поиск и настройка устройств компьютера;
• создание ядерных процессов;
• (опционально, при загрузке вручную) действия оператора системы;
• выполнение rc-команд;
• переход в многопользовательский режим.

Процессом загрузки системы можно управлять посредством редактирования сценариев запуска (rc-команд).
Рассмотрим каждый шаг загрузки. Первый из них — загрузка и инициализация ядра.
Ядро ОС Линукс – это программа, и первый шаг загрузки заключается в записи этой программы в оперативную память компьютера для последующего выполнения. Файл ядра (kernel) обычно имеет название /boot/vmlinuz или /vmlinuz.
Следует заметить, что процесс загрузки ядра происходит в два этапа. Первый — в оперативную память с помощью BIOS записывается небольшая программка-загрузчик, которой передаются права. Именно она на втором этапе загружает собственно ядро и передает ему управление.

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

Следующий шаг — настройка аппаратных средств компьютера. Если вы приняли решение скомпилировать ядро для конкретного компьютера, вы можете собрать указать ему те устройства, наличие которых требуется проверять. В процессе инициализации ядро находит и проверяет все устройства, о которых оно было проинформировано. Главная информация о каждом найденном устройстве выводится на терминал пользователя. Большинство современных дистрибутивов Linux имеют в своем составе ядро, способное без дополнительной перекомпиляции работать на подавляющем большинстве конфигураций ПК.
Тем не менее, информация, которую производитель дистрибутива заложил в ядро, может оказаться неполной. В таком случае, kernel (ядро) подключается к системной шине и собирает необходимую информацию у драйверов устройств, подключенных к ней. Драйвера устройств, которые не отвечают на сигнал ядра или вообще отсутствуют, выключаются. Если устройство добавляется в аппаратную конфигурацию в ходе работы, администратор системы обладает инструментами для включения драйвера ядра.

Третий шаг загрузки — создание процессов ядра. После того, как ядро опросит все аппаратные составляющие, приходит черед создания процессов. Создание данных процессов происходит независимо от fork (стандартного вызова системы). Подробнее о fork будет рассказано в следующих статьях.
Создание таких процессов, являющихся «самовыполняемыми», характерно для всех систем семейства UNIX, но их количество и функции отличаются. Например, в Linux к таким процессам относится демон init, а также обработчики сигналов kernel. Для того чтобы выяснить, какие процессы относятся к «самовыполняемым», можно в консоли набрать команду ps. Идентификаторы этих процессов будут стоять в самом начале, а их названия должны быть в квадратных скобках. В ряде дистрибутивов квадратные скобки убраны.

Пример.

[ilya@localhost ~]$ ps -e
PID TTY TIME CMD
1 ? 00:00:00 init
2 ? 00:00:00 kthreadd
3 ? 00:00:00 migration/0
4 ? 00:00:16 ksoftirqd/0
5 ? 00:00:01 events/0
6 ? 00:00:00 khelper
47 ? 00:00:00 kintegrityd/0
48 ? 00:00:00 kblockd/0
50 ? 00:00:00 kacpid
51 ? 00:00:00 kacpi_notify
132 ? 00:00:00 kseriod
172 ? 00:00:01 pdflush
174 ? 00:00:05 kswapd0
217 ? 00:00:00 aio/0
371 ? 00:00:00 kpsmoused
384 ? 00:00:00 ksuspend_usbd
385 ? 00:00:00 khubd

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

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

Сделаем небольшой обзор документации, расположенной в сети Интернет.

Документы HOW-TO — небольшие статьи по какому-то конкретному вопросу настройки – готовятся в рамках проекта Linux Documentation Project (LDP). Их можно найти на странице tldp.org, которая выполняет функцию хранилища разнородных данных о Linux, а также документацию на большом количестве языков. Такие руководства, как, например, Linux System Administration Made Easy или Advanced Bash-Scripting Guide будут полезны для системных администраторов. Большая часть документов Linux Documentation Project не обновляется, то есть устаревает достаточно быстро. Поэтому на дату появления этого документа на сайте нужно обращать внимание. Только она может рассказать о степени актуальности данных, содержащихся в документе.
Самые главные компоненты ОС Linux находят поддержку у таких организаций, как ASF, объединяющей разработчиков ПО для веб-сервера Apache, или ISC – консорциума разработчиков ПО для Сети. Они также предоставляют к пакетам документацию. В отличие от ряда поставщиков, не прилагающих ее к дистрибутиву.
Документы серии Request for comments (сокращенно – RFC) – тоже кладезь информации о пакетах Linux. В них содержатся описания протоколов и ПО интернет.

Такие документы должны быть в свободном доступе на FTP-серверах, содержащих архивы данной ОС. Если выхода по FTP нет, данные можно поискать на серверах CompuServe или BBS. При наличии доступа к электронной почте возможно использование сервиса ftpmail. Он также позволяет получать такие документы.
Ресурсы, освещающие UNIX, тоже интересны. Ведь доля информации об этой системе применима к Линукс. В частности, сведения по системному администрированию. Их можно найти в разных видах в поисковиках Yahoo!, Yandex, Google.

Список русскоязычных сайтов и форумов с документацией по Linux:

• http://www.linux.org.ru — ресурс с довольно агрессивным, но грамотным сообществом. На сайте есть разделы с документацией и wiki.
• http://www.opennet.ru/ – большой и активный ресурс, посвященный свободному программному обеспечению.
• http://linuxforum.ru/- самый активный *nix-форум.
• http://posix.ru/sitemap.shtml — сайт с достаточно устаревшей документацией.
• http://rus-linux.net/ – виртуальная энциклопедия «Linux по-русски».

Однако Линукс не является единственной ОС, которая доступна и генетически связана с UNIX. Операционные системы NetBSD, OpenBSD и FreeBSD являются прямыми потомками версии UNIX, разрабатываемой в университете Беркли. Эти системы сравнимы с Линукс по функционалу, но менее популярны. Их меньшая популярность во многом обусловлена историческими причинами. В начале разработки этих систем они находились под угрозой патентного преследования со стороны производителей коммерческий версий UNIX. Для того чтобы избежать проблемы, разработчики *BSD-системы были вынуждены тратить силы на переписывание заимствованного кода. А в это время Linux развивался и набирал все большую популярность.

Программное обеспечение, разрабатываемое под ОС Linux, являются POSIX-программами. Это означает, что любые программы, написанные по этому стандарту, могут быть запущены на любой POSIX-совместимой системе путем перекомпиляции исходного кода.
Еще одним фактором популярности Linux является то, что проект GNU выбрал данную ОС для своих программных компонентов. Глава Free Software Fondation, Ричард Столлманн, автор проекта GNU, считает, что правильнее называть ОС GNU/Linux, поскольку все основные утилиты написаны именно в рамках его проекта.
Благодаря стандарту POSIX, Linux, *BSD и различные коммерческие инкарнации UNIX имеют большое количество приложений, способных работать в любой их этих систем.

Можно выделить несколько основных типов документации:

• man-страницы. Это информация по конкретным командам, которую можно получить с помощью команды: man имя_команды.
• страницы Texinfo, гипертекстовая система справочной документации. Вызывается одноименной командой.
• статьи в сети Интернет посвященные той или иной проблеме и путям ее решения (HOW-TO).
• серии статей, посвященных тому или иному разделу;
• руководства дистрибутивов.

Поговорим теперь о каждом из типов подробнее.

Первый и главный тип документации — man-страницы. Они есть в любой системе Linux, так что, даже если у вас нет Интернета, вы не останетесь без справки. Man-страница — это первое место, куда нужно обращаться за помощью.

В ОС Linux страницы интерактивного справочного руководства man делятся на 9 основных разделов:

1. Справка по командам уровня пользователя и приложений;
2. Расшифровка кодов ядерных ошибок и системные вызовы;
3. Функции библиотек.
4. Справка по сетевым протоколам и драйверам устройств;
5. Стандартные для любой системы форматы файлов;
6. Справка по игровым программам и демо-версиям;
7. Другие файлы и документы.
8. Справка по командам администрирования системы.
9. Информация ядру и внутренним модулям.

Разделы могут быть разделены на подразделы. Подразделы обозначаются цифрой главного раздела и буквой латинского алфавита, связанного с тематикой раздела (раздел 3M, таким образом, содержит информацию о математических функциях одной из библиотек системы). Шестой и девятый разделы, как правило, пусты и являются резервными. Некоторые дистрибутивы Linux включают в себя еще два раздела:

l — для дистроспецифичных man-страниц;
n — для описания команд отдельных программных оболочек (например, bash, sh и zsh).

Информация, отображаемая командой man, как правило, хранится в папке /usr/share/man/manN, где N — номер или буква раздела. Информация хранится в архивах, которые созданы с помощью сжимающей утилиты gzip. Перед выводом информации команда man запускает утилиту разархивирования, результат которой в форматированном виде поступает на вывод.
Команда man кэширует наиболее часто вызываемые страницы. Для этого ей необходим доступ на запись в каталог /var/cache/man/catN (N, здесь также соответствует букве или номеру раздела). man производит форматирование во время отображения на экране.
Утилита man происходит поиск страниц в нескольких каталогах, которые можно узнать с помощью команды manpath. Вывод команды manpath в дистрибутиве Mandriva Linux выглядит так:

[ilya@localhost ~]$ manpath
/usr/share/man/ru:/usr/share/man:/usr/local/share/man

Настройка того, в каких каталогах искать страницы справки, содержится в переменной MANPATH. Если нужно, содержимое переменной можно изменить.
Команда man производит форматирование страницы справочного руководства и выводит ее в консоль пользователя с помощью команды less или другой утилиты, предназначенной для разбивки на страницы и заданной в переменной PAGER.
Аргументом команды man является название утилиты, имя команды, файл или устройство, по которому требуется справка. Команда производится поиск по разделам интерактивного справочного руководства по возрастанию номеров. Правда, разделы, в которых описываются утилиты (1, 6 и просматриваются с самого начала.
Команда man раздел имя_утилиты формирует страницу справки из данного раздела. Например, команда

man tty

выдает на консоль информацию из первого раздела, то есть справку по самой команде tty, а команда

man 4 tty

выведет в терминал страницу интерактивного руководства, посвященную драйверу управляющей консоли.
Команда man -k ключ выдает в консоль наименования страниц, в описаниях к которым имеется данный ключ.

Пример:

[ilya@localhost ~]$ man -k urpmi
proxy.cfg [proxy] (5) – urpmi proxy configuration file format
rurpmi (8) – restricted urpmi
urpm (3pm) – Mandriva perl tools to handle the urpmi database
urpm::cfg (3pm) – routines to handle the urpmi configuration files
urpmi (8) – rpm downloader, installer and dependency solver
urpmi.addmedia [urpmi] (8) – adds a new rpm media to be used by urpmi
urpmi.cfg [urpmi] (5) – urpmi option and media configuration file format
urpmi.files [urpmi] (5) – files used by the urpmi tools
urpmihowto (8) – urpmi Advanced How-To
urpmi.removemedia [urpmi] (8) – remove a rpm media from the known media of urpmi
urpmi.update [urpmi] (8) – Updates package lists for specified media
urpmq (8) – urpmi database query tool
urpm::sys (3pm) – OS-related routines for urpmi
urpm::util (3pm) – Misc. utilities subs for urpmi

В данном примере мы запросили названия всех страниц справки, в описаниях которой употребляется команда управления пакетами urpmi в Mandriva Linux.
Для того чтобы получить справку по самой команде man необходимо в консоли набрать команду:

man man

Следующим типом документации являются страницы руководства Texinfo. Данная справочная система так же, в большинстве случае, устанавливается вместе с дистрибутивом. Новые программы, инсталлируемые в систему, тоже вносят свои страницы справки в интерактивное руководство. Страница руководства Texinfo содержат конкретные сведения об утилитах, командах, форматах файлов, драйверах и библиотеках. Зачастую данная система дублирует информацию, содержащуюся на страницах руководства man.

Система руководства Texinfo была разработана в рамках проекта GNU как замена man, которая появилась в коммерческих UNIX и была несвободная для использования. В частности, для обработки страниц по мере вывода на терминал пользователя man использовала команду nroff, являющуюся собственностью автора UNIX, компании AT&T.
В настоящее время команда nroff заменена командой groff, поэтому данный факт потерял свое значение. Однако до сих пор ряд программ (большинство из них разработано проектом GNU) нуждаются в том, чтобы справочная информация для них распространялась в формате Texinfo.

Фактически, на сегодняшний момент система интерактивного руководства Texinfo совершенно избыточна. Следует заметить, что пользование ей достаточно затруднено самой гипертекстовой природой системы. Если вы все же хотите использовать данную систему документации, мы советуем вам направить вывод команды
info имя_утилиты
с помощью команды less. Это позволит вам использовать поисковые возможности команды less,одновременно заблокировав навигацию справочной системы Texinfo.
При всех отрицательных сторонах данной справочной системы есть один положительный момент: при установке программного обеспечения, как правило, в страницы руководства man инсталлируются страницы-маячки, сообщающие, что справку по данной программе можно найти в info. Следовательно, вы вполне можете продолжать использовать систему man, обращаясь к Texinfo в том случае, если это действительно необходимо.

Ведь история UNIX стартовала в 1969 году на базе исследовательского проекта, проводимого лабораторией Bell Labs, принадлежащей корпорации AT&T. Через семь лет, в 1976 году, данная система начала распространяться среди студентов абсолютно бесплатно. Именно поэтому диссертации, посвященные рассмотрению операционных систем, а также различные образовательные курсы по этой теме стали такими популярными.

В 1977 году увидела свет система Berkeley UNIX. Именно в том году группа исследователей из Калифорнийского университета, расположенного в Беркли, заинтересованная в вычислительных системах, приобрела лицензию у AT&T на код системы. Все версии, авторами которых были участники данной группы, получали название BSD – аббревиатура от Berkeley Software Distribution. Первой такой версией стала 1BSD, подходящая для компьютера PDP-11. В 1993 году появилась версия 4.4BSD, ставшая кульминационной.
Исходный код UNIX становился все дороже по мере того, как система завоевывала коммерческое признание. В итоге сотрудники университета решили убрать из BSD код, принадлежащий корпорации AT&T. Эта работа обещала быть долгой, тщательной и сложной. К тому же перед самым финалом работы университет, находящийся в Беркли, оказался без финансовой поддержки, ранее направляемой на исследование ОС. Поэтому группа исследователей распалась. Но до расформирования группа успела явить миру 4.4BSD-Lile – версию, в которой не было этого кода. Именно от этого пакета начинают свою историю такие версии BSD UNIX, как NetBSD Mac OS X2, FreeBSD, OpenBSD и прочие современные.

А такие версии, как Solaris или HP-UX – потомки ОС, основанных на AT&T.
Linux, в свою очередь, имеет ряд отличий как от кода BSD, так и от кода UNIX AT&T. Но при этом находится где-то между (с позиции функциональных возможностей).

Подобный подход упрощает администрирование и является одним их конкурентных преимуществ систем *nix не только перед Microsoft Windows, но и перед рядом систем UNIX-семейства.
Этот же подход порождает неразбериху в деле описания дистрибутивов. В данном случае, совершенно непонятно, что считать, а что не считать частью той или иной операционной системы. Например, пакет java присутствует на установочном диске, но не ставится по умолчанию. Входит ли он в дистрибутив? А если этот пакет можно скачать после установки из репозитария?
Оговоримся, что мы будем рассматривать тот или иной дистрибутив в его стандартной инсталляции. Но если мы будем говорить, что такой-то пакет не устанавливается по умолчанию, это не значит, что его вообще нет.
Для того чтобы узнать, есть ли необходимый пакет в системе, в первую очередь, следует использовать команду which, которая помогает выяснить, указана ли нужная команда в переменной среды PATH.

Пример.

Пакет установлен:

[ilya@localhost ~]$ which firefox
/usr/bin/firefox

Пакет не установлен:

[ilya@localhost ~]$ which flick
which: no flick in (/usr/bin:/bin:/usr/local/bin:/usr/X11R6/bin/:/usr/games:/usr/lib/qt4/bin:/usr/bin:/opt/kde3/bin:/home/ilya/bin)

Если данная команда which не нашла утилиты, это еще не означает, что ее вообще нет в системе. Можно воспользоваться командой whereis, которая ищет нужные файлы во всех системных каталогах. В ряде дистрибутивов эта команда не находит файлы, не помеченные как исполняемые.

[ilya@localhost ~]$ whereis ppp
ppp: /etc/ppp
[ilya@localhost ~]$ whereis pptp
pptp: /usr/sbin/pptp /etc/pptp.d

Можно воспользоваться не менее эффективной командой locate, которая проводит поиск в специально собранном файле-индексе файловой системы в соответствии с маской, заданной пользователем дистрибутива. Она способна проводить поиск не только утилит или пакетов, но и файлы практически любых других типов, находящихся в системе.
Например, вы хотите узнать, где находится файл rc.local, но не хотите перебирать все папки в системном разделе. Тогда команда будет выглядеть так:

[ilya@localhost ~]$ locate rc.local
/etc/rc.local
/etc/rc.d/rc.local

Как видите, система нашла целых два файла с таким названием.
Недостаток команды locate вытекает из ее достоинства: она проводит поиск по базе, которая пересоздается ночью командой updatdb, приводимую в действие демоном cron. Поэтому новые файлы не могут быть найдены, пока база не будет пересоздана. Если вы точно знаете, что файлы в системе есть — ничто не мешает вам регенерировать базу командой udatedb вручную. Команда должна запускаться от имени суперпользователя (root).
Если имя искомого пакета известна, вы можете воспользоваться инструментами более высокого уровня: системами управления пакетами. В дистрибутивах, основанных на rpm (Red Hat, Fedora, OpenSuSE, Mandriva, CentOS и других), наличие пакета можно проверить одноименной командой:

[ilya@localhost ~]$ rpm -q kppp
kppp-4.1.3-1.1mdv2009.0
[ilya@localhost ~]$ rpm -q java
пакет java не установлен

Если пакет не установлен, его можно найти в репозитарии дистрибутива. Для этого необходимо воспользоваться системой управления пакетами. Все разработанные системы могут установить и обновить пакеты из репозитария дистрибутива, но наиболее распространенными и развитыми являются три системы: yum, APT и urpmi.
Для того чтобы установить java в дистрибутиве Debian GNU/Linux, необходимо в консоли под root набрать следующую команду:

[root@localhost ~]# apt-get install java

В Mandriva аналогом APT является urpmi:

[root@localhost ilya]# urpmi java

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

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

Процесс сборки пакетов будет описан в следующих статьях цикла.
Стоит сделать еще одно замечание: даже если разные дистрибутивы используют пакеты rpm, это не означает, что пакеты из одной системы подойдут к другой. Инсталлируя пакеты, к примеру, принадлежащие OpenSuSE в Mandriva, вы рискуете получить неработоспособную систему, потому что иерархия их файловых систем неодинакова и зависимости пакетов различаются.
Пакеты, отсутствующие в репозитариях, можно попробовать поискать в различных интернет-хранилищах. Таких, например, как rpmfind.net, или воспользоваться сервисом Google для поиска информации, связанной с Linux: http://wwwgoogle.com/linux.