9.6. Le super-serveur inetd

9.6. Le super-serveur `inetd`

inetd (souvent appelé « super-serveur Internet ») est en réalité un serveur de serveurs, employé pour invoquer à la demande les serveurs rarement employés qui ne fonctionnent donc pas en permanence.

Le fichier /etc/inetd.conf donne la liste de ces serveurs et de leurs ports habituels, qu'inetd écoute tous ; dès qu'il détecte une connexion sur l'un d'entre eux, il exécute le programme du serveur correspondant.

DEBIAN POLICY Register a server in /etc/inetd.conf

Les paquets souhaiteraient parfois enregistrer un nouveau serveur dans le fichier /etc/inetd.conf, mais la charte Debian interdit à tout paquet de modifier un fichier de configuration qui ne relève pas de lui. C'est pourquoi le script update-inetd (du paquet éponyme) a été créé : il a à sa charge le fichier de configuration et les autres paquets peuvent ainsi l'employer pour demander au super-serveur de prendre en compte un nouveau serveur.

Chaque ligne significative du fichier /etc/inetd.conf décrit un service par sept champs (séparés par des blancs):

Le numéro du port TCP ou UDP, ou le nom du service (qui est associé à un numéro de port standard par la table de correspondance définie dans le fichier /etc/services).
Le type de socket : stream pour une connexion TCP, dgram pour des datagrammes UDP .
The protocol: tcp, tcp6, udp, or udp6.
Les options : deux valeurs sont possibles : wait ou nowait, pour signifier à inetd qu'il doit, ou non, attendre la fin du processus lancé avant d'accepter une autre connexion. Pour les connexions TCP, facilement multiplexables, on pourra généralement utiliser nowait. Pour les programmes répondant sur UDP, il ne faut retenir nowait que si le serveur est capable de gérer plusieurs connexions en parallèle. On pourra suffixer ce champ d'un point suivi du nombre maximum de connexions autorisées par minute (la limite par défaut étant de 256).
The user name of the user under whose identity the server will run. Optionally one can add the group too via user.group syntax.
Le chemin complet du programme serveur à exécuter.
Les arguments : il s'agit de la liste complète des arguments du programme, y compris son propre nom (argv[0] en C).

The following example illustrates some use-cases after installing talkd, nullidentd (ident-server), and fingerd:

Exemple 9.1. Extrait de /etc/inetd.conf

#:BSD: Shell, login, exec and talk are BSD protocols.
talk   dgram   udp     wait    nobody.tty   /usr/sbin/in.talkd      in.talkd
ntalk  dgram   udp     wait    nobody.tty   /usr/sbin/in.ntalkd     in.ntalkd

#:INFO: Info services
ident  stream  tcp     nowait  nobody       /usr/sbin/nullidentd    nullidentd
finger stream  tcp     nowait  nobody       /usr/sbin/tcpd          /usr/sbin/in.fingerd

The tcpd program is frequently used in the /etc/inetd.conf file. It allows limiting incoming connections by applying access control rules, documented in the hosts_access(5) manual page, and which are configured in the /etc/hosts.allow and /etc/hosts.deny files. Once it has been determined that the connection is authorized, tcpd executes the real server (like in.fingerd in our example). It is worth noting that tcpd relies on the name under which it was invoked (that is the first argument, argv[0]) to identify the real program to run. So you should not start the arguments list with tcpd but with the program that must be wrapped.

ALTERNATIVE Autres inetd

While Debian installs openbsd-inetd by default, there is no lack of alternatives: we can mention inetutils-inetd, rlinetd, and xinetd, which all provide the virtual package inet-superserver.

Most of these alternatives share the same configuration file /etc/inetd.conf.

This last incarnation of a super-server however, offers different syntax and very interesting possibilities. Most notably, its configuration can be split into several files (stored, of course, in the /etc/xinetd.d/ directory), which can make an administrator's life easier. It is considered to be more powerful, but also more complex.

Last but not least, it is even possible to emulate inetd's behavior with systemd's socket-activation mechanism (see Section 9.1.1, « Le système d'initialisation systemd »).