Auteur : Thomas Lecomte (Deather)
Date : Mars 2006
Solaris 10 a introduit la notion de services, similaire à ce qu'on retrouve sous Windows NT. Les services sont des programmes fonctionnants en arrière-plan, sans interruption. SMF offre aussi une interface à inetd(1M), rendant ainsi le fichier /etc/inetd.conf inutilisé.
Dans le cadre de l'administration des services, les commandes à utiliser sont les suivantes :
Avec ces commandes, vous pourrez réaliser l'ensemble de l'administration SMF.
Chaque service est identifié par un Fault Management Ressource Identifier, ou FMRI. Ce FMRI se présente sous la forme suivante :
svc://host/category/service:instance
Par exemple, pour le client NFS :
svc://localhost/network/nfs/client:default
Notez que le champ //host peut être omis, auquel cas le système local sera utilisé. Le champ
category peut comporter plusieurs niveaux.
Il faut aussi savoir qu'il n'est pas nécessaire d'écrire le FMRI
en entier. Il est possible de se contenter de la partie component
du FMRI.
Exemple :
# svcs svc:/network/ssh:default
STATE STIME FMRI
online Mar_04 svc:/network/ssh:default
# svcs ssh
STATE STIME FMRI
online Mar_04 svc:/network/ssh:default
Les services possèdent un statut, qui permet de s'informer sur leur état actuel. Ceci est un résumé de la page de manuel de smf(5).
Ceci est le statut initial de tout service, avant qu'il soit traité (et démarré) par svc.startd(1M).
Cela signifie que le service est activé, mais qu'il n'est pas en cours de fonctionnement ou indisponible.
Ce statut indique que le service fonctionne. Ce statut est celui attendu lors du fonctionnement normal d'un service.
Le service fonctionne, mais de manière limitée. Une restauration de la part de l'administrateur provoquera son passage en mode ONLINE.
Le service est indisponible mais activé, et requiert une opération de l'administrateur afin d'être réparé et relancé.
Le service est désactivé et ne fonctionne pas. Il n'est pas lancé au démarrage de la machine.
Ce statut est utilisé pour des pseudo-services qui ne sont pas directement gérés par SMF. Il ne garantit pas que le service soit en fonctionnement.
La manipulation des services s'effectue avec la commande svcadm.
Pour démarrer un service, on utilise la commande suivante :
# svcadm [-r] enable <FMRI>
L'option -r précise que le démarrage des dépendances doit aussi être effectué. Pour les autres options, consultez la page de manuel de svcadm(1M) qui décrit très bien les opérations possibles.
Pour arrêter un service :
# svcadm [-t] disable <FMRI>
L'option -t indique que le service doit être arrêté
temporairement, et qu'il sera relancé au prochain reboot.
Le cas échéant, le service ne sera pas redémarré tant que
l'administrateur ne l'aura pas réactivé.
Pour relancer un service :
# svcadm restart <FMRI>
Le rafraîchissement est en général utilisé pour indiquer au service de relire son fichier de configuration. Il peut aussi être utilisé pour mettre à jour les propriétés du service, par exemple ses dépendances.
# svcadm refresh <FMRI>
Cette action peut être utilisée sur les services étant en mode MAINTENANCE ou DEGRADED venant d'être réparés par l'administrateur. Le service repasse alors en mode ONLINE.
# svcadm clear <FMRI>
Le services peuvent dépendre les uns des autres. Ils peuvent aussi dépendre de la présence d'un fichier. Si les dépendances d'un service ne sont pas satisfaites, celui-ci reste OFFLINE. Par contre, si celles-ci le sont, le dit service est alors lancé et passe en mode ONLINE, sous réserve que son lancement se déroule avec succès.
On peut lister les dépendances d'un service à l'aide de la commande svcs
-d <service>.
Exemple avec le service volfs :
# svcs -d svc:/system/filesystem/volfs:default
STATE STIME FMRI
online Mar_04 svc:/system/filesystem/local:default
online Mar_04 svc:/network/rpc/bind:default
online Mar_04 svc:/network/rpc/smserver:default
Pour plus d'infos sur les dépendances et leur gestion, reportez-vous à la section 8 (Création d'un service) où un exemple est donné.
La commande utilisée pour manipuler les propriétés d'un service est svccfg, qui peut être utilisée de manière interactive ou non. La syntaxe pour l'utiliser en mode interactive est la suivante :
# svccfg [-s FMRI]
L'option -s permet de sélectionner un service dès le lancement. Le cas échéant, vous devrez le sélectionner en tapant la commande suivante (par exemple ici avec volfs) :
# svccfg
svc:> select volfs
svc:/system/filesystem/volfs>
Pour exécuter directement une action, on utilisera cette syntaxe :
# svccfg -s FMRI subcommand args...
Nous allons voir ici uniquement les commandes permettant de lister et de modifier les propriétés d'un service. La création d'un nouveau service sera vue plus loin.
Afin d'identifier une propriété, on utilise l'expression suivante :
pg/name
Où pg signifie Property Group et name est le nom de la propriété.
Une fois le service sélectionné, la commande listprop liste toutes les propriétés du service :
svc:/system/filesystem/volfs> listprop
vold application
vold/config_file astring
vold/log_debuglevel count 0
vold/log_file astring
vold/log_nfs_trace boolean false
[...]
svc:/system/filesystem/volfs>
On peut préciser la propriété à afficher :
svc:/system/filesystem/volfs> listprop start/timeout_seconds
start/timeout_seconds count 30
svc:/system/filesystem/volfs>
La commande à utiliser est setprop. Voici sa syntaxe :
setprop pg/name = [type:] value
Si type est précisé et n'est pas identique au type de la propriété, alors l'action échoue.
Grâce à la commande editprop, vous pouvez facilement modifier toutes les propriétés d'un service. Cette commande provoque l'invocation de l'éditeur spécifié dans la variable $EDITOR, ou bien de vi.
La commande delprop permet de supprimer une propriété ou tout un groupe. Sa syntaxe est la suivante :
delprop pg[/name]
Il est possible de spécifier des variables d'environnement qui seront propres au service à l'aide des commandes setenv et unsetenv. Les options -i et -spermettent d'appliquer ce paramètre respectivement à l'instance ou au service.
Les fichiers de description de services sont rédigés au fomat XML et se trouvent dans le dossier /var/svc/manifest.
Il est aussi nécessaire de créer un starter, équivalent aux fichiers trouvés auparavant dans /etc/init.d.
Je me baserai ici sur un exemple concret : Apache. Par défaut, Apache est livré sous Solaris en legacy_run, c'est-à-dire en utilisant les anciens scripts dans /etc/init.d.
Voici le fichier /var/svc/manifest/network/apache.xml, qui décrit le service svc:/network/apache:default. J'y ai rajouté des commentaires en rouge.
<?xml version='1.0'?>
<!DOCTYPE service_bundle SYSTEM
'/usr/share/lib/xml/dtd/service_bundle.dtd.1'>
<!--
Thomas Lecomte, inspired from William Pool's SMF manifest for MySQL
Service manifest for Apache
-->
On précise le nom du service.
<service_bundle type='manifest' name='apache:apache'>
Ici, la catégorie du service ainsi que son nom et son type.
<service
name='network/apache'
version='1'>
<create_default_instance enabled='false' />
<single_instance />
On définit les dépendances du service.
grouping : relation de dépendance
-> require_all : toutes les dépendances doivent être online pour que le service démarre ;
-> require_any : au moins une des dépendances doit être online ;
-> exclude_all : aucune des dépendances ne doit être online ;
-> optionnal_all : elles peuvent être en mode online ou en mode maintenance.
restart_on : redémarrer le service lorsqu'un évenement a lieu sur la dépendance
-> none : le service ne sera pas redémarré ;
-> restart : le service sera relancé si la dépendance est relancée ;
-> refresh : le service sera relancé si la dépendance est relancée ou rafraichie ;
-> error : le service sera arrêté si la dépendance s'est arrêtée à cause d'une erreur.
Type : type de dépendance
-> service : la dépendance est sur un autre service géré par SMF ;
-> path : la dépendance est sur un fichier.
service_fmri : le FMRI du service dont notre service dépend.
<dependency name='fs'
grouping='require_all'
restart_on='none'
type='service'>
<service_fmri value='svc:/system/filesystem/local' />
</dependency>
<dependency name='net'
grouping='require_all'
restart_on='none'
type='service'>
<service_fmri value='svc:/network/loopback' />
</dependency>
<dependency name='config_file'
grouping='require_all'
restart_on='error'
type='path'>
<service_fmri value='file://localhost/etc/apache/httpd>conf' />
</dependency>
Ici, on définit les actions à faire pour arrêter, démarrer, et relancer le service.
type : On définit une méthode
name : L'action que l'on définit
exec : La commande à lancer
timeout_seconds : Le temps maximal à attendre pour l'exécution de la méthode
<exec_method
type='method'
name='start'
exec='/lib/svc/method/svc-apache start'
timeout_seconds='-1'>
</exec_method>
<exec_method
type='method'
name='stop'
exec='/lib/svc/method/svc-apache stop'
timeout_seconds='-1'>
<exec_method
type='method'
name='restart'
exec='/lib/svc/method/svc-apache restart'
timeout_seconds='-1'>
</exec_method>
</service>
</service_bundle>
Voici le script /lib/svc/method/svc-apache, qui est similaire à ceux trouvés dans /etc/init.d.
#!/usr/bin/sh
#
# Thomas Lecomte, inspired from William Pool's script
# SMF method file for Apache
#
. /lib/svc/share/smf_include.sh
case "$1" in
start)
/usr/apache/bin/apachectl start
;;
stop)
/usr/apache/bin/apachectl stop
;;
restart)
/usr/apache/bin/apachectl restart
;;
esac
Une fois ces fichiers créés, il faut ajouter le manifest. Il faut d'abord configurer les permissions :
# chown root:bin /lib/svc/method/svc-apache
# chmod 555 /lib/svc/method/svc-apache
# chown root:sys /var/svc/manifest/network/apache.xml
# chmod 444 /var/svc/manifest/network/apache.xml
Ensuite, on le valide à l'aide de la commande suivante, afin de vérifier qu'on ne s'est pas trompé :
# svccfg validate /var/svc/manifest/network/apache.xml
Puis on l'ajoute :
# svccfg import /var/svc/manifest/network/apache.xml
Et enfin, on actualise SMF :
# /lib/svc/method/manifest-import
Si tout s'est bien passé, vous devriez pouvoir voir le service avec la commande suivante :
# svcs apache
STATE STIME FMRI
disabled 19:11:10 svc:/network/apache:default
Et le démarrer :
# svcadm enable apache
# svcs apache
STATE STIME FMRI
enabled 19:11:23 svc:/network/apache:default
Voilà, normalement maintenant Apache tourne !
Les fichiers XML des services présents d'origine se trouvent dans /var/svc/manifest.
Si vous souhaitez les modifier, par exemple rajouter des dépendances, vous n'avez qu'à éditer
le fichier XML correspondant.
Quant à la syntaxe des fichiers, elle est bien entendu identique à celle du fichier ci-dessus.
Une fois le fichier modifié, il vous suffit de réimporter le manifest à l'aide des commandes suivantes :
# svccfg import /var/svc/manifest/votre_service_modifié.xml
# /lib/svc/method/manifest-import
Loaded 1 smf(5) service descriptions
Le service sera mis à jour et vos modifications seront donc prises en compte.
Afin d'éviter d'avoir à passer root pour gérer les services, il est possible d'utiliser le mécanisme de rôles présent dans Solaris 10. Il serait également possible d'utiliser sudo, mais c'est moins propre.
Afin d'autoriser un utilisateur à gérer les services, il suffit de rajouter la ligne suivante au fichier /etc/user_attr :
username::::profiles=Service Management
Vous avez maintenant le droit de manipuler les services, avec par exemple la commande svcadm.
C'en est terminé pour cette introduction à SMF ! J'espère que cet article vous aura aidé à tirer parti de cette fonctionnalité très puissante de Solaris !
Je remercie Julien Bendjou (joof) de m'avoir relu :-)
Voici aussi mes sources d'inspiration :
Dernière mise à jour de cette page : Dimanche 19 mars 2006. Version : 1.01
Écrit avec OpenOffice.org 2 et Mozilla Editor sous Solaris 10.
