Управление службами с помощью SMF

Взаимосвязь служб

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

Если при запуске службы выясняется, что не работают какие-то другие службы, от которых она зависит, то служба не запускается и переводится в состояние offline. Если ошибки возникают во время запуска службы, она переводится в состояние maintenance.

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

Удовлетворены ли взаимосвязи службы, определяется типом взаимосвязи:

• require_all – считается удовлетворенной, когда все перечисленные службы запущены (находятся в состояниях online или degraded ) или все указанные файлы присутствуют.
• require_any – считается удовлетворенной, когда хотя бы одна из перечисленных служб запущена (находится в состояниях online или degraded ) или по крайней мере один из указанных файлов присутствует.
• optional_all – считается удовлетворенной, когда все перечисленные службы запущены (находятся в состояниях online или degraded ), или не могут быть запущены без вмешательства администратора (т.е. находятся в состояниях disabled, maintenance, offline ), или не существуют.
• exclude_all – считается удовлетворенной, когда все перечисленные службы запрещено запускать, либо они находятся в состоянии maintenance, либо все указанные службы или файлы отсутствуют.

Взаимосвязи также иногда называют "зависимостями" (от англ. "dependencies").

Каждая служба управляется с помощью службы запуска ( restarter'a – т.е. "пускателя"). У службы может быть своя собственная служба запуска. Кроме этого, есть общая служба запуска – svc.startd. В документации она называется master restarter.

Служба запуска выполняет свои функции, вызывая методы каждой службы, за которую она отвечает. Методы – это обычно скрипты, которым передаются параметры start, stop, refresh и т.п.

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

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

Узнать, от каких служб и файлов зависит служба, какая программа является ее службой запуска, а также изменить описание взаимосвязей можно с помощью команд svcs и svccfg соответственно.

Объявление службы (manifest)

Каждая служба имеет свое объявление ( manifest ) – файл в формате XML, содержащий полное описание всех свойств службы или ее экземпляра. Объявления служб хранятся в каталоге /var/svc/manifest. Эти файлы не следует использовать для изменения свойств служб, так как для этого предназначены команды svccfg и inetadm. Файлы объявлений сами по себе не являются источником информации для служб SMF, так как источником является репозиторий. Для импорта информации из файлов объявлений в репозиторий надо дать команду svccfg import или подождать перезагрузки – при старте системы импорт произойдет автоматически.

Для изучения структуры файлов объявлений имеет смысл прочесть страницу системного руководства по service_bundle(4).

С помощью команды svccfg export можно получить архивный файл в формате XML со всеми свойствами всех служб, за исключением непостоянных свойств типа текущего состояния службы.

Унаследованные сценарии запуска

Унаследованные от прежних версий системы сценарии (скрипты) запуска служб, расположенные в каталогах /etc/rc?.d, запускаются как часть соответствующего этапа работы системы:

Каталог со скриптами Этап
/etc/rcS.d milestone/single-user:default
/etc/rc2.d milestone/multi-user:default
/etc/rc3.d milestone/multi-user-server:default

Запущенные с помощью этих скриптов процессы показываются в выводе svcs как экземпляры служб, которые идентифицируются полным именем файла, породившего процесс и находящегося в состоянии legacyrun. Этими службами нельзя управлять с помощью svcadm и для них не производится перезапуск и подробная диагностика в случае сбоев.

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

Для получения всех запущенных служб следует дать команду

svcs

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

svcs -a

При поиске служб, которые оказались в состоянии maintenance и которым требуется вмешательство администратора для возобновления нормальной работы, следует использовать

svcs -xv

Для изменения состояния службы надо пользоваться svcadm, для изменения настроек служб – svccfg, для получения информации о свойствах служб – svcprop.

Рассмотрим настройку конкретных служб на примере настроек сетевого интерфейса в Solaris.

Как указывалось в "лекции 2" , при настройке сети в Solaris Express можно применять одну из трех схем – классическую, связанную с inetmenu и самую современную, основанную на NWAM (NetWork Auto Magic). Можно ожидать, что после тестирования в дистрибутивах Solaris Express эта функциональность будет интегрирована в Solaris 10 или следующую версию Solaris.

Посмотрим, какие службы связаны с сетью в нашей системе (мы используем Solaris Express, build 79a для этого эксперимента):

svcs | grep network
online февр svc:/network/tnctl:default
online февр svc:/network/loopback:default
online февр svc:/network/physical:nwam
online февр svc:/network/ipsec/ipsecalgs:default
online февр svc:/network/ipsec/policy:default
online февр svc:/milestone/network:default
online февр svc:/network/initial:default
online февр svc:/network/service:default
online февр svc:/network/shares/group:default
online февр svc:/network/shares/group:zfs
online февр svc:/network/routing-setup:default
online февр svc:/network/routing/ndp:default
online февр svc:/network/rpc/bind:default
online февр svc:/network/routing/route:default
online февр svc:/network/inetd:default
online февр svc:/network/smtp:sendmail
online февр svc:/network/ssh:default
online февр svc:/network/rpc/gss:default
online февр svc:/network/rpc/smserver:default
online февр svc:/network/rpc/cde-calendar-manager:default
online февр svc:/network/rpc/cde-ttdbserver:tcp
online февр svc:/network/security/ktkt_warn:default
online февр svc:/network/rpc-100235_1/rpc_ticotsord:default

Мы получили список только тех служб, которые в настоящий момент запущены. Только одна из них имеет отношение к настройкам сетевого интерфейса – svc:/network/physical:nwam.

Изучим свойства этой службы:

svcprop svc:/network/physical:nwam
nwamd/dhcp_wait_time count 60
nwamd/popup_info boolean true
nwamd/popup_query boolean true
nwamd/scan_interval count 120
nwamd/stability astring Unstable
nwamd/use_net_svc boolean true
nwamd/value_authorization astring solaris.smf.value.nwam
general/action_authorization astring solaris.smf.manage.nwam
general/value_authorization astring solaris.smf.manage.nwam
general/enabled boolean true
general/entity_stability astring Unstable
start/exec astring /lib/svc/method/net-nwam\ start
start/timeout_seconds count 600
start/type astring method
stop/exec astring /lib/svc/method/net-nwam\ stop
stop/timeout_seconds count 60
stop/type astring method
...
(вывод сокращен)

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

Предположим, что нам надо перейти от настроек сети с помощью NWAM к классическому методу, т.е. к статическим файлам настроек, описанным в "лекции 3" . Для этого следует запретить службу svc:/network/physical:nwam и разрешить классическую настройку. Прежде всего потребуется выяснить, как называется служба классической настройки:

svcs -a | grep physical
disabled svc:/network/physical:default
online svc:/network/physical:nwam

Теперь запретим запуск nwam и разрешим запуск physical:default (используем сокращенные идентификаторы служб):

svcadm disable nwam
svcadm enable physical:default
svcs -a | grep physical
online svc:/network/physical:default
disabled svc:/network/physical:nwam

Теперь конфигурация сети считывается из файлов конфигурации.

Профили SMF

Хотя администратор Solaris в состоянии сам указать, какие службы следует запускать при старте системы, в помощь ему созданы профили. После установки или обновления системы для того, чтобы определить, какие службы следует запускать по умолчанию, система обращается к профилю generic.xml, который является символической ссылкой на generic_limited_net.xml.

В более старых версиях Solaris 10 (до Solaris 10 update 3 включительно) запускались службы согласно профилю generic_open.xml ( generic.xml указывал на него).

По сути дела профиль – это файл XML, содержащий список служб, разрешенных к запуску. В каталоге /var/svc/profile есть несколько предустановленных профилей:

• /var/svc/profile/generic_open.xml – службы, стандартные для более ранних версий Solaris 10;
• /var/svc/profile/generic_limited_net.xml – стандартные службы, как и в generic_open.xml, но с запретом запускать сетевые службы, кроме network/ssh ;
• /var/svc/profile/ns_*.xml – профиль разрешает запуск служб, имеющих отношение к службе имен;
• /var/svc/profile/platform_*.xml – профиль служб, связанных с конкретной аппаратной платформой.

Если в каталоге /var/svc/profile при старте системы обнаруживается профиль с именем site.xml, то в качестве списка запускаемых по умолчанию служб используется он. Вы можете создать свой собственный site.xml для компьютеров вашей организации на основе файлов *.xml в этом каталоге.

Резервные копии и снимки настроек SMF

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

Для возврата к предыдущим настройкам следует применять команды svccfg (и ее подкоманды – listsnap, selectsnap и revertsnap ), а для того, чтобы измененные настройки вступили в силу – svcadm refresh.