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.
6) If I split up into two environments (such as "management" and
"production"), would I still be able to use exported resources across the
two environments, such that I could perhaps manage a single nagios
instance to monitor both environments? Or would it be better at that
point to keep the management and production servers under the same
environment, but split into two different basenodes?
Thanks all!
-Matt
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
