[nycbug-talk] OT: Puppet Questions

[Matt Juszczak]

Hello fellow puppet savvy sys-admins,

I have a few puppet questions, and I'm wondering if anyone knows the 
answers to any of them.

1) I'm a little confused on the fileserver.  I have a file in /etc/puppet 
called "fileserver.conf".  There are no lines in it.  The documentation 
says that if no files are specified in that file, then the default is to 
"deny" all access to the file server.  However, when I do things like:

file { "name":
 	source => "puppet:///module/filename"
}

it works fine.  If the default policy of the fileserver is to deny access, 
why is that file able to be transferred?  The main reason I'm concerned 
about this is because we're on a shared LAN (Cloud environment), and while 
I have puppet blocked off to the outside, on the LAN it's open to 
10.0.0.0/8, which allows hosts that *aren't* ours to connect to it anyway. 
I manually approve any client SSL certificates with puppet-ca --sign, so 
that blocks hosts from using puppet when they aren't approved, but what's 
to stop those hosts from using the fileserver to grab files meant for our 
instances?  Or am I confused, and is the fileserver.conf an added security 
measure ON TOP of the SSL certificate signing, but without the client 
certificate being signed, no access is allowed?


2) Nagios: I'm currently using Puppet to generate nagios configuration for 
our instances.  It works well, but I need to also generate nagios 
host/service information for hosts which *aren't* managed by LDAP.  Would 
there be an easy way to do this inside Nagios (for instance, manually 
configure those hosts inside the nagios module, so that they are mixed 
into the Nagios_host and Nagios_service files?)  The other option I've 
been thinking of is putting those host configurations into LDAP (alongside 
other puppet nodes), and just manually generating nagios configs from LDAP 
with a cron.  It seems like the stored configuration might hold good data 
too, but again, it would only hold data for instances managed by puppet. 
Any thoughts?


3) Simulating a private LAN with iptables: the LAN we have is shared 
(cloud environment).  The negative of that is that any other host on the 
LAN can connect to puppet, internal DNS servers, LDAP, etc.  I'm fairly 
confident in the security of those three tools, so I've considered leaving 
them fully open to the LAN and just making sure they are configured 
securely (IE: no anonymous bind for LDAP, etc.).  Even if that is the 
case, I'd still like to lock down certain services on certain boxes to 
only allow connections from my other boxes (and not the entire LAN). 
What would the easiest way be to implement an access list that all hosts 
would maintain?  It would be a set of X number of IPs (where X is unknown 
at this time) that would constantly be maintained automatically (so when a 
new server is launched, access is granted the next time each existing 
server checks into puppet).


4) Failover: What are people doing these days for puppet failover?  My gut 
says to keep the configs in SVN, and always have another host on stand by. 
However, there's an issue with that: the puppet nodes wouldn't be able to 
just be re-pointed, because the client SSL certificates would be validated 
by the failover server (and therefore, there would be certificate 
validation errors).


5) Puppetizing your puppet servers: I've already made the decision NOT to 
LDAPify my LDAP servers (master and failover), as I wouldn't want LDAP to 
fail and cause issues getting into the LDAP box.  My gut has also told me 
NOT to puppetize my puppet server (and just keep good backups); however, 
what have others done?  I've seen conflicting documentation and blog 
entries on the subject.

Thanks all!

-Matt