JavaScript is required to for searching.
Ignorer les liens de navigation
Quitter l'aperu
Administration d’Oracle Solaris : Tâches courantes     Oracle Solaris 11 Information Library (Français)
search filter icon
search icon

Informations document

A propos de ce manuel

1.  Localisation des informations relatives aux commandes Oracle Solaris

2.  Gestion des comptes utilisateur et des groupes (présentation)

3.  Gestion des comptes utilisateur et des groupes (tâches)

4.  Initialisation et arrêt d'un système Oracle Solaris

5.  Utilisation d'Oracle Configuration Manager

6.  Gestion des services (présentation)

Présentation de SMF

Concepts SMF

Service SMF

Dépendances SMF

Identificateurs de service

Etats des services

Fichiers manifestes SMF

Profils SMF

Référentiel de configuration de service

Sauvegardes du référentiel SMF

Instantanés SMF

Couches administratives SMF

Journalisation des erreurs du service SMF

Interfaces d'administration et de programmation SMF

Utilitaires d'administration en ligne de commande SMF

Interfaces de bibliothèque de configuration de gestion de service

Composants SMF

Démon d'agent de redémarrage maître SMF

Agents de redémarrage délégués SMF

Propriétés et groupes de propriétés SMF

Gestion des informations dans le référentiel de configuration de service

Affichage des informations SMF

Modification des informations SMF

Suppression des informations SMF

SMF et initialisation

Compatibilité SMF

Niveaux d'exécution

Cas d'utilisation des niveaux d'exécution et des jalons

Identification du niveau d'exécution d'un système

Fichier /etc/inittab

Evénements lorsque le système passe au niveau d'exécution 3

7.  Gestion des services (tâches)

8.  Utilisation du gestionnaire de pannes

9.  Gestion des informations système (tâches)

10.  Gestion des processus système (tâches)

11.  Surveillance des performances du système (tâches)

12.  Gestion des packages de logiciels (tâches)

13.  Gestion de l'utilisation du disque (tâches)

14.  Tâches de planification du système (tâches)

15.  Configuration et administration d'imprimantes à l'aide de CUPS (tâches)

16.  Gestion de la console système, des périphériques terminaux et des services d'alimentation (tâches)

17.  Gestion des informations sur les pannes système (tâches)

18.  Gestion des fichiers noyau (tâches)

19.  Dépannage du système et des problèmes logiciels (tâches)

20.  Dépannage de divers problèmes système et logiciels (tâches)

Index

Concepts SMF

Cette section présente les termes utilisés dans la structure SMF et leurs définitions. Ces termes sont utilisés dans la documentation Une bonne compréhension de ces termes est essentielle pour appréhender les concepts SMF.

Service SMF

L'unité de base de gestion dans la structure SMF est l'instance de service. Chaque service SMF peut disposer de plusieurs versions configurées. De même, plusieurs instances de la même version peuvent s'exécuter sur un système. Une instance est une configuration spécifique d'un service. Un serveur Web est un service. Un démon de serveur Web spécifique qui est configuré pour être à l'écoute du port 80 est une instance. Chaque instance du service de serveur Web peut avoir différentes configurations requises. La configuration requise du service s'applique à l'échelle du système, mais chaque instance peut ignorer des exigences spécifiques, en fonction des besoins. Des instances multiples d'un service sont gérées en tant qu'objets enfant de l'objet de service.

Les services ne sont pas seulement la représentation de services système standard de longue durée d'exécution, tels que in.dhcpd ou nfsd. Les services représentent également diverses entités du système qui comprennent notamment des applications ISV. En outre, un service peut représenter des entités moins traditionnelles, telles que les suivantes :

De manière générique, un service est une entité qui fournit une liste de capacités aux applications et autres services, au niveau local et à distance. Un service dépend d'une liste de services locaux déclarée de manière implicite et explicite.

Un jalon est un type de service spécial. Les services jalons représentent un niveau de préparation du système. Par exemple, les niveaux d'exécution sont représentés par des jalons dans SMF. En outre, les jalons peuvent être utilisés pour indiquer la préparation d'un groupe de services, tels que svc:/milestone/name-services:default pour les services de noms ou svc:/milestone/config:default pour le service sysconfig.

Dépendances SMF

Les dépendances définissent les relations entre les services. Ces relations assurent le confinement précis des erreurs en redémarrant uniquement les services directement affectés par une erreur au lieu de les redémarrer tous. Les dépendances fournissent également un processus d'initialisation évolutif et reproductible. Enfin, la définition de dépendances précises permet au démarrage du système de tirer profit des machines modernes très parallèles, car tous les services indépendants peuvent être lancés en parallèle.

