[Mageia-sysadm] [138] use a cname for puppet
Michael Scherer
misc at zarb.org
Fri Nov 5 15:57:55 CET 2010
Le vendredi 05 novembre 2010 à 14:59 +0100, nicolas vigier a écrit :
> On Fri, 05 Nov 2010, Michael Scherer wrote:
>
> >
> > I see 2 solutions :
> > - keep in sync puppet.conf with modules/puppet/templates/puppet.conf
> > - (re)move puppet.conf so it doesn't conflict, and be sure that puppet
> > deploy the proper one even on the master
>
> I don't understand 2nd solution. But 1st solution seems ok.
cd $CHECKOUT_OF_PUPPET
svn rm puppet.conf
svn commit
then, on next cron update on puppetmaster :
svn up will remove puppet.conf
then puppet agent will kick in, recreate the config file and all is
well.
Then later, updates are handled like all others file managed by puppet.
( we should just be sure that we do not ask puppet to reload when the
file change and while it is updating itself )
Or I hope so.
We may have to add the puppet file by hand for the migration however.
> But maybe new changes to puppet.conf on clients are going to be very
> rare, so it can be ok if managed managed manually ?
I was planning on enabling some features after more tests :
- reporting, so we get mail when there is a error ( once I have tested
the feature, doing mistakes is not so easy :p )
- filebucket, so file are saved if the were manually edited on the
server ( useful to prevent errors ), didn't play with it
- there is also a system of plugin, that could be used if we start to
manage urpmi with it ( I have such a plugin, except it is not finished
and do not work and not public ), and this requires "pluginsync = true"
in agent
- puppet config file may change ( they changed it for 2.6 ) and so may
requires cluster wide update to remove warning
I also think we could use storedconfig in the futur ( puppet node send
their configuration to the master ), but this doesn't requires config on
client, afaik.
--
Michael Scherer
More information about the Mageia-sysadm
mailing list