Personnellement, j'ai toujours entendu "Keep it simple and stupid!". je pense que la traduction anglaise de "fais un truc stupidement simple" serait plutôt "Keep it stupidly simple".
Quoiqu'il en soit, d'après Wikipedia, il semble que plusieurs significations de cet acronyme soient possibles, y compris celle donnée par l'auteur de ce journal : http://en.wikipedia.org/wiki/KISS_principle
A l'époque où l'outil a été créé, le XML était très en vogue et les mêmes qui disent "Aïe" dès qu'on parle de XML auraient approuvés à l'époque en disant "si tu veux un truc portable et simple, choisis du XML".
J'avais aussi à l'idée de faire une interface graphique à mon outil qui aurait pu modifier le XML facilement. Encore une fois à l'époque c'était un choix pertinent.
En tout cas, on peut débattre très longtemps sur le choix d'un format de fichier, mais je préfère largement voir ça :
define host {
address X.X.X.X
host_name monserveur
alias monserveur
use generic-host
}
Pas sûr qu'en YAML ça soit mieux.
Enfin je préfère le choix d'un fichier de conf sur fichier plutôt que d'une conf en base ou par du LDAP qui oblige à installer des outils tiers et à maintenir des services.
Le fichier, pour de la configuration, c'est bien. Ca se lit facilement, ça se modifie facilement, ça se partage facilement avec du NFS, ça se backup facilement.
Nous utilisons Nagios dans notre entreprise et c'est vrai que la configuration imposée par Nagios est assez horrible. Pour environ 1000 services, nous avions plus de 10 000 lignes de configuration !
C'est pourquoi, j'avais réfléchi à l'époque à un système pour simplifier la configuration et j'ai fini par développé un générateur de configuration pour Nagios. L'idée est de prendre un fichier XML en entrée et de sortir une config pour nagios.
L'avantage de mon fichier est l'ajout d'une notion assez puissante : les listes de services. En gros, je créé des listes de services qui contiennent plusieurs services, puis j'utilise ces listes dans la déclaration des "hosts". Comme nous avons généralement les mêmes profiles de serveurs, la définition d'une liste de service par profile de serveur est très pratique.
J'ai tout de même laissé la possibilité de redéfinir au sein de chaque "host" les services qu'il contient de manière individuel.
Ensuite, pour la génération c'est pareil, je peux ne générer la conf que pour une partie des serveurs ou des services.
Grâce à cela, nous sommes passé de 10 000 lignes de conf à environ 2 000. Et encore, dans ces 2 000 lignes, il y en a une grande partie qui ne bougent jamais.
Je partage donc l'idée de reféfinir la configuration de Nagios si tu te lance dans un projet comme celui-ci et je pense qu'intégrer la notion de "profiles" serait une bonne chose.
Chose amusante, le générateur de configuration est lui aussi en python :)
En général, à moins de geler la base, il n'y a aucun moyen de savoir si les fichiers de base sont cohérents au moment du snapshot. La restauration du snapshot peut donc entraîner une corruption de la base.
Quel système de fichier utilises-tu sur ta partition où sont stockés tes mails ?
J'ai déjà vu un thunderbird mal fonctionner car le fichier contenant les mails s'approchait de la limite des 4Go imposée par le FAT32.
C'est étonnant qu'avec 8000 mails tu y sois arrivé, mais si tu as des grosses pièces jointes, ce n'est pas impossible.
[^] # Re: « KISS » ("Keep it simple, Stupid!")
Posté par Florian . En réponse à la dépêche WebMotion, un nouveau framework web libre en Java. Évalué à 4.
Personnellement, j'ai toujours entendu "Keep it simple and stupid!". je pense que la traduction anglaise de "fais un truc stupidement simple" serait plutôt "Keep it stupidly simple".
Quoiqu'il en soit, d'après Wikipedia, il semble que plusieurs significations de cet acronyme soient possibles, y compris celle donnée par l'auteur de ce journal : http://en.wikipedia.org/wiki/KISS_principle
[^] # Re: Vachement gore
Posté par Florian . En réponse au journal Nagios va-t-il quitter le C pour le Python?. Évalué à 6.
J'avais aussi à l'idée de faire une interface graphique à mon outil qui aurait pu modifier le XML facilement. Encore une fois à l'époque c'était un choix pertinent.
En tout cas, on peut débattre très longtemps sur le choix d'un format de fichier, mais je préfère largement voir ça :
<host name="monserveur" services-list="unix-www" ip="X.X.X.X" />
Plutôt que ça :
define host {
address X.X.X.X
host_name monserveur
alias monserveur
use generic-host
}
Pas sûr qu'en YAML ça soit mieux.
Enfin je préfère le choix d'un fichier de conf sur fichier plutôt que d'une conf en base ou par du LDAP qui oblige à installer des outils tiers et à maintenir des services.
Le fichier, pour de la configuration, c'est bien. Ca se lit facilement, ça se modifie facilement, ça se partage facilement avec du NFS, ça se backup facilement.
[^] # Re: Vachement gore
Posté par Florian . En réponse au journal Nagios va-t-il quitter le C pour le Python?. Évalué à 2.
C'est pourquoi, j'avais réfléchi à l'époque à un système pour simplifier la configuration et j'ai fini par développé un générateur de configuration pour Nagios. L'idée est de prendre un fichier XML en entrée et de sortir une config pour nagios.
L'avantage de mon fichier est l'ajout d'une notion assez puissante : les listes de services. En gros, je créé des listes de services qui contiennent plusieurs services, puis j'utilise ces listes dans la déclaration des "hosts". Comme nous avons généralement les mêmes profiles de serveurs, la définition d'une liste de service par profile de serveur est très pratique.
J'ai tout de même laissé la possibilité de redéfinir au sein de chaque "host" les services qu'il contient de manière individuel.
Ensuite, pour la génération c'est pareil, je peux ne générer la conf que pour une partie des serveurs ou des services.
Grâce à cela, nous sommes passé de 10 000 lignes de conf à environ 2 000. Et encore, dans ces 2 000 lignes, il y en a une grande partie qui ne bougent jamais.
Je partage donc l'idée de reféfinir la configuration de Nagios si tu te lance dans un projet comme celui-ci et je pense qu'intégrer la notion de "profiles" serait une bonne chose.
Chose amusante, le générateur de configuration est lui aussi en python :)
# Cas des bases de données
Posté par Florian . En réponse au journal Btrfs : idées d'application des snapshots inscriptibles. Évalué à 2.
En général, à moins de geler la base, il n'y a aucun moyen de savoir si les fichiers de base sont cohérents au moment du snapshot. La restauration du snapshot peut donc entraîner une corruption de la base.
Btrfs apporte-t-il une solution à ce problème ?
# Fat32 ?
Posté par Florian . En réponse au message Comment perd t-on tous ses mails grace a Thunderbird. Évalué à 3.
J'ai déjà vu un thunderbird mal fonctionner car le fichier contenant les mails s'approchait de la limite des 4Go imposée par le FAT32.
C'est étonnant qu'avec 8000 mails tu y sois arrivé, mais si tu as des grosses pièces jointes, ce n'est pas impossible.