Le comportement de redémarrage d'un service est défini par l'attribut restart_on pour chaque dépendance. Un service peut être configuré de manière à s'arrêter si le service dont il est dépendant s'arrête en raison d'une erreur ou pour une autre raison, ou s'il est actualisé. Après l'arrêt d'un service par ce processus, il est automatiquement redémarré dès que le service dont il est dépendant démarre. Par exemple, le service ssh dépend du service network/ipfilter. L'attribut restart_on est défini sur error, ce qui signifie que le service ssh est arrêté et automatiquement redémarré si le service network/ipfilter s'arrête en raison d'une erreur. Le service ssh n'est pas arrêté si les autres types d'événements surviennent.

Identificateurs de service

Chaque instance de service est appelée avec un identificateur de ressource de gestion des pannes ou FMRI (Fault Management Resource Identifier). Le FMRI inclut le nom de service et le nom de l'instance. Par exemple, le FMRI du service rlogin est svc:/network/login:rlogin, où network/login identifie le service et rlogin l'instance de service.

Les formats équivalents pour un FMRI sont les suivants :

En outre, de nombreuses commandes SMF peuvent utiliser un nom de service ou d'instance abrégé, lorsqu'il n'y a aucune ambiguïté. Par exemple, system-log peut être utilisé directement plutôt que les formats plus longs. Reportez-vous aux pages de manuel relatives à la commande SMF, telles que svcadm(1M) ou svcs(1), pour consulter des instructions sur les formats FMRI appropriés.

Les noms de service comprennent des préfixes permettant d'identifier l'objectif de chaque service. Ces préfixes peuvent consister notamment en des noms tels que application, device, milestone, network ou system. Le préfixe site est réservé aux personnalisations propres au site et les services utilisant ce préfixe ne seront pas fournis dans une version d'Oracle Solaris.

D'anciens scripts init.d sont également représentés avec des FMRI commençant par lrc au lieu de svc, par exemple : lrc:/etc/rc2_d/S47pppd. Les heures de démarrage initiales du service hérité pendant l'initialisation du système sont affichées à l'aide de la commande svcs. Toutefois, ces services ne peuvent pas être administrés à l'aide de SMF.

Lors du déploiement initial du système, les services répertoriés dans /etc/inetd.conf sont automatiquement convertis en services SMF. Les FMRI pour ces services sont légèrement différents. La syntaxe d'un service inetd converti est la suivante :

network/service-name/protocol

En outre, la syntaxe d'un service converti utilisant le protocole RPC est la suivante :

network/rpc-service-name/rpc_protocol

service-name est le nom défini dans /etc/inetd.conf et protocol est le protocole du service. La commande inetconv peut être utilisée pour convertir les entrées inetd.conf après le déploiement initial du système.

Etats des services

La commande svcs affiche l'état, l'heure de début et le FMRI des instances de service. Les états des services peuvent être les suivants :

Un astérisque (*) est ajouté en regard de l'état pour les instances en transition. Un point d'interrogation (?) s'affiche si l'état est absent ou non reconnu.

Fichiers manifestes SMF

Un manifeste SMF est un fichier XML qui décrit un service et un jeu d'instances. Les manifestes sont importés pour charger les propriétés de ce service et ses instances dans le référentiel de configuration de service. Reportez-vous à la page de manuel service_bundle(4) pour obtenir une description complète du contenu des manifestes SMF.

L'emplacement préféré pour les manifestes est /lib/svc/manifest. Les manifestes qui s'y trouvent sont importés et mis à niveau par le service svc:/system/early-manifest-import:default pendant le processus d'initialisation avant le lancement des services. L'exécution précoce du processus d'importation garantit que le référentiel contient les informations issues des derniers manifestes avant que les services ne soient démarrés. Dans d'autres circonstances, vous pouvez importer des informations à partir de ces manifestes en exécutant la commande : svcadm restart manifest-import. /var/svc/manifest reste disponible pour des raisons de compatibilité, mais les manifestes qui s'y trouvent ne sont importés ou mis à niveau qu'à partir du moment où le service svc:/system/manifest-import:default s'exécute.

