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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On Tue, May 18, 2010 at 06:01:56PM -0400, Matt Juszczak wrote:> 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.I have a very small separate set of configs that will bootstrap my puppet master installation and the other provisioning services I need to rebuild my entire environment (dhcp etc.) I run (ran, it''s been a while) them via the puppet binary so the only prerequisites are access to packages repositories and the puppet package being installed. They only do enough to get me to the point where I can untar a backup and then have puppet build everything else properly. Dean -- Dean Wilson http://www.unixdaemon.net Profanity is the one language all programmers understand --- Anon -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
> I have a very small separate set of configs that will bootstrap my > puppet master installation and the other provisioning services I need to > rebuild my entire environment (dhcp etc.) I run (ran, it''s been a while) > them via the puppet binary so the only prerequisites are access to > packages repositories and the puppet package being installed. > > They only do enough to get me to the point where I can untar a backup and > then have puppet build everything else properly.That makes sense, but do you then manage your puppetmaster via puppet as a normal client from then on? It would make me nervous. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Wed, May 19, 2010 at 11:14:41AM -0400, Matt Juszczak wrote:> That makes sense, but do you then manage your puppetmaster via puppet as > a normal client from then on? It would make me nervous.I do. Although rather than use environments we have a number of different puppetmasters, one per location (which is a logical collection of servers for us) and puppet changes get pushed from staging to live in the same way as everything else does in our workflow. But with even more scrutiny ;) In theory that catches any puppet issues in my personal dev environment or early staging and way before they could break production. Anything that slips through is my own fault for not testing it enough. Dean -- Dean Wilson http://www.unixdaemon.net Profanity is the one language all programmers understand --- Anon -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
> I do. Although rather than use environments we have a number of different > puppetmasters, one per location (which is a logical collection of > servers for us) and puppet changes get pushed from staging to live in > the same way as everything else does in our workflow. But with even more > scrutiny ;) > > In theory that catches any puppet issues in my personal dev environment or > early staging and way before they could break production. Anything that > slips through is my own fault for not testing it enough.Makes sense, and I think that''s the route we''re going to take, too (separate puppet masters for our dev environment versus having different environments on a single puppet master - we want to keep testing completely separate). However, don''t you have concerns that a change could get introduced to your puppet config that would cause your puppetmaster to have issues? This is why I''m leaning towards not regulating my puppetmaster with puppet (as I make the same decision to not have my LDAP server authenticate with LDAP). It''s kind of the chicken + egg problem, no? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
"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)." * keepalived to carry the vip * certname = puppet * copy the cert from the primary to the secondary * use a tool to keep /var/lib/puppet/ssl sync''d between the nodes (cron? rsnapshot?) Might have to get a little creative.. I think you can also do a common CA, but that wasn''t a requirement for my environment. -Chris On Wed, May 19, 2010 at 11:22 AM, Dean Wilson <dwilson@unixdaemon.net>wrote:> On Wed, May 19, 2010 at 11:14:41AM -0400, Matt Juszczak wrote: > > That makes sense, but do you then manage your puppetmaster via puppet as > > a normal client from then on? It would make me nervous. > > I do. Although rather than use environments we have a number of different > puppetmasters, one per location (which is a logical collection of > servers for us) and puppet changes get pushed from staging to live in > the same way as everything else does in our workflow. But with even more > scrutiny ;) > > In theory that catches any puppet issues in my personal dev environment or > early staging and way before they could break production. Anything that > slips through is my own fault for not testing it enough. > > Dean > -- > Dean Wilson http://www.unixdaemon.net > Profanity is the one language all programmers understand > --- Anon > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
> * keepalived to carry the vip > * certname = puppet > * copy the cert from the primary to the secondary > * use a tool to keep /var/lib/puppet/ssl sync''d between the nodes (cron? rsnapshot?) > > Might have to get a little creative.. I think you can also do a common CA, but that wasn''t a requirement for my > environment.So I assume you''re only talking about certname = puppet on the master, correct? The clients would still generate hostname based certs? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Wed, May 19, 2010 at 11:41:36AM -0400, Matt Juszczak wrote:> However, don''t you have concerns that a change could get introduced to > your puppet config that would cause your puppetmaster to have issues?There are (to me) two types of changes in this context, changes to the puppetmaster itself (its /etc/default/puppetmaster file for example), which we don''t do very often and keep quite a close eye on, and new modules / nodes (such as bringing resolv.conf under puppet control) - which we do a lot of and end up going through the usual testing cycle. Either way we do them in staging first and then watch them like a hawk.> This is why I''m leaning towards not regulating my puppetmaster with > puppet (as I make the same decision to not have my LDAP server > authenticate with LDAP). It''s kind of the chicken + egg problem, no?I''d rather have most of my changes done in a consistent way that''s been tested on dozens of my nodes than have a special out of band config mechanism just for puppetmasters. Although my view might change if we ever really screw it up - but a mistake of that size will kill more than one node in staging anyway :) Another way to look at it is that the fear makes you keep your recovery procedures up to date and close at hand ;) Dean -- Dean Wilson http://www.unixdaemon.net Profanity is the one language all programmers understand --- Anon -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
> I''d rather have most of my changes done in a consistent way that''s been > tested on dozens of my nodes than have a special out of band config mechanism > just for puppetmasters. Although my view might change if we ever really > screw it up - but a mistake of that size will kill more than one node in > staging anyway :)Makes sense. Perhaps I''ll go this route. I''d still be a little hesitant to ldapify the boxes, as a failed LDAP daemon would potentially could slow(er) authentication to the box I need to log into to fix the issue. But I can see how puppetizing the puppet master would help with consistency. Still, this is a virtual environment, so nightly snapshots are occuring anyway :) But that still doesn''t solve the issue of re-producing a box from the ground up. Anyone else making their puppetmaster a puppet client? -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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Wed, May 19, 2010 at 11:58:43AM -0400, Matt Juszczak wrote:> I''d still be a little hesitant to ldapify the boxes, as a failed LDAP > daemon would potentially could slow(er) authentication to the box I > need to log into to fix the issue.We only have a handful of people that need shell level access to the servers so we push the users out with Puppet. Removes the LDAP network dependency for us. Dean -- Dean Wilson http://www.unixdaemon.net Profanity is the one language all programmers understand --- Anon -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
The masters would get certname = puppet, so the cert filename would end up being puppet.pem. You can then create a DNS entry for the VIP called puppet.<domain>.<suffix>. You just have to copy that cert to the secondary nodes as well as keeping the client certs in sync so when a failover happens you have the client certs on the failover node. -Chris On Wed, May 19, 2010 at 11:45 AM, Matt Juszczak <matt@atopia.net> wrote:> * keepalived to carry the vip >> * certname = puppet >> * copy the cert from the primary to the secondary >> * use a tool to keep /var/lib/puppet/ssl sync''d between the nodes (cron? >> rsnapshot?) >> >> Might have to get a little creative.. I think you can also do a common CA, >> but that wasn''t a requirement for my >> environment. >> > > So I assume you''re only talking about certname = puppet on the master, > correct? The clients would still generate hostname based certs? > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Makes sense. So that''s just a certname setting inside the [puppetmasterd] config section of /etc/puppet.conf on the master, correct? But that needs to be set as puppet before the puppetmaster is started and any certificates are signed. Keeping on this same subject, perhaps you can answer the fileserver.conf question as well - if a node does not have a signed cert, can it still access the fileserver, regardless of the allow/deny rules inside fileserver.conf? -Matt On Wed, 19 May 2010, Christopher Johnston wrote:> The masters would get certname = puppet, so the cert filename would end up being puppet.pem. You can then create a DNS > entry for the VIP called puppet.<domain>.<suffix>. You just have to copy that cert to the secondary nodes as well as > keeping the client certs in sync so when a failover happens you have the client certs on the failover node. > > -Chris > > On Wed, May 19, 2010 at 11:45 AM, Matt Juszczak <matt@atopia.net> wrote: > * keepalived to carry the vip > * certname = puppet > * copy the cert from the primary to the secondary > * use a tool to keep /var/lib/puppet/ssl sync''d between the nodes (cron? rsnapshot?) > > Might have to get a little creative.. I think you can also do a common CA, but that wasn''t a > requirement for my > environment. > > > So I assume you''re only talking about certname = puppet on the master, correct? The clients would still generate > hostname based certs? > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
> We only have a handful of people that need shell level access to the > servers so we push the users out with Puppet. Removes the LDAP network > dependency for us.So sounds like you still maintain the users in LDAP, but use puppet to pull the users out of LDAP and generate shadow, passwd, and group files? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Yup certname = puppet on both masters (primary/secondary). Yea if you are setting up a fresh server I usually clear all the pem files under /var/lib/puppet/ssl then restart puppetmasterd so it generated a fresh new cert. I then rsync the tree over to the secondary. I have most of this in a dumb script, but hopefully you get the idea. For your fileserver question.. I don''t believe thats needed, at least I dont have anything in there for that. I only have [configs] [plugins] [facts]. I think the new version of 25+ now uses auth.conf for access the certificate directories. -Chris On Wed, May 19, 2010 at 12:30 PM, Matt Juszczak <matt@atopia.net> wrote:> Makes sense. > > So that''s just a certname setting inside the [puppetmasterd] config section > of /etc/puppet.conf on the master, correct? But that needs to be set as > puppet before the puppetmaster is started and any certificates are signed. > > Keeping on this same subject, perhaps you can answer the fileserver.conf > question as well - if a node does not have a signed cert, can it still > access the fileserver, regardless of the allow/deny rules inside > fileserver.conf? > > -Matt > > > On Wed, 19 May 2010, Christopher Johnston wrote: > > The masters would get certname = puppet, so the cert filename would end up >> being puppet.pem. You can then create a DNS >> entry for the VIP called puppet.<domain>.<suffix>. You just have to copy >> that cert to the secondary nodes as well as >> keeping the client certs in sync so when a failover happens you have the >> client certs on the failover node. >> >> -Chris >> >> On Wed, May 19, 2010 at 11:45 AM, Matt Juszczak <matt@atopia.net> wrote: >> * keepalived to carry the vip >> * certname = puppet >> * copy the cert from the primary to the secondary >> * use a tool to keep /var/lib/puppet/ssl sync''d between the >> nodes (cron? rsnapshot?) >> >> Might have to get a little creative.. I think you can also do a >> common CA, but that wasn''t a >> requirement for my >> environment. >> >> >> So I assume you''re only talking about certname = puppet on the master, >> correct? The clients would still generate >> hostname based certs? >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-users@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-users@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> >> >> > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Comments inline: On Tue, May 18, 2010 at 3:01 PM, Matt Juszczak <matt@atopia.net> wrote:> 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).We set up a separate root CA and used it to sign certificates on our puppetmasters. The puppetmasters then act as intermediate CAs and any client can connect to any puppetmaster. We then threw the puppetmasters behind our load balancer.> 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.LDAP sucks a LOT when it breaks, and it seems to break a lot. The puppetmaster is much less volatile in my experience. I''m a big fan of puppetizing the puppetmaster; it makes it much easier when there''s only a single process used for configuring servers. It hasn''t caused any huge problems in our environment. Remember, if the puppetmasters is misconfigured badly enough that it isn''t passing out configs, worst-case scenario is that you can''t deploy new configs. Just log in to the puppetmaster and fix by hand. Whereas, with LDAP logins, worst case is you *can''t* log in and fix (yikes!) --Paul -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Hi all, I have received replies to three of my six questions (thank you!). I''m still looking for answers on: * Fileserver: How does fileserver.conf control access? Is it possible for a server to access the fileserver without having its cert signed? * Nagios: What are people doing to add hosts/services to nagios where some hosts AREN''T puppet hosts? For instance, deprecated hosts that were spun up prior to puppet (we won''t be installing puppet on those hosts). * Does anyone have experience with puppet in the cloud? How are you launching your servers at Rackspace Cloud or EC2 automatically - is there bootstrap integration at all? Are you making your own images? How are you dealing with shared LAN access on clouds (are you finding people attempting to brute force your puppetmasterd instance?) Thanks! -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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
> We set up a separate root CA and used it to sign certificates on our > puppetmasters. The puppetmasters then act as intermediate CAs and any > client can connect to any puppetmaster. We then threw the > puppetmasters behind our load balancer.Interesting idea!> LDAP sucks a LOT when it breaks, and it seems to break a lot. The > puppetmaster is much less volatile in my experience. I''m a big fan of > puppetizing the puppetmaster; it makes it much easier when there''s > only a single process used for configuring servers. It hasn''t caused > any huge problems in our environment. Remember, if the puppetmasters > is misconfigured badly enough that it isn''t passing out configs, > worst-case scenario is that you can''t deploy new configs. Just log in > to the puppetmaster and fix by hand. Whereas, with LDAP logins, worst > case is you *can''t* log in and fix (yikes!)Yeah. In this case, our LDAP servers are also our puppetmaster servers, so they share responsibilities. Hence why I wanted to keep those boxes un-managed. -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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Hi, Matt Juszczak <matt@atopia.net> writes:> * Nagios: What are people doing to add hosts/services to nagios where > some hosts AREN''T puppet hosts? For instance, deprecated hosts that > were spun up prior to puppet (we won''t be installing puppet on those > hosts).Just use several cfg_dir and cfg_file directives in your nagios config file. I have the following: #### from /etc/nagios/nagios.cfg # host and service definitions for monitoring this machine cfg_file=/etc/nagios/localhost.cfg # human-maintained parts, if any cfg_dir=/etc/nagios/admin cfg_dir=/etc/nagios/hosts cfg_dir=/etc/nagios/services # script-generated parts cfg_file=/etc/nagios/commands.cfg cfg_file=/etc/nagios/hosts.cfg cfg_file=/etc/nagios/services.cfg # puppet-generated parts cfg_file=/etc/nagios/nagios_service.cfg #### -- Arnaud -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On May 19, 6:05 pm, Arnaud Gomes-do-Vale <Arnaud.Go...@ircam.fr> wrote:> Hi, > > Matt Juszczak <m...@atopia.net> writes: > > * Nagios: What are people doing to add hosts/services to nagios where > > some hosts AREN''T puppet hosts? For instance, deprecated hosts that > > were spun up prior to puppet (we won''t be installing puppet on those > > hosts). >While I haven''t used them (yet?), there are a few modules available on github that provide the ability to declare unmanaged hosts. Here''s an example, but not the only one: http://github.com/duritong/puppet-nagios -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1> While I haven''t used them (yet?), there are a few modules available on > github that provide the ability to declare unmanaged hosts. Here''s an > example, but not the only one: > > http://github.com/duritong/puppet-nagios >where [1] is the much newer and better version for that one. cheers pete [1] http://git.cmaisonneuve.qc.ca/?p=puppet/module-nagios;a=summary -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv1liIACgkQbwltcAfKi388tQCfZtkQB3P3uqY1R58noFJzlFzT FPQAn0YRBi1IjfRhkq2Mp5ExKRgv8+wI =ODG5 -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
> > That makes sense, but do you then manage your puppetmaster via puppet as a > normal client from then on? It would make me nervous. >I''m a big fan of this. I have several pieces carved out in my puppet module including: puppet::client - installs and manages the puppet client puppet::master - provides a file server for replication to the slaves puppet::server - class that does all heavy lifting (apache, passenger, etc) puppet::slave - a define The slaves are provided via a define because I use Branch Testing. This allows me to set up a slave for 1 or both of my environments: node myawesome inherits my_awesome_style { include myawesome_puppetslave } class myawesome_puppetslave { puppet::slave { [''testing'', ''production'']: } } With that in place, the definition manages instance-specific things that I rely on like /etc/puppet.testing and /etc/puppet.production. Both slave and master setup users with keys and cron jobs that result in the slaves rsyncing via ssh from the master. This way, my slaves are always in sync. The testing instance uses a more frequent value in minutes => (cron job) than production. I realize much of what I''m saying is very abstract and specific to my environment but wanted to provide some food for thought. Another nice thing is being able to update one or more of the slaves as a result of using a variable like $my_puppet_version. By using that as the value to ensure =>, you can basically update 1 or more of your slaves at will. At the end of the day, every slave is running a client that points to itself. This works for me because each slave is in a unique DNS zone. The slave syncs with the master (really just a glorified file server where the development happens) via ssh. I''ve also implemented a filtering mechanism in order to prevent a slave in clientA''s site from seeing any puppet code that is meant for clientB. This is achieved by using rsync''s filters (exclude, include) on the master to strip the inappropriate bits. The remainder is stored in a site-specific user''s home dir which is accessible from the site''s slave. So... lots can be done. If it weren''t for puppet being able to manage puppet, I''d never have bothered setting this all up :) -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
> * Does anyone have experience with puppet in the cloud?There really is no such thing as "the cloud". It''s just the latest buzz phrase used to describe... networked computers. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>> * Does anyone have experience with puppet in the cloud? > > There really is no such thing as "the cloud". It''s just the latest > buzz phrase used to describe... networked computers.I actually agree with you :) But it''s the term used to reference Rackspace and Amazon virtualization platform, so I use it. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
> where [1] is the much newer and better version for that one. > > cheers pete > > [1] http://git.cmaisonneuve.qc.ca/?p=puppet/module-nagios;a=summaryThanks, this looks great! -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.