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.
OPTIONS
-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
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.
CONTR??LER XINETD
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.
FICHIERS
/etc/xinetd.conf
fichier de configuration par d??faut
/var/run/xinetd.dump
fichier de dump par d??faut
VOIR AUSSI
"inetd(8)," "xinetd.conf(5)," "xinetd.log(5)"
AUTEUR
Panos Tsirigotis, CS Dept, University of Colorado, Boulder
Rob Braun