N'apportez pas de modifications aux manifestes fournis par Oracle ou par des fournisseurs de logiciels tiers. Ne modifiez pas directement ces manifestes dans /lib/svc/manifest et /var/svc/manifest, car ces personnalisations sont perdues en cas de mise à niveau. Créez plutôt un profil de site pour personnaliser le service ou utilisez la commande svccfg ou la commande inetadm pour manipuler directement les propriétés. Les répertoires /lib/svc/manifest/site et /var/svc/manifest/site sont également réservés à un usage propre au site. La version d'Oracle Solaris ne fournit pas de manifestes dans ces répertoires.

Dans la version Oracle Solaris 11, plusieurs manifestes peuvent être utilisés pour décrire un service unique. Cela peut être utile, par exemple, pour définir une nouvelle instance d'un service sans modifier le manifeste existant du service. Si la même propriété du même service ou de la même instance est définie par plusieurs manifestes, SMF ne peut pas déterminer la valeur à utiliser. Lorsque ce type de conflit est détecté, l'instance est placée en état de maintenance.

Profils SMF

Un profil SMF est un fichier XML qui permet la personnalisation des services et des instances fournis par le système. Les profils sont fournis pour permettre la personnalisation à l'aide d'un fichier plutôt que d'un ensemble de scripts, ou pour personnaliser la configuration au moment du déploiement ou de l'installation.

Toutes les configurations peuvent être personnalisées à l'aide d'un profil, y compris l'ajout d'instances pour des services fournis par le système.

Les personnalisations locales doivent être placées dans des fichiers dont le nom comporte le suffixe .xml dans le répertoire /etc/svc/profile/site. Toutes les personnalisations dans ce répertoire sont appliquées lorsque le système est initialisé ou lorsque la commande svcadm restart manifest-import est exécutée.

Comme pour les manifestes, toute définition conflictuelle entre les fichiers dans /etc/svc/profile/site est traitée comme un conflit, et les instances affectées sont placées en état de maintenance.

Un profil système est également appliqué au cours de l'installation. Les modifications apportées au profil système dans /etc/svc/profile/generic.xml sont rarement nécessaires. Reportez-vous à la page de manuel smf_bootstrap(5) pour plus d'informations.

Pour plus d'informations sur l'utilisation des profils, reportez-vous à la section Procédure d'application d'un profil SMF .

Référentiel de configuration de service

Le référentiel de configuration de service stockent des informations de configuration persistantes, ainsi que des données d'exécution SMF des services. Le référentiel est distribué entre la mémoire locale et les fichiers locaux. Le référentiel de configuration de service peut uniquement être manipulé ou interrogé à l'aide des interfaces SMF. Pour plus d'informations sur la manipulation et l'accès au référentiel, reportez-vous aux pages de manuel svccfg(1M) et svcprop(1). Le démon du référentiel de configuration de service est abordé à la page de manuel svc.configd(1M). La bibliothèque de configuration de service est documentée à la page de manuel libscf(3LIB).

Les propriétés dans le référentiel peuvent être définies sur le service ou l'instance. Les propriétés qui sont définies sur le service sont partagées par toutes les instances de ce service. Les propriétés qui sont définies sur l'instance sont uniquement utilisées par cette instance et peuvent se substituer aux propriétés sur le service.

La commande svccfg offre un affichage brut des propriétés et montre clairement si les propriétés sont définies sur le service ou sur l'instance. Si vous affichez un service en utilisant la commande svccfg, vous ne pouvez pas voir les propriétés de l'instance. Si vous affichez l'instance en revanche, vous ne pouvez pas voir les propriétés du service. La commande svcprop offre une vue composée de l'instance, où les propriétés d'instance et les propriétés de service sont combinées en un espace de noms de propriétés unique. Lorsque des instances de service sont démarrées, la vue composée de leurs propriétés est utilisée.

Toutes les modifications apportées à la configuration SMF peuvent être consignées à l'aide de la structure d'audit d'Oracle Solaris. Reportez-vous à la section Configuration du service d’audit (liste des tâches) du manuel Administration d’Oracle Solaris : services de sécurité pour plus d'informations.

Sauvegardes du référentiel SMF

SMF effectue automatiquement les sauvegardes suivantes du référentiel :

Quatre sauvegardes de chaque type sont mises à jour par le système. Le système supprime la sauvegarde la plus ancienne, lorsque cela est nécessaire. Les sauvegardes sont stockées en tant que /etc/svc/repository-type- YYYYMMDD_HHMMSWS, où YYYYMMDD (année, mois, jour) et HHMMSS (heures, minutes, secondes) sont la date et l'heure auxquelles la sauvegarde a été effectuée. Notez que le format horaire est sur 24 heures.

