On Mon, Aug 18, 2014 at 01:48:55PM -0700, Wil Cooley wrote: > On Mon, Aug 18, 2014 at 10:01 AM, Christopher Wood > <[1]christopher_w...@pobox.com> wrote: > > This is generally the reason that you need something like puppet, that > you want to enforce a configuration. > > If you need to detect things about a server, there are a number of > things you can do: > > a) monitoring (snmp?) check invoking a custom script, script detects the > dir > b) use something like mcollective to check in real time whether the dir > exists > c) ssh in and use ls > > d) Write a custom fact; [2]external facts make it as easy as writing a > small shell script: > /etc/facter/facts.d/mydir.sh: > #!/bin/sh > test -d /foo/bar && echo "dir_foo_bar_exists=true"
If you're using this in manifests and you really can't manage the directory, this is better. Of course, I'd say go for a custom fact rather than an external fact. That way you get pluginsync for free. https://docs.puppetlabs.com/facter/2.0/fact_overview.html That said, if you need your monitoring-of-this-directory to eventually alert a human if something goes wrong, you'll need to set up monitoring/ticketing/alerting. Dig around on forge.puppetlabs.com for strings like: nagios snmp monit > > The usual point also, that you should stop asking your servers how they > are and tell them how they should be. Declare, don't inquire. > > That's great advice and a worthwhile long-term goal. But when you're just > starting out or are increasing management coverage incrementally, you need > to do these kinds of things. > Wil That rather depends on your goals, albeit that I'm on my second set of production puppetized services. In short, based on prior horrible experiences, I'm going for "know what you're doing". For the current set of puppetized hosts I went with: a) be able to bootstrap all puppet infrastructure from a CentOS minimal install and the puppet git tree (some chicken/egg here requiring manual intervention, I admit) b) any node should be automagically configurable from a CentOS minimal install to full production readiness with no manual intervention (The basics.) This makes knowing what components constitute the puppetized services a direct requirement of running their backend nodes. It took longer to get going, but now there's no puppet-vs-nonpuppet-bits tracking, no "who made that change when", and no "make sure all servers have this" for the puppetized hosts. (Still the basics.) It has, of course, shown up a number of interesting cultural practices around configuration changes that are still sorting themselves out. If I had to sum up, I'd say that puppet's main value so far is to throw all this stuff into sharp relief. The automation is good, but knowing what it takes to run things is the real advantage. > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [3]puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > > [4]https://groups.google.com/d/msgid/puppet-users/CAMmm3r7XFyhLHy2ocT1JSydYuY1GvJW9H_4XgJVQCKwptWeWEw%40mail.gmail.com. > For more options, visit [5]https://groups.google.com/d/optout. > > References > > Visible links > 1. mailto:christopher_w...@pobox.com > 2. > https://docs.puppetlabs.com/facter/latest/custom_facts.html#external-facts > 3. mailto:puppet-users+unsubscr...@googlegroups.com > 4. > https://groups.google.com/d/msgid/puppet-users/CAMmm3r7XFyhLHy2ocT1JSydYuY1GvJW9H_4XgJVQCKwptWeWEw%40mail.gmail.com?utm_medium=email&utm_source=footer > 5. https://groups.google.com/d/optout -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/20140818214134.GA2144%40iniquitous.heresiarch.ca. For more options, visit https://groups.google.com/d/optout.
