Нейл Мэтью - Основы программирования в Linux
Этот раздел стандарта точен, краток и понятен. Далее перечислены некоторые требования стандарта.
□ Спецификация требует для получения подробных сведений о пользователе никогда не читать напрямую такие файлы, как /etc/passwd, а всегда применять вызовы стандартной библиотеки, например getpwent, или стандартные утилиты, например passwd.
□ Стандарт требует наличия пользователя с именем root в группе root, который является администратором системы с полным набором привилегий или прав доступа. Мы также находим в стандарте ряд необязательных имен пользователей и групп, которые никогда не следует применять в стандартных приложениях; они предназначены для использования дистрибутивами.
□ В стандарте также указано, что ID, меньшие 100, — системные учетные записи, диапазон 100-499 занимают системные администраторы и постустановочные сценарии, и, наконец, ID с номерами 500 и большими предназначены для учетных записей обычных пользователей.
Как правило, большинство программистов Linux должно знать о требованиях стандартов, касающихся пользователей.
Инициализация системы LSB
Область инициализации или запуска системы всегда, по крайней мере для нас, была источником беспокойства из-за трудноуловимых различий дистрибутивов.
Система Linux унаследовала от UNIX-подобных операционных систем идею уровней запуска или выполнения, определяющих сервисы, постоянно выполняющиеся в системе. В табл. 18.1 приведены стандартные определения для ОС Linux.
Таблица 18.1
Уровень запуска Описание 0 Halt. Применяется как логическое состояние, к которому следует перейти при остановке системы 1 Однопользовательский режим. Каталоги, отличающиеся от / (корневой), могут не монтироваться, и сетевой поддержки не будет. Обычно применяется для обслуживания системы 2 Многопользовательский режим, но без сетевой поддержки 3 Обычный многопользовательский режим с сетевой поддержкой, использующий экран регистрации в текстовом режиме 4 Зарезервирован 5 Обычный многопользовательский режим с сетевой поддержкой, использующий экран регистрации в графическом режиме 6 Псевдоуровень, применяемый для перезагрузкиСтандарт LSB приводит эти уровни, но не требует их обязательного использования, хотя они и очень распространены.
Сопровождает уровни запуска набор сценариев инициализации, применяемых для запуска, останова и повторного запуска сервисов. В прошлом они хранились в разных местах в каталоге /etc, часто в /etc/init.d или в /etc/rc.d/init.d. Подобное разнообразие часто было причиной путаницы, поскольку пользователи, менявшие дистрибутивы, не могли найти сценарии инициализации в привычных местах, и установка программ завершалась аварийно при попытке выполнить сценарий инициализации из неверного каталога.
Стандарт LSB 3.1 определяет каталог /etc/init.d, как место хранения сценариев инициализации, но при этом разрешает этому каталогу быть ссылкой на другое место в системе.
У каждого сценария в каталоге /etc/init.d есть имя, связанное с предоставляемым им сервисом. Поскольку все сервисы ОС Linux должны совместно использовать одно пространство имен, важно, чтобы эти имена были уникальны. Например, жизнь будет несладкой, если сервисы MySQL и PostgreSQL решат назвать свои сценарии "database". Для устранения такого конфликта существует еще один набор стандартов. Это стандарт Assigned Names And Numbers Authority (LANANА, орган назначения имен и номеров в Linux), который можно найти на Web-сайте http://www.lanana.org/. К счастью, вам понадобится знать очень немногое об этом стандарте, за исключением того, что в нем хранится список зарегистрированных имен сценариев и пакетов, облегчающий жизнь пользователям систем Linux.
Сценарий инициализации должен принимать параметр, управляющий его действиями. В стандарте определены параметры, перечисленные в табл. 18.2.
Таблица 18.2
Параметр Значение start Запускает (или перезапускает) сервис stop Останавливает сервис restart Перезапускает сервис; обычно реализован как простой останов сервиса, за которым следует запуск этого сервиса reload Переустанавливает сервис, повторно загружая параметры без реальной остановки сервиса. Этот вариант поддерживают не все сервисы, поэтому данный параметр может быть недоступен в некоторых сценариях, а если доступен, то не имеет эффекта force-reload Пытается вызвать переустановку, если сервис ее поддерживает, если нет — выполняет перезапуск сервиса status Выводит текстовое сообщение о состоянии сервиса и возвращает код состояния, который может применяться для определения состояния сервисаВсе команды возвращают 0 в случае успешного завершения или код ошибки, обозначающий причину аварийного исхода. В случае параметра status возвращается 0, если сервис выполняется; все остальные коды означают, что сервис не запущен по какой-то причине.
Стандарт устройства файловой системы
Последний стандарт, который мы собираемся, рассмотреть в этой главе, — Filesystem Hierarchy Standard (FHS, стандарт иерархии файловой системы). Его можно найти по адресу http://www.pathname.com/fhs/.
Назначение этого стандарта — определение типовых мест хранения в файловой системе Linux для того, чтобы как разработчики, так и пользователи могли делать обоснованные предположения относительно местонахождения тех или иных файлов. Многолетние пользователи UNIX-подобных операционных систем долгое время жаловались на трудноуловимые различия в схемах расположения файловых систем, и стандарт FHS предлагает дистрибутивам Linux способ избежать повторения этого прерывистого пути.
Схема размещения файлов в системе Linux на первый взгляд может показаться полупроизвольной структурой файлов и каталогов, основанной на исторически сложившихся представлениях. Отчасти это правда, но с годами схема размещения небезосновательно эволюционировала в иерархию, которую мы видим сегодня. Основная ее идея — разделение файлов и каталогов на три следующие группы:
□ файлы и каталоги, уникальные для конкретной работающей системы Linux, такие как сценарии запуска и файлы конфигурации;
□ файлы и каталоги, предназначенные только для чтения и, возможно, совместно используемые несколькими работающими системами Linux, например исполняемые файлы приложений;
□ каталоги, предназначенные для чтения/записи, но, возможно, совместно используемые работающими системами Linux или другими операционными системами, например исходные каталоги пользователей.
В этой книге нас не слишком интересует совместное использование файлов разными версиями Linux, хотя, в случае сети из машин с ОС Linux, это отличный способ убедиться в том, что существует только одна копия каталогов ключевых программ, и совместно использовать ее на разных машинах в сети. Это особенно полезно для бездисковых рабочих станций.
В стандарте FHS определена структура верхнего уровня, имеющая ряд обязательных подкаталогов и несколько необязательных каталогов; основные из них приведены в табл. 18.3.
Таблица 18.3
Каталог Обязательный? Назначение /bin Да Важные системные двоичные файлы /boot Да Файлы, необходимые для загрузки системы /dev Да Устройства /etc Да Системные файлы конфигурации /home Нет Каталоги для файлов пользователей /lib Да Стандартные библиотеки /media Да Место для съемных монтируемых носителей с отдельными подкаталогами для каждого типа носителей, поддерживаемого системой /mnt Да Удобная точка для временно монтируемых устройств, таких как CD-ROM и накопители флэш-памяти /opt Да Дополнительное прикладное программное обеспечение /root Нет Файлы пользователя root /sbin Да Важные системные двоичные файлы, которые необходимы в процессе запуска системы /srv Да Предназначенные только для чтения данные для сервисов, предоставляемых данной системой /tmp Да Временные файлы /usr Да Вспомогательная иерархия. Традиционно файлы пользователей также хранятся здесь, но в наши дни это считается дурным стилем и обычным пользователем не следует предоставлять право записи в этот каталог /var Да Переменные данные, например файлы регистрацииКроме того, могут существовать и другие каталоги, начинающиеся с lib, хотя это и не распространено. Как правило, вы также будете встречать каталог /lost+found (для восстановления файловой системы с помощью программы fsck) и каталог /proc, представляющий собой псевдофайловую систему, обеспечивающую отображение работающей системы. Текущая версия стандарта FHS усиленно поддерживает файловую систему /proc, но ее присутствие не обязательно. Подробности, касающиеся системы /proc, в основном выходят за рамки тем, обсуждаемых в этой книге, хотя мы и привели ее краткий обзор в главе 3.
