INETD(8) Administration du système FreeBSD
NOM
inetd - "super-serveur" internet
SYNOPSIS
inetd [-d] [-l] [-w] [-W] [-c maximum] [-C taux] [-a adresse] [-p
fichier] [-R taux] [fichier de configuration ]
DESCRIPTION
Le programme inetd est lancé lors du démarrage par /etc/rc (voir rc(8)). Il écoute le réseau pour détecter les connexions sur certaines sockets internet. Lorsqu'une connexion est trouvée, il détermine à quel service correspond cette socket et appelle le programme qui peut satisfaire la requète. Ce dernier est appelé avec le service de sockets et ses description d'entrée, sortie et erreur standard. Une fois le programme terminé, inetd poursuit son écoute (sauf dans quelques cas décrits plus loin). Essentiellement, inetd permet de faire tourner un démon pour en appeler plusieurs autres, réduisant ainsi la charge du système. Les option suivantes sont disponibles : -d Active le débogage. -l Active l'enregistrement des actions. -w Active le TCP Wraping pour les services externes. Voir les Notes d'implémentation pour plus d'informations sur ce support. -W Active le TCP Wraping pour les services internes, compilés dans inetd. -c maximum Définie le nombre maximum par défaut de services à appeler. Peut être remplacé suivant le service par le paramètre "maxchild". -C taux Définie le nombre maximum de fois qu'un service peut être appelé par minute depuis une même adresse IP. Illimité par défaut. Peut être remplacé suivant le service par le paramètre "max-connections-per-ip-per-minute". -R taux Définie la maximum de fois qu'un service peut être appelé par minite. 256 par défaut. -a Définie une adresse IP spécifique à laquelle se lier. -p Définie un autre fichier dans lequel enregistrer les identifiants des process. Lors de son exécution, inetd détermine sa configuration à partir d'un fichier qui, par défaut, est /etc/inetd.conf. Il doit y avoir une entrée pour chaque champ de configuration chacune séparée de la suivante par une tabulation ou un espace. Les commentaires sont précédés d'un "#" en début de ligne. Insistons : il doit y avoir une entrée pour chaque champ. Ces champs sont :
Le programme inetd est lancé lors du démarrage par /etc/rc (voir rc(8)). Il écoute le réseau pour détecter les connexions sur certaines sockets internet. Lorsqu'une connexion est trouvée, il détermine à quel service correspond cette socket et appelle le programme qui peut satisfaire la requète. Ce dernier est appelé avec le service de sockets et ses description d'entrée, sortie et erreur standard. Une fois le programme terminé, inetd poursuit son écoute (sauf dans quelques cas décrits plus loin). Essentiellement, inetd permet de faire tourner un démon pour en appeler plusieurs autres, réduisant ainsi la charge du système.
Les option suivantes sont disponibles :
-d
Active le débogage.
-l
Active l'enregistrement des actions.
-w
Active le TCP Wraping pour les services externes. Voir les Notes d'implémentation pour plus d'informations sur ce support.
-W
Active le TCP Wraping pour les services internes, compilés dans inetd.
-c maximum
Définie le nombre maximum par défaut de services à appeler. Peut être remplacé suivant le service par le paramètre "maxchild".
-C taux
Définie le nombre maximum de fois qu'un service peut être appelé par minute depuis une même adresse IP. Illimité par défaut. Peut être remplacé suivant le service par le paramètre "max-connections-per-ip-per-minute".
-R taux
Définie la maximum de fois qu'un service peut être appelé par minite. 256 par défaut.
-a
Définie une adresse IP spécifique à laquelle se lier.
-p
Définie un autre fichier dans lequel enregistrer les identifiants des process.
Lors de son exécution, inetd détermine sa configuration à partir d'un fichier qui, par défaut, est /etc/inetd.conf. Il doit y avoir une entrée pour chaque champ de configuration chacune séparée de la suivante par une tabulation ou un espace. Les commentaires sont précédés d'un "#" en début de ligne. Insistons : il doit y avoir une entrée pour chaque champ. Ces champs sont :
nom du service type de socket protocole {wait|nowait}[/max-child[/max-connections-per-ip-per-minute]] utilisateur [:groupe][/login-class] programme serveur arguments du programme serveur
Pour définir un service ONC RPC, l'entrée doit contenir ces champs :
nom du service /version type de socket rpc/protocole utilisateur [:groupe][/login-class] programme serveur arguments du programme serveur
inetd peut démarrer deux types de services : standard et TCPMUX. Un service standard est associé à un numéro de port déja connu et peut être un service Internet officiel ou spécifique à BSD. Comme le décrit RFC 1078, les services TCPMUX ne sont pas standards et n'ont pas de numéro de ports déja connus. Ils sont appelés par inetd lorsqu'un programme se connecte à un port "tcpmux" connu avec un nom de service. Cette caractéristique est utile dans le cas de serveurs spécifiques développés localement. Les requètes TCPMUX ne sont acceptées que lorsque le multiplexage est activé, au dessus et au delà des serveurs TCPMUX. Voir plus loin la discussion sur les services internes. nom du service est le nom du service valide tel qu'il apparait dans le fichier /etc/services. Pour les services "internes" (voir discussion plus loin), le nom du service doit être le nom officiel (c'est à dire la première entrée dans /etc/services). Pour les services ONC RPC, le nom est celui qui apparait dans le fichier /etc/rpc. La partie à droite du "/" est le numéro de version RPC, qui peut être un nombre ou un intervalle de versions. Un intervalle est déterminé par ses extrémités comme dans " rusers/1-3". Pour les services TCPMUX, le nom est composé de "tcpmux" suivi d'un "/" et du nom de service choisi localement. Les noms de services listés dans /etc/services ainsi que "help" sont réservés. Essayez de choisir les noms de vos services tcpmux en mettant avant le nom de votre entreprise et après un numéro de version. Le type de socket est au choix "stream'', "gram", "raw", "rdm" ou "seqpacket" suivant si le socket est par flux, datagramme, rangées, message expédié de façon fiable (reliably delivered message) ou bien par paquets séquentiels. Les services TCPMUX doivent utiliser "stream". Le protocole est le nom d'un protocole valide tel qu'il apparait dans le fichier /etc/protocols. Par exemple "tcp" ou "udp". Si le service doit être accessible par T/TCP, indiquez " tcp/ttcp". Les services rpc sont définis avec " rpc/tcp" ou " rpc/udp". Les services TCPMUX doivent utiliser "tcp". L'option wait/nowait indique si le serveur appelé par inetd prime sur le socket associé, et donc si inetd attend que le service quitte avant de se remettre à l'écoute des nouvelles requètes. Les serveurs datagramme doivent utiliser "wait" puisqu'ils sont toujours appelés avec le socket datagram original lié à l'adresse du service spécifié. Ces serveurs doivent lire au moins un datagramme du socket avant de quitter. Si un serveur datagramme se connecte au port, libérant le socket afin que inetd puisse en recevoire les messages suivants, il est dit "multi-threadé". Il peut lire un datagramme sur le socket et en créer un nouveau connecté au port. Il peut se scinder pour laisser le parent quitter et permettre à inetd de récupérer de nouvelles requètes et d'engendrer de nouveaux serveurs. Les serveurs qui ne traitent les datagrammes que sur un socket, et éventuellement quittent après un certain délais, sont dits "mono-threadés". Comsat(8), (biff(1)) et talkd(8) sont des exemple de ce dernier type de serveur. Tftpd(8) est un exemple de serveur multi-threadé. Les serveurs utilisant les sockets par flux (stream) sont généralement multi-threadés et utilisent l'option "nowait". Les demandes de connexions à ces services sont acceptées par inetd et celui-ci ne donne au serveur que ce qui vient du nouveau socket connecté au client de ce service. Tous les services par flux opèrent de cette manière. Ceux qui utilisent "nowait" démarrent avec le service d'écoute de socket et doivent accepter au moins une connexion avant de quitter. D'une manière générale, un tel serveur accepte et traite les requètes dans un certaint délais (time out). Les services TCPMUX doivent utiliser "nowait". Le nombre maximum de processus fils (ou "thread") d'un service "nowait" peut être explicitement donné en ajoutant un "/" suivi du nombre voulu au mot clé "nowait". Il n'y a normalement aucune limite (équivalent à /0). Sinon, lorsque le maximum est atteint, les connexions suivantes sont mises en attente jusqu'à la création d'un nouveau process fils. Cela marche aussi dans le cas du mode "nowait", bien qu'une valeur autre que un (par défaut) n'a pas de sens dans certains cas. Vous pouvez aussi indiquer le nombre maximum de connexions par minutes pour une adresse IP donnée en ajoutant un "/" suivi du nombre voulu. Une fois le maximum atteint, les connexions suivantes, de cette adresse IP, seront ignorées jusqu'à la fin de la minute. L'utilisateur est le nom de l'utilisateur pour lequel doit tourner le service. Cela permet de donner moins de permissions au serveur que celles de root. L'option groupe, séparée par ":", permet de spécifier un groupe différent de celui de cet utilisateur. L'option login-class, séparée par des "/", permet d'indiquer des classes de login autre que "deamon" utilisé par défaut. Le programme serveur est le chemin d'accès du programme exécuté par inetd lorsqu'une requète arrive sur son socket. Si inetd fournit ce service en interne, le chemin doit être "internal". Les arguments du programme serveur sont entrés comme les arguments habituels, en commençant par argv[0], qui est le nom du programme. Si le service est fournit en interne, le nom du service (et ses éventuels arguments) ou bien le mot "internal" doivent prendre la place de cette entrée. Actuellement, le seul service interne a demander des arguments est "auth". Sans eux, il retourne systématiquement " ERROR : HIDDEN-USER". Ceux disponibles sont les suivants : -r : Offre un réel service "auth", comme pour RFC 1413. Les flags suivants ne s'appliquent que dans ce cas. -f : Si le fichier .fakeid existe dans le répertoir personnel de l'utilisateur identifié, inscrit le nom trouvé dedans à la place du vrai nom d'utilisateur. -n : Si le fichier . noident existe dans le répertoir personnel de l'utilisateur identifié, retourne " ERROR : HIDDEN-USER" à la place. -o nom-de-système : Utilise nom-de-système à la place du nom du système d'exploitation retourné par uname(3). -t sec [.usec] : Spécifie un délais d'expiration du service. Par défaut, il vaut 10,0 secondes. Le programme inetd fournit aussi quelques services internes triviaux à partir de routines. Ces services sont "echo", "disgard", " chargen" (générateur de caractères), "daytime" (heure lisible) et "time" (heure lisible par la machine : nombre de secondes depuis le 1er janvier 1900 à minuit). Ils sont disponible à la fois pour TCP et UDP. La version UDP refusera le service si la requète demande un port de réponse correspondant à un service interne (ceci sert de défense contre les attaques en boucle; l'adresse IP du demandeur est enregistrée). Pour les détails sur ce service, voir le document RFC approprié. Le service de démultiplexage TCPMUX est aussi implémenté en interne. Pour mettre en marche les services TCPMUX, ajoutez la ligne suivante dans le fichier in inetd.conf : tcpmux stream tcp nowait root internal
inetd peut démarrer deux types de services : standard et TCPMUX. Un service standard est associé à un numéro de port déja connu et peut être un service Internet officiel ou spécifique à BSD. Comme le décrit RFC 1078, les services TCPMUX ne sont pas standards et n'ont pas de numéro de ports déja connus. Ils sont appelés par inetd lorsqu'un programme se connecte à un port "tcpmux" connu avec un nom de service. Cette caractéristique est utile dans le cas de serveurs spécifiques développés localement. Les requètes TCPMUX ne sont acceptées que lorsque le multiplexage est activé, au dessus et au delà des serveurs TCPMUX. Voir plus loin la discussion sur les services internes.
nom du service est le nom du service valide tel qu'il apparait dans le fichier /etc/services. Pour les services "internes" (voir discussion plus loin), le nom du service doit être le nom officiel (c'est à dire la première entrée dans /etc/services). Pour les services ONC RPC, le nom est celui qui apparait dans le fichier /etc/rpc. La partie à droite du "/" est le numéro de version RPC, qui peut être un nombre ou un intervalle de versions. Un intervalle est déterminé par ses extrémités comme dans " rusers/1-3". Pour les services TCPMUX, le nom est composé de "tcpmux" suivi d'un "/" et du nom de service choisi localement. Les noms de services listés dans /etc/services ainsi que "help" sont réservés. Essayez de choisir les noms de vos services tcpmux en mettant avant le nom de votre entreprise et après un numéro de version.
Le type de socket est au choix "stream'', "gram", "raw", "rdm" ou "seqpacket" suivant si le socket est par flux, datagramme, rangées, message expédié de façon fiable (reliably delivered message) ou bien par paquets séquentiels. Les services TCPMUX doivent utiliser "stream".
Le protocole est le nom d'un protocole valide tel qu'il apparait dans le fichier /etc/protocols. Par exemple "tcp" ou "udp". Si le service doit être accessible par T/TCP, indiquez " tcp/ttcp". Les services rpc sont définis avec " rpc/tcp" ou " rpc/udp". Les services TCPMUX doivent utiliser "tcp".
L'option wait/nowait indique si le serveur appelé par inetd prime sur le socket associé, et donc si inetd attend que le service quitte avant de se remettre à l'écoute des nouvelles requètes. Les serveurs datagramme doivent utiliser "wait" puisqu'ils sont toujours appelés avec le socket datagram original lié à l'adresse du service spécifié. Ces serveurs doivent lire au moins un datagramme du socket avant de quitter. Si un serveur datagramme se connecte au port, libérant le socket afin que inetd puisse en recevoire les messages suivants, il est dit "multi-threadé". Il peut lire un datagramme sur le socket et en créer un nouveau connecté au port. Il peut se scinder pour laisser le parent quitter et permettre à inetd de récupérer de nouvelles requètes et d'engendrer de nouveaux serveurs. Les serveurs qui ne traitent les datagrammes que sur un socket, et éventuellement quittent après un certain délais, sont dits "mono-threadés". Comsat(8), (biff(1)) et talkd(8) sont des exemple de ce dernier type de serveur. Tftpd(8) est un exemple de serveur multi-threadé.
Les serveurs utilisant les sockets par flux (stream) sont généralement multi-threadés et utilisent l'option "nowait". Les demandes de connexions à ces services sont acceptées par inetd et celui-ci ne donne au serveur que ce qui vient du nouveau socket connecté au client de ce service. Tous les services par flux opèrent de cette manière. Ceux qui utilisent "nowait" démarrent avec le service d'écoute de socket et doivent accepter au moins une connexion avant de quitter. D'une manière générale, un tel serveur accepte et traite les requètes dans un certaint délais (time out). Les services TCPMUX doivent utiliser "nowait".
Le nombre maximum de processus fils (ou "thread") d'un service "nowait" peut être explicitement donné en ajoutant un "/" suivi du nombre voulu au mot clé "nowait". Il n'y a normalement aucune limite (équivalent à /0). Sinon, lorsque le maximum est atteint, les connexions suivantes sont mises en attente jusqu'à la création d'un nouveau process fils. Cela marche aussi dans le cas du mode "nowait", bien qu'une valeur autre que un (par défaut) n'a pas de sens dans certains cas. Vous pouvez aussi indiquer le nombre maximum de connexions par minutes pour une adresse IP donnée en ajoutant un "/" suivi du nombre voulu. Une fois le maximum atteint, les connexions suivantes, de cette adresse IP, seront ignorées jusqu'à la fin de la minute.
L'utilisateur est le nom de l'utilisateur pour lequel doit tourner le service. Cela permet de donner moins de permissions au serveur que celles de root. L'option groupe, séparée par ":", permet de spécifier un groupe différent de celui de cet utilisateur. L'option login-class, séparée par des "/", permet d'indiquer des classes de login autre que "deamon" utilisé par défaut.
Le programme serveur est le chemin d'accès du programme exécuté par inetd lorsqu'une requète arrive sur son socket. Si inetd fournit ce service en interne, le chemin doit être "internal".
Les arguments du programme serveur sont entrés comme les arguments habituels, en commençant par argv[0], qui est le nom du programme. Si le service est fournit en interne, le nom du service (et ses éventuels arguments) ou bien le mot "internal" doivent prendre la place de cette entrée.
Actuellement, le seul service interne a demander des arguments est "auth". Sans eux, il retourne systématiquement " ERROR : HIDDEN-USER". Ceux disponibles sont les suivants :
-r : Offre un réel service "auth", comme pour RFC 1413. Les flags suivants ne s'appliquent que dans ce cas. -f : Si le fichier .fakeid existe dans le répertoir personnel de l'utilisateur identifié, inscrit le nom trouvé dedans à la place du vrai nom d'utilisateur. -n : Si le fichier . noident existe dans le répertoir personnel de l'utilisateur identifié, retourne " ERROR : HIDDEN-USER" à la place. -o nom-de-système : Utilise nom-de-système à la place du nom du système d'exploitation retourné par uname(3). -t sec [.usec] : Spécifie un délais d'expiration du service. Par défaut, il vaut 10,0 secondes.
-r : Offre un réel service "auth", comme pour RFC 1413. Les flags suivants ne s'appliquent que dans ce cas.
-f : Si le fichier .fakeid existe dans le répertoir personnel de l'utilisateur identifié, inscrit le nom trouvé dedans à la place du vrai nom d'utilisateur.
-n : Si le fichier . noident existe dans le répertoir personnel de l'utilisateur identifié, retourne " ERROR : HIDDEN-USER" à la place.
-o nom-de-système : Utilise nom-de-système à la place du nom du système d'exploitation retourné par uname(3).
-t sec [.usec] : Spécifie un délais d'expiration du service. Par défaut, il vaut 10,0 secondes.
Le programme inetd fournit aussi quelques services internes triviaux à partir de routines. Ces services sont "echo", "disgard", " chargen" (générateur de caractères), "daytime" (heure lisible) et "time" (heure lisible par la machine : nombre de secondes depuis le 1er janvier 1900 à minuit). Ils sont disponible à la fois pour TCP et UDP. La version UDP refusera le service si la requète demande un port de réponse correspondant à un service interne (ceci sert de défense contre les attaques en boucle; l'adresse IP du demandeur est enregistrée). Pour les détails sur ce service, voir le document RFC approprié.
Le service de démultiplexage TCPMUX est aussi implémenté en interne. Pour mettre en marche les services TCPMUX, ajoutez la ligne suivante dans le fichier in inetd.conf :
tcpmux stream tcp nowait root internal
Lorsque l'option -l est donnée, inetd écrit dans syslog, chaque fois qu'une connexion est acceptée, le service demandé ainsi que l'adresse IP du demandeur, si elle est disponible. Le programme inetd relit son fichier de configuration quand il reçoit le signal de racrochement, SIGHUP. Des services peuvent être ajoutés, enlevés ou modifiés lorsque le fichier de configuration est relu. A part quand il est lancé en mode débogage, inetd enregistre son identifiant de process dans le fichier /var/run/inetd.pid pour aider sa reconfiguration.
Lorsque l'option -l est donnée, inetd écrit dans syslog, chaque fois qu'une connexion est acceptée, le service demandé ainsi que l'adresse IP du demandeur, si elle est disponible.
Le programme inetd relit son fichier de configuration quand il reçoit le signal de racrochement, SIGHUP. Des services peuvent être ajoutés, enlevés ou modifiés lorsque le fichier de configuration est relu. A part quand il est lancé en mode débogage, inetd enregistre son identifiant de process dans le fichier /var/run/inetd.pid pour aider sa reconfiguration.
NOTES D'IMPLEMENTATION
Lorsque l'option -w est donnée, inetd passe tous les services spécifiés en "stream nowait" ou "dgram", sauf les services internes. Si l'option -W est donnée, les services internes spécifiés sont passés. Si les deux options sont données, les services internes et externes seront passés. Si l'opion -l est spécifiée, toute connexion demandée est enregistrée, qu'elle soit permise, défendue ou couverte (wrapped). Sinon, seules les requètes défendues sont enregistrées. Notez que inetd couvre seulement les requètes de services "wait" tant qu'aucun serveur ne peut répondre. Une fois que la connexion est acceptée, inetd n'a plus de contrôle sur les connexions au services qui suivent jusqu'à ce qu'il ne reste plus de serveurs pour répondre aux requètes. Lorsque la couverture (wrapping) est activée, le démon tcpd n'est pas utile puisque la fonctionnalité est intrinsèque. Pour plus d'informations sur les TCP Wrappers, reportez-vous à hosts_access(5). Gardez à l'esprit que les services internes n'ont pas de noms de démon. C'est celui défini dans inetd.conf qui est utilisé.
Lorsque l'option -w est donnée, inetd passe tous les services spécifiés en "stream nowait" ou "dgram", sauf les services internes. Si l'option -W est donnée, les services internes spécifiés sont passés. Si les deux options sont données, les services internes et externes seront passés.
Si l'opion -l est spécifiée, toute connexion demandée est enregistrée, qu'elle soit permise, défendue ou couverte (wrapped). Sinon, seules les requètes défendues sont enregistrées.
Notez que inetd couvre seulement les requètes de services "wait" tant qu'aucun serveur ne peut répondre. Une fois que la connexion est acceptée, inetd n'a plus de contrôle sur les connexions au services qui suivent jusqu'à ce qu'il ne reste plus de serveurs pour répondre aux requètes.
Lorsque la couverture (wrapping) est activée, le démon tcpd n'est pas utile puisque la fonctionnalité est intrinsèque. Pour plus d'informations sur les TCP Wrappers, reportez-vous à hosts_access(5). Gardez à l'esprit que les services internes n'ont pas de noms de démon. C'est celui défini dans inetd.conf qui est utilisé.
TCPMUX
Le RFC 1078 décrit le protocole TCPMUX : "Un client TCP se connecte à une machine étrangère sur le port 1. Il envoie le nom du service suivi d'un retour chariot-saut de ligne <CRLF>. La casse du nom n'importe pas. Le serveur répond avec un caractère d'acceptation posifif (+) ou négatif (-) immédiatement suivi d'une éventuelle explication, terminée par <CRLF>. Si la réponse était positive, le protocole voulu démarre sinon la connexion est fermée." Le programme reçoit la connexion TCP comme les descripteurs de fichiers 0 et 1. Si le nom du service TCPMUX commence par un "+", inetd envoie une réponse positive au programme. Cela vous permet d'appeler un programme utilisant stdin/stdout sans avoir à spécialement lui donner un code. Le nom "help" est réservé à inetd, il lui permet de lister les services TCPMUX de inetd.conf.
Le RFC 1078 décrit le protocole TCPMUX : "Un client TCP se connecte à une machine étrangère sur le port 1. Il envoie le nom du service suivi d'un retour chariot-saut de ligne <CRLF>. La casse du nom n'importe pas. Le serveur répond avec un caractère d'acceptation posifif (+) ou négatif (-) immédiatement suivi d'une éventuelle explication, terminée par <CRLF>. Si la réponse était positive, le protocole voulu démarre sinon la connexion est fermée." Le programme reçoit la connexion TCP comme les descripteurs de fichiers 0 et 1.
Si le nom du service TCPMUX commence par un "+", inetd envoie une réponse positive au programme. Cela vous permet d'appeler un programme utilisant stdin/stdout sans avoir à spécialement lui donner un code.
Le nom "help" est réservé à inetd, il lui permet de lister les services TCPMUX de inetd.conf.
FICHIERS
/etc/inetd.conf fichier de configuration. /etc/rpc correspondance entre noms de service et numéros RPC. /etc/services correspondance entre noms de service et numéros de port. /var/run/inetd.pid l'identifiant du process actuel d'inetd.
EXEMPLES
Voici quelques exemple de services de divers types :
ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l ntalk dgram udp wait root /usr/libexec/ntalkd ntalkd tcpmux/+date stream tcp nowait guest /bin/date date tcpmux/phonebook stream tcp nowait guest /usr/local/bin/phonebook phonebook rstatd/1-3 dgram rpc/udp wait root /usr/libexec/rpc.rstatd rpc.rstatd
MESSAGES D'ERREUR
Le serveur inetd enregistre les messages d'erreurs avec syslog(3). Les principaux messages d'erreurs et leur explication sont : protocol /service server failing (looping), service terminated. Le nombre de requètes pour le service a été dépassé durant la dernière minute. Cette limite existe pour éviter une panne du programme ou pour empècher un utilisateur malicieux de submerger le système. Ce message d'erreur apparait pour plusieurs raisons : 1. Beaucoup d'utilisateur demandent le service durant la même courte période. 2. Un programme client planté demande le service trop fréquemment. 3. Un utilisateur malintentionné fait tourner un programme qui appelle le service afin de le faire planter. 4. Le service demandé a une erreur qui fait que le client ré-essaie aussitôt. Utilisez l'option -R taux, comme décrit plus haut, pour changer la limite. Une fois celle-ci atteinte, le service sera réactivé automatiquement dans les 10 minutes. service/protocol: No such user utilisateur, service ignored service/protocol: getpwnam: user: No such user Aucune référence à l'utilisateur n'existe dans la base de données passwd(5). Le premier message apparait lorsqu'inetd (re)lit son fichier de configuration, le second lorsque le service est appelé. service: can't set uid uid service: can't set gid gid L'identifiant de l'utilisateur ou du groupe dans le champ utilisateur est invalide. setsockopt(SO_PRIVSTATE): Operation not supported Le programme inetd a tenté de renoncer aux privilèges associés à un socket mais n'a pas réussi.
Le serveur inetd enregistre les messages d'erreurs avec syslog(3). Les principaux messages d'erreurs et leur explication sont :
protocol /service server failing (looping), service terminated.
Le nombre de requètes pour le service a été dépassé durant la dernière minute. Cette limite existe pour éviter une panne du programme ou pour empècher un utilisateur malicieux de submerger le système. Ce message d'erreur apparait pour plusieurs raisons : 1. Beaucoup d'utilisateur demandent le service durant la même courte période. 2. Un programme client planté demande le service trop fréquemment. 3. Un utilisateur malintentionné fait tourner un programme qui appelle le service afin de le faire planter. 4. Le service demandé a une erreur qui fait que le client ré-essaie aussitôt. Utilisez l'option -R taux, comme décrit plus haut, pour changer la limite. Une fois celle-ci atteinte, le service sera réactivé automatiquement dans les 10 minutes.
Le nombre de requètes pour le service a été dépassé durant la dernière minute. Cette limite existe pour éviter une panne du programme ou pour empècher un utilisateur malicieux de submerger le système. Ce message d'erreur apparait pour plusieurs raisons :
1. Beaucoup d'utilisateur demandent le service durant la même courte période.
2. Un programme client planté demande le service trop fréquemment.
3. Un utilisateur malintentionné fait tourner un programme qui appelle le service afin de le faire planter.
4. Le service demandé a une erreur qui fait que le client ré-essaie aussitôt.
Utilisez l'option -R taux, comme décrit plus haut, pour changer la limite. Une fois celle-ci atteinte, le service sera réactivé automatiquement dans les 10 minutes.
service/protocol: No such user utilisateur, service ignored
service/protocol: getpwnam: user: No such user
Aucune référence à l'utilisateur n'existe dans la base de données passwd(5). Le premier message apparait lorsqu'inetd (re)lit son fichier de configuration, le second lorsque le service est appelé.
service: can't set uid uid
service: can't set gid gid
L'identifiant de l'utilisateur ou du groupe dans le champ utilisateur est invalide.
setsockopt(SO_PRIVSTATE): Operation not supported
Le programme inetd a tenté de renoncer aux privilèges associés à un socket mais n'a pas réussi.
VOIR AUSSI
hosts_access(5), hosts_options(5), login.conf(5), passwd(5), rpc(5), services(5), comsat(8), fingerd(8), ftpd(8), portmap(8), rexecd(8), rlogind(8), rshd(8), telnetd(8), tftpd(8)
Identification Protocol, RFC1413 de Michael C. St. Johns
HISTORIQUE
La commande inetd apparait dans BSD 4.3. TCPMUX est basé sur le code et la documentation de Mark Lottor. Le support des services ONC RPC a été mis en place après avoir été fourni par SUNOS 4.1. Le support des TCP Wrappers est apparu avec FreeBSD 3.2.
7 février 1996
Traduction française le 15 mai 2000 par Guillain Seuillot <Guillain@lycosmail.com>