Reprise du message précédent :
 
 
Dans ce cas, voir mes deux commentaires sur les paquets en questions
 

Tiens, j'ai découvert ce matin que puppet et foreman allaient devenir des briques de base du système RH satellite.

Je suis pas trop RedHat-friendly, mais ça montre la maturité de ces 2 projets (et leur avenir très prometteur).

 
Ouais c'est fait    
Je vais peut-être repasser la main à un monsieur qui a fait des provider pour arch toussa  

Donc Scullder c'est toi ou ton pote ? Tu sais si l'update corrige le point que j'ai levé en commentaire ? Le "it's not fully tested" me donne pas confiance comme ça
 
Du même coup à la lecture des commentaires, Salt c'est vraiment si bien que ça ? L'ancien mainteneur de Puppet sous Arch le conseille.

Tiens, c'est intéressant ça, Salt

Yop OSA
 
Soit un master qui kick un client.
Sur le master, j'ai l'intégralité de la conf qui est dans /etc/puppet :
 

 
Lors du kick, je me prend un "No files found for import 'nom-de-mon-module' at path/bla/bla". Bien évidemment, si je fais un puppet apply sur le master, aucun problème.
 
Les modules doivent être dans un emplacement partagé, ou c'est sensé marcher tel quel ?

 
Non, tes modules ne sont que sur ton serveur puppet. Le serveur compile ensuite un "catalog" pour chaque client.
Vérifie ton fichier /etc/puppet/fileserver.conf pour voir si tu autorises bien la connexion par ton client.

Tu vois quoi en lançant puppet agent depuis le client ?

et là en rejouant les commandes que j'évoquais plus haut, je me rend compte que j'ai pas été clair sur la définition du problème :

Je rappelle que si sur le master, j'applique cette même configuration à cou de puppet apply, ça fonctionne.

Jamais utilisé puppet kick.
Je lance mon serveur avec "sudo puppetmasterd --no-daemonize -v"
Sur le client :  "puppetd --test -v --pluginsync true"
 
Dans ton manifests/site.pp, tu dois obligatoirement avoir une ligne de ce genre :

 
En fait, ça va importer tous tes modules dans le répertoire modules.
 
Si ça marche tjrs pas, vérifie ton puppet.conf, pour ton environnement par défaut, tu dois avoir une variable modulepath, manifest, manifestdir.
Enfin, mon environnement est tout customisé, c'est difficile de t'aider...

 
poste tes fichiers de conf. (pp)

Je les ai pas sous la main, mais ils sont vraiment tout bêtes, c'est du style :
 

# site.pp
import "modules"
import "nodes

# modules.pp
import "mon-module"

# nodes.pp
node basenode {
   include mon-module
}

 
Et je répète, si je fais un puppet apply sur le master avec le site.pp comme cible, pas de soucis.
 

Je comprends rien à vos puppet apply et puppet kick
C'est du puppet-ng que vous faites ?

Riton, tu n'as pas de node par défaut, (et il manque également un guillemet à ton site.pp)

 
Comme mentionné, je n'ai pas le matos sous les yeux, j'ai recopié pour le principe. Le guillemet manquant y est et pour le nodes.pp, en plus de la définition du basenode, j'ai bien évidemment un node 'mon-host' inherits basenode {} (avec mon-host le host que je kick par exemple).
 
Et de toute manière la conf est aussi parsée lors du puppet apply qui je répète, fonctionne correctement, donc si il y avait un soucis de syntaxe je le verrais à cet endroit non ?
 
@e_esprit : depuis je sais plus quelle version, les commandes sont regroupées sous un même exécutable, voir http://docs.puppetlabs.com/man/

D'accord, donc le kick c'est comme un puppetrun.
Du coup le message d'erreur (Connection refused - connect(2)) pourrait indiquer que :
- le client n'écoute pas sur le port dédié (ou le port n'est pas accessible à cause d'une ACL réseaux/règle de firewall)
- le maître n'est pas autorisé à kicker le client.

Petit up, j'ai commencé la migration/conversion des modules pour Puppet 3.x et c'est la misère. Je commence à voir le bout du tunnel heureusement.
 
Après, mise à jour des clients, de the foreman et on va pouvoir commencer le passage en prod en douceur.
 
Ensuite il faudra le faire évoluer pour utiliser un ENC.
 
Tout un programme !

il semble que puppet 3 supporte l'installation de fichiers exe et pas seulement msi pour les clients windows. Je me demande si ça vaut la peine de faire le passage.

Pour ma part, je reste en 2.7 pour le moment
 
