Reprise du message précédent :

 
C'est cette partie :
 

 
par contre j'ai un doute sur l'utilisation je demanderai à l'auteur

il fait ça pour virer les morceaux de fichiers qui ne seraient plus utilisés (donc vidage puis re-remplissage lorsque nécessaire) et ne pas avoir des morceaux de conf non voulus

Mais reremplissage à partir de quoi ?
Il gère ça ailleurs dans une autre règle ?
 
Je capte pas, ou du moins je trouve ça tordu comme logique

 
oui il gère le remplissage à partir de ses manifests. Là c'est juste un define, donc une seule ligne dans ses autres manifests qu'il réutilise à façon
 

C'est space je trouve
Je vais gérer ça autrement

salut les jeunes, comment je peux utiliser puppet sans reverse DNS ?
 
pour les besoins de test, et vu le setup bordélique que j'ai, les reverse-DNS sont impossible à configurer en un temps raisonnable.

 
tu utilises ton /etc/hosts. Note que puppet n'a pas besoin de reverse DNS

Sans parler du bien-fondé de la chose, y'a moyen d'utiliser un poste sous Windows en tant que puppet master ? Possible d'administrer une VM par ce biais ?
C'est pour du très léger, PC sous Win en puppet master, une VM sur ce même poste en serveur de test, un serveur linux sur le réseau privé en recette et un serveur de prod en dédié.

A priori y a du boulot en cours pour le support windows, mais vu la quantité de doc dispo à ce sujet, j'aurais tendance à dire que d'une part ca doit pas être très avancé, et d'autre part ca ne semble concerner que la partie cliente.
 
Donc à mon avis, trouve une autre solution (c'est déjà assez complexe comme ça à prendre en main).

+1

C'est dommage
Des avis d'outils pour mon besoin ?

On ne connait pas ton besoin (les 2 lignes de ton précédent poste ne sont pas très parlantes)

Quand je parlais d'une autre solution, c'était d'installer ton puppet master sur un UNIX, pas de passer à un autre outil d'ailleurs

 
En gros, maintenir 2.5 machines (des serveurs web, rien de sorcier, le .5 étant une VM) sur des conf équivalentes, susceptibles de changer au cours du temps, et avec la possibilité d'une resto rapide. Puppet me semblait coller parfaitement, plus qu'un iso bien lourd et qui ne résout pas la problématique d'une conf changeante.
 

 
Moui Je suis que moyennement chaud.
 

off-topic : 1 vm c'est pas une demi machine, faut gérer la conf, c'est 1 machine à part entière.

Bon, j'ai installé mcollective, ça me reponds correctement, mais j'arrive pas à récupérer les facts

J'ai installé l'agent facter dans les agents de mcollective (même si à priori la méthode de fact 2 yaml est mieux, pour l'instant je commence juste à tester les possibilités).

Il me manque quoi pour que ça fonctionne ?

configurer mcollective pour utiliser facter plutot que le fichier yaml ?

Ah oui, bien vu
 

On avance...

En mettant facter.rb dans facts plutot que dans agent, c'est un peu mieux, mais toujours pas ça
 

 
Je vais passer le log en debug

ta machine est lente

sinon teste avec :
 

 
 
et utilise le plugin yaml

Ah ben ça marche maintenant...
 
C'est pas très rassurant

 
facter a un point noir : il est lent. Personnellement je dumpe les facts dans le yaml (aussi parce que j'utilise des infos custom que je place dans un second fichier yaml)

Bah c'est ce que je comptais faire de toutes façons

mais je voulais voir ce que ça donnait avec un petit script pour faire des rapports, sans me prendre le chou à déployer des recettes Puppet dans un premier temps

Y'en a qui ont testé chef par ici ?
Sans vouloir déclencher une guerre ... disons que l'aspect ruby des recettes chefs me plait un peu plus que le pseudo langage puppet ... A moins que certains aient testé la syntaxe ruby pour puppet (mais la documentation est maigre ...)

Bon, GOTO rédiger un module mcollective maintenant

J'ai lu un article hier qui m'a pas du tout donner envie de passer à chief
 
=> http://bhuga.net/node/46

Oui, je l'ai lu aussi, il m'a un peu refroidi ...
Les commentaires finalement m'intéressent plus que l'article, mais un an ça commence à faire, et je suppose que ces deux projets très actifs ont eu un peu de temps pour changer..

 
Moi j'aime bien le DSL puppet. et j'aime pas le bloat apporté par chef.
 
Et sinon il n'y aura pas de guerre ici

 
goto la forge puppet

Ah ben ouais

Il est un peu "pollué" ton module quand même, tu l'as généré avec quoi ?

 
le truc normal

T'as toujours pas regarder foreman ?
 
Je trouve ça plutot sympa, mais j'ai un truc bizarre avec quand j'importe mes classes Puppet : il les tag avec un environment "master" au lieu de "production". C'est comme si il interprétait le [master] de puppet.conf comme l'environnement Rails

non pas regardé

En fait j'ai juste retaggé toutes mes machines en "master" et c'est bon
Enfin c'est bon, ca récupère pas les associations classes <=> hotes existantes (ou du moins je n'arrive pas encore à le faire )

Bon, c'est un peu mon blog sur puppet ici
 
Donc, après quelques mois sans trop avoir (ou plutot prendre) le temps de regarder plus en détails les possibilités de foreman, je me suis enfin replongé dedans, et j'ai enfin réussi à tout mettre en place pour faire le provisionning (boot PXE => preseed => install puppet + enregistrement auprès du maitre => reboot).
 
Franchement ça commence à déchirer grave

Ohad a fait du bon, de mémoire le seul truc qui manque vraiment c'est le support des parameterized classes.

Et c'est que la version 0.3, je trouve que ça avance très vite vu le nombre de fonctionnalités (support libvirt, provisionning, smart proxies DHCP/DNS/TFTP/PUPPETCA).
 
Je risque de gérer pas mal de choses dedans

tu peux virer mon delicious du premier post, j'ai pas accepté les conditions de avos et mon compte est fermé

Question stupide : pour manager un node Debian et étant donné que c'est Puppet qui se charge de l'installe de tous les packages, j'installe pas Aptitude ?