Puppet staging server
Gonzalo Servat
Paul Tötterman
> I tried to implement a second Puppet server as a "staging" server with the idea of being able to run puppet in dry run mode against this staging server.
> I ran into some SSL trouble. When I point at the staging server, I get various SSL related errors and I assume it's because the ca cert is different. I can get around it by clearing /var/lib/puppet/ssl and regenerating/signing the certificate, but I have to do the same thing when I go back to the production server which is not what I was hoping for.
Pablo Fernandez
Hi Gonzalo,
> Has anyone done this sort of thing? How'd you get around the SSL issues? I
> could use the same CA cert on both Puppet servers but I assume that won't
> work as the hostnames are different?
I am actually doing this, but on the same puppet server. What I have done is the following:
- Main puppet master runs as user puppet, with default parameters. The /etc/puppet directory is a Git checkout.
- Then, as my normal username, I run another instance of puppet master, listening on a different port, with my local changes:
* I choose a unique $PORT for each user, this way you can have as many puppetmasters as you want.
* I create a runtime-puppet directory with empty 'rundir' and 'logdir' subdirectories. They just get the logs and the pidfile.
* Then, I populate a third 'vardir' subdirectory it with a copy of /var/lib/puppet, that brings together all the certificates. You may need to change the ownership of that directory to your username, for the private key. The client's keys may be shared with simlinks if you like, otherwise you will need to sync both directories every time you have a new cert.
* Finally puppetmasterd runs as my username, this way:
puppetmasterd --rundir=/home/pablof/runtime-puppet/rundir --vardir=/home/pablof/runtime-puppet/vardir --confdir=/home/pablof/puppet-tree --logdir=/home/pablof/runtime-puppet/logdir --masterport=$PORT "$@"
You can then have in --confdir (I call it puppet-tree) a local copy of the /etc/puppet dir I share with Git. This way I make my local copies, without pushing the changes, and my private puppetmasterd sees them instantly. If I want to have a single node pick up my temp configuration, I stop puppetd there, and run by hand (in the client): puppetd -t --masterport=$PORT, with the same $PORT I used in the puppetmasterd.
Easy, and It works like a charm.
But if you need it to be different machines, I don't know what will happen with the server certificate. If puppetd is smart enough, it won't let you, but maybe you can trick your client with a temporal /etc/hosts entry, may be worth a try.
Good luck!
Pablo
Nan Liu
> Hi All,
>
> I tried to implement a second Puppet server as a "staging" server with the
> idea of being able to run puppet in dry run mode against this staging
> server.
As other have suggested, environments might be an easier way to do this.
> I ran into some SSL trouble. When I point at the staging server, I get
> various SSL related errors and I assume it's because the ca cert is
> different. I can get around it by clearing /var/lib/puppet/ssl and
> regenerating/signing the certificate, but I have to do the same thing when I
> go back to the production server which is not what I was hoping for.
The issue here is you are running two puppet master with two different
self signed CA. If you intend all puppet agents to connect to both
system, only run CA on one master and configure the second master
ca=false. Generate the second master's cert on the CA server with the
appropriate dns_alt_name:
puppet cert -g secondmaster --dns_alt_name='secondmaster,secondmaster.foo.lan'
Copy this cert to the appropriate location on your secondary puppet
master. All puppet agent should configure puppet_ca to the master
running ca, and they should be able to connect to both server.
Thanks,
Nan
ad
an external node classifier, you have to set the environment in each
node's puppet.conf for everything to work. I use foreman and set the
environment using a puppet.conf template with the undocumented (I
think) foreman_env variable.
I use 3 environments, dev, staging, and production, and have a script
on the master that lets me publish changes committed to our svn server
to any environment. It works pretty well so far.
Adam
Steve Shipway
We have a Dev, Test and Production environment, and migrate between them using subversion scripts.
The only thing to be aware of, is that you need to set up the file server so that all puppet: resources include the environment; thus: puppet:///files-$environment/myfile ; in this way, modules and manifests can move between environments without needing to change the files URL (under modules is fine because it already is aware of environments)
Another useful thing is to append the Production modules path to the end of the Dev and Test module paths, so you dont have to have a copy of every module in each environment.
If you want to have a client pointing at completely different puppet servers, then make a second client directory /etc/puppet2 for example, that defines a completely different varpath etc. Then use --confpath=/etc/puppet2 to activate this one rather than using --server. This way you can have a completely separate puppet agent installation, separate certificates, and so on.
We do this in some cases where we have an applications puppet server, where the client runs as a non-root user, and a systems puppet server, where the agent runs as root. We can allow the apps team to maintain the manfests on the applications server.
Steve
Sent: Wednesday, 7 March 2012 8:20 p.m.
To: puppet...@googlegroups.com
Subject: [Puppet Users] Puppet staging server
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.