Системное администрирование ОС Solaris 10

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

Разбить на страницы
Показывать лекцию целиком

Краткое описание

Задача управления службами сводится к следующему:

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

    В Solaris 10 появился новый инструмент, позволяющий по-новому управлять службами в системе и тем самым коренным образом изменяющий и облегчающий этот процесс. Сам по себе механизм SMF (Service Managament Facility) состоит из следующих компонент: описания взаимозависимостей между службами, инфраструктуры их автоматизированного запуска и перезапуска, средств управления службами.

    Описание взаимозависимостей находится в репозитории, хранящем информацию в базе данных SQLite. Строго говоря, формат хранения никак не отражается на интерфейсе взаимодействия с репозиторием, и для модификации репозитория следует использовать библиотеку libscf(3LIB) или svcprop(1). В будущих версиях Solaris формат хранения может быть изменен.

    Репозиторий состоит из двух частей – постоянной, которая не может измениться без вмешательства человека от одной перезагрузки до другой, и непостоянной, где хранятся непостоянные свойства служб (например, их текущие состояния). Постоянная часть хранится в /etc/svc/repository.db, а непостоянная – в /etc/svc/volatile/svc_nonpersist.db.

    Инфраструктура запуска и перезапуска служб состоит из двух служб – svc.startd и svc.configd. Первая запускается при старте системы и считывает информацию из репозитория служб. После этого svc.startd запускает службы в соответствии с этой информацией – т.е. проверяет, какие службы отмечены к запуску для заданного этапа (milestone) работы системы, и запускает службы так, чтобы удовлетворить все их взаимозависимости (например, если httpd зависит от named, то named будет запущен до httpd ).

    Служба svc.configd отвечает за модификацию репозитория по командам администратора или посредством вызовов библиотеки libscf(3LIB).

    Средства управления службами (т.е. программы, предназначенные для такого управления) отвечают за взаимодействие администратора с другими компонентами smf. Для того, чтобы запретить старт какой-либо службы, разрешить его или иначе модифицировать текущее или будущее состояние службы либо ее настройки, надо использовать команды svcs, svcadm, svcprop, svccfg. Начиная с Solaris 10, другие средства управления службами не поддерживаются, хотя в отдельных случаях вы сможете обойтись и без инфраструктуры smf для запуска ваших служб.

    Использование SMF делает вашу систему более предсказуемой и легче диагностируемой, приводя порядок управления разнородными службами к единому образцу. В этой лекции управление службами будет рассмотрено подробнее.

    Механизм SMF разработан в рамках более широкого подхода – самовосстанавливающейся компьютерной системы, который носит название predictive self-healing ("прогнозируемое самовосстановление").

    Термины

    Для практического использования SMF нам потребуется использовать ряд терминов, которые мы определим в данном разделе.

  • Управление процессом устранения отказов (fault management) – действия, направленные на обнаружение, изоляцию и исправление сбоев.
  • FMRI – уникальный идентификатор управляемого ресурса (fault managed resource identifier).
  • Ресурс – это экземпляр службы, где служба понимается широко: как собственно служба, как программное состояние физического устройства, как конкретная настройка интерфейса, а также как набор нескольких служб или другой компонент системы, требующий управления (например, сервер баз данных Oracle).
    •

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

    Службы и управление ими

    Именование служб

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

    Все службы содержатся в определенном контексте (scope), представляющем собой набор логически связанных служб. В Solaris 10 пока определен только один контекст – localhost, объединяющий все службы локальной системы Solaris.

    Каждый экземпляр службы имеет свой идентификатор ( FMRI ), причем имя идентификатора всегда начинается с svc. К экземпляру можно обращаться по полному имени или по сокращенному, например, запретить запуск службы NWAM можно так:

    svcadm disable svc:/network/physical:nwam

    а можно и так:

    svcadm disable nwam

    Для служб, имеющих несколько экземпляров, может потребоваться более длинное указание идентификатора:

    svc:/application/database/postgresql:version_81

    Кстати, этот же идентификатор без сокращений выглядит так:

    svc://localhost/application/database/postgresql:version_81

    Здесь svc – тип службы, localhost – контекст, application/database/postgresql – имя службы, а version_81 определяет конкретный экземпляр этой службы.

    Имя службы может содержать несколько слэшей (символов "/" ), и тогда все его части, кроме последней, указывают на категорию службы (например, application/database ). По умолчанию в системе определены следующие категории:

  • application
  • device
  • milestone
  • network
  • platform
  • site
  • system
    •

    Службы, специфичные для данной конкретной системы, принято относить к категории site.

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

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

    Полный список служб, определенных в системе, можно получить по команде

    svcs -a

    Осторожно! Результат выполнения этой команды – длинный список служб!

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

  • degraded (ослабленное) – запуск разрешен, но работа происходит с ограниченной функциональностью.

    (Пример: запущен httpd, но named недоступен; в описании службы httpd указано, что она зависит от named, но последний не обязателен для работы httpd ; при протоколировании обращений к httpd имена компьютеров, с которых выполнялись обращения, не будут записаны, но их IP-адреса все равно попадут в протокол.)

  • disabled (запрещено запускать) – запуск запрещен; экземпляр службы не запущен.
  • legacy_run (унаследованный) – некоторые унаследованные (от предыдущих версий системы) службы не подлежат управлению через SMF, однако их работу можно наблюдать стандартными для SMF средствами; это состояние возможно только для унаследованных служб.
  • maintenance (обслуживание) – экземпляр службы аварийно завершился и не может быть запущен заново без вмешательства администратора.
  • offline (не работает) – запуск разрешен, но экземпляр службы еще не запущен или нет возможности его запустить.
  • online (работает) – запуск разрешен, экземпляр службы работает без проблем.
  • uninitialized (неинициализирован) – в этом состоянии находятся все службы до того, как их конфигурация будет считана из репозитория.
    •

    Перевод службы из состояния в состояние осуществляется автоматически (например, из состояния online в состояние maintenance – при невозможности перезапустить аварийно завершившийся процесс, представляющий ту или иную службу) или администратором вручную (например, при запрете запуска – из состояния online в состояние disabled ).

    Для управления службами следует использовать программы svcs (просмотр состояния), svcadm (изменение состояния), svcprop (просмотр настроек), svccfg (изменение настроек).

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

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

    Если при запуске службы выясняется, что не работают какие-то другие службы, от которых она зависит, то служба не запускается и переводится в состояние 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):

    Снимки настроек экземпляров служб
    initial начальная настройка службы, созданная при первом импорте ее описания (манифеста)
    last-import последняя из импортированных с помощью svccfg настройка экземпляра службы
    running настройка запущенного экземпляра службы
    start снимок настроек, созданный при последнем успешном переходе экземпляра службы в состояние online
    previous снимок настроек, созданный при последнем возврате к предыдущим настройкам

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

    Страницы:

    Краткое описание

    Задача управления службами сводится к следующему:

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

    В Solaris 10 появился новый инструмент, позволяющий по-новому управлять службами в системе и тем самым коренным образом изменяющий и облегчающий этот процесс. Сам по себе механизм SMF (Service Managament Facility) состоит из следующих компонент: описания взаимозависимостей между службами, инфраструктуры их автоматизированного запуска и перезапуска, средств управления службами.

    Описание взаимозависимостей находится в репозитории, хранящем информацию в базе данных SQLite. Строго говоря, формат хранения никак не отражается на интерфейсе взаимодействия с репозиторием, и для модификации репозитория следует использовать библиотеку libscf(3LIB) или svcprop(1). В будущих версиях Solaris формат хранения может быть изменен.

    Репозиторий состоит из двух частей – постоянной, которая не может измениться без вмешательства человека от одной перезагрузки до другой, и непостоянной, где хранятся непостоянные свойства служб (например, их текущие состояния). Постоянная часть хранится в /etc/svc/repository.db, а непостоянная – в /etc/svc/volatile/svc_nonpersist.db.

    Инфраструктура запуска и перезапуска служб состоит из двух служб – svc.startd и svc.configd. Первая запускается при старте системы и считывает информацию из репозитория служб. После этого svc.startd запускает службы в соответствии с этой информацией – т.е. проверяет, какие службы отмечены к запуску для заданного этапа (milestone) работы системы, и запускает службы так, чтобы удовлетворить все их взаимозависимости (например, если httpd зависит от named, то named будет запущен до httpd ).

    Служба svc.configd отвечает за модификацию репозитория по командам администратора или посредством вызовов библиотеки libscf(3LIB).

    Средства управления службами (т.е. программы, предназначенные для такого управления) отвечают за взаимодействие администратора с другими компонентами smf. Для того, чтобы запретить старт какой-либо службы, разрешить его или иначе модифицировать текущее или будущее состояние службы либо ее настройки, надо использовать команды svcs, svcadm, svcprop, svccfg. Начиная с Solaris 10, другие средства управления службами не поддерживаются, хотя в отдельных случаях вы сможете обойтись и без инфраструктуры smf для запуска ваших служб.

    Использование SMF делает вашу систему более предсказуемой и легче диагностируемой, приводя порядок управления разнородными службами к единому образцу. В этой лекции управление службами будет рассмотрено подробнее.

    Механизм SMF разработан в рамках более широкого подхода – самовосстанавливающейся компьютерной системы, который носит название predictive self-healing ("прогнозируемое самовосстановление").

    Термины

    Для практического использования SMF нам потребуется использовать ряд терминов, которые мы определим в данном разделе.

  • Управление процессом устранения отказов (fault management) – действия, направленные на обнаружение, изоляцию и исправление сбоев.
  • FMRI – уникальный идентификатор управляемого ресурса (fault managed resource identifier).
  • Ресурс – это экземпляр службы, где служба понимается широко: как собственно служба, как программное состояние физического устройства, как конкретная настройка интерфейса, а также как набор нескольких служб или другой компонент системы, требующий управления (например, сервер баз данных Oracle).
    •

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

    Службы и управление ими

    Именование служб

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

    Все службы содержатся в определенном контексте (scope), представляющем собой набор логически связанных служб. В Solaris 10 пока определен только один контекст – localhost, объединяющий все службы локальной системы Solaris.

    Каждый экземпляр службы имеет свой идентификатор ( FMRI ), причем имя идентификатора всегда начинается с svc. К экземпляру можно обращаться по полному имени или по сокращенному, например, запретить запуск службы NWAM можно так:

    svcadm disable svc:/network/physical:nwam

    а можно и так:

    svcadm disable nwam

    Для служб, имеющих несколько экземпляров, может потребоваться более длинное указание идентификатора:

    svc:/application/database/postgresql:version_81

    Кстати, этот же идентификатор без сокращений выглядит так:

    svc://localhost/application/database/postgresql:version_81

    Здесь svc – тип службы, localhost – контекст, application/database/postgresql – имя службы, а version_81 определяет конкретный экземпляр этой службы.

    Имя службы может содержать несколько слэшей (символов "/" ), и тогда все его части, кроме последней, указывают на категорию службы (например, application/database ). По умолчанию в системе определены следующие категории:

  • application
  • device
  • milestone
  • network
  • platform
  • site
  • system
    •

    Службы, специфичные для данной конкретной системы, принято относить к категории site.

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

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

    Полный список служб, определенных в системе, можно получить по команде

    svcs -a

    Осторожно! Результат выполнения этой команды – длинный список служб!

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

  • degraded (ослабленное) – запуск разрешен, но работа происходит с ограниченной функциональностью.

    (Пример: запущен httpd, но named недоступен; в описании службы httpd указано, что она зависит от named, но последний не обязателен для работы httpd ; при протоколировании обращений к httpd имена компьютеров, с которых выполнялись обращения, не будут записаны, но их IP-адреса все равно попадут в протокол.)

  • disabled (запрещено запускать) – запуск запрещен; экземпляр службы не запущен.
  • legacy_run (унаследованный) – некоторые унаследованные (от предыдущих версий системы) службы не подлежат управлению через SMF, однако их работу можно наблюдать стандартными для SMF средствами; это состояние возможно только для унаследованных служб.
  • maintenance (обслуживание) – экземпляр службы аварийно завершился и не может быть запущен заново без вмешательства администратора.
  • offline (не работает) – запуск разрешен, но экземпляр службы еще не запущен или нет возможности его запустить.
  • online (работает) – запуск разрешен, экземпляр службы работает без проблем.
  • uninitialized (неинициализирован) – в этом состоянии находятся все службы до того, как их конфигурация будет считана из репозитория.
    •

    Перевод службы из состояния в состояние осуществляется автоматически (например, из состояния online в состояние maintenance – при невозможности перезапустить аварийно завершившийся процесс, представляющий ту или иную службу) или администратором вручную (например, при запрете запуска – из состояния online в состояние disabled ).

    Для управления службами следует использовать программы svcs (просмотр состояния), svcadm (изменение состояния), svcprop (просмотр настроек), svccfg (изменение настроек).

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

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

    Если при запуске службы выясняется, что не работают какие-то другие службы, от которых она зависит, то служба не запускается и переводится в состояние 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):

    Снимки настроек экземпляров служб
    initial начальная настройка службы, созданная при первом импорте ее описания (манифеста)
    last-import последняя из импортированных с помощью svccfg настройка экземпляра службы
    running настройка запущенного экземпляра службы
    start снимок настроек, созданный при последнем успешном переходе экземпляра службы в состояние online
    previous снимок настроек, созданный при последнем возврате к предыдущим настройкам

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

    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^