> Pour inetd/xinetd, c'est vrai (en tout cas sur la Woody).
Je parle bien de la woody.
> Pour ce qui est de logrotate: faux problème, il est désormais installé.
Comme pour xinetd, il est installé, mais pas utilisé. En particulier pour tout ce qui concerne syslog (ce qui fait la majorité des fichiers de logs générés chez moi), c'est traité par des scripts dont certains sont vraiment douteux.
Pourquoi ne pas utiliser ces outils qui existent depuis longtemps et qui ont fait leurs preuves?
> Pour ce qui est des runlevels: précise, je n'y décèle pas de problème.
Il n'y a pas de vrai problème, c'est juste que suivant la politique debian (ca a ete decidé comme ca alors on voit pas pourquoi changer), les runlevels 2345 ont la meme utilité. Pourtant sur la grande majorité des un*x, le 2 est un multi-user sans reseau, 3 avec reseau, et le 5 avec une interface graphique en plus.
D'une part, qd on est habitué ca perturbe (mais je suis douillet :)), d'autre part, ce sont des recommandations qui sont ds la LSB, et finalement c'est sympa de ne pas aller ds /etc/rc?.d si on veut passer de 3 a 5 par ex.
Une des raisons (la plus valable d'apres moi) pour ce schema, c'est que l'utilisateur fait ce qu'il veut (*), mais si je fais les modifs necessaires et que j'ai a upgrader un package ou en installer un nouveau, il faut ensuite que je refasse le boulot.
(*) Une idée maitresse de la politique Debian, dont l'origine doit etre une absence totale de concensus lors des choix de config par défaut, et qui conduit en général à des valeurs absurdes, suivies de la petite note: "L'utilisateur fera comme il lui plait".
> Pour chkconfig, je ne connais pas. La merde infame, c'est update-rc.d? Si oui, je suis assez d'accord maintenant quand je désactive un service temporairement, ce qui ne se pratique pas tous les jours, on peut aussi faire un "service stop", non?
yep. Mais des fois du veut desactiver un service pendant une periode plus longue (les vacances par exemple), sans avoir le risque de le redémarrer si ta machine doit rebooter (coupure de courant pendant la nuit depassant le temps autorisé par l'onduleur - ca arrive presque jamais, mais faut prevoir).
> sur un serveur tu rebootes rarement et tu devrais contrôler au delà d'une couleur rouge ou verte.
Sauf qd tu es persuadé que tout fonctionne bien au moment ou tu reboot (ca m'est arrivé une ou 2 fois cette année, et c'est incroyable ce que ca fait gagner comme temps :)).
> Les points soulevés ne sont que des détails,
Oui.
Enfin, pour ldap en root, xinetd et logrotate c'est plus que du detail pour moi. Ce sont des outils qui existent depuis longtemps et qui facilitent enormement l'administration d'un serveur. Qd j'ai proposé mon aide sur la liste debian-devel on m'a envoyé bouler...
Sinon je suis d'accord avec toi (d'ailleurs j'ai gardé un serveur sous Debian et j'essaie de m'adapter :)).
[^] # Re: La prochaine version stable de Debian pour décembre ?
Posté par Patrice Fortier . En réponse à la dépêche La prochaine version stable de Debian pour décembre ?. Évalué à 4.
Je parle bien de la woody.
> Pour ce qui est de logrotate: faux problème, il est désormais installé.
Comme pour xinetd, il est installé, mais pas utilisé. En particulier pour tout ce qui concerne syslog (ce qui fait la majorité des fichiers de logs générés chez moi), c'est traité par des scripts dont certains sont vraiment douteux.
Pourquoi ne pas utiliser ces outils qui existent depuis longtemps et qui ont fait leurs preuves?
> Pour ce qui est des runlevels: précise, je n'y décèle pas de problème.
Il n'y a pas de vrai problème, c'est juste que suivant la politique debian (ca a ete decidé comme ca alors on voit pas pourquoi changer), les runlevels 2345 ont la meme utilité. Pourtant sur la grande majorité des un*x, le 2 est un multi-user sans reseau, 3 avec reseau, et le 5 avec une interface graphique en plus.
D'une part, qd on est habitué ca perturbe (mais je suis douillet :)), d'autre part, ce sont des recommandations qui sont ds la LSB, et finalement c'est sympa de ne pas aller ds /etc/rc?.d si on veut passer de 3 a 5 par ex.
Une des raisons (la plus valable d'apres moi) pour ce schema, c'est que l'utilisateur fait ce qu'il veut (*), mais si je fais les modifs necessaires et que j'ai a upgrader un package ou en installer un nouveau, il faut ensuite que je refasse le boulot.
(*) Une idée maitresse de la politique Debian, dont l'origine doit etre une absence totale de concensus lors des choix de config par défaut, et qui conduit en général à des valeurs absurdes, suivies de la petite note: "L'utilisateur fera comme il lui plait".
> Pour chkconfig, je ne connais pas. La merde infame, c'est update-rc.d? Si oui, je suis assez d'accord maintenant quand je désactive un service temporairement, ce qui ne se pratique pas tous les jours, on peut aussi faire un "service stop", non?
yep. Mais des fois du veut desactiver un service pendant une periode plus longue (les vacances par exemple), sans avoir le risque de le redémarrer si ta machine doit rebooter (coupure de courant pendant la nuit depassant le temps autorisé par l'onduleur - ca arrive presque jamais, mais faut prevoir).
> sur un serveur tu rebootes rarement et tu devrais contrôler au delà d'une couleur rouge ou verte.
Sauf qd tu es persuadé que tout fonctionne bien au moment ou tu reboot (ca m'est arrivé une ou 2 fois cette année, et c'est incroyable ce que ca fait gagner comme temps :)).
> Les points soulevés ne sont que des détails,
Oui.
Enfin, pour ldap en root, xinetd et logrotate c'est plus que du detail pour moi. Ce sont des outils qui existent depuis longtemps et qui facilitent enormement l'administration d'un serveur. Qd j'ai proposé mon aide sur la liste debian-devel on m'a envoyé bouler...
Sinon je suis d'accord avec toi (d'ailleurs j'ai gardé un serveur sous Debian et j'essaie de m'adapter :)).