En cas d'erreur, vous pouvez restaurer le référentiel à partir de ces sauvegardes. Pour ce faire, utilisez la commande /lib/svc/bin/restore_repository. Pour plus d'informations, reportez-vous à la section Procédure de réparation d'un référentiel corrompu .

Instantanés SMF

Les données du référentiel de configuration de service incluent des instantanés, ainsi qu'une configuration éditable. Les données relatives à chaque instance de service sont stockées dans des instantanés. Les instantanés standard sont les suivants :

Le service SMF s'exécute toujours avec l'instantané running. Si cet instantané n'existe pas, il est automatiquement créé.

La commande svccfg permet de modifier les valeurs de propriété actuelles. Ces valeurs deviennent visibles pour le service lorsque la commande svcadm est exécutée pour intégrer ces valeurs dans l'instantané en cours d'exécution. La commande svccfg peut également être utilisée pour visualiser ou rétablir une configuration d'instance d'un autre instantané.

Couches administratives SMF

Dans la version Oracle Solaris 11, des informations renseignant sur la source de propriétés, de groupes de propriétés, d'instances et de services ont été ajoutées au référentiel de configuration de service. Ces informations permettent aux utilisateurs de déterminer les données qui correspondent à des personnalisations administratives et celles qui ont été fournies avec le logiciel.

Pour vous aider à identifier la source d'une entité, les couches suivantes sont définies :

Pour préserver la compatibilité des clients existants qui s'attendent à une seule propriété par nom de propriété, ainsi que pour créer une stratégie pour les remplacements, l'organisation en couches a un comportement de remplacement simple. La couche admin est prioritaire. Si une propriété possède une valeur dans la couche admin, c'est cette valeur qui est utilisée par le service. Si ce n'est pas le cas, la couche site-profile est vérifiée, puis la couche system-profile, et enfin la couche manifest. Ce comportement permet aux personnalisations locales d'être prioritaires par rapport aux valeurs fournies lors de l'installation du système.

Ces couches sont gérées automatiquement par le système. Les modifications directes apportées au référentiel par un administrateur n'apparaissent que dans la couche admin. D'autres couches ne sont modifiées qu'en plaçant ou en supprimant des fichiers dans des emplacements standard. Lorsqu'une propriété est placée dans le référentiel en raison du contenu d'un fichier, les informations relatives à cette propriété incluent le nom du fichier dont est issu le contenu.

Un administrateur ne peut pas modifier directement les couches inférieures en utilisant les appels svccfg ou libscf. Lorsque la commande svccfg delete, svccfg delpg ou svccfg delprop est utilisée, l'entité est masquée au lieu d'être entièrement supprimée. Normalement, les utilisateurs ne peuvent pas voir l'entité supprimée, mais les entités masquées peuvent être explicitement explorées à l'aide de la commande svccfg listcust, et leur masquage peut être levé à l'aide de la commande svccfg delcust en cas de besoin.

La commande svccfg listprop propose des options permettant l'exploration de ces couches. Par exemple, svccfg listprop -l all imprime toutes les couches et les valeurs de chaque couche. En outre, la commande svccfg listcust peut être utilisée pour répertorier uniquement les personnalisations.

Journalisation des erreurs du service SMF

Les informations propres au service, notamment les erreurs émises par le service ou ses méthodes, ainsi que les informations sur les actions d'activation, les heures de démarrage etc. sont consignées dans des fichiers individuels pour chaque instance de service dans /var/svc/log. Pour déterminer le nom du fichier journal d'un service, exécutez la commande svcs -x service.

Par défaut, l'utilitaire SMF écrit les messages du journal dans le programme syslog et dans la console uniquement si une intervention d'administration est nécessaire, par exemple si un service entre en état de maintenance. D'autres options sont disponibles mais rarement utilisées. Reportez-vous à la page de manuel svc.startd(1M) pour consulter d'autres configurations potentielles.

En plus de la journalisation des erreurs, le service SMF peut être configuré de manière à vous avertir lorsqu'un événement FMA se produit ou lorsque des services entrent dans un état de service ou en sortent. Ces notifications peuvent utiliser le protocole SNMP (Simple Network Management Protocol) ou le protocole SMTP (Simple Mail Transfer Protocol). Reportez-vous à la section Procédure de configuration de la notification par e-mail pour les événements de transition SMF pour plus d'informations sur la configuration des notifications de SMF.