> c'est comme si le client web recevait les pages brutes et exécutait les scripts (genre je me connecte à la base de données, on voit tout de suite que c'est idiot)
Idiot, je n'irais pas jusque là : je dirais plutôt "délicat". Par exemple, pour ce qui est des mots de passe d'administration, j'utilise sudo avec une identité que je réserve pour ça : en revanche, je ne mets pas le même mot de passe pour toutes les machines ; ie j'en ai un pour la DMZ publique, un pour la DMZ privée, un pour les stations en accès public, et un pour les machines qui ont un rapport avec l'administration - et bien, c'est facile : ça fait quatre sous-domaines et quatre "grant", chacun vers le fichier qui contient les mots de passes hashés idoines pour le sous-domaine.
Pour les clés d'hôtes, les démons qui ont besoin d'avoir des mots de passe, et cie, comme je l'ai dit, un "grant" par hôte.
Pour le reste, de toute façon, je me fous qu'on accède aux fichiers de conf : les seules clés SSH à copier sont publiques (bon courage pour choper mes clés privées : elles sont dans des smartcards, qui sont dans des poches de mon futal), et la plupart des fichiers (bashrc, conf d'aptitude, ...) ne sont pas sensibles, puisqu'identiques entre chaque machine, et même accessibles en lecture aux utilisateurs potentiels du système... cela dit, comme je fais déjà une ségrégation par "grands" sous-domaines (pour le "shadow") et par hôtes (pour ce qui l'est, privé), j'en profite ainsi pour que tout le monde n'ait pas accès à toute la configuration (genre, ma DMZ publique, avec Exim et cie, n'a aucune idée que j'ai du serveur MythTV, deux CUPS et va savoir quoi, grâce aux imports dynamiques en fonction du nom de domaine, qui impliquent une conf cfengine séparée, et inaccessible pour les autres, mais aussi via du DNS séparé, et du firewall comme il faut [je réfléchis quand même à IPSEC, à l'occasion de mon futur passage à IPv6], entre autres).
Le tout est d'être précautionneux, cohérent, et de ne pas donner accès à n'importe quoi, à n'importe qui... dans ce cas, le "pull" est, m'est avis, plus sain que le "push", ne serait-ce que parce que l'application de la conf ne dépend pas directement d'une connectivité à un instant "t" (chacun de mes quatre sous-domaines vérifie sa config toutes les 20 minutes, mais ils le font en décalé de 5 minutes - ce qui fait que le moindre trifouillage de câble réseau pendant 5 minutes aurait 100% de chances d'être nuisible, avec du push)...
Sinon, on peut aussi coupler le "push" avec cfagent via autre chose (SSH, rsync, ...) : on force la copie de fichiers dans le "inputs" des clients, avec un fichier de contrôle pour marquer que la copie a bien été faite (pour parer aux coupures de réseaux, et aux fichiers à moitié copiés), puis on laisse cfagent les manipuler - ça peut éviter de se prendre les pieds dans les "grant" (mais ça fait intervenir davantage d'outils, et c'est donc potentiellement plus casse-gueule que de n'en avoir qu'un, qu'on maîtrise bien - après, l'idéal serait d'avoir tout ça dans un seul outil - oui-da).
Après, à chaque admin, à chaque site, ses pratiques... moi, je fais ça pour m'amuser, avec deux vieux Athlon-XP en guise de serveurs, et 4 PC clients (plus d'autres clients, qui tiennent plus de l'artefact que du PC, comme la Squeezebox ; m'enfin, pas de cfengine pour eux ; sauf en ce qui concerne le routage, les serveurs auxquels ils accèdent, ...)... OpenVZ me permet de faire tourner entre 20 et 30 serveurs (entre 40 et 50, à terme - par exemple, Exim, Dovecot, Fetchmail, ou encore RSS2mail ont chacun leur conteneur... j'ai aussi plusieurs DNS autoritaires et récursifs, afin de bien compartimenter... et j'en passe : moult), et pour que tout soit uniforme facilement (y compris les clients), quelque chose comme cfengine, si manié avec dextérité et précaution, c'est quand même génial.
Même si faire gaffe à ce qu'on fait avec lui peut passer par des changements dans les manières de faire, et dans l'organisation du site, c'est aussi une occasion de revoir la cohérence de ce dernier : s'il y a trop de choses à y modifier pour faire les choses proprement avec Cfengine, c'est l'occasion de se poser des questions, et, pourquoi pas ? d'optimiser...
Là où, en revanche, j'abonde dans le sens de tes remarques, c'est que des exemples de comment gérer proprement ce genre de choses, je n'en ai trouvé ni pour puppet, ni pour cfengine... dans un cas comme dans l'autre, la doc est bonne (très bons tutoriels et manuels de référence, pour chacun), mais ne couvre que des usages vraiment basiques, et pas ceux qu'on _va_ rencontrer dans un vrai site, avec plusieurs domaines, et des données sensibles. En gros, ils se contentent d'expliquer le "quoi", mais pas trop le "comment" ni le "pourquoi", ce qui augmente forcément la difficulté pour venir à les utiliser proprement.
[^] # Re: Cfengine v3...
Posté par Aefron . En réponse au journal vos prévisions 2009 ... Évalué à 4.
Idiot, je n'irais pas jusque là : je dirais plutôt "délicat". Par exemple, pour ce qui est des mots de passe d'administration, j'utilise sudo avec une identité que je réserve pour ça : en revanche, je ne mets pas le même mot de passe pour toutes les machines ; ie j'en ai un pour la DMZ publique, un pour la DMZ privée, un pour les stations en accès public, et un pour les machines qui ont un rapport avec l'administration - et bien, c'est facile : ça fait quatre sous-domaines et quatre "grant", chacun vers le fichier qui contient les mots de passes hashés idoines pour le sous-domaine.
Pour les clés d'hôtes, les démons qui ont besoin d'avoir des mots de passe, et cie, comme je l'ai dit, un "grant" par hôte.
Pour le reste, de toute façon, je me fous qu'on accède aux fichiers de conf : les seules clés SSH à copier sont publiques (bon courage pour choper mes clés privées : elles sont dans des smartcards, qui sont dans des poches de mon futal), et la plupart des fichiers (bashrc, conf d'aptitude, ...) ne sont pas sensibles, puisqu'identiques entre chaque machine, et même accessibles en lecture aux utilisateurs potentiels du système... cela dit, comme je fais déjà une ségrégation par "grands" sous-domaines (pour le "shadow") et par hôtes (pour ce qui l'est, privé), j'en profite ainsi pour que tout le monde n'ait pas accès à toute la configuration (genre, ma DMZ publique, avec Exim et cie, n'a aucune idée que j'ai du serveur MythTV, deux CUPS et va savoir quoi, grâce aux imports dynamiques en fonction du nom de domaine, qui impliquent une conf cfengine séparée, et inaccessible pour les autres, mais aussi via du DNS séparé, et du firewall comme il faut [je réfléchis quand même à IPSEC, à l'occasion de mon futur passage à IPv6], entre autres).
Le tout est d'être précautionneux, cohérent, et de ne pas donner accès à n'importe quoi, à n'importe qui... dans ce cas, le "pull" est, m'est avis, plus sain que le "push", ne serait-ce que parce que l'application de la conf ne dépend pas directement d'une connectivité à un instant "t" (chacun de mes quatre sous-domaines vérifie sa config toutes les 20 minutes, mais ils le font en décalé de 5 minutes - ce qui fait que le moindre trifouillage de câble réseau pendant 5 minutes aurait 100% de chances d'être nuisible, avec du push)...
Sinon, on peut aussi coupler le "push" avec cfagent via autre chose (SSH, rsync, ...) : on force la copie de fichiers dans le "inputs" des clients, avec un fichier de contrôle pour marquer que la copie a bien été faite (pour parer aux coupures de réseaux, et aux fichiers à moitié copiés), puis on laisse cfagent les manipuler - ça peut éviter de se prendre les pieds dans les "grant" (mais ça fait intervenir davantage d'outils, et c'est donc potentiellement plus casse-gueule que de n'en avoir qu'un, qu'on maîtrise bien - après, l'idéal serait d'avoir tout ça dans un seul outil - oui-da).
Après, à chaque admin, à chaque site, ses pratiques... moi, je fais ça pour m'amuser, avec deux vieux Athlon-XP en guise de serveurs, et 4 PC clients (plus d'autres clients, qui tiennent plus de l'artefact que du PC, comme la Squeezebox ; m'enfin, pas de cfengine pour eux ; sauf en ce qui concerne le routage, les serveurs auxquels ils accèdent, ...)... OpenVZ me permet de faire tourner entre 20 et 30 serveurs (entre 40 et 50, à terme - par exemple, Exim, Dovecot, Fetchmail, ou encore RSS2mail ont chacun leur conteneur... j'ai aussi plusieurs DNS autoritaires et récursifs, afin de bien compartimenter... et j'en passe : moult), et pour que tout soit uniforme facilement (y compris les clients), quelque chose comme cfengine, si manié avec dextérité et précaution, c'est quand même génial.
Même si faire gaffe à ce qu'on fait avec lui peut passer par des changements dans les manières de faire, et dans l'organisation du site, c'est aussi une occasion de revoir la cohérence de ce dernier : s'il y a trop de choses à y modifier pour faire les choses proprement avec Cfengine, c'est l'occasion de se poser des questions, et, pourquoi pas ? d'optimiser...
Là où, en revanche, j'abonde dans le sens de tes remarques, c'est que des exemples de comment gérer proprement ce genre de choses, je n'en ai trouvé ni pour puppet, ni pour cfengine... dans un cas comme dans l'autre, la doc est bonne (très bons tutoriels et manuels de référence, pour chacun), mais ne couvre que des usages vraiment basiques, et pas ceux qu'on _va_ rencontrer dans un vrai site, avec plusieurs domaines, et des données sensibles. En gros, ils se contentent d'expliquer le "quoi", mais pas trop le "comment" ni le "pourquoi", ce qui augmente forcément la difficulté pour venir à les utiliser proprement.