Par contre je veux passer à puppetdb, même si ça implique de rajouter un pgsql et du Java dans le bouzin, parce que Foreman 1.2 l'exige (et ça apporte des fonctionnalités bien sympas en terme de provisionning de passer à la 1.2).
 
Comme j'utilisais storeconfigs jusqu'à présent, je veux récupérer mes data comme indiqué dans la doc de puppetdb :

Et bien sûr :
# puppet storeconfigs export  
Error: Unknown Puppet subcommand 'storeconfigs'
   
 
Tain mais le jour où une mise à jour de puppet/foreman se passera sans douleur et sans larmes ni sang, c'est pas demain la veille

Je crois que je vais créer un topic "défouloir pour les administrateurs qui ont à gérer des applis Ruby/RoR"  

Bon, je pense que malgré le fait qu'il parle d'un master mini en 2.7.13, il doit falloir une version beaucoup plus récente pour avoir cette commande qui semble avoir été introduite il y a peu.
 
Bref, si je choppe un dev de Puppet un jour, je lui ouvre le bide de là à là, j'lui sors les boyaux et je file sa langue à bouffer aux chiens. C'est clair, ça ?  

moi je me prends plus la tête avec les versions de puppet. J'installe la version du repository redhat, je me contente de la doc qui va avec et basta. Si je m'amuse à installer depuis rubygems c'est la croix et la bannière. Je ne veux plus jamais ça, plus jamais. ever. mais vraiment hein!

Ah ouais non mais moi puppet c'est dépot Debian officiel (de Debian, pas de puppetlabs), et eventuellement backports, je suis pas fou
 
Déjà que je dois me cogner un redmine à la mano, c'est bon

alors qu'avec chef vous auriez un paquet omnibus tout choupi de dernière fraicheur  

Je regarde plutot du coté de salt
 
Mais bon, j'ai finalement réussi à installer foreman 1.2, et j'ai surtout découvert qu'en fait il n'utilise pas du tout puppetdb
 
Du coup je vais voir si j'ai un intérêt quelconque à le conserver

J'ai pas testé mais de ce que j'ai lu il manque encore des morceaux "critiques" à mes yeux
 
Après y'a des trucs sympas comme zmq

Pour l'instant je suis de loin
 
Disons que puppet + foreman ça va me permettre de virer le xCat que je trouve inmaintenable et qu'on utilise pour un cluster de calcul.
 
Pour le reste on verra, c'est pas comme si on gérait des milliers de serveurs

Si je passais autant de temps à bosser sur un de ses systèmes que j'en passe à les survoler je pense que je serais passé guru y a longtemps.

 
Pas mieux, c'est pour ça que j'ai chosi de me consacrer sur Puppet, qui reste une référence même s'il peut y avoir mieux. Ca permet au moins d'avoir un truc fonctionnel, de bien comprendre les concepts de ce genre de softs et de mettre à plat ce qu'on veut gérer. Et si on veut changer plus tard de brique logiciel, le plus dur a déjà été fait.
 
Après il y a des projet intéressant sur le papier (http://www.rudder-project.org/site/) mais de la se lancer dedans, il faut bien réfléchir

xCat ne tourne pas sur la dernière redhat, sympa. On ne peut pas netbooter sur le dernier kernel. y parait que c'est un bug du kernel et que ça ne vient pas de chez eux. Moi je le garde parce qu'une fois configuré ça fait son taff', mais la doc fait peur, franchement. On sent qu'ils poussent le plus possible vers des serveurs IBM.
 
Si je veux adjoindre un outil de provisionning à puppet vous conseillez foreman ?

Si t'es prêt à mettre les mains dans le cambouis, parce que y a pas mal de features liées au provisionning qui sont toutes récentes (comme le système de discovery).
 
Mais bon en même temps c'est le seul outil que j'ai vu qui le propose (en ayant en plus un lien avec puppet).

 
et razor ?

Pas trop suivi l'évolution.
A vue de nez c'est kif kif, mais j'ai de mauvais à priori pour les produits de puppetlabs

Drapoil  

Lol

Bah j'vais faire du puppet, donc voila quoi
Déjà, faut que je reprenne la bouze que nous a fourni linagora et que je remette tout ça au propre, et ensuite ... ah ben ensuite faut tout refaire finalement, incompatibilité de version entre le client et le serveur ...
 
 

 
welcome, welcome to the jungle ...of the multiple documentation among versions.
 
Je dirais que le pire que j'ai connu en terme de documentation c'est xCAT, mais puppet est pas loin derrière.

Vous avez testé blueprint ? Il semble qu'il peut scanner un serveur et retourner les modules puppet qui permettent de le réinstaller.

pro tip : https://gist.github.com/rottenbytes [...] a0d95e0bea