xinetd − Le démon des services Internet

xinetd [options]

xinetd fournit les même fonctionalités que inetd : il démarre les programmes fournissant des services Internet. Au lieu de démarrer ces services au moment de l’initialisation du système, et de les laisser inactifs jusqu’à ce qu’il y ait une demande de connexion, on ne démarre que xinetd et celui ci écoute sur tous les ports nécessaires aux services listés dans ses fichiers de configuration. Lorsqu’une requête arrive, xinetd démarre le service correspondant. à cause de la façon dont il fonctionne, xinetd (comme inetd) est aussi appelé le super-serveur.

Les services listés dans les fichiers de configuration de xinetd peuvent être séparés en 2 groupes. Les services du premier groupe sont dit multi-threaded et ils nécessitent que le processus père crée un nouveau processus pour chaque nouvelle demande de connexion. Chaque processus gère alors une connexion. Pour de tels services, xinetd continue d’écouter pour prendre en charge de nouvelles demandes de connexions, et de lancer de nouveaux processus. D’un autre côté, le deuxième groupe est composé des services pour lesquels un seul démon prend en charge toute les nouvelles requêtes de connexion. De tels services sont appelés single-threaded et xinetd ne prendra plus en charge les requêtes destinées à ce serveur tant que le serveur sera en service. Les services de cette catégorie sont habituellement de type datagramme.

Jusqu’à présent, la seule raison de l’existence d’un super-serveur était de préserver les ressources système en évitant de créer de nombreux processus dont la plupart ne seront actifs que très peu de temps. Tout en remplissant ces fonctions, xinetd tire parti de l’idée du super-serveur pour ajouter des fonctionnalités telle que le contrôle d’accès et le logging. De plus, xinetd ne se restreint pas aux services listés dans le fichier /etc/services. Par conséquent, tous le monde peut utiliser xinetd pour démarrer des services personnalisés.

−d

Autorise le mode debug. Ceci produit de nombreuses informations de debugging, et permet d’utiliser un debugger sur xinetd.

−syslog option_syslog

Cette option permet de récupérer les messages produits par xinetd en utilisant les nombreuses options du démon syslog. Les possibilités suivantes sont supportées : daemon, auth, user, local[0-7] (voir syslog.conf(5) pour leur signification). Cette option est sans effet en mode debug, car tous les messages significatifs sont envoyés vers le terminal.

−filelog fichier_de_log

Les messages produits par xinetd seront placés dans le fichier spécifié. Les messages sont toujours ajoutés au fichier existant. Si le fichier n’existe pas , il sera créé. Cette option est sans effet en mode debug, car tous les messages significatifs sont envoyés vers le terminal.

−f fichier_de_config

Désigne le fichier de configuration utilisé par xinetd. Le fichier par défaut est /etc/xinetd.conf.

−pidfile fichier_pid

L’identificateur du processus est écrit dans ce fichier. Cette option est sans effet en mode debug.

−stayalive

Indique à xinetd de continuer à tourner même si aucun service n’est spécifié.

−loop taux

Cette option indique le taux de création de processus au delà duquel on considère qu’il y a une erreur et que le service est désactivé. Ce taux est défini en nombre de processus qui peuvent être créé en une seconde. Ce taux est déterminé par la puissance de votre machine. La valeur par défaut est 10.

−reuse

Si cette option est utilisée, xinetd va activer l’option de socket SO_REUSEADDR avant de donner une adresse IP à la socket du service. Ceci permet l’utilisation de l’adresse, même si celle ci est utilisée par d’autre programmes, ce qui arrive lorsqu’une instance précédente de xinetd a lancé des serveurs qui tournent toujours. Cette option n’a aucun effet sur les services RPC

−limit proc_limit

Cette option limite le nombre de processus concurrents qui peuvent être lancés par xinetd. Son utilité est d’éviter un débordement de la table des processus.

−logprocs limit

Cette option limite le nombre de processus concurrents pour l’acquisition d’userid à distance.

−shutdownprocs limit

Cette option limite le nombre de processus concurrents pour l’arrêt du service (forké lorsque l’option RECORD est utilisée).

−cc interval

Cette option indique à xinetd de faire des vérifications périodique sur son état interne toute les interval secondes.

Les options syslog et filelog sont mutuellemnt exclusives. Si aucune n’est spécifiée, la valeur par défaut est syslog et utilise l’option daemon. Il ne faut pas confondre les messages venant de xinetd avec les messages relatifs aux services de logging. Ces derniers sont loggués seulement si cela est spécifié dans les fichiers de configuration.

xinetd effectue certaines actions quand il reçoit certains signaux. Les actions associées avec des signaux spécifiques peuvent être redéfinies en éditant le fichier config.h et en recompilant.

SIGUSR2

génère une reconfiguration hard, ce qui signifie que xinetd relit le fichier de configuration et arrête les processus pour les services qui ne sont plus disponibles. Le contrôle d’accès est effectué à nouveau sur les services qui fonctionnent, en vérifiant l’adresse IP du client, les horaires d’accès et le nombre d’instances du service. Si le nombre de serveurs est diminué, certaines instances prises au hasard seront détruites afin de satisfaire la nouvelle limite ; cela sera effectué après que certaines instances soient arrêtées car elle ne satisfont plus aux nouvelles règle d’adressage ou de créneau horaire. De plus, si le flag INTERCEPT n’était pas mis et qu’il est mis, tous les processus de ce service seront arrétés ; La raison de cela est d’être certain qu’après une reconfiguration hard il n’y aura plus aucun processus qui puisse accepter des paquets venant d’une adresse qui est interdite par les nouveaux critères du contrôle d’accès.

SIGQUIT

termine le programme.

SIGTERM

termine tous les processus avant de tuer xinetd.

SIGHUP

génère un dump de l’état interne (le fichier par défaut est /var/run/xinetd.dump ; pour utiliser un autre fichier, il faut éditer config.h et recompiler).

SIGIOT

fait une vérification interne pour s’assurer que les structures de données utilisées par le programme n’ont pas été corrompues. Lorsque la vérification est terminée xinetd génère un message qui indique que la vérification est réussie ou non.

Lors d’une reconfiguration, les fichiers de log sont fermés et rouverts. Ceci permet de se débarrasser des vieux fichiers de log.

/etc/xinetd.conf

fichier de configuration par défaut

/var/run/xinetd.dump

fichier de dump par défaut

inetd(8),

xinetd.conf(5),

xinetd.log(5)

Panos Tsirigotis, CS Dept, University of Colorado, Boulder Rob Braun

Christophe Donnier (Octobre 2001)

zy-net-d