Ça a l'avantage de la simplicité, mais si on veut un truc un peu mieux intégré dans le réseau, il faudra passer par autre chose.
Quand tu dis mieux intégré, tu as des exemples?
Je sais que via un socket on peut récupérer pas mal d'informations, mais la plupart c'est via des sockets de type UNIX, me semble qu'on peut les transférer d'une machine à une autre via des tunnels mais... jamais essayé encore.
ce type de fonctionnement est présenté dans systemd comme une « révolution »
Je le sais, mais je pense que systemd est un projet qui vise à implémenter tout un environnement spécifique au noyau linux pour gérer la totalité du système.
inetd n'est pas le seul daemon qu'ils ont ré-implémenté en appelant ça une révolution: syslogd & consorts, crond, ... je ne vois plus systemd comme un ensemble de logiciels mais comme une framework.
Avis personnel: les framework, c'est bien pour le jetable, dès qu'on veut maintenir un truc sur plus de 5 ans, utiliser des lib permets de n'avoir à remplacer qu'un seul composant le jour ou il y a un problème.
Pour moi c'est en priorité pour le simplicité de stdin/stdout, cf. plus haut, c'est tout.
À la lumière d'une autre de tes réponses, cette phrase m'intrigue.
La réponse en question dit:
Si ton service est Unix standard, il utilise syslog. Forcément, si tu parles de l'avantage du logging pour palier son manque dû à des applis Web codées par des dev modernes...
Si ma mémoire est bonne, syslogd nécessite une connexion sur un socket pour récupérer les logs, et non sur l'entrée standard.
Si le but est la simplicité, l'idée de logguer dans stdout plutôt que dans un socket avec le protocole syslog n'est-elle pas bonne? Après tout, un admin peut toujours utiliser des trucs comme svlogd pour ensuite récupérer ces logs?
D'ailleurs, est-ce vraiment une obligation d'utiliser syslog pour un outil UNIX standard? Si je me souviens bien, la philosophie d'UNIX, c'est de toujours balancer du texte sur les entrées et sorties standard, et pour le coup, je trouve que syslogd y déroge, mais bon, ce n'est pas mon domaine, je dois rater un truc (centraliser les logs dans un daemon permets peut-être un filtrage plus efficace, je ne sais pas).
[^] # Re: L’avenir et le passé
Posté par freem . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 3.
Quand tu dis mieux intégré, tu as des exemples?
Je sais que via un socket on peut récupérer pas mal d'informations, mais la plupart c'est via des sockets de type UNIX, me semble qu'on peut les transférer d'une machine à une autre via des tunnels mais... jamais essayé encore.
Je le sais, mais je pense que systemd est un projet qui vise à implémenter tout un environnement spécifique au noyau linux pour gérer la totalité du système.
inetd n'est pas le seul daemon qu'ils ont ré-implémenté en appelant ça une révolution: syslogd & consorts, crond, ... je ne vois plus systemd comme un ensemble de logiciels mais comme une framework.
Avis personnel: les framework, c'est bien pour le jetable, dès qu'on veut maintenir un truc sur plus de 5 ans, utiliser des lib permets de n'avoir à remplacer qu'un seul composant le jour ou il y a un problème.
À la lumière d'une autre de tes réponses, cette phrase m'intrigue.
La réponse en question dit:
Si ma mémoire est bonne, syslogd nécessite une connexion sur un socket pour récupérer les logs, et non sur l'entrée standard.
Si le but est la simplicité, l'idée de logguer dans stdout plutôt que dans un socket avec le protocole syslog n'est-elle pas bonne? Après tout, un admin peut toujours utiliser des trucs comme svlogd pour ensuite récupérer ces logs?
D'ailleurs, est-ce vraiment une obligation d'utiliser syslog pour un outil UNIX standard? Si je me souviens bien, la philosophie d'UNIX, c'est de toujours balancer du texte sur les entrées et sorties standard, et pour le coup, je trouve que syslogd y déroge, mais bon, ce n'est pas mon domaine, je dois rater un truc (centraliser les logs dans un daemon permets peut-être un filtrage plus efficace, je ne sais pas).