Применение стандарта LSB к библиотекам
Довольно об истории создания стандартов. Что означает для людей, пишущих программы на языке С (или С++), требование их переносимости?
Во-первых, вы должны убедиться в том, что используемая вами библиотечная функция приведена в стандарте LSB. Если ее там нет, возможно, вы делаете что-то, что нелегко будет перенести в другую систему, и вам следует поискать стандартный способ реализации той задачи, которую вы пытаетесь решить. Быть может, стоит попробовать команду Linux apropos, которая ищет страницы интерактивного справочного руководства для соответствующих ссылок.
Во-вторых, что труднее, следует убедиться в том, что поведение используемой вами функции включено в стандарт, и вы не полагаетесь на поведение, не описанное в стандарте. Возможно, для этого вам придется обратиться к стандарту Single UNIX Specification, если применение функции не определено в стандарте LSB. Очень хороший способ проверки неопределенного или потенциально ошибочного поведения — обращение к интерактивному руководству Linux. На многих его страницах есть раздел "BUGS" ("Ошибки"), представляющий собой неоценимый источник информации о том, где в ОС Linux конкретный вызов не в полной мере реализует стандарты или где существуют дефекты и нелепости в поведении.
Пользователи и группы LSB
Этот раздел стандарта точен, краток и понятен. Далее перечислены некоторые требования стандарта.
□ Спецификация требует для получения подробных сведений о пользователе никогда не читать напрямую такие файлы, как /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 способ избежать повторения этого прерывистого пути.
