Re: [Puppet Users] Exec resource don't write file after the command

[Brian Gallew]

The "creates" attribute tells Puppet that the "command" attribute actually
creates a file, and that the Exec{} should not be run if that file exists.
 You need to alter your command:
command => "rm -rf /root/essai/html;touch /root/essai/exec.txt"

On Wed, Aug 8, 2012 at 6:42 AM, Rost  wrote:

> Hi all,
>
> I'm trying to have the exec resource write a file after the command but it
> don't.
>
> here is the resource declaration
>
> class gepet {
> notify { 'begin':}
>  file { '/root/essai/html':
> ensure => present,
> content => "Wrote By Yves Nton",
> notify => Exec['test'],
> }
>  exec { 'test':
> path => "/usr/bin:/usr/sbin:/bin",
> cwd => "/root/essai",
> command => "rm -rf /root/essai/html",
> creates => "/root/essai/exec.txt",
> refreshonly => true
> }
>  notify { 'end':
> require => File['/root/essai/html']
> }
> }
>
> suggestions ?
> Thanks
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/4u6oOxidJJUJ.
> To post to this group, send email to puppet-users@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.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Cron Bugs

[Brian Gallew]

Alternatively, you can buy a support contract and mandate that it be fixed.

On Fri, Jul 13, 2012 at 5:56 AM, R.I.Pienaar  wrote:

>
>
> - Original Message -
> > From: "Felix Frank" 
> > To: puppet-users@googlegroups.com
> > Sent: Friday, July 13, 2012 1:04:53 PM
> > Subject: Re: [Puppet Users] Cron Bugs
> >
> > Hi,
> >
> > On 07/13/2012 11:46 AM, R.I.Pienaar wrote:
> > > cant comment on the rest of your questions - but many of us dont
> > > specifically
> > > follow bugs as we get all bug mails on the projects we work on, not
> > > being
> > > followed by a PL employee doesn't mean no-one is aware.
> >
> > well, that's certainly reassuring. I guess I jumped to conclusions
> > from
> > the lack of any reactions.
> >
> > Do you suspect it's worthwhile to keep bugging (no pun intended)
> > whomever it may concern via issue updates?
>
> Sure, as you are no doubt aware there are many many bugs and a very
> long tail of idle bugs thats just out of mind.
>
> So commenting on them and asking for updates might ping someone into
> action or increase their view of importance of the issue, even just
> people saying they also have the problem and showing some code or
> logs from recent versions of puppet would be useful.
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] The Puppet Way to handle slow resources? (newbie)

[Brian Gallew]

If I understand the OPs question correctly, he has an ordering problem:
some services aren't waiting for other services to come online before
starting themselves?

If that's the case, you handle this with dependencies and chaining, e.g.
service { fast_service:  require => Service['slow_service']...}

If the real issue is that the initial startup of a service involves a long
initialization process, then you need to insert some kind of test in
between the two services that verifies the slow service is truly up and
running, e.g.
exec { slow_service_check:  require => Service['slow_service'], command =>
"process that will wait for the slow service"...}
service { fast_service:  require => Exec['slow_service_check']...}

If the real issue is that the slow service takes longer than puppet_timeout
to complete its startup, then you have an insurmountable problem without
either MCollective or multiple puppet runs.

One way to address this with multiple puppet runs involves having a
progression of environments (assuming this happens once on provisioning and
never again).  Essentially, you have systems boot up into a "provisioning"
environment, where puppet runs, say, every 5 minutes.  Then you have your
ENC set up such that when a provisioning run completes with no changes, it
switches to a "longterm" environment, which is generally much more
lightweight and runs puppet on a slower schedule (e.g. once a day outside
of business hours).  This methodology can make the majority of your puppet
runs very lightweight and fast (which can matter if you are paying for CPU
cycles), but requires that everyone be good citizens who never change a
system without using Puppet.

On Wed, Jul 11, 2012 at 7:12 AM, Trevor Vaughan wrote:

> Hi Dave,
>
> This is definitely not a dumb question. I wrote a post on what I
> thought a puppet semaphore system should do quite some time ago.
> Unfortunately, you don't really want to hang an instance until the
> semaphore flips so you end up having to wait through puppet runs.
>
> If you've got a solid SSH infrastructure working, then I would suggest
> looking at something like Capistrano or Func to give you that one-off,
> lightweight punch that you need.
>
> The big thing to watch out for is that you need to make sure that your
> manifests work properly even if they don't run in order since your
> nodes will be calling in over time.
>
> One way of doing this is to use a custom fact and drop a file onto the
> system when you're ready for that extra bit to run or have it based on
> hitting the remote system to see if your target service is actually
> functional.
>
> Ideally though, the startup scripts for the different services would
> be smart enough to figure out if the environment is ready for them to
> run. The puppet can do what it does best and the services can merrily
> go on their way trying to come up until they succeed (or ultimately
> fail).
>
> Trevor
>
> On Tue, Jul 10, 2012 at 2:39 PM, Dave Anderson 
> wrote:
> > Hi
> >
> > I have a resource that is slow to come into service and I have other
> resources that are dependent on the service in order to be configured. I've
> been searching for the "puppet way" to do this, but all the options I've
> found don't seem optimal, so I'm assuming there is a better way that I'm
> missing.
> >
> > I have several instances, so I want puppet to kick them off in parallel.
> And I want the reliant services to be configured as soon as possible when
> the slow services are ready
> >
> > So I don't really want to use long timeout/multiple retry because I
> believe that won't be executed in parallel - and anyway, it's not a retry I
> want, it's a wait
> >
> > I don't want to have Mcollective/AMQP just for this one problem, it
> feels like a sledgehammer to crack a nut
> >
> > I don't want some external process to repeatedly kick puppet repeatedly
> until the dependency is resolved and the reliant service can be configured
> >
> > I'm imagining something like a semaphore, puppet sleeps and wakes up
> when the semaphore is flipped (the slow resource is available)
> >
> > Sorry if this is a dumb question, first post etc ...
> >
> > Thanks
> >
> > Dave
> > --
> > This email and any files transmitted with it are confidential and
> intended
> > solely for the use of the individual or entity to whom they are
> addressed.
> > If you have received this email in error please notify the system
> manager.
> > This message contains confidential information and is intended only for
> the
> > individual named. If you are not the named addressee you should not
> > disseminate, distribute or copy this e-mail.
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> > To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/zZfbu37DrsQJ.
> > To post to this group, send email to puppet-users@googlegroups.com.
> > To unsubscribe from this group, send email to
> puppet-users+unsubscr...@

Re: [Puppet Users] OT: Monitoring solutions

[Brian Gallew]

If you are thinking abou Nagios, Icinga, or Shinken, may I suggest you look
at omdistro.org?  They provide a single installable RPM/DEB (e.g.
omd-0.54.rpm) which includes all three, plus 10 or so add-ins, all
configured to work together, *plus* a nifty management tool that makes it
super easy to set up multiple environments.  We are using
check_mk/multisite (included in OMD) which makes automatic configuration
via Puppet a snap.  Each node exports 2 or 3 file resources, which are then
collected by the correct Nagios server, which in turn kicks off an
inventory and rebuilding of the Nagios configuration.

It is a thing of beauty.

On Mon, Jun 25, 2012 at 6:39 AM, Michael Friedrich <
michael.friedr...@univie.ac.at> wrote:

> Hi,
>
>
>  Original Message 
> Subject: [Puppet Users] OT: Monitoring solutions
> From: Kyle Sexton 
> To: puppet-users@googlegroups.com
> Date: 2012-06-24 22:45
>
>> Icinga: Never used, Nagios fork that I have no opinion on yet
>>
>
> developing & using it at work, in combination with pnp4nagios for
> graphing, plus checkmk for inventory and snmp checks.
>
> doing it the puppet way (like many users report that the nagios cookbooks
> still work) is one of my many todos left.
>
> so if you got any insights on that topic, feel free to enhance that page :)
> https://wiki.icinga.org/**display/howtos/Puppet
>
> kind regards,
> Michael
>
>
> --
> DI (FH) Michael Friedrich
>
> Vienna University Computer Center
> Universitaetsstrasse 7 A-1010 Vienna, Austria
>
> email:  michael.friedr...@univie.ac.at
> phone:  +43 1 4277 14359
> mobile: +43 664 60277 14359
> fax:+43 1 4277 14338
> web:http://www.univie.ac.at/zid
>http://www.aco.net
>
> Lead Icinga Core Developer
> http://www.icinga.org
>
>
> --
> 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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Reducing system load

[Brian Gallew]

There actually is a way to do this, though you may find it to be more
painful to work with.

Imagine, if you will, two environments: production and maintenance.

The production environment is the one you're running right now, for
production.  It fully manages everything and ensures that your systems are
all fully up-to-spec.  It takes about 5 minutes for a full run of this
manifest.

The maintenance environment, on the other hand, manages /etc/passwd,
exported resources, and a couple critical resources that change frequently.
 It doesn't check package versions, update /etc/ssh/ssh_known_hosts,
configure backup software, etc.  It's main purpose is to keep puppet
running.

Once you have these two environment configured, you move the majority of
your hosts from "production" to "maintenance", and your puppet runtime
drops.  When you make actual changes to the manifests, you temporarily move
all those hosts back into the production manifest so they get applied, and
then revert them to maintenance.

Another possibility for reducing overall CPU usage is to reduce the number
of times a day that Puppet runs.  If you cut it back to twice daily, then
your total CPU usage goes from 120 minutes/host to 10 minutes/host.  That
is, in fact, how we run Puppet where I work, though we do that out of a
culture of a "no changes during production" mindset rather than saving CPU
cycles.

Finally, consider the actual reasons for your long run times.  If it's
primarily that you are checksumming large file trees, you may want to
consider other alternatives.  While Puppet is fabulous for templated files,
perhaps the bulk of those files could go into a bzr/svn/git/hg/whatever
repository?  Then your manifest for that directory is reduced to an exec{}
for creating it, and either an exec{} or perhaps a cron{} for running the
appropriate update.

On Tue, Jun 19, 2012 at 6:38 AM, jcbollinger wrote:

>
>
> On Tuesday, June 19, 2012 5:23:42 AM UTC-5, Duncan wrote:
>>
>> Hi folks, I'm scratching my head with a problem with system load.
>>
>> When Puppet checks in every hour, runs through all our checks, then exits
>> having confirmed that everything is indeed as expected, the vast majority
>> of the time no changes are made.  But we still load our systems with this
>> work every hour just to make sure.  Our current configuration isn't perhaps
>> the most streamlined, taking 5 minutes for a run.
>>
>> The nature of our system, however, is highly virtualised with hundreds of
>> servers running on a handful of physical hosts.  It got me thinking about
>> how to reduce the system load of Puppet runs as much as possible.
>> Especially when there may be a move to outsource to virtualisation hosts
>> who charge per CPU usage (but that's a business decision, not mine).
>>
>> Is there a prescribed method for reducing Puppet runs to only be done
>> when necessary?  Running an md5sum comparison on a file every hour isn't
>> much CPU work, but can it be configured so that Puppet runs are triggered
>> by file changes?  I know inotify can help me here, but I was wondering if
>> there's anything already built-in?
>>
>
> You seem to be asking whether there's a way to make the Puppet agent run
> to see whether it should run.  Both "no, obviously not" and "yes, it's
> automatic" can be construed as correct answers.  In a broader context,
> anything you run to perform the kind of monitoring you suggest will consume
> CPU.  You'd have to test to see whether there was a net improvement.
>
> Consider also that although file checksumming is one of the more expensive
> operations Puppet performs, files are not the only managed resources in
> most Puppet setups.  You'll need to evaluate whether it meets your needs to
> manage anything only when some file changes.
>
> There are things you can do to reduce Puppet's CPU usage, however.  Here
> are some of them:
>
>- You can lengthen the interval between runs (more than you already
>have done).
>- You can apply a lighter-weight file checksum method (md5lite or even
>mtime).
>- You can employ schedules to reduce the frequency at which less
>important resources are managed.
>- You can minimize the number of resources managed on each node.
>
> John
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/5UkHTsXNKIsJ.
>
> To post to this group, send email to puppet-users@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.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit thi

Re: [Puppet Users] can we avoid notify/subscribe firing on a mode change?

[Brian Gallew]

As has already been suggested, make the change yourself, submit a patch.
 You have indicated several times that this isn't that big a change.
 Further, it's a change that is clearly only of benefit to you at this
point, so trying to convince others to do it for you is pointless.  If you
*really* want Puppetlabs to do the change for you, then buy a support
contract and have them do it.

On Fri, Jun 15, 2012 at 5:36 PM, Jo Rhett  wrote:

> On Jun 15, 2012, at 3:25 PM, Ashley Penney wrote:
>
> I figure I should clarify a little bit.  Unless my understanding of Puppet
> internals is way off it would be quite a lot of work to add the filter as
> it stands.  A lot of code would have to change internally to make it
> capable of filtering on parameters.  By complexity I meant code wise, not
> puppet manifest/syntax wise.  I just meant that it would take a lot of
> development to get it working consistently and properly as a metaparam
> throughout the codebase.  It would be nice to hear from someone at
> puppetlabs just how difficult this would be to add based on the 3.0
> codebase.
>
>
> I've looked at the code. It requires changing the triggers to have
> attributes, which is honestly a fairly trivial change and likely backwards
> compatible with anything today, too. Look at Puppet::Relationship.match? ()
> -- it's accepts the idea of event types, but only has triggers for
> :ALL_EVENTS or :NONE.
>
> That or else could be replaced with specific event types being passed
> quite easily.  Then each object would have to be modified to accept a
> revised syntax in the situation (optional) where only specific types are
> desired.
>
> It really doesn't appear to be a large change.
>
> --
> Jo Rhett
> Net Consonance : net philanthropy to improve open source and internet
> projects.
>
>
>
>  --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: how to refresh ssh/authorized_keys file content ?

[Brian Gallew]

"ensure => absent" is the standard syntax for all Puppet types.

On Fri, Jun 15, 2012 at 6:21 AM, eduardo  wrote:

>  Having advised :
>  'it is highly recommended to migrate work from exec to native
> Puppet types as quickly as possible.'
>
>  Is there any chance to purge keys ?
>
>  Do nothing writing resources { "ssh_authorized_key": purge => true }
> in my init.pp module.
>
>  Regards,
>   eduardo.
>
>
> On 13 jun, 13:02, eduardo  wrote:
> >  Thanks you felix for answer me. I owe you another one.
> >
> >  The bad news I tried resources { "ssh_authorized_key": purge =>
> > true } but don't result.
> >
> >  The good one is templates are great for it.
> >
> >   I appreciate your help,
> >Bests regards,
> >   eduardo.
> >
> > On 13 jun, 03:34, Felix Frank  wrote:
> >
> >
> >
> >
> >
> >
> >
> > > Hi,
> >
> > > On 06/12/2012 07:39 PM, eduardo wrote:
> >
> > > > Hi all,
> >
> > > >  How to refresh ssh/authorized_keys file content ?
> >
> > > >  I'm trying massive loading keys. I need refresh authorized_keys file
> > > > content.
> >
> > > >  I try delete file before call ssh_authorized_key :
> >
> > > please don't. This is *not* how you are supposed to interact with
> > > authorized keys.
> >
> > > Either use the ssh_autherized_key type *or* fiddle with the file, but
> > > don't mix them.
> >
> > > >  exec { "del_${user_local}_authorized_keys":
> > > >   command => "rm /home/$user_local/.ssh/
> > > > authorized_keys ; touch /home/$user_local/.ssh/authorized_keys ;
> chown
> > > > $user_local:$user_local /home/$user_local/.ssh/authorized_keys",
> > > >   path => '/bin:/usr/bin',
> > > >}
> >
> > > >   First run only delete file and in the second one I got desired
> > > > result.
> >
> > > >   I think is possible create content file using template but before
> > > > leave ssh_authorized_key resource type way I want to know any other
> > > > chance.
> >
> > > A template would work.
> >
> > > You can also try simply pruning all unmanaged keys, so puppet will
> clear
> > > all unwanted stuff out. Take note that this will affect keys of *all*
> > > users (I believe), so you have to manage all keys on the system in
> question.
> >
> > > resources { "ssh_authorized_key": purge => true }
> >
> > > HTH,
> > > Felix
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Can Puppet detect if a user has changed a *.conf file and not do anything to that *.conf file?

[Brian Gallew]

I had exactly this situation: I wanted to manage application configuration,
but developers wanted to be able to alter the configs as necessary, yet
still revert to the "real" config when they wanted.  It's a snap with a
define{}:


# We would like to both distribute configuration files as well as
# enable the developers to make their own changes without having them
# overriden.  This define is for doing that.  You probably want to
# have good defaults set with File{} so that the file is created with
# the appropriate permissions.
#
# Usage:
#
# managed_file { "/export/home/geek/festus": source =>
"puppet:///modules/foo/bar" }
#
# In /export/home/geek, two files will be create: README.festus and
# festus-puppet.  The README file will contain a message telling the
# reader to touch festus.noupdate to prevent Puppet from updating the
# file.  As long as the festus.noupdate file does NOT exist, Puppet
# will ensure that festus matches festus-puppet.
#
define managed_file($source = undef, $content = undef) {
  $pdir = inline_template("<%= name.reverse().split('/',2)[1].reverse() %>")
  $basename = inline_template("<%= name.split('/')[-1] %>")

  file {
"${name}-puppet":
  source => $source, content => $content, ensure => present;
"${pdir}/README-${basename}":
  ensure => present,
  content => "${name} is managed by Puppet.\n\nIf you need to
edit\n${name}\nand have your changes persist, touch\n${name}.noupdate\nand
Puppet will ignore that file.  When you are done with your\ntesting, please
have your changes put in Puppet and delete the\n${name}.noupdate\nfile.
 Thanks.\n\n";
  }

  exec {
"${name}-sync":
  unless => "test -f ${name}.noupdate || cmp -s ${name} ${name}-puppet",
  command => "/usr/local/bin/rsync -a ${name}-puppet ${name}",
  require => File["${name}-puppet"];
  }
}


On Thu, Jun 14, 2012 at 11:09 AM, Nick Fagerlund <
nick.fagerl...@puppetlabs.com> wrote:

>
>
> On Thursday, June 14, 2012 6:00:21 AM UTC-7, PorkCharSui wrote:
>>
>> ... can Puppet detect if a user has changed a *.conf file him(her)self
>> and NOT do anything to that *.conf file?
>>
>
> Nope! Puppet has no good way to tell the difference between:
>
>- A user using sudo to deliberately change a file,
>- A rogue or malicious process overwriting the file,
>- A package update replacing the file with a boilerplate one that
>lacks the modifications you need
>
> As far as I know, that kind of knowledge always has to come from
> out-of-band; there's nothing intrinsic in the file that can tell you about
> intent.
>
> But so anyway. Some possible approaches:
>
>- Investigate the file type's replace => false capability, for
>initializing files and then not managing content afterwards.
>- If you're comfortable having users able to edit their puppet.conf
>files, use environments. If a user changes their environment from
>"production" to "manual," you can have a selector statement in all of your
>conf file resources that sets the source (or content) to undef, which makes
>it unmanaged. This is good because environments show up in reports, so you
>can tell how many of your users have switched into manual mode.
>- If you aren't comfortable with opening up puppet.conf, you could
>also do the same thing with a fact, using the facts.d plugin in the
>puppetlabs-stdlib module. (Facts.d lets you treat the contents of a plain
>text file as a custom fact, and then expose that text files to users as a
>config file.)
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/nSkZNChOpokJ.
>
> To post to this group, send email to puppet-users@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.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] can we avoid notify/subscribe firing on a mode change?

[Brian Gallew]

I certainly don't see any value there.  You need to come up with a
non-strawman argument.

Configuration management is about consistency.  Every system is like every
other system to the extent that is possible.  Where it is not possible, you
describe that difference in the manifests such that it affects the minimum
number of systems.  If, because of a mistake in your design, you later need
to go through and change everything, you've got a couple alternatives:
1) Do the change in two stages, where in the first stage you make the
change while at the same time removing any relevant Notify/Subscribe
clauses, and then after that is applied, you put the Notify/Subscribe
clauses back.
2) Make your change in the manifests and use a tool like Func or
MCollective or whatever to make the real change everywhere.
3) Trust that a rolling restart of your services is OK (because if it's
not, then you've probably screwed everything up even worse than you think).
4) Learn how to use selectors, quite possibly combined with
inline_templates or better yet, real data sources like Hiera, to limit the
changes.

Personally, I've done one green field Puppet implementation and two
retrofits, and guess what?  I've wanted to fix file ownership/group/mode in
the first month of all three, and after that never needed to go back and do
that, and the initial fixups were due to mistakes on my part (like failure
to set reasonable defaults for File{}s in a module).

On Thu, Jun 14, 2012 at 12:29 PM, Jo Rhett  wrote:

> On Jun 14, 2012, at 8:51 AM, David Schmitt wrote:
>
> When something changes the service has to be notified.
> When the service should not be restarted, puppet should not be running or
> the Service%restart parameter should be set to /bin/true.
>
>
> That's far too black/white for any real world scenario. Puppet not running
> just means it will catch it when it is, so that's not useful. And setting
> the restart parameter to bin/true would prevent content changes from
> restarting the process which defeats the purpose.
>
> You don't see any value in letting a service definition decide which
> things it cares to subscribe to -- like content, versus mode?
>
> --
> Jo Rhett
> Net Consonance : net philanthropy to improve open source and internet
> projects.
>
>
>
>  --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Nagios hostgroup collation

[Brian Gallew]

As one who has previously used Puppet to drive Nagios configurations (and
attempted to contribute patches to Puppetlabs), allow me offer a somewhat
fabulous alternative: check_mk.  check_mk is a package that can be used to
generate your Nagios configuration in a programmatic fashion.  Here's how
it works for my site:

1) Puppet runs on every host export three files: ${hostname}.mk,
${hostname}.mk.wato, and ${hostname}.parents.mk as well as ensuring that
the check_mk agent is installed, along with our local extensions.
2) Those files are collected on the appropriate Nagios server using tags
and the spaceship operator in a no-replace operation.
3) If new files get written, an exec{} gets kicked off that runs the
check_mk inventory against the new hosts and regenerates the Nagios
configuration.

Step three is where most of the magic happens.  As an example, our check_mk
configuration files specify that hosts named with "c2h" are Resin
application servers.  check_mk will automatically assign the three
web-based checks (port 80 HTTP, port 443 HTTPS, and a /resin-status URL
that gets parsed for app server data).

The programmatic decision on checks makes lots of stuff easy.  Inventory
makes some of the stuff even better.  As an example, ever notice that every
time you use a different network configuration (1-2-3 NICs, bonding,
VLANs), you need to do separate checks and write extra rules?  The
inventory catches all of the current network configuration and watches
that, and any changes will show up as an appropriate notification (in our
case, we chose to mark those as UNKNOWN).  You can also choose to have
weighting on your disks, i.e. a 4GB disk alarms at ~75% utilization while a
30TB filesystem doesn't alarm until it hits ~98%.  The weighting is done
with a strict formula, and isn't always appropriate, but for our
environment it works very well.

On Tue, Jun 12, 2012 at 4:34 PM, Jared Ballou  wrote:

> Hi everyone,
>
> I am reconsidering how I am using the Puppet nagios functionality, at
> the moment I am creating one service for each check on each host. A
> lot of them are identical, and would be better tied to hostgroups to
> simplify my config. Namely, I have about 5,000 checks in there now
> which will go up to about 20K over the next month, and it's taking
> about 5-10 minutes for a Puppet agent run on the nagios server now.
> I've tried running through the spaceship operator to collect hostgroup
> members or assign groups to hosts at realization time, but I can't get
> it working. Does anyone have this sort of setup done for me to poke
> at, or am I stuck with making an object for each check?
>
> Thanks,
>
> -Jared
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Adding files to file server on Puppet Master from a client

[Brian Gallew]

So, yeah, you're doing it wrong.

Really, you probably want to be running something like archiva and have the
clients install from there, but I'm going to guess that's not really
possible for you.

I presume that "done by a script being run (puppetd -onetime) but it should
be run on the client" really means, "run on the puppet client that is
actually either the build server or some destination host".  If that's the
case, the script could be an scp (with the right ssh keys installs), or a
copy to an NFS-mounted filesystem.  Theoretically, it's also possible to
set up a Puppet file server on the client in question, in which case the
file can just be moved around locally, but I have no experience with
actually doing that.

On Tue, Jun 12, 2012 at 7:50 AM, Mark Baxter  wrote:

> HI.
>
> Firstly, I'm bound to be doing something utterly basically wrong here, so
> if I am I apologise.
>
> Right now I have a fairly simple setup where the JAR files for a
> Weblogic-based application server are stored in the file server on my
> Puppet Master. I run scripts on the client that downloads the files from
> the file server, puts them in the right place etc etc. All very simple. I
> am now trying to automate the other side, getting the files into the file
> server. I've looked all over the place online and I just can't seem to find
> any answers.
>
> Basically, the JAR files are in a zip file on another server. Right now I
> have to manually download it and place the files in the right place on the
> file server. Instead I'd like Puppet to do this for me.
>
> The awkward bit is that due to annoying internal office politics this not
> only has to be done by a script being run (puppetd -onetime) but it should
> be run on the client (due to access control for who may have to run the
> scripts) and not on the Puppet Master. So is there any way to, from a
> client, trigger the Puppet Master to download a file to update the files on
> the file server? I realise that what could be done is that the client
> downloads the zip locally, instead of from the file server, but ideally I'd
> like to download only once due to the possibility of changes being made to
> the zip file between downloads.
>
> Thanks in advance to anyone that can help or point out what I
> am doing wrong ;o)
>
> /Mark
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/-L_tagstm-sJ.
> To post to this group, send email to puppet-users@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.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Announce: PuppetDB 0.9.0 (first release) is available

[Brian Gallew]

I'm a long-term PostgreSQL fan, but MySQL has one feature that makes it a
hands-down winner in our environment: trivial replication.  I have
puppetmasters in two different datacenters.  Being able to have my
dashboard see the status of systems in both datacenters makes it a lot more
useful to the team.  The PostgreSQL alternatives just don't work nearly as
well, nor as transparently.

On Tue, May 22, 2012 at 11:34 AM, Nick Lewis  wrote:

> On Tuesday, May 22, 2012 8:26:22 AM UTC-7, Brice Figureau wrote:
>>
>> On Mon, 2012-05-21 at 15:39 -0600, Deepak Giridharagopal wrote:
>> > On Mon, May 21, 2012 at 2:04 PM, Marc Zampetti
>> >  wrote:
>>
>> >Why wouldn't a DB-agnostic model be used?
>> >
>> >
>> > The short answer is performance. To effectively
>> > implement things we've
>> > got on our roadmap, we need things that (current)
>> > MySQL doesn't
>> > support: array types are critical for efficiently
>> > supporting things
>> > like parameter values, recursive query support is
>> > critical for fast
>> > graph traversal operations, things like INTERSECT are
>> > handy for query
>> > generation, and we rely on fast joins (MySQL's nested
>> > loop joins don't
>> > always cut it). It's much easier for us to support
>> > databases with
>> > these features than those that don't. For fairly
>> > divergent database
>> > targets, it becomes really hard to get the performance
>> > we want while
>> > simultaneously keeping our codebase manageable.
>> >
>> >
>> > I understand the need to not support everything. Having
>> > designed a number of systems that require some of the features
>> > you say you need, I can say with confidence that most of those
>> > issues can be handled without having an RDBMS that has all
>> > those advanced features. So I will respectfully disagree that
>> > you need features you listed. Yes, you may not be able to use
>> > something like ActiveRecord or Hibernate, and have to
>> > hand-code your SQL more often, but there are a number of
>> > techniques that can be used to at least achieve similar
>> > performance characteristics. I think it is a bit dangerous to
>> > assume that your user base can easily and quickly switch out
>> > their RDBMS systems as easy as this announcement seems to
>> > suggest. I'm happy to be wrong if the overall community thinks
>> > that is true, but for something that is as core to one's
>> > infrastructure as Puppet, making such a big change seems
>> > concerning.
>> >
>> >
>> > We aren't using ActiveRecord or Hibernate, and we are using hand-coded
>> > SQL where necessary to wring maximum speed out of the underlying data
>> > store. I'm happy to go into much greater detail about why the features
>> > I listed are important, but I think that's better suited to puppet-dev
>> > than puppet-users. We certainly didn't make this decision cavalierly;
>> > it was made after around a month of benchmarking various solutions
>> > ranging from traditional databases like PostgreSQL to document stores
>> > like MongoDB to KV stores such as Riak to graph databases like Neo4J.
>> > For Puppet's particular type of workload, with Puppet's volume of
>> > data, with Puppet's required durability and safety requirements...I
>> > maintain this was the best choice.
>> >
>> > While I don't doubt that given a large enough amount of time and
>> > enough engineers we could get PuppetDB working fast enough on
>> > arbitrary backing stores (MySQL included), we have limited time and
>> > resources. From a pragmatic standpoint, we felt that supporting a
>> > database that was available on all platforms Puppet supports, that
>> > costs nothing, that has plenty of modules on the Puppet Forge to help
>> > set it up, that has a great reliability record, that meets our
>> > performance needs, and that in the worst case has free/cheap hosted
>> > offerings (such as Heroku) was a reasonable compromise.
>>
>> I didn't had a look to the code itself, but is the postgresql code
>> isolated in its own module?
>>
>> If yes, then that'd definitely help if someone (not saying I'm
>> volunteering :) wants to port the code to MySQL.
>>
>> On a side note, that'd be terriffic Deepak if you would start a thread
>> on the puppet-dev explaining how the postgresql storage has been done to
>> achieve the speed :)
>>
>
> I'm working on putting together an in-depth look into the technology
> inside PuppetDB, as well as everything we've done to make it fast. That
> should be coming soon.
>
>
>> --
>> Brice Figureau
>> Follow the latest Puppet Community evolutions on www.plan

Re: [Puppet Users] override resource created with create_resource function

[Brian Gallew]

Your requirements are moving you to the "must use an ENC or Hiera or Ruby
DSL" camp.  Puppet's static typing will absolutely prevent you from doing
this the way you seem to be thinking about it.  At this point, your easiest
answer is probably to use Hiera for looking up the value of this hash.

On Mon, May 14, 2012 at 1:08 AM, Luke Bigum  wrote:

> Hi Nan,
>
> Thanks for the reply. I did start thinking about how I could use the merge
> function to achieve what I wanted. I was messing around with something like
> this (which obviously doesn't work because of the inheritance order):
>
> ---
>
> $hash = { 'msg' => { message => 'woof' } }
>
> class base($more_hash = undef) {
>  if ($more_hash) {
>$real_hash = merge($more_hash, $hash)
>  } else {
>$real_hash = $hash
>  }
>  create_resources('notify', $real_hash)
> }
>
> class over inherits base {
>  $more_hash = { 'msg' => { message => 'meow' } }
> }
>
> class { 'base': }
> class { 'over': }
> 
>
> This question relates to my other post about a sysctl class. In my case
> I'd like the create_resources call to always reside within class 'base' as
> that would be a standard declaration on all nodes - and that's my real
> problem. Class 'base' can't be in a standard list of declarations if it's
> ever going to take a parameter and be configurable. I have yet to find the
> perfect balance of common things to manage and configurability ;-)
>
> -Luke
>
>
> On 11/05/12 18:29, Nan Liu wrote:
>
>> On Fri, May 11, 2012 at 3:57 AM, Luke Bigum  wrote:
>>
>>> Hello,
>>>
>>> Is it possible to override a resource that is created with the
>>> create_resource function?
>>>
>>> This manifest does not compile:
>>>
>>> --
>>> $hash = { 'msg' =>  { message =>  'woof' } }
>>>
>>> class base {
>>>  create_resources('notify', $hash)
>>> }
>>>
>>> class over inherits base {
>>>  Notify['msg'] { message =>  'meow' }
>>> }
>>>
>>> class { 'base': }
>>> class { 'over': }
>>> -
>>>
>> You can't declare both classes, but you can override resources in
>> class over, because we can merge hash values before calling create
>> resource.
>>
>> The example here is obviously contrived, but I assume you have a
>> bigger hash you want to merge. The merge function comes from stdlib:
>>
>> # don't inherit base we can create the resources here instead.
>> class over {
>>   $local_setting = { 'msg' =>  { message =>  'meow'} }
>>   $newhash = merge($local_setting, $hash)
>>   create_resource('notify', $newhash}
>> }
>>
>> Thanks,
>>
>> Nan
>>
>>
>
> --
> Luke Bigum
>
> Information Systems
> Ph: +44 (0) 20 3192 2520
> luke.bi...@lmax.com | http://www.lmax.com
> LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN
>
>
> FX and CFDs are leveraged products that can result in losses exceeding
> your deposit.  They are not suitable for everyone so please ensure you
> fully understand the risks involved.  The information in this email is not
> directed at residents of the United States of America or any other
> jurisdiction where trading in CFDs and/or FX is restricted or prohibited
> by local laws or regulations.
>
> The information in this email and any attachment is confidential and is
> intended only for the named recipient(s). The email may not be disclosed
> or used by any person other than the addressee, nor may it be copied in
> any way. If you are not the intended recipient please notify the sender
> immediately and delete any copies of this message. Any unauthorised
> copying, disclosure or distribution of the material in this e-mail is
> strictly forbidden.
>
> LMAX operates a multilateral trading facility.  Authorised and regulated
> by the Financial Services Authority (firm registration number 509778) and
> is registered in England and Wales (number 06505809). Our registered
> address is Yellow Building, 1A Nicholas Road, London, W11
> 4AN.
>
> --
> 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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] White list of packages

[Brian Gallew]

Rather than whitelisting packages, you probably want to build a severely
cut-down repository and ensure it's the only one configured for your box.
On May 1, 2012 1:40 PM, "bainar"  wrote:

> Can anyone tell me if it is possible to explicitly specify the only
> allowed packages on a host (modules on a node?) - i.e. a white list?
> This is for hardening a VPS in the cloud.
>
> Thanks in advance
> Andrew
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Need puppet module for condition copy

[Brian Gallew]

You can't put a file{} resource inside an exec{} resource.


On Thu, Apr 12, 2012 at 7:53 AM, Munna S <19.mu...@gmail.com> wrote:

> Hi Brian,
>
> below is my updated init.pp file. but i am getting the error as
>
> Apr 12 14:49:51 pil-vm-pup-01 puppet-master[14586]:
> (//vm-jeeva2.aircell.prod/Puppet) Could not retrieve catalog from remote
> server: Error 400 on SERVER: Could not find class dev_jboss_jeeva for
> vm-jeeva2.aircell.prod at /etc/puppet/manifests/nodes/jeeva_base.pp:2 on
> node vm-jeeva2.aircell.prod
> Apr 12 14:49:51 pil-vm-pup-01 puppet-master[14586]:
> (//vm-jeeva2.aircell.prod/Puppet) Using cached catalog
> Apr 12 14:49:51 pil-vm-pup-01 puppet-master[14586]:
> (//vm-jeeva2.aircell.prod/Puppet) Could not retrieve catalog; skipping run
> my init.pp file
>
> class dev_jboss_jeeva {
> exec {
> onlyif => "test -d /opt/xyz"
>
> file { "/opt/xyz/file.txt":
> owner => "jboss",
> group => "jboss",
> source => "puppet://$puppetserver/modules/module_name/opt/xyz/file.txt",
> }
> }
> }
>
> Thanks,
> Jeeva
> On Thu, Apr 12, 2012 at 9:24 AM, Brian Gallew  wrote:
>
>> Another alternative is to unconditionally copy the file to a staging
>> director (e.g. /var/staging) and then have
>>
>> exec {
>>   "conditional copy to path1":
>> onlyif => "test -d /opt/path1"
>> command => "rsync -a /var/staging/file.txt /opt/path1";
>>   "conditional copy to path2":
>> onlyif => "test -d /opt/path2"
>> command => "rsync -a /var/staging/file.txt /opt/path2";
>>   "conditional copy to path3":
>> onlyif => "test -d /opt/path3"
>> command => "rsync -a /var/staging/file.txt /opt/path3";
>> }
>>
>> For neatness' sake, you could turn that into a define{}
>>
>> On Thu, Apr 12, 2012 at 7:18 AM, Munna S <19.mu...@gmail.com> wrote:
>>
>>> Hi  Gary,
>>>
>>> I created a custom fact path_to_check.rb and placed it under
>>> .../module_name/lib/facter
>>>
>>> below is my init.pp file
>>>
>>> class class_name
>>> if $path_to_check == present{
>>> file { "/opt/xyz/file.txt":
>>> owner => "jboss",
>>> group => "jboss",
>>> source =>
>>> "puppet://$puppetserver/modules/module_name/opt/xyz/file.txt",
>>>  }
>>> }
>>> }
>>> But  i dont see files are getting pushed
>>> On Sun, Apr 1, 2012 at 11:08 PM, Munna S <19.mu...@gmail.com> wrote:
>>>
>>>> Thank you so much Gary. I will try this
>>>>
>>>> Thanks,
>>>> Jeeva
>>>>
>>>> On Sun, Apr 1, 2012 at 11:05 PM, Gary Larizza wrote:
>>>>
>>>>> Jeeva,
>>>>>
>>>>> Your custom fact would do something like:
>>>>>  File.directory?('/path/to/check')  that returns true or false depending 
>>>>> on
>>>>> whether the directory existed.  Your fact would return a true or false
>>>>> value (so if the custom fact were named 'path_to_x' you would do something
>>>>> like this in your init.pp
>>>>>
>>>>> if $path_to_x == 'true' {
>>>>>   # Do something here
>>>>> } else {
>>>>>   # Do something else here
>>>>> }
>>>>>
>>>>> Do this for every custom fact (corresponding to the paths you want to
>>>>> check) in your manifest, or combine them into one giant if statement like:
>>>>>
>>>>> if ($path_to_x == 'true') or ($path_to_y == 'true') {
>>>>>   # Do something
>>>>> }
>>>>>
>>>>> Does this make sense?
>>>>>
>>>>>
>>>>> On Sun, Apr 1, 2012 at 8:48 PM, Munna S <19.mu...@gmail.com> wrote:
>>>>>
>>>>>> Hi Gary,
>>>>>>
>>>>>> How i can put this in my init.pp file. Actually i am checking for the
>>>>>> path. if path found then copy the file else dont create any file/folder. 
>>>>>> So
>>>>>> here i need to check for 3 different path on each server. if any of the
>>>>>> belo

Re: [Puppet Users] Re: Need puppet module for condition copy

[Brian Gallew]

Another alternative is to unconditionally copy the file to a staging
director (e.g. /var/staging) and then have

exec {
  "conditional copy to path1":
onlyif => "test -d /opt/path1"
command => "rsync -a /var/staging/file.txt /opt/path1";
  "conditional copy to path2":
onlyif => "test -d /opt/path2"
command => "rsync -a /var/staging/file.txt /opt/path2";
  "conditional copy to path3":
onlyif => "test -d /opt/path3"
command => "rsync -a /var/staging/file.txt /opt/path3";
}

For neatness' sake, you could turn that into a define{}

On Thu, Apr 12, 2012 at 7:18 AM, Munna S <19.mu...@gmail.com> wrote:

> Hi  Gary,
>
> I created a custom fact path_to_check.rb and placed it under
> .../module_name/lib/facter
>
> below is my init.pp file
>
> class class_name
> if $path_to_check == present{
> file { "/opt/xyz/file.txt":
> owner => "jboss",
> group => "jboss",
> source =>
> "puppet://$puppetserver/modules/module_name/opt/xyz/file.txt",
>  }
> }
> }
> But  i dont see files are getting pushed
> On Sun, Apr 1, 2012 at 11:08 PM, Munna S <19.mu...@gmail.com> wrote:
>
>> Thank you so much Gary. I will try this
>>
>> Thanks,
>> Jeeva
>>
>> On Sun, Apr 1, 2012 at 11:05 PM, Gary Larizza wrote:
>>
>>> Jeeva,
>>>
>>> Your custom fact would do something like:
>>>  File.directory?('/path/to/check')  that returns true or false depending on
>>> whether the directory existed.  Your fact would return a true or false
>>> value (so if the custom fact were named 'path_to_x' you would do something
>>> like this in your init.pp
>>>
>>> if $path_to_x == 'true' {
>>>   # Do something here
>>> } else {
>>>   # Do something else here
>>> }
>>>
>>> Do this for every custom fact (corresponding to the paths you want to
>>> check) in your manifest, or combine them into one giant if statement like:
>>>
>>> if ($path_to_x == 'true') or ($path_to_y == 'true') {
>>>   # Do something
>>> }
>>>
>>> Does this make sense?
>>>
>>>
>>> On Sun, Apr 1, 2012 at 8:48 PM, Munna S <19.mu...@gmail.com> wrote:
>>>
 Hi Gary,

 How i can put this in my init.pp file. Actually i am checking for the
 path. if path found then copy the file else dont create any file/folder. So
 here i need to check for 3 different path on each server. if any of the
 below path exist then copy the file.

 Thanks,
 Jeeva

 On Sun, Apr 1, 2012 at 10:41 PM, Gary Larizza wrote:

> Jeeva,
>
>
> I would make a custom fact (
> http://docs.puppetlabs.com/guides/custom_facts.html) that checks for
> the presence of these files.  Your Puppet manifest would check the
> condition of this fact to ensure the file absent or present (i.e. if
> $custom_fact { file { '/path/to/file': ensure => file } } ).
>
>
> Does that make sense?
>
>
>
> On Sun, Apr 1, 2012 at 8:37 PM, Munna S <19.mu...@gmail.com> wrote:
>
>> Team,
>>
>> Any help
>>
>> Thanks,
>> Jeeva
>>
>> On Fri, Mar 30, 2012 at 12:51 PM, Munna S <19.mu...@gmail.com> wrote:
>>
>>> Team,
>>>
>>> I need a puppet module to copy a file to different location based on
>>> condition check . Below is my requirement
>>>
>>> if /opt/path1 found on the server  then copy file1
>>> if /opt/path2 found on the server then copy file1
>>> if /opt/path3 found on the server then copy file1
>>>
>>> if none of the above path found then dont copy file1
>>>
>>> Thanks,
>>> Jeeva
>>>
>>>
>>
>>  --
>> 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+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-users?hl=en.
>>
>
>
>
> --
>
> Gary Larizza
> Professional Services Engineer
> Puppet Labs
>
>  --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/puppet-users?hl=en.

>>>
>>>
>>>
>>> --
>>>
>>> Gary

Re: [Puppet Users] Re: Creating classes for individual nodes

[Brian Gallew]

I'm absolutely with John on this.  As an example, for our JBoss application
we need the configuration file to be different based on the the hostname
(we only host one app per host/VM) and environment
(dev/integration/qa/staging/production).  Further, some "dev" boxes need to
allow the developers to hand-update their configs.  So what I have is a
templated configuration file that has all the configuration information in
it for all the environments, and only the pertinent information gets
shipped to the Puppet client.  Further, I wrap this in a define{} so that
the file Puppet actually manages is "server.properties-default".  There is
an exec{} in the define which checks for a "server.properties-noupdate"
file.  If that file exists, the exec{} bails.  If it doesn't, then it
rsync's the -default file onto the "server.properties" file that JBoss
references.  Finally, the define{} also creates a
"server.properties-README" which tells the developer about how the file is
managed and what they can do if they want to override Puppet.


On Wed, Apr 11, 2012 at 1:52 PM, jcbollinger wrote:

>
>
> On Apr 11, 12:04 pm, Josh  wrote:
> > This is more of a style question than implementation. I have a bunch of
> > nodes running the same software but in many cases they need config files
> > that are customized for that specific node. I was thinking I could push
> all
> > the main files from the app through a central class and have separate
> > classes for each individual node that has the config files. Is this the
> > best way to do this or does it go against the purpose of using puppet?
>
>
> There is no inherent problem with that approach, but for a little
> extra effort you can get something that will be easier to maintain.
> I'm not a big fan of parameterized classes myself, but I heartily
> endorse an external data store, accessed via Hiera.  Instead of using
> per-node classes, record per-node data where needed.  You can use that
> data to fill templates, choose among alternatives in your manifests,
> set resource properties, etc..
>
>
> > Also, for implementation, is it best practice to create a separate module
> > and class for each node where the class includes only that module?
> Thanks.
>
>
> I would say not.  It might or might not make sense to put the per-node
> classes in the module with the main classes for the application in
> question, but I certainly see no reason to separate them from each
> other.  But the question is moot if you choose a cleaner strategy.
>
>
> John
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Multiple Nagios Servers

[Brian Gallew]

Every host is trying to create an exported resource named "foo-admins".
 That's not what you want.  You want a *virtual* resource named foo-admins
and then realize it on each node.

On Tue, Apr 10, 2012 at 3:19 PM, Robert Smith  wrote:

> Hello,
>
> I've been trying to build multiple Nagios servers using Puppet (2.6.12),
> with no luck.  I've got a nagios::server class that includes:
>
>   include nagios::server::commands
>   include nagios::server::contacts
>   include nagios::server::contactgroups
>   include nagios::server::timeperiods
>   include nagios::server::servicegroups
>   include nagios::server::hostgroups
>
> and then it does it's collection by running all the Nagios_command <<|
> |>>, Nagios_contactgroups <<| |>>, etc.
>
> In the contactgroups.pp manifest, for example, I have something like:
>
>   @@nagios_contactgroup {
> "foo-admins_${hostname}":
>   contactgroup_name => 'foo-admins',
>   alias => 'foo-admins',
>   members   => 'sysadmin1, sysadmin2';
>   }
>
> My thinking was that by including the _${hostname} in the resource name,
> that it wouldn't cause conflicts between servers.  However, when I run
> nagios::server on more than one system, I get err: Failed to apply catalog:
> Parameter alias failed: foo-admins can not create alias foo-admins: object
> already exists.
>
> Everything seems to be working on the @@nagios_host and @@nagios_service
> resources, which include $hostname in their resource names.
>
> Any help greatly appreciated.
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/wMSQVr2r1P8J.
> To post to this group, send email to puppet-users@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.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] local vs global variables

[Brian Gallew]

I would imagine this has to do with the whole, "you can't override
variables" thing that comes with a declarative language.  Truly, if you
want do to this you need to just change the variable names so they won't
conflict with the facter values.  This is the primary reason (IMO) that
example42 use my_ to prefix just about every variable they use.

On Fri, Mar 30, 2012 at 7:02 AM, Pablo Fernandez wrote:

> I have trying to dig more into this, and I found out the problem is not
> the scope of the variable, but hiera!
>
> So, it seems like hiera('netmask') is actually looking into the node's
> facts! Is this the expected behavior?
>
> This is my hiera.yaml:
> :backends:
>  - puppet
>
> :hierarchy:
>  - %{hostname}
>  - %{environment}
>  - group_%{group0}
>  - group_%{group1}
>  - group_%{group2}
>  - group_%{group3}
>  - group_%{group4}
>  - group_%{group5}
>  - group_%{group6}
>  - group_%{group7}
>  - group_%{group8}
>  - group_%{group9}
>
> :puppet:
>  :datasource: data
>
> Most of those classes don't even exist. And data::myhost certainly doesn't.
>
> And the place it should be looking into the right variable is:
> class data::group_all {
>$netmask = "255.255.252.0"
> }
>
> (in this case, $group1='all')
>
> I have tried, for the sake of testing, to change the variable to something
> different (and the hiera lookup) and it does the right thing, so I am quite
> sure it's actually conflicting with the "netmask" fact.
>
> Any ideas?
>
> Thanks!
> Pablo
>
>
> On 03/30/2012 11:59 AM, Pablo Fernandez wrote:
>
>> Hi,
>>
>> I have just found something very weird. I define this:
>>
>> define networking::basic_interface ($ip, $netmask = hiera('netmask'),
>> $gateway = hiera('gateway')) {
>>file { "/etc/sysconfig/network-**scripts/ifcfg-${name}" :
>>content => "DEVICE=${name}\nIPADDR=${ip}\**
>> nNETMASK=${netmask}\nGATEWAY=$**{gateway}\nONBOOT=yes\n",
>>mode  => '0644', owner => 'root', group => 'root',
>>}
>> }
>>
>> And create the resource doing:
>> networking::basic_interface { "eth0:0": ip => '1.2.3.4' }
>>
>> So, the variables $netmask and $gateway should pick up their default
>> values, that are taken from Hiera. But then, when I apply the manifests in
>> the node, the value picked up is the one from Facter.
>>
>> To summarize: the content of the file takes ${netmask} which is a
>> parameter of the define, but it turns out that the fact $::netmask has
>> preference over it. How is it possible?
>>
>> Thanks!
>> Pablo
>>
>>
> --
> 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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Upgrading puppet - upgrade O/S of puppet master but leave clients on older version?

[Brian Gallew]

You're very welcome.  The stepwise upgrade previously mentioned is a little
tedious, but it's safe and, if you collect and watch your logs, it will
give you the chance to see how new versions are looking at old manifests
(think deprecation warnings).

On Thu, Mar 29, 2012 at 10:48 PM, Richard  wrote:

>
>
> On Friday, 30 March 2012 06:43:17 UTC+1, Brian Gallew wrote:
>>
>>
>>
>>> Thanks Justin!
>>>
>>> If we go with the stepped approach, would the following work?
>>>
>>> Puppet Master running 2.6.x on RHEL 6.2, serving 2.5.x clients on RHEL
>>> 5?  Do the different versions of Ruby come into play at all?
>>>
>>>
>> You're not thinking about this clearly.  As long as the puppet clients
>> are no more than one major revision behind the master AND they are running
>> on a supported version of ruby for the client system, there is no issue.
>>  Puppet is designed so that the master and the clients are unrelated except
>> insofar that the master is the single point of truth for configurations.
>>  Otherwise, you would have to have a separate Puppet master running on
>> Windows, AIX, Solaris, RHEL4, RHEL5, Debian Squeeze, Debian Etch, Gentoo,
>> etc., one for each client OS.  I run my puppet masters on Solaris 10
>> (only), and have clients on Solaris 10, CentOS 5.5, Ubuntu 10.04, RHEL5,
>> and AIX.
>>
>>
> Perfect - thanks for clarifying.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/IIlP1CtUJVYJ.
>
> To post to this group, send email to puppet-users@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.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Suggestion - puppet preload stage?

[Brian Gallew]

I just did a 2.6.11 -> 2.7.12 migration with Puppet updating Puppet.  The
only real hitch I ran into was my puppet masters would update themselves
but somehow Apache/Passenger didn't get restarted, so I had to do that by
hand.  Since I didn't start putting any 2.7 features into my manifests
until *after* the 2.7 upgrade, the clients basically just upgraded
themselves.  And while I do have puppet running as a daemon, it's with
no-schedule, and the "real" run happens out of cron.  I think I'm actually
going to kill off the daemon as it offers no benefit to me (and frequently
wedged when I let it schedule updates).  Doing it in cron allows me to meet
externally imposed scheduling restrictions (no changes while production is
running).

On Thu, Mar 29, 2012 at 10:42 PM, Ken Barber  wrote:

> Hi Amos - its been a long long long time mate :-).
>
> > example for (1): Our vagrant (http://vagrantup.com/) dev base boxes
> > still come with Puppet 2.6.3 while the manifest depends on Puppet 2.7
> > features. I can manually upgrade puppet manually (and that's what I do
> > on dev), but when the time to deploy to production comes it
> > practically means that I have to manually upgrade Puppet to 2.7 on all
> > hosts before I push the change.
>
> You know - I've generally just used mcollective with the puppetral
> plugin to do the Puppet agent RPM/deb upgrade in the case where the
> client is the wrong version, and can now no longer interact with my
> master:
>
>
> http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/AgentPackage
> https://github.com/puppetlabs/mcollective-plugins/tree/master/agent/package
>
> At the end of the day, it uses the Puppet resource abstraction layer
> anyway behind the scenes, only difference is that it is making the
> change directly without the Puppet master interaction. But I can see
> why you would want Puppet to just deal with this on its own.
>
> > 1. Provider exists but has to be updated.
>
> I could be mistaken about what I'm about to say, as I haven't
> experimented with this new behaviour all that much. I wouldn't take my
> word for it - so experiment and see :-).
>
> Surely the lazy evaluate solves this, I could be wrong - but if you
> build up a relationship between the action that does the update - and
> the provider that users that update then the update should occur
> first. Then when the provider is evaluated lazily - all is well - it
> has a new updated command/library/whatever?
>
> So:
>
> package { "daemontools":
>  ensure => "1.2.3",
> }
> Service {
>  require => Package["daemontools"]
> }
>
> Is a rough way of doing it, but the default _is_ of course generic
> here, and run stages may be a better solution - as its easier to have
> your 'require's changed/overridden later on. (because defaults don't
> stack with overrides).
>
> > 2. Puppet version update.
>
> Updating Puppet can be tricky, from an agent perspective if you run it
> as a daemon there was a problem when updating to the recent Facter
> 1.6.6 for example - as parts of Facter are loaded/evaluated
> dynamically each (ie. the facts) - while others are loaded and cached
> and never re-evaluated. This created a problem with I believe the ec2
> fact from memory - which started to use a library in facter/util/ec2
> (yes my fault). In that edge case you need to probably force a restart
> of an agent after the package update really. Its crap I agree ... and
> I'm all ears for a better solution/policy generally.
>
> From the master perspective - you can run into similar scenarios as
> well. Generally speaking, the 'puppet managing puppet' case is always
> hard mate. I always spend the most amount of time helping clients
> 'manage' their puppetmaster with Puppet. And their are lots of
> strategies here :-).
>
> What are you hitting that is problematic at the moment? Or what in
> particular do you see?
>
> > 3. Configuration files - missing or have to be updated.
>
> Again, build up the dependencies using relationships in Puppet - as
> per 1. Should work in a similar manner (from the description of the
> new feature that is).
>
> > 4. Other types of configurations which have to take place, e.g. add a
> > network link (e.g. VPN, proxy),
>
> Same again.
>
> > or make any other arbitrary change which can
> > affect the rest of the puppet run (or future puppet runs).
>
> You might be getting into the 'manage the puppet case', again -
> anything specific you expect?
>
> > What I'm thinking about is a generic way to say "OK, now I'm finished
> doing
> > all sorts of tweaks to the system, please start puppet and take these
> tweaks
> > into consideration".
> >
> > Is that possible?
>
> To be absolutely honest with you - up until now, this has been done
> with pre-puppet stuff. That is - done with kickstart, jumpstart or
> whatever you use to build the system. Of course, this then becomes
> non-idempotent which makes Puppet less useful overall.
>
> Dude - try the lazy evaluate with the edge cases you've been seeing
> an

Re: [Puppet Users] Upgrading puppet - upgrade O/S of puppet master but leave clients on older version?

[Brian Gallew]

On Thu, Mar 29, 2012 at 10:23 PM, Richard  wrote:

>
> Thanks Justin!
>
> If we go with the stepped approach, would the following work?
>
> Puppet Master running 2.6.x on RHEL 6.2, serving 2.5.x clients on RHEL 5?
> Do the different versions of Ruby come into play at all?
>
>
You're not thinking about this clearly.  As long as the puppet clients are
no more than one major revision behind the master AND they are running on a
supported version of ruby for the client system, there is no issue.  Puppet
is designed so that the master and the clients are unrelated except insofar
that the master is the single point of truth for configurations.
 Otherwise, you would have to have a separate Puppet master running on
Windows, AIX, Solaris, RHEL4, RHEL5, Debian Squeeze, Debian Etch, Gentoo,
etc., one for each client OS.  I run my puppet masters on Solaris 10
(only), and have clients on Solaris 10, CentOS 5.5, Ubuntu 10.04, RHEL5,
and AIX.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: @@file tricks..

[Brian Gallew]

I do check_mk configuration and Netbackup work via this method.

On Mon, Mar 5, 2012 at 1:57 PM, windowsrefund wrote:

>
> This is exactly how I handle things.
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Developers having access to deploy

[Brian Gallew]

I did up a nifty deployment engine using Jenkins.  Give the devs/CM a form
(e.g. "silo", application versions, etc).  It would figure out what it
needed to deploy and then do so, complete with telling the Nagios system to
disable checks while everything was going on.  Foreman/Puppet could be the
right tool for a *production* environment, particularly if your
applications can be deployed piecemeal, but doing it for dev seems like it
would add increased overhead without any real benefit.

On Fri, Mar 2, 2012 at 12:15 PM, Adam Heinz  wrote:

> We do something similar to what you describe with foreman (which can
> be used as an ENC).  The user sets the my-app-version parameter on the
> node, then runs puppet on that node.  The main drawback is that
> foreman does not currently have a permission for puppetrun, so the
> users have to be admins, so I have a test puppet master for this
> purpose.
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Puppet Master VMs

[Brian Gallew]

Also, there are some known issues with certain Ruby builds that cause the
puppet daemon to randomly hang.  Sometimes it's best to have cron run your
puppet jobs.

On Thu, Mar 1, 2012 at 3:01 PM, Alexander Swen  wrote:

> Thanks Markus, that's a very usefull tip. will follow!
>
>
>
>> # Whether to sleep for a pseudo-random (but consistent) amount of time
>> before
>> # a run.
>> # splay = false
>>
> best regards, Alex
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/nwAfDpOddOUJ.
>
> To post to this group, send email to puppet-users@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.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Creating domain zone files

[Brian Gallew]

Allow me to offer a couple of alternatives:
1) If Puppet is not otherwise doing stuff with the domains, then stop
trying to manage the bind configs purely with Puppet.  Instead, have your
configs in revision control (best practice) and have the puppet run do an
update/reload (e.g. have the exec something like onlyif =>"bzr status",
command => "bzr update", notify => Service["bind9"]
2) Use augeas to ensure the appropriate include stanza appreas in your
zones.conf file, and have the included fragment be generated via template
on Puppet.
3) Use R.I.P.'s snippets extension to construct your zone file from whole
cloth.
4) if you are using storedconfigs AND your zones are tied into your
infrastructure appropriately, it might be nice to collect exported
resources (files) on the DNS servers.

To give you something of an example of #4, I want to see that NetBackup is
installed on all my servers.  However, doing so requires the execution of a
script from the Netbackup server.  So each host checks the installed
Netbackup version against the configured version.  If they differ, and
*only* then, they will export an exec{} that will be collected (and run) on
the Netbackup server.  What this means is that the only time my Netbackup
server runs any execs is when I either upgrade Netbackup or add a new host.

You could do something similar.  If you DNS zones are, for instance, tied
to, say, web services, when the web service configures, it could do a DNS
lookup.  If the results of that lookup are not satisfactory, it could then
export the appropriate updates for use on the DNS servers.

On Tue, Feb 28, 2012 at 2:43 PM, Mailing Lists wrote:

> I'm currently looking for a more efficient method of creating domain zone
> files.  At the moment I have a shell script that I run to create the domain
> zone, then add the domain to puppet define list so it'll know to add the
> domain to the dns servers.
>
> The new method I'm working on, I add the domain to a puppet define, then
> let puppet run the shell script for me to create the zone file.  Only
> problem once its done validating that the domain exists are not (using the
> shell script) its about 55 minutes when complete!
>
> Below is what I've written and I'll add comment along the way.  If any has
> any suggestions of how I can make it complete faster, I'm all ears!
>
> class s_domain {
> # This is where I add the domain to define the new domain, I will
> paste the code below...
> include s_domain::all_zone
>
> # The shell script that runs to create the zone file
> file {
> "domain.sh":
> mode => 700, owner => root, group => root,
> ensure => present,
> path => "/root/domain.sh",
> source => "puppet://$servername/s_domain/domain.sh",
> }
># The text that puppet looks at before running the domain.sh script
> file {
> "zones":
> mode => 600, owner => root, group => root,
> ensure => present,
> replace => true,
> path => "/root/zones",
> }
># It creates the file for domain.sh
> exec { "domain_check":
> command => "/bin/ls /var/shared/bind/zones > /root/zones",
> logoutput => true,
> }
>
> }
>
>  # Taking the information from the include to define
> define s_domain::zones($domains) {
>
> s_domain::zonefile { $domains: }
>
> file { "/var/named/chroot/etc/zones.conf":
> owner   => "named",
> group   => "named",
> mode=> "0644",
> }
> }
> # File it creates with the domain.sh script
> define s_domain::zonefile() {
> file { $name:
> path => "/var/shared/bind/zones/$name.zone",
> owner => "root",
> group => "root",
> mode  => "0644",
> }
> # The domain.sh script runs only if the domain isn't in the zones
> file it create above
> exec { "domain $name":
> command => "/root/domain.sh $name",
> logoutput => true,
> unless => "/bin/grep -o $name /root/zones 2>/dev/null",
> }
> }
>
> INCLUDE code:
>
> class s_domain::all_zone {
> s_domain::zones { "company.com":
> domains => [ "thedomain.com", }
>   }
> }
>
> The above code is short, the whole list of domains we have is about 2,000,
> reason it takes so long.  I'm new to puppet coding, what I would like to do
> is not have file created or puppet using the "unless" variable.  I've been
> trying to figure how to get puppet to just look at the all_zone.pp file
> only, but haven't been able to figure a method to implement.  Thanks in
> advance!
>
>
>  --
> 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-u

Re: [Puppet Users] Questions regarding Puppet with httpd.conf

[Brian Gallew]

Further, you should remember that there is no reason for an Apache
configuration to be monolithic.  Apache is perfectly happy to have a bunch
of files to include.  Throw in a naming convention (e.g. files named
foo.ssl will be included by my SSL config file) and you've got some real
flexibility.

On Wed, Feb 8, 2012 at 5:56 PM, Michael Stahnke wrote:

> On Wed, Feb 8, 2012 at 3:46 PM, the_fonz 
> wrote:
> > Hi,
> >
> > I'd like to start using Puppet to manage an httpd.conf file across
> > several webservers. I have a Puppet server and client config setup and
> > have followed a couple of simple "How To's" to get off the ground. I'm
> > syncing a couple of files and ensuring certain packages are installed
> > etc on the client.
> >
> > Now, here 's where I'm stuck... what happens if the httpd.conf file is
> > slightly different on each webserver? For example, each httpd.conf
> > file has multiple Virtual Host entries that are defined by the
> > webservers IP.  for example.
>
> You'll want to look at http://docs.puppetlabs.com/guides/templating.html
>
> You can use a template and have it fill in variables.  Luckily, the
> host's IP address is already available as a variable via facter.
>
>
> >
> > How do I manage one httpd.conf file from the Puppet server given the
> > VirtualHost IP's will be different on each server? I guess I just want
> > to "taylor" the http.conf file for each weberserver but manage it from
> > the Puppet Server.
> >
> > If anyone can give me a few pointers it would be appreciated.
> >
> > Thanks,
> >
> > --
> > 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+unsubscr...@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] puppetd hanging on some nodes

[Brian Gallew]

If you are like me, the problem is that the ruby for your platform sucks.
 The webstack ruby 1.8.7 for Solaris 10 has a nasty tendency to hang (for
the daemons) and core dump for individual runs.  Individual runs out of a
crontab are the most reliable way I've found to make it all work.

On Tue, Feb 7, 2012 at 7:11 PM, Gonzalo Servat  wrote:

> Hi All,
>
> In my set-up, I've got a cron job that triggers a Puppet run every 20
> minutes. I've found that on approximately 13 nodes (out of 166),
> puppetd just hangs. I have to go in, kill the process, remove
> /var/lib/puppet/state/puppetdlock, and run puppet again and then it's
> fine.
>
> After a while, it just hangs again so I have to go in, kill the process,
> etc.
>
> Any ideas?
>
> Thanks!
> Gonzalo
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Puppet Triage-A-Thon

[Brian Gallew]

#4020 has been ready for 4 months now.  It really makes my efforts feel 
appreciated.

On Jan 10, 2012, at 10:20 AM, Daniel Pittman wrote:

> Those are high priority for the platform team anyhow, but if there is
> something you feel we have missed shoot me an email with the ticket
> number and I will try and get it bumped up in priority.
> 
> Daniel
> 
> On Tue, Jan 10, 2012 at 10:06, Brian Gallew  wrote:
>> Does this mean that the tickets which are just awaiting merge (including all 
>> the relevant unit tests) will get done some day soon?
>> 
>> On Jan 9, 2012, at 11:36 PM, James Turnbull wrote:
>> 
>>> Love Puppet? Hate the backlog of tickets? Want to help us out? The
>>> Puppet community has grown really fast and a lot of you have logged
>>> tickets and issues. We’ve tried to give those tickets as much love as we
>>> could but some slip through the cracks and sometimes we get overwhelmed.
>>> We’ve recognized this and want to try to get a handle on the backlog of
>>> tickets. But we need your help to do this.
>>> 
>>> What we’re going to do is hold a Triage-a-thon hosted locally in our
>>> offices, virtually on IRC (Freenode #puppethack) and the Web.
>>> 
>>> http://puppetlabs.com/events/triagepuppet/
>>> 
>>> We’re going to review all the open tickets in the Puppet project with a
>>> view to:
>>> 
>>> * Update and confirm that issues are still relevant
>>> * Ensure tickets are in the right status and all the right information
>>> is present to help us resolve it
>>> * Close any invalid or no longer relevant tickets
>>> 
>>> We’ll assign blocks of tickets to every participant, have documentation
>>> explaining what you need to do and provide people on the ground to help
>>> you make decisions and answer questions.
>>> 
>>> Triaging starts Saturday January 21st from 7am and last until 4pm (-8 GMT).
>>> 
>>> We’ll also provide pizza, snacks (and beer!) and a venue locally in our
>>> Portland, OR offices. Virtually we’ll provide an IRC channel, IM and
>>> rewards (t-shirts, patches, stickers, badges, and books) for people who
>>> triage tickets and get involved.
>>> 
>>> We’ll also offer Amazon Gift Cards to our top 3 participants!
>>> 
>>> You can register for the event here:
>>> http://triagepuppet.eventbrite.com/?ref=ebtn.
>>> 
>>> We hope you'll be interested in attending and helping us make Puppet better.
>>> 
>>> Thanks
>>> 
>>> James
>>> 
>>> --
>>> James Turnbull
>>> Puppet Labs
>>> 1-503-734-8571
>>> To schedule a meeting with me: http://tungle.me/jamtur01
>>> 
>>> --
>>> 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+unsubscr...@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+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/puppet-users?hl=en.
>> 
> 
> 
> 
> -- 
> ⎋ Puppet Labs Developer – http://puppetlabs.com
> ♲ Made with 100 percent post-consumer electrons
> 
> -- 
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Puppet Triage-A-Thon

[Brian Gallew]

Does this mean that the tickets which are just awaiting merge (including all 
the relevant unit tests) will get done some day soon?

On Jan 9, 2012, at 11:36 PM, James Turnbull wrote:

> Love Puppet? Hate the backlog of tickets? Want to help us out? The
> Puppet community has grown really fast and a lot of you have logged
> tickets and issues. We’ve tried to give those tickets as much love as we
> could but some slip through the cracks and sometimes we get overwhelmed.
> We’ve recognized this and want to try to get a handle on the backlog of
> tickets. But we need your help to do this.
> 
> What we’re going to do is hold a Triage-a-thon hosted locally in our
> offices, virtually on IRC (Freenode #puppethack) and the Web.
> 
> http://puppetlabs.com/events/triagepuppet/
> 
> We’re going to review all the open tickets in the Puppet project with a
> view to:
> 
> * Update and confirm that issues are still relevant
> * Ensure tickets are in the right status and all the right information
> is present to help us resolve it
> * Close any invalid or no longer relevant tickets
> 
> We’ll assign blocks of tickets to every participant, have documentation
> explaining what you need to do and provide people on the ground to help
> you make decisions and answer questions.
> 
> Triaging starts Saturday January 21st from 7am and last until 4pm (-8 GMT).
> 
> We’ll also provide pizza, snacks (and beer!) and a venue locally in our
> Portland, OR offices. Virtually we’ll provide an IRC channel, IM and
> rewards (t-shirts, patches, stickers, badges, and books) for people who
> triage tickets and get involved.
> 
> We’ll also offer Amazon Gift Cards to our top 3 participants!
> 
> You can register for the event here:
> http://triagepuppet.eventbrite.com/?ref=ebtn.
> 
> We hope you'll be interested in attending and helping us make Puppet better.
> 
> Thanks
> 
> James
> 
> -- 
> James Turnbull
> Puppet Labs
> 1-503-734-8571
> To schedule a meeting with me: http://tungle.me/jamtur01
> 
> -- 
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Puppet Dashboard and Ruby 1.8.7 for EL5 systems HOWTO (draft)

[Brian Gallew]

Very nice write-up, Jo.  Thanks.

On Wed, Jan 4, 2012 at 5:04 PM, Jo Rhett  wrote:

> NOTE: this is a draft document, just because there are some things here
> that I'd really like to improve.  Please let me know if you have a better
> way to do these things.  There's also a few issues with Puppet Dashboard
> that appear to be bugs that need either improved documentation or changes
> to their source RPM to fix.  I'd love to see better ways to fix this.
>
> I am attempting to document how one can take an EL5 system (like CentOS
> 5.x) to Ruby 1.8.7 and meets the minimum requirements for Puppet Dashboard.
> There are many reasons for this:
>
> 1. PuppetLabs blames many server-side issues on Ruby 1.8.5's known memory
> problems.  They have indicated that only Ruby 1.8.7 is supportable.
>
> 2. Dashboard requires Ruby 1.8.7
>
> 3. Foreman requires Ruby 1.8.7
>
> Requirements:
> EL5 system with rpmbuild utilities and ~/rpmbuild structure set up as
> documented nearly everywhere.  If you use different paths, adjust as
> necessary for the remainder of the document.
>
> Step 1: Upgrade Ruby
> I have seen recommendations for Koran's Ruby build, but it didn't build on
> a fairly stock EL5 system, and included a bunch of unrelated-to-puppet Tk
> and JP patches.  I found a much simpler spec file that appears to build
> properly on EL5 that uses a significantly higher patch level of Ruby, fixes
> the autoconf problems. It was trivial to review the few patches on this.
>
> wget http://rbel.frameos.org/stable/el5/SRPMS/ruby-1.8.7.352-5.el5.src.rpm
> rpm -i ruby-1.8.7.352-5.el5.src.rpm
> rpmbuild -ba ~/rpmbuild/SPECS/ruby.spec
>
> For any of the nodes, you need only put this RPM in your repository and
> have Puppet upgrade them.  It just works ;-)
>
> For the passenger server, you'll need to get the source RPM from stealth
> monkeys.  You don't need to change anything at all -- just build the SRC
> rpm and it will adjust everything to use Ruby 1.8.7.  Very simple.
>
> wget
> http://passenger.stealthymonkeys.com/SRPMS/rubygem-passenger-3.0.11-1.src.rpm
> rpm -i rubygem-passenger-3.0.11-1.src.rpm
> rpmbuild -ba ~/rpmbuild/SPECS/passenger.spec
>
> Step 2: Dashboard Requirements
>
> First you need to get the mysql drivers for Ruby. The EPEL version binds
> against ruby 1.8.5, but you can compile their source RPM on your ruby-1.8.7
> system and it will work great.
>
> wget ${EPEL_MIRROR_OF_CHOICE}/5/SRPMS/ruby-mysql-2.7.3-1.el5.src.rpm
> rpm -i ruby-mysql-2.7.3-1.el5.src.rpm
> rpmbuild -ba ~/rpmbuild/SPECS/ruby-mysql.spec
>
> Next thing is that Puppet Dashboard requires a newer version of Ruby Gems,
> but it doesn't tell you this. Instead it just barfs weird error messages.
>  They need to rewrite their Rakefile to explicitly define the minimum
> versions.
>
> Thankfully, upgrading gems is very easy.
>
> wget
> http://rbel.frameos.org/stable/el5/SRPMS/rubygems-1.8.10-1.el5.src.rpm
> rpm -i rubygems-1.8.10-1.el5.src.rpm
> rpmbuild -ba ~/rpmbuild/SPECS/rubygems.spec
>
> Unfortunately, I never found a simple way to build RPMs for the three gems
> you need.  I'd like to fix this next part of the HOWTO in the near future.
>  For now, the easiest way to get the minimum requirements installed is to
> run the following commands.
> gem install rake
> gem install rdoc
> gem install rack -v 1.1.2
>
> You'll observe that we installed a very specific version of Rack.  The
> reason for this is that Puppet Dashboard includes rack 1.1.2 within the
> package, but the default Rakefile doesn't load it -- so it wants you to
> have Rack in your normal gems library too.  However if the version doesn't
> match the same version included in the frozen vendor directory, it
> complains about that and barfs. I consider this a bug in the dashboard
> packaging: https://projects.puppetlabs.com/issues/11669
>
> However, if you install 1.1.2 and nothing newer, it will work just fine.
>
> Step 3: Install Dashboard
>
> For unknown reasons to me, the source RPM for dashboard can't be extracted
> on EL5 unless you pass --nomd5 --nosignature.  The good news is that the
> source RPM for EL6 compiles without any changes on EL5.
>
> wget
> http://yum.puppetlabs.com/el/6/products/SRPMS/puppet-dashboard-1.2.4-1.el6.src.rpm
> rpm --nomd5 --nosignature -i puppet-dashboard-1.2.4-1.el6.src.rpm
> rpmbuild -ba rpmbuild/SPECS/puppet-dashboard.spec
>
> That's it!  You now have puppet dashboard installed with all dependancies.
>  You can then follow the standard documentation from puppet labs at
>   http://docs.puppetlabs.com/guides/installing_dashboard.html#installation
>
> Skip the first two #1 bullets and the first #2 bullet and start with the
> second #2.
>
> One problem I found was that when I tried to run it under
> Passenger/Apache, I was told that it couldn't read the config.ru file.  I
> had to do the following to fix this:
>   cd /usr/share/puppet-dashboard
>   ln ./vendor/rails/railties/dispatches/config.ru config.ru
>
> This is already tracked in https://projects.pup

Re: [Puppet Users] Re: Is puppet right for us?

[Brian Gallew]

Let me emphasize the beauty of running Puppet out of cron.  Not only do you
not end up with resource leaks (or just simple consumption when you don't
need it), but you also get much more reliable load on your puppet masters.
 Further, if you are wiling to make a trivial effort to write a
site-specific fqdn_rand() work-alike function, you can even arrange to be
sure that updates roll across related servers in a reliable way.

On Thu, Dec 8, 2011 at 6:08 PM, Jeffrey Watts wrote:

> I've found Puppet to be unreliable running as a daemon - I suspect due to
> older versions of ruby floating around. So I switched to running it from
> cron, and it works a lot better. Memory usage doesn't seem to be an issue,
> and the agent only runs for a few seconds.  Use Puppet Dasboard (or
> something like it) and/or use Nagios to make sure those cron jobs run.   I
> use both.
>
> The main thing is to have Puppet managing itself and the cron job. I have
> ours set up to run the cron job twice an hour, using the concatenated IP
> address modulo 30 and modulo 30 + 30 as the times (to keep the clients from
> hammering the Puppetmaster all at once).  Let me know if you go with Puppet
> and I'll show you how I did it.
>
> Part of the reason we chose Puppet was the quantity of documentation and
> working examples and the helpfulness of the community. I support (and
> implement) our Puppet environment here at my job. I would highly recommend
> Mr Turnbull's Pro Puppet book. It is VERY sysadmin focused and will save
> you a lot of time.  The sections on environments, modules, and Dashboard
> were really helpful.
>
> Jeffrey
> Sent from my iPad
>
> On Dec 8, 2011, at 2:59 PM, Luke  wrote:
>
> > This tool will be used by primarily system admins to automate server
> > builds app installs, configurations etc. The devs will use it in their
> > own environment to help automate some of their tasks. I don't think we
> > have too much Ruby expertise since we are mostly a Java shop.
> >
> > In terms of performance I have read that CFengine uses much less
> > memory and can be faster than puppet. Can anyone comment on the agent
> > and server memory usage? I have read that the puppet agent can use
> > 85mb and the server upwards to 1GB after 20-30agents. Is that
> > accurate?
> >
> > I guess which tool would you consider to be the quickest, easy to
> > implement etc? From what I am seeing the community here seems to be
> > much more active than the others. I have yet to get a response on the
> > other forums.
> >
> > On Dec 8, 4:39 pm, Jeffrey Watts  wrote:
> >> I should also add that a very important consideration is to take in mind
> >> _who_ will be working with this.  Are they developers, sysadmins, QA?
>  Will
> >> the people working on it be spending a lot of time with
> >> Puppet/Chef/CFengine, or just a little?  Are you planning on writing a
> >> bunch of custom modules, or relying on the community?  What languages
> does
> >> your team work on primarily?  For example, folks that work with Ruby a
> lot
> >> would probably do better with Puppet and Chef.
> >>
> >> As a sysadmin, I often see developers get distracted by arguments about
> >> what's "best" or the most technically advanced.  Often they forget that
> in
> >> the end the real answer is often which tool gets the job done the
> quickest,
> >> with the least amount of labor, and is the most supportable.
> >>
> >> Jeffrey.
> >>
> >> On Thu, Dec 8, 2011 at 12:44 PM, Daniel Pittman  >wrote:
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>> Instead, I suggest you focus on your ability to learn the concrete use
> >>> of the tool, and on how effectively you can solve problems with them;
> >>> doing a small trial of each - solve the same mid-sized problem three
> >>> times, giving each a day or two - and see what you think works best
> >>> for your company and culture.
> >>
> >>> There is no silver bullet.
> >
> > --
> > 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+unsubscr...@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Is it possible to get a list of all nodes in your manifests and all classes assigned to those nodes programatically in Ruby?

[Brian Gallew]

This is (almost) trivial.
First, create a fact that turns /var/lib/puppet/state/classes.txt into an 
array.  Then extract that fact from the storedconfigs DB programmatically.  
Admittedly, this won't get all defined nodes, as that is somewhat meaningless 
since nodes can be "default" or regular exceptions.  Instead, this gets all 
nodes that have run Puppet at least once.

On Nov 20, 2011, at 6:04 PM, James Turnbull wrote:

> Trevor Vaughan wrote:
>> Sorry but...bump?
>> 
>> On 11/18/2011 02:20 PM, Trevor Vaughan wrote:
>>> Sorry if this is a double post, my e-mail glitched on me.
>> 
>>> Anyway, I'm trying to write a Ruby script that can get all defined
>>> nodes and all classes assigned to those nodes. I would prefer to not
>>> have to compile a catalog for each node.
>> 
>>> I tried looking through the puppet/util/rdoc material but it really
>>> didn't handle the node entries as far as I could tell and also didn't
>>> seem to have a way to get the info without printing it all out.
>> 
> 
> Sorry missed this one - I do something vaguely similar for the Puppet
> Rundeck integration - have a look at the code at:
> 
> https://github.com/jamtur01/puppet-rundeck
> 
> Others may be able to chime in with better ideas.
> 
> James
> 
> -- 
> James Turnbull
> Puppet Labs
> 1-503-734-8571
> To schedule a meeting with me: http://tungle.me/jamtur01
> 
> -- 
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Publicly accessible server?

[Brian Gallew]

In theory, as long as you are NOT auto-signing certificate requests, this is 
exactly what the puppet server was designed for.  However, you should note that 
the server is likely to suffer lots of random probing and may be susceptible to 
performance problems.


On Oct 20, 2011, at 3:13 PM, Jon Davis wrote:

> I have a numer of hosts in different locations I want to manage with puppet.  
> Can I set up my Puppet server to be publicly accessible, or is this a 
> horribly bad idea likely to end with a destroyed server?
> 
> -- 
> Jon 
> [[User:ShakataGaNai]] / KJ6FNQ
> http://snowulf.com/
> http://www.linkedin.com/in/shakataganai
> 
> 
> -- 
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Official puppetlabs position on cron vs puppet as a service?

[Brian Gallew]

Most of my puppet runs take ~15 seconds or so, however my Nagios servers
take up to 4 minutes to complete.

On Mon, Oct 10, 2011 at 7:00 AM, Chris Phillips  wrote:

>
>
> On 10 October 2011 13:05, Jonathan Gazeley  > wrote:
>
>> On 08/10/11 21:22, Chris Phillips wrote:
>>
>>> What better way to monitor the puppet runs than by executing that run as
>>> part of the check?
>>>
>>
>> I assume your Nagios execution timeout must be insanely long? :)
>>
>> In the past I have considered using Nagios for things other than
>> monitoring, and likewise using Puppet for things other than configuration.
>> On both counts I decided it was probably best to set a boundary and not
>> wilfully abuse these tools, since it's likely to go wrong sooner or later!
>> In my organisation we use Nagios only to monitor, and Puppet only to
>> configure.
>>
>>
> always done within 30 seconds, and it's not like if it took longer on an
> occasional rollout  it would impact puppet at all, temporarily messy as the
> monitor results might be.
>
> fundamentally though, with cron or puppetd being trivial simple, i'm more
> than happy to be doing it this way.
>
>
> Chris
>
>  --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Hostname fact doesn't handle hostnames with periods

[Brian Gallew]

ALso, let's not forget that "all the world is *not* linux".  "hostname -s" 
doesn't do what you think it does when it's not the GNU toolset.

On Sep 29, 2011, at 9:13 PM, Doug Balmer wrote:

> Our concept of 'hostname' as a fact is equivalent to hostname -s up
> until now - it doesn't mean the result of the 'hostname' command
> necessarily.
> 
> This makes sense and is an easy compromise. Could I suggest the doco reflect 
> that $hostname is `hostname -s`?
> 
> ... or at least your definition of what a hostname is.
> 
> -- 
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Hostname fact doesn't handle hostnames with periods

[Brian Gallew]

Technically, a hostname may not legally contain a dot.  A fully qualified
domain name, OTOH, pretty much has to have (at least) one dot.

On Thu, Sep 29, 2011 at 10:59 AM, Sans  wrote:

> Is it really a good idea to have a period/dot in the hostname?
> Although I do agree it should be considered as a bug in terms of
> "good" programing. Cheers!!
>
>
> On Sep 29, 3:25 am, Doug Balmer  wrote:
> > I raised a bug earlierhttps://projects.puppetlabs.com/issues/9766which
> > could be a can of worms.
> >
> > My opinion is, facter has a bug and needs (eventual) fixing even if it
> > causes problems for some. There is a reason we have changelogs.
> >
> > Debate?
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Naginator and Puppet on different hosts

[Brian Gallew]

So, I have all the nodes export their Nagios stuff, and all my Nagios hosts 
then collect what they need (via tagging).  The only tricks I used were to 
override the file locations so that everything actually gets put into a test 
directory, and then have an exec kicked by changes which runs a pre-flight and, 
if the results are good, rsyncs the files from the test directory into the real 
directory.  To clean up nodes/services that have gone away, there is a nightly 
job that wipes the test directory.

On Sep 29, 2011, at 8:47 AM, Bernd Adamowicz wrote:

> We were using Naginator resources like nagios_host, etc. along with stored 
> configurations and exported resources. Worked pretty well. However we have to 
> separate the Puppet master and the Icinga (Nagios) server. They will be on 
> different machines from now on. Are there any best practices for such a 
> scenario? I already thought about some kind of 'rsync' of the configuration 
> from Puppet master to the Icinga host. Any ideas?
> 
> Thanks
> Bernd
> 
> -- 
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Official puppetlabs position on cron vs puppet as a service?

[Brian Gallew]

I ended up writing a custom rand_fqdn function based heavily off the
standard rand_fqdn.  In my environment, we have a lot of related system
(e.g. webs001, webs002, webs003), many of which have significant startup
times.  I changed the function to split an incoming hostname into a
name+numeric suffix (or zero if there is none).  Then it uses the standard
rand algorithm on the name part and multiplies the suffix by 5 and adds that
in with an appropriate modulus.  This means that for all the "webs" hosts,
there is a standard base time, after which they are staggered at 5 minutes
intervals (overlapping every 6th, of course).  The end result is that no
matter what happens with the rand() function, an entire group of servers is
never restarted at the same time.

On Mon, Sep 26, 2011 at 1:10 AM, Ohad Levy  wrote:

> On Mon, Sep 26, 2011 at 12:29 AM, Scott Smith  wrote:
> > Ohad, was rand_fqdn not sufficient for you?
>
> well.. I did it a long time ago, so I'm not 100% sure, but I think the
> main reason was to allow to manage cron entries over an interval, e.g.
> 3 times an hour, or 7 times a day in a random fashion.
>
> Ohad
> >
> > On Sep 25, 2011 1:03 PM, "Ohad Levy"  wrote:
> >> On Sun, Sep 25, 2011 at 10:33 PM, treydock  wrote:
> >>>
> >>>
> >>> On Sep 24, 9:42 pm, Aaron Grewell  wrote:
>  We had frequent inexplicable daemon crashes on Solaris, but not on
> RHEL5
>  (at
>  least not yet) .   Given known issues with memory leakage in older
> Ruby
>  releases Cron seemed more likely to be reliable.   We stuck a random
>  wait in
>  the Cron job to spread load on the master and so far it works well.
>  On Sep 24, 2011 7:22 AM, "treydock"  wrote:
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  > On Sep 23, 5:42 pm, Brian Gupta  wrote:
>  >> Over the years many shops have come to start running puppet via
> cron
>  >> to
>  >> address memory leaks in earlier versions of Ruby, but the official
>  position
>  >> was that puppet was meant to be run as a continually running
> service.
> 
>  >> I am wondering if the official position has changed. On one hand
> many
>  >> if
>  not
>  >> all of the early Ruby issues have been fixed, on the other, the
>  >> addition
>  of
>  >> mcollective into the mix as a lightweight agent for triggering
> adhoc
>  puppet
>  >> runs, and other tasks somewhat lowers the requirements for puppet
> to
>  >> be
>  run
>  >> as a service. (Or out of cron for that matter).
> 
>  >> I understand that in cases where old Ruby versions are for whatever
>  reason
>  >> mandated the answer may be different.
> 
>  >> Thanks,
>  >> Brian
> 
>  >> --
>  >> 
> 
>  > Could those memory leak problems cause the Puppet daemon to crash
> with
>  > no logs indicating why? I have about 20 systems all running CentOS 5
>  > and 6, with Puppet 2.6.9, and I now have to have Zabbix run a "/etc/
>  > init.d/puppet start" everytime the daemon crashes which is almost on
> a
>  > daily basis for every client. Would be interested to know of a known
>  > fix or if the only "fix" is the workaround of using Cron.
> 
>  > Thanks
>  > - Trey
> 
>  > --
>  > 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+unsubscr...@googlegroups.com.> For more options, visit
> this
>  group at
> 
>  http://groups.google.com/group/puppet-users?hl=en.
> 
> 
> 
> 
> 
> 
> 
> 
> >>>
> >>> Could you share how you did the random wait?  I may have to switch to
> >>> a cron job with how often my daemons are crashing and having to be
> >>> restarted by Zabbix.
> >>
> >> I used the ip_to_cron function from
> >> http://projects.puppetlabs.com/projects/1/wiki/Cron_Patterns
> >>
> >> afterwards, I just do a sleep random 59, so its also random within the
> >> minute.
> >>
> >> Ohad
> >>>
> >>> Thanks
> >>>  - Trey
> >>>
> >>> --
> >>> 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+unsubscr...@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+unsubscr...@googlegroups.com.
> >> For

Re: [Puppet Users] "Cross-nodes" modules: howto?

[Brian Gallew]

I do this with a define.  In my case, I define a web application and pass in
several arrays of hosts.  This expands, in turn, to a series of if
statements that check to see which array (if any) $hostname is in and then
sets appropriate variables.  I use this to generate Nagios hostgroups,
assign roles, generate configuration files, etc.  And since the ugliness is
all in the define, the manifest is very readable, e.g.
complete_app_environment{ "Production Reno"
  app_servers => [host1, host2, host3],
  web_servers => [host4, host5],
  solr_servers => [host6, host7],
  mule_servers => [host8, host9],
  external_name => foo.bar.com;
}

On Tue, Sep 6, 2011 at 5:13 AM, Francis GALIEGUE  wrote:

> Let's say I have a web application which I want to deploy separately:
>
> * the static content and appropriate configuration on a machine with
> Apache on it,
> * the dynamic content and appropriate configuration on a machine with
> Tomcat on it.
>
> Is there a possibility to write a module which takes as an argument
> the name of the Apache node and the name of the Tomcat node, along
> with appropriate configurations for Apache and Tomcat, and which would
> do what is appropriate so that this web application be
> installed/updated/removed?
>
> --
> Francis Galiegue
> ONE2TEAM
> Ingénieur système
> Mob : +33 (0) 683 877 875
> Tel : +33 (0) 178 945 552
> f...@one2team.com
> 40 avenue Raymond Poincaré
> 75116 Paris
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Updating /etc/puppet ?

[Brian Gallew]

On Sep 1, 2011, at 2:01 PM, Douglas Garstang wrote:

> 
> Editing files locally under /etc/puppet as an individual user is not mutually 
> exclusive with editing files in a distributed working copy owned by the same 
> user.

If it's not, then there's no point in asking for help: your environment is 
screwed and there is nothing anyone here can do about it other than suggest 
that we can't help you until you help yourself.  The nice thing about "current 
reality" is that it's generally easy to point out why it sucks and why it needs 
to be fixed.  If you team can't handle change, then either *you* need to accept 
that status quo, or else you should find another team to work with.  The only 
solution to your problem is to fix the problem.  Pointing in other directions 
and saying "that doesn't work in my current environment" is the moral 
equivalent of asking for help and then immediately sticking your fingers in 
your ears and yelling "LALALALALALALAICAN'THEARYOU".

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Composing a text file with Puppet

[Brian Gallew]

On Aug 31, 2011, at 6:57 AM, jcbollinger wrote:

> 
> 
> On Aug 30, 9:15 am, M C  wrote:
>> Hi,
>> 
>> is it possible to push a file (with "source" or "content") and then add
>> lines without having Puppet to regenerate it every time it runs?
>> And, how can I add, remove or alter text lines without keeping old contents?
> 
> 
> As I understand you, you want Puppet to provide a default version of
> the file in the event that it does not exist at all, but otherwise to
> leave it completely alone.  That runs against the Puppet grain: it
> would be better to completely manage the file content, updating the
> node's manifests as appropriate when you want the file's contents to
> change.

Call me crazy, but isn't this just a matter of adding "replace => false" to the 
file resource?  If it doesn't exist, Puppet will create it according to the 
manifest.  Once in place, Puppet will leave it alone unless it vanishes, at 
which point it will be re-created.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Hash Interpolation inside double quotes?

[Brian Gallew]

String interpolation in the Puppet DSL is strictly variable->string, and does 
not handle arrays.  For what you want, use
inline_template("tomcat-<%= $config['tomcat_version_server'] %>")


On Aug 8, 2011, at 11:19 AM, Douglas Garstang wrote:

> I've got this:
> 
> file {
> '/opt/sugarsync/tomcat/tomcat-home/current':
> ensure => "tomcat-$config['tomcat_version_server']";
> 
> where $config['tomcat_version_server'] was set with extlookup (the yaml one), 
> by loading:
> 
> ---
> tomcat_config:
>   tomcat_version_server: 6.0.20-1
>   tomcat_version_libs: 1.0-1
> 
> Inside those double quotes, where variable interpolation is supposed to 
> occur, I'm actually getting:
> 
> tomcat-tomcat_version_libs1.0-1tomcat_version_server6.0.20-1['tomcat_version_server']
> 
> Not '6.0.20-1'. How can I interpolate a hash inside a string? Is this a bug?
> 
> Doug.
> 
> -- 
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Templates and self-knowledge

[Brian Gallew]

So, I'm into templating.  I *like* templating.  What I *don't* like, of
course, is to have to use multiple, similar templates for different output
files.  So, let's work a concrete example.  Suppose I have a template
"standard_profile.erb" which looks like this:

install_typeinitial_install
>
> system_type standalone
>
> partitioningexplicit
>
> <% if zfs_root == "undef" -%>
>
> fdisk all solaris all
>
> boot_device any preserve
>
> filesys rootdisk.s1 16384 swap
>
> filesys rootdisk.s0 40960 /
>
> filesys rootdisk.s7 free /export
>
> <% elsif zfs_root == "c3s" %>
>
> pool rootpool auto 16g 16g mirror c3t0d0s0 c3t4d0s0
>
> fdisk c3t0d0 solaris all
>
> fdisk c3t4d0 solaris all
>
> <% else %>
>
> pool rootpool auto 16g 16g mirror <%= zfs_root %>t0d0s0 <%= zfs_root
>> %>t1d0s0
>
> fdisk <%= zfs_root %>t0d0 solaris all
>
> fdisk <%= zfs_root %>t1d0 solaris all
>
> <% end -%>
>
> cluster SUNWCprog
>
> cluster SUNWCgna11y delete
>
> cluster SUNWCgna11ydev delete
>
>
>From this I generate 2 different files, one which does ZFS root, and one
which doesn't (actually, it generates more than that, as I pass in
zfs_root=>"c1" or whatever is necessary.  However, while this is very
flexible, it's also very ... specific.  As in, the define that I've created
to use this file isn't really re-usable elsewhere:

  define profile_file($zfs_root = "undef") {
>
> file{"/jumpstart/Profiles/$name":
>
>   require => File["/jumpstart/Profiles"],
>
>   content => template("jumpstart/solaris_profile.erb"),
>
>   mode => 0644
>
> }
>
>   }
>
>
>
What I would much rather be able to do is introspection.  This ERB is being
evaluated in the context of a source file (.pp), modules, class, and file
resource.  If I could even look at the file resource, I'd be able to make
decisions in the more general case.  Otherwise, I end up with a bunch of
defines sprinkled all over my manifests, all of which do the same thing:
bring a value into the ERB scope as a named variable.

Of course, it just now occurred to me that I can create a define like this:

> define smart_template($module, $mode = 0644, $args = undef) {
>>
>>   $this_filename = $name
>>
>>   $this_short_filename = inline_template("<%=
>>> this_filename.split(/\//)[-1] %>")
>>
>>   $template_file = "${module}/${this_short_filename}.erb"
>>
>>   file{$name:
>>
>> content => template($template_file),
>>
>> mode => $mode
>>
>>   }
>>
>> }
>>
>>
>>
I guess this will give me the flexibility I want, because now I have not
just the filename in scope, but the module name and whatever random args I
define, but it still feels somewhat ... unclean.  Does someone have a better
idea?

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] puppet terminating - continually forcing itself to stop

[Brian Gallew]

I was seeing the behavior on my Solaris boxes when running Puppet under SMF.
 The issue, in my case, was that I was trying to work around an SMF bug.  My
"workaround" was to "svcadm disable puppetd;svccfg import
/var/svc/manifest/network/puppetd.xml;svcadm enable puppet".  The astute
viewer will notice that "svcadm disable puppetd" will cause SMF to send
SIGTERM to puppet, at which point it will stop (as instructed) the current
run, so the new manifest will not be imported and the service will not be
re-started.  It was all very amusing, except for the bit where I had to fix
a bunch of systems that weren't running Puppet anymore.  Mea culpa.

On Tue, Jul 5, 2011 at 4:49 AM, vagn scott  wrote:

> On 07/05/2011 07:15 AM, Chris Phillips wrote:
>
>>
>> > debug: Service[puppet](provider=**redhat): Executing '/sbin/service
>> puppet
>> > stop'
>> > notice: Caught TERM; calling stop
>> > [root@gibsvlin-erp2dst ~]# /etc/init.d/puppet status
>> > puppetd is stopped
>>
> That's just weird looking.
> So puppet is running, and trying to kill puppetd.
> Instead it catches the TERM signal itself.
> Is that what I'm seeing?
>
> That looks racy as hell.
>
> Maybe you should rethink that and instead have
> something like monit watch puppetd to make
> sure it stays off.
>
> Or have nagios start a script that makes sure
> puppet is not running, then runs it, then makes
> sure it is stopped.
>
> --
> 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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Deployed but unmanaged file

[Brian Gallew]

On Jun 29, 2011, at 9:05 AM, Nigel Kersten wrote:

> I've long wanted the equivalent of a "conffile" in Puppet.
> 
> e.g. "replace this file if it's still the same as the one Puppet put down, 
> but if it's been modified from the default, don't replace it"
> 
> I've wanted this in the past for things like a user .rc file, where you want 
> to be able to continually update the default, but not throw away any 
> customization the user may have done.

SInce I support developer who sometimes want to control the conf files, and 
sometimes want Puppet to control them, I created a define:

define managed_file($source = undef, $content = undef) {
  $pdir = inline_template("<%= name.reverse().split('/',2)[1].reverse() %>")
  $basename = inline_template("<%= name.split('/')[-1] %>")
  
  file {
"${name}-puppet":
  source => $source, content => $content, ensure => present;
"${pdir}/README-${basename}":
  ensure => present,
  content => "${name} is managed by Puppet.\n\nIf you need to 
edit\n${name}\nand have your changes persist, touch\n${name}.noupdate\nand 
Puppet will ignore that file.  When you are done with your\ntesting, please 
have your changes put in Puppet and delete the\n${name}.noupdate\nfile.  
Thanks.\n\n";
  }

  exec {
"${name}-sync":
  unless => "test -f ${name}.noupdate || cmp -s ${name} ${name}-puppet",
  command => "/usr/local/bin/rsync -a ${name}-puppet ${name}",
  require => File["${name}-puppet"];
  }
}


And you use it like so:
managed_file {
  "${muledir}/lib/user/system-config.properties":
content => template("jboss/system-config.properties.erb"),
require => File["${muledir}/lib/user"],
notify => Service["/site/mule"];
}

That will create three files in ${muledir}/lib/user: 
README-system-config.properties, system-config.properties-puppet, and 
system-config.properties.  If one of the developers on a managed system needs 
to hand-edit that file, they red the instructions in the README-* and simply 
touch system-config.properties.noupdate.  Removing that file re-enables Puppet 
management.  As a further benefit, they can trivially see what's going to 
change when they remove the .noupdate file because the -puppet version will 
always be Puppet-managed.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: How do you handle deleted nodes with exported resources in this situation?

[Brian Gallew]

On Jun 8, 2011, at 8:50 AM, jcbollinger wrote:

> 
> 
> On Jun 7, 11:12 am, Stefan Schulte 
> wrote:
>> You can download the puppet sources. In the ext Directory you'll find a
>> script »puppetstoredconfigclean.rb NODE_TO_BE_REMOVED«. AFAIK the script will
>> set the ensure property of all exported resources of the specified host
>> to absent.
> 
> 
> Nice.  Do I judge correctly that this is an *alternative* to actually
> removing the node in question from the storeconfig DB?  I mean,
> otherwise, there are no resources in the DB to flag absent.  If you
> already have removed the node and its resources from the DB, then I
> can't imagine that such a script could help.

My experience is that this script actually purges all of the resources, facts, 
reports, etc. from the storedconfigs repository.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Virtual resources and hashes

[Brian Gallew]

On Jun 8, 2011, at 8:45 AM, Aaron Grewell wrote:

> Here's the thing though: since arrays are the only native method of looping, 
> Puppet needs to handle arrays of all native types well.  If it doesn't, from 
> an end-user perspective that's broken.

See, there's the crux of the issue: arrays are *not* a method of looping.  
Puppet's DSL is declarative, not procedural (imperative).  What you are 
thinking of as "looping" is simply a convenient shorthand (syntactic sugar is 
the appropriate term).  If you are thinking in procedural terms (which we've 
all done at one point or another), you're simply going to run around in circles 
ranting that Puppet is broken until you get your head wrapped around its 
declarative nature (much like I did/do).  Puppet is not procedural.  Never has 
been, never will be.

You can probably meet your needs by thinking about the desired state in 
different terms and using extlookup, or using custom functions.  If you are 
really insane, you can modify the Puppet backend to execute a file and read the 
output instead of reading the file directly, which might allow you to 
dynamically generate the manifests you want applied, though the added 
complexity may well be a net loss.

In short, if you are thinking "procedural", then you have not yet drunk the 
Kool-Aide.  Join us.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Puppet managed hosts in multiple nagios hostgroups

[Brian Gallew]

I solved this in a similar manner.  I wrote a custom fact (which essentially
returned /var/lib/puppet/state/classes.txt) and then a custom function that
generated a list of hostgroups based on that.

On Wed, Jun 8, 2011 at 6:47 AM, Chris Phillips  wrote:

>
>
> On 8 June 2011 13:30, Martijn Grendelman  wrote:
>
>> Hi,
>>
>> > i want to archive the following:
>> >
>> > i define an exported ressource for HostX to be monitored in nagios:
>> >
>> > @@nagios_host { $fqdn:
>> > ensure => present,
>> > alias  => $hostname,
>> > address=> $ipadress,
>> > use=> "generic-host",
>> > hostgroups => ubuntu,
>> > target => $icingahostfile,
>> > }
>> >
>> > That fine and works as expected and HostX is in hostgroup ubuntu.
>> > HostX has included a class ssh which installs the ssh services and
>> > configures them. Inside this class i want to define that HostX is also
>> in
>> > hostgroup ssh-server.
>> > And another class, which puts the node in another environment => there i
>> > want to define, that HostX is in hostgroup testing-server and so on.
>> > How do i archive that? How must the definition inside all these classes
>> > look like?
>>
>> That's a lot more difficult than you might expect.
>>
>> I recently solved it, by collecting all the necessary hostgroups for a
>> host in a file using 'concat', and creating a custom fact (hostgroups)
>> that joins all the lines in the hostgroups-file together, for use with
>> nagios_host's hostgroups parameter.
>>
>> The biggest drawback is that it takes two puppet runs on the target (first
>> one for populating the hostgroups-file, so that the custom fact is set
>> properly on the second run) before the nagios server can collect the
>> exported hosts, so it takes a while.
>>
>>
> Well that's mad... I literally just was about to ask the exact same
> question after a month of wondering...
>
> so where do you put this fact? Sounds like it is on the nagios "client"
> side, which makes sense in terms of pulling it out, but how does it get in
> there in the first place? Can you show how this file on each client is
> managed? That seems to be the only bit I'm not clear on. Are you just
> putting in a single word for each class? Are you at all able to manage the
> class being removed from the client? Would you need to routinely purge the
> file? have a initial stage class that wipes the file?
>
> Thanks
>
> Chris
>
>  --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Distributed Puppet Architecture and Management

[Brian Gallew]

It depends on two things: your CA and the content of auth.conf.  If you have
one CA signing all your certificates, then every host can validate the cert
on every master.  If that's the case, then any host with the correct
permissions in auth.conf can issue the puppet kick command.  If you have
different CAs, then the auth.conf can only (successfully) authorize hosts
signed with the same CA.

On Fri, Apr 22, 2011 at 12:51 PM, Arm Adam wrote:

> Posting here as well as on the developers group (they suggested that I
> repost here).
>
> How does puppet kick work in a scenario where a puppet master is
> managing puppet masters who manage puppet masters who manage agents?
> Do I have to kick from the immediate Master of the agent I want to
> kick?  Do I first have to wait for a deployed module at the top level
> puppet master to trickle down to agent's immediate puppet master or
> will a puppet master look upstream if it doesn't have a module that an
> agent is configured to receive (via LDAP)?
>
> Pardon the below ASCII art (hopefully it comes through), but take a
> look to see what I mean. PM = Puppet Master.  PA = Puppet Agent.
>
>   PM
> /  \
>  PMPM
>   /\ / \
> PM   PM PM
>   /  \  /  \  /   \
>  PA  PA   PA PA PA
>
> Thanks!
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Templating question

[Brian Gallew]

That would undoubtedly have been a neater solution.  I may well switch to
using that.  Thanks!

On Fri, Apr 15, 2011 at 1:48 AM, Felix Frank <
felix.fr...@alumni.tu-berlin.de> wrote:

> On 04/13/2011 04:24 AM, Ben Hughes wrote:
> > On Tue, Apr 12, 2011 at 07:20:24PM -0700, Brian Gallew wrote:
> >
> >> I ended up doing something even uglier (and probably stupider).  I
> created
> >> two sub-classes of jumpstart: jumpstart::mirrorroot and
> jumpstart::zfsroot,
> >> and each one just sets a variable ($target) and the uses the template.
>  It's
> >> incredibly stupid, but it works.
> >
> > That is neater than trying to pick your way through the objects. Really.
>
> Indeed, but my preferred canonical approach is to wrap templates in
> defines. No need for subclassing here, just pass different parameters to
> your wrapping define.
>
> Cheers,
> Felix
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] What do you use "import" for?

[Brian Gallew]

I use it to include files which, for whatever reason, won't be auto-imported.  
Specifically, I use it to includes my nodes.pp and defines.pp files, since 
neither of them define any classes, and I want my defines all in one place, 
usable anywhere.

On Apr 14, 2011, at 11:05 AM, Randall Hansen wrote:

> Good people ~
> 
> I'm running through the Puppet DSL trying to understand it.  Some
> parts seem a little funky, like "import."  Before I start forming any
> silly opinions, tell me:  what do you use "import" for?  Does it serve
> that purpose well, or do you grimace a little every time you type it?
> 
> Thanks!
> 
> r
> 
> --
> Randall Hansen • Director of User Experience • rand...@puppetlabs.com
> 
> -- 
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Templating question

[Brian Gallew]

On Tue, Apr 12, 2011 at 6:39 PM, Ben Hughes  wrote:

> > Sadly, my introspection-fu seems to be lacking and I'm unable to figure
> it out.  Any help?
>
> Not easily. The only way I was able to find mention of it at all was
> with the horrible voodoo of a template of:
>
> <%= require 'pp' ; pp @__scope__ %>
>
> And even then, there's no safe, sane or simple way of getting it out.
>
> You're best off just having two different templates I'm afraid and less
> magic.
>
>
I ended up doing something even uglier (and probably stupider).  I created
two sub-classes of jumpstart: jumpstart::mirrorroot and jumpstart::zfsroot,
and each one just sets a variable ($target) and the uses the template.  It's
incredibly stupid, but it works.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Templating question

[Brian Gallew]

OK, I'm trying to do something (apparently) stupid.  Here's the relevant 
fragment of my manifest:

 "/jumpstart/Begin/rootmirror.beg":
   require => File["/jumpstart/Begin"],
   content => template("jumpstart/standard.beg.erb");
 "/jumpstart/Begin/standard.beg":
   require => File["/jumpstart/Begin"],
   content => template("jumpstart/standard.beg.erb");


So the key thing here is that I've got two different files, but I'm using the 
same template for them.  I had assumed that inside the template I could access 
"name" or "path" to figure out what the current resource was, and thereby 
choose the correct contents of the script.  Sadly, my introspection-fu seems to 
be lacking and I'm unable to figure it out.  Any help?

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] extlookup == bad?

[Brian Gallew]

On Tue, Apr 12, 2011 at 12:54 AM, R.I.Pienaar  wrote:

> The PDL is a *much* more desirable solution than either layered classes
> or extlookup, why it has gone un-implemented I dont know and why the
> current suggestion is that layered classes somehow represents an effective
> alternative to the PDL I do not understand at all - since surely why
> bother with the PDL at all then?
>
>

I'll answer this one.  The obvious, and correct, answer is, "because it's a
lot of work to do this."

For Puppetlabs to do this, they're going to have to invest a lot of time and
energy, because their implementation *must* be backwards-compatible or else
provide an automated tool for doing the conversion.  Further, the PDL
proposal hasn't actually been around all that long.  Puppetlabs isn't
Microsoft and doesn't have a thousand developers on hand to write stuff up.
Their staff is small and no matter how talented they are, there is limited
time with each day.  Even a user-contributed patch set probably will take
time to vet simply because of the compatibility requirements.

Caveat: I don't work with or for Puppetlabs, and while I may occasionally
complain about X or Y, I respect the work they are doing and their efforts
to provide a quality product.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: how puppet client update the files only when the flles from puppet server are new?

[Brian Gallew]

I think the fundamental problem here is that you see a particular piece of
metadata in your mind (this version of the file is the previous version)
which does not, in fact, exist.  Since good practices dictate that your
Puppet manifests, files, and templates are all in some form of version
control, it's easy to fall into that trap.  You'll note, however, that
Puppet itself has no notion of "version" in the file type.All Puppet
knows about the file is either it's the same as the file on the client or
it's different.   @yoda(Same or different, there is no version.)

One way to address this would be to put your file into a package (which
*does* know about versions) and manage it as a package resource.  Even
still, you have the same problem in that, if you specify versions in the
Puppet manifest and the manifest reverts to an earlier version, then the
package, as installed on the client, will also revert to an earlier version
(on the next run).  This is the *desired* behavior.  If you don't want your
Puppet manifests to ever revert, then don't do that.

If the problem is that a co-worker is editing the Puppet manifests in-place
and revision control is undoing those changes, well, that's a social
problem, not a technical problem.  Puppet is really good for managing your
servers, but it's not really capable of instilling good work habit in actual
people.

2011/3/29 Patrick 

>
> On Mar 29, 2011, at 7:38 PM, metalove wrote:
>
> > Let's assume that
> > the file in the server was rollbacked to old data because of some
> > reason.
> >
> > then, puppet client will update also..
> >
> > What I want is,
> > puppet client should reject the update in this case...
> >
> > so is there any option at puppet clinet to reject update in this case?
>
>
> Short answer:
> No
>
> Hard answer: (and probably the wrong answer):
> You can hack something together using exec or write your own provider using
> ruby.
>
>
> Complete answer:
> I'd say that if you have a problem with your server's files reverting for
> no reason, you need to fix your process or server.  To me this suggests you
> need to put tighter control on your puppetmaster's folder.  Frankly, I
> consider being able to revert files in the puppet folder to undo a change to
> be good.  (Yes, reverting does take thought because puppet won't undo
> changes.  It will only push the current configuration.)
>
> > Thanks.
> >
> > On 3월30일, 오전10시27분, Patrick  wrote:
> >> On Mar 29, 2011, at 8:52 AM, metalove wrote:
> >>
> >>> sorry for confusion.
> >>
> >>> What I meant was,  if
> >>
> >>> -. the same file is between puppet daemon(server) and client
> >>> -. the timestamp was older at puppet server,
> >>
> >>> I think that puppet client should not update, right?
> >>> but puppet client seems update even the server's file is old
> >>
> >>> so, what I should do, not to update the old file from server?
> >>
> >> The problem is that, in general, this isn't how puppet works.  Usually,
> it's considered a feature that you know that if the file is changed on the
> client, puppet will revert it.  First, you should consider if generating the
> file using information about the client might be better.
> >>
> >> Next, with you design, what would us expect to happen if the server's
> file changes?  Is it only then that you want to wipe it?
> >>
> >> Conclusion:
> >> Puppet can do that, but it's not the usual way, and I think you need to
> use an exec instead.
> >>
> >>
> >>
> >>
> >>
> >>> puppet client <--> puppet server
> >>
> >>> index.htmlindex.html
> >>> 2011-03-29   2011-03-28
> >>
> >>> On 3월29일, 오후11시56분, Felix Frank 
> >>> wrote:
>  Hi,
> >>
>  On 03/29/2011 03:32 AM, metalove wrote:
> >>
> > Hi, all.
> >>
> > I'm not familiar with puppet itself and want to know that this is
> > possible or not..
> > As I know, puppet client updates all files from server without regard
> > to the files are old or new..
> > But, I think that puppet client should update the files only when the
> > target files from server are new..
> > so is there any option to do this?
> >>
>  Not that I'm aware of, no. When you're using files' "source"
> parameter,
>  you tell puppet that the contents should never change.
> >>
>  To enable puppet to deal with changing files, there are other ways
> such
>  as augeas.
> >>
>  HTH,
>  Felix
> >>
> >>> --
> >>> 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+unsubscr...@googlegroups.com.
> >>> For more options, visit this group athttp://
> 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, se

Re: [Puppet Users] Re: parameterized classes and variable inheritance

[Brian Gallew]

On Mar 21, 2011, at 1:39 PM, jcbollinger wrote:

> 
> On Mar 21, 3:15 pm, Brian Gallew  wrote:
>> It has occurred to me that another way of doing this would be to use defines
>> 
>>   define kludge($sudo_add_rule=undef) {
>> node { "${name}":
>> class {sudoers: additional_rules => [$sudo_add_rule}}
>>  }  
>>   }
>> 
>> The beauty of this is that it gets around the traditional problem of node 
>> inheritance: that including classes in any inherited node requires adding 
>> extra helper classes just to enable value overrides.
> 
> Does it actually work to declare a node inside a define?  I wouldn't
> have expected so, but if it does then that might prove useful to know.

That will teach me to jump in before testing: no, it doesn't work.

There goes another bright idea.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: parameterized classes and variable inheritance

[Brian Gallew]

It has occurred to me that another way of doing this would be to use defines

  define kludge($sudo_add_rule=undef) {
node { "${name}":
class {sudoers: additional_rules => [$sudo_add_rule}}
 }  
  }

The beauty of this is that it gets around the traditional problem of node 
inheritance: that including classes in any inherited node requires adding extra 
helper classes just to enable value overrides.

On Mar 21, 2011, at 11:28 AM, Ashley Gould wrote:

> On Mon, Mar 21, 2011 at 04:23:40AM -0700, Bill Proud wrote:
>> The following would work:
>> 
>> node default {
>>class { sudoers: }
>> }
>> 
>> node 'sl11lab02' {
>>class { sudoers: additional_rules => [ "$rules_uas" ] }
>> }
>> 
> 
> This does work, but I lose inheritance from node default.
> In fact, this is my current work around.
> 
> 
> -- 
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] How to get the result of a command in puppet?

[Brian Gallew]

In that case I've got nothing.  Sorry.

On Mar 15, 2011, at 6:37 AM, duff wrote:

> Hi Brian
> 
> The problem isn't the lack of output from the puppet custom function. I have 
> written some that return results.
> I used puts statements in the example to show the absence of result from the 
> %x[] statement without having to write some convoluted manifest and puppet 
> output.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] How to get the result of a command in puppet?

[Brian Gallew]

On Mon, Mar 14, 2011 at 8:12 AM, duff wrote:

> Hello, I am trying to export the latest tag of an svn repository to a
> puppet client.
> To do so, I would like to run the following command to get the latest
> tag
>/usr/bin/svn ls http://url_to_my_svn_repository/tags | /usr/bin/
> tail -1
>
> However, I couldn't find a way to store the result of an exec in a
> variable.
>
> Since the url to the repository will change depending on the project,
> I decided to use a custom function and get it to run and return the
> result of the command.
>
>module Puppet::Parser::Functions
>newfunction(:get_latest_tag, :type => :rvalue) do |args|
>cmd = "/usr/bin/svn ls http://"; + arg[0] + " | /usr/bin/
> tail -1"
>puts cmd
>puts %x[ #{cmd} ]
>puts 'the end'
>end
>end
>
>
If you are actually using "puts" in your function as indicated, then your
return value should be "nil".  Have you tried your function this way:
module Puppet::Parser::Functions
  newfunction(:get_latest_tag, :type => :rvalue) do |args|
   %x["/usr/bin/svn ls http://"; + arg[0] + " | /usr/bin/tail -1"]
  end
end

This is straight Ruby code, so the result of the function is the return
value of the last statement/expression evaluated.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] templates for user resources types

[Brian Gallew]

On Mon, Mar 14, 2011 at 11:07 AM, VinceT  wrote:

>
>
> class passwd {
>
> user { "root":
>ensure => present,
>comment => template("passwd/passwd.root.user.erb"),
>
>}
>
> passwd.root.user.erb contains:
>
> Root user on <%= hostname %>
>
>
For such a simple substitution, you're working too hard:

user { "root":
ensure => present,
comment => "Root user on ${hostname}";
}

Nigel's comment is spot-on, though: use <%= blah -%> to suppress the
trailing newline.  If you are planning on doing much templating, you would
be well advised to read the ruby docs on ERB as they are the most complete.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Deduplication (was: Why is it so hard to make a sane nagios server config?)

[Brian Gallew]

On Mar 11, 2011, at 7:52 AM, Nick Moffitt wrote:

>> I'm not sure what you mean by deduplicating.  Puppet won't let you
>> have duplicate *anything*, exported or not.  If you mean "filtering",
>> that's doable, but any non-trivial filtering rule will require to you
>> write evil Puppet functions that hook into the internals.  If you
>> could provide us a reasonably detailed example, perhaps we could be of
>> more help.
> 
> All right, let's say I have a nagios check that has a new hostgroup.  My
> nagios configs fall out as a consequence of *use* to ensure that they
> match the manifests 100%.  So there's a define in the foo::monitoring
> class that updates the local NRPE configs and then exports:
> 
>   1. A request that a service exist, in a hostgroup provided, to
>  probe this check over NRPE.
>   2. A request that the provided hostgroup exist.
>   3. A request that the host's server-side definition include
>  membership in the provided hostgroup.
> 
> 1. and 2. need to be unique globally.  3. only needs to be unique
> per-host.  All would benefit from behaving like the invocation of a
> class, or the resolution of notifies down to a single event.  Having
> the ability to export "ensure X is Y" rather than "here is an X+Z=Y just
> like thousands of others" would be helpful to me.

Oh, I see.  You want to define the Nagios service in the same place the 
service is declared, and the hostgroup in the class.  Yeah, that would be a 
sweet way to do it, but Puppet's manifest methodology is completely incapable 
of doing it.  I've always wanted a reasonable way to collect the hostgroups 
from the various service/host definitions, but that's never been possible 
without deep magic.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Deduplication (was: Why is it so hard to make a sane nagios server config?)

[Brian Gallew]

A cons cell isn't actually that hard to produce in Puppet: you can use a
hash.  Each key is the member of the cell you want to keep, while the value
is a throwaway.  But.  Puppet's non-determinate evaluation order is pretty
much guaranteed to bite you in the butt.  You can really only get the "full"
information on the puppet client after the catalog is fully generated, which
means that all your templated or variable-substituted strings are already
fully formed.  You have to have a custom fact on the child which gets its
information from /var/lib/puppet/state.

I'm not sure what you mean by deduplicating.  Puppet won't let you have
duplicate *anything*, exported or not.  If you mean "filtering", that's
doable, but any non-trivial filtering rule will require to you write evil
Puppet functions that hook into the internals.  If you could provide us a
reasonably detailed example, perhaps we could be of more help.

On Fri, Mar 11, 2011 at 6:29 AM, Nick Moffitt  wrote:

> Martijn Grendelman:
> > I'm afraid not.
>
> This is distressing news.
>
> I feel like there are two things conspiring to defeat me, here:  one is
> that nagios resource types like to enumerate *children* instead of
> *parent* relationships.  Having to maintain these static lists of
> "members" is part of the crisis.  My kingdom for a cons cell!
>
> The second problem is that Puppet doesn't provide me with any efficient
> mechanism for *deduplicating* collected resources.  I appreciate that
> there are race conditions that make it impossible to determine which
> "version" of a resource is the one that gets instantiated.
>
> I'd hope, though, that when all parameters are equal, that there could
> be some way to say "uniq these, thanks."  Maybe something like
> puppet::concat that removes instead of adds.
>
> --
> "N'aimez pas votre voiture?
> Alor, l'heure est arrive pour la brulé!"
>-- Mark Jaroski
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Why is it so hard to make a sane nagios server config?

[Brian Gallew]

My setup also has a worst-case propagation delay of 90 minutes.  I have a
custom fact that collects all of the information in classes.txt on the
client.  That, in turn, is used (for Nagios) by a custom parser function
that produces the hostgroup list for when the nagios_host resource is
exported.  It's not optimal, but it's fully automatic.  In the rare case
where I want/need the info to propagate immediately, I can run "puppet agent
--test" twice on the client and then once more on the Nagios server.

All of the services, as in your case, are generated as members of
hostgroups.

On Fri, Mar 11, 2011 at 6:14 AM, Martijn Grendelman wrote:

> On 11-03-11 12:46, Martijn Grendelman wrote:
> [snip]
>
> > I did exactly what you did: use exported concat-fragments to collect the
> > hostgroups on the puppetmaster and then use generate() to provision the
> > hostgroups parameter of the nagios_host.
>
> [snip]
>
> > The biggest downside of my system so far, is the fact that, in a
> > worst-case scenario, it takes 90 minutes for a configuration change to
> > propagate to Nagios.
>
> I now replaced the exported concat fragments with local concat fragments
> and a custom fact, which reads the result of the concat and joins it into
> a comma-separated string.
>
> Dependencies make sure that the concats are done before the nagios_hosts
> are exported.
>
> This removes the need to collect anything on the puppetmaster and reduces
> the time needed to propagate a configuration change to Nagios in the worst
> case to 30 minutes.
>
> Best regards,
> Martijn.
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] How can I dynamically realize this?

[Brian Gallew]

The short answer is: it sucks to be you.

The longer answer is that variables are really rvalues: they are something
that you can read and test, but they are not function calls or otherwise
subject to evaluation.  When you write
Cron <| tag == "a" |>
in your manifest, you are evaluating an == expression using the values on
either side.  When you write
Cron <| $complicated_string |>
there is no test in there!  It's just a string.  The content of the string
can be arbitrarily complex, but it will *never* be evaluated as anything
other than a string.

Puppet has a declarative language, not imperative.  And like all declarative
languages, it suffers from the "there are no shortcuts" issue.  You have to
declare everything explicitly.  There is no supported way to really to do
anything dynamic such as you are trying to do.

All that said, evil tricks lurk in the land of dragons.  Don't bother asking
for help if you go down this particular path, because the Puppetlabs people
will only tell you that "you're doing it wrong" and no one else will be
willing to admit that you've pervert Puppet in this manner.  All that said,
think about this: you can write functions that will, in turn, be available
from within Puppet manifests.  Those functions, written in Ruby, can do
anything that Ruby can do.  Puppet is written in Ruby, and all of the
internal library bits are available to your function, if only you bend
enough programming and convention rules, as well as discovering all of the
(possibly intentionally undocumented) internals necessary to do what you
need.  As a starting point, read (and understand) the code in
puppet-2.6.6/lib/puppet/parser/collector.rb.  You essentially want to write
your own function that behaves very similarly to the code in there.

On Thu, Mar 10, 2011 at 3:56 PM, Roberto Bouza  wrote:

> I have an array like this:
>
> $items = [ "a", "-b" ]
>
> That should generate something like this (let's say for the Cron
> resource:
>
> Cron <| (tag == "a" or title == "a") and (tag != "b" or title != "b") |
> >
>
> The reason is because we are grouping sets of virtual resources with
> tags to be realized (as a whole) but sometimes we don't want an item
> of that group to get realized.
>
> Like:
>
> @cron { "a":
>  tag => "a",
> }
>
> @cron { "b":
>  tag => "a",
> }
>
> @cron { "c":
>  tag => "a",
> }
>
> All this is generated dynamically... I can write a function to
> generate the string like:
>
> $to_realize = (tag == "a" or title == "a") and (tag != "b" or title !=
> "b")
>
> but if I do
>
> Cron <| $to_realize |>
>
> It fails... brutally.
>
> Any ideas?
>
> Thank you.
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Nagios configuration arrays

[Brian Gallew]

I've found that Puppet/Naginator has the bad habit of occasionally breaking the 
Nagios config.  Here's how I worked around this:
1) When you collect your Nagios resource, store them all in a temporary 
directory (in my case, ~nagios/var/tmp)
2) Purge that directory with a cron job every night (so deleted resources 
disappear)
3) Create an exec that creates a ~nagios/etc/nagios-tmp.cfg by running sed on 
~nagios/etc/nagios.cfg and changing directories appropriately.
4) Create an exec that pre-flights Nagios using the nagios-tmp.cfg (which 
checks the tmp dir) and, if successful, sync the files over into the real 
Nagios config directory.

It's a little clunky, but Nagios doesn't ever break anymore.  Remember that 
your pre-flight exec should require all the Nagios resources (so the files get 
updated first), and should always run if the contents of the tmp dir vary at 
all from the real target (diff is your friend here).  Otherwise, the preflight 
may fail once and then never run again until the next time you make a 
substantive server change.


On Mar 2, 2011, at 10:34 AM, Gabriel Filion wrote:

> Hello,
> 
> I finally abandoned the idea of having a group-based sane-looking Nagios
> configuration with puppet, because there are too many weirdnesses in
> Naginator. And unfortunately I can't really bring any help with patches
> since I don't write any ruby..
> 
> There are some great nagios modules out there which you could use, or
> from which you could borrow ideas. Generally speaking, I see that they
> tend to define services for each host and attach them directly to hosts.
> It's big and clunky, but at least it works..
> 
> For example, in an sshd module, you would have something like:
> 
> @@nagios_service { "${fqdn}_ssh":
>  check_command => "check_ssh",
>  host_name => $fqdn,
> }
> 
> 
> The biggest problem I have right now is that purging nagios resources
> doesn't seem to erase anything, so my config gets messed up from time to
> time when nodes are taken out or things are moved around and I need to
> manullay remove nagios config files and have puppet regenerate them :\
> 
> On 11-03-02 09:55 AM, Martijn Grendelman wrote:
>> On 02-03-11 14:49, Brian Gallew wrote:
>>> Sadly, signs point to "no".
>> 
>> Too bad. But since I run a patched Puppetmaster anyway, I can do what I
>> want :-)
>> 
>> Unfortunately, it doesn't solve my problem.
>> 
>> I am trying to do the same thing as Gabriel Filion in this post:
>> http://groups.google.com/group/puppet-users/browse_thread/thread/276e6e694520224d
>> 
>> So, I have a nagios-target class, that defines a virtual resource:
>> 
>>@@nagios_host { "$hostname":
>>use => "generic-host",
>>address => $fqdn,
>>alias => $hostname,
>>ensure => present,
>>hostgroups => [],
>>}
>> 
>> and I would like to do something along the lines of this: in a different
>> class (not a subclass of nagios-target), for example in the class that
>> configures the MTA:
>> 
>>Nagios_host [$hostname] {
>>hostgroups +> "mail-satellite-servers",
>>}
>> 
>> which results in this error:
>> 
>> "Only subclasses can override parameters at ..."
>> 
>> which sounds logical, but...
>> 
>> Is there any way to do what I want? I can't really think of anything,
>> since (variable) scoping will always be in my way, as far as I can see...
>> 
>>> On Wed, Mar 2, 2011 at 5:15 AM, Martijn Grendelman >> <mailto:mart...@iphion.nl>> wrote:
>>> 
>>>Hi,
>>> 
>>>A question for the devs. Will this:
>>> 
>>>http://projects.puppetlabs.com/issues/4020
>>> 
>>>make it into a release any time soon?
> 
> 
> -- 
> Gabriel Filion
> 
> -- 
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Nagios configuration arrays

[Brian Gallew]

Dude, I struggled with that for more than 6 months, and the position of the 
Puppet people was, "you're doing it wrong".  Since that didn't help my problem 
I ended up doing it this way:
1) Create a new fact (see attached) that reports back to the master server on 
what classes are defined on the client (during the last run!).
2) Create a new function (see attached) that will compute the correct set of 
hostgroups from the class list
3) Create a new fact (see attached) that will determine if the client is a zone 
server (e.g. global zone) or if it's a zone running on a server.
4) Use those to drive my Nagios configs.

Here's the relevant class fragment:

  @@nagios_host {
$fqdn:
  alias => $hostname,
  address => $service_ipaddress,
  max_check_attempts => 3,
  contact_groups => "unix",
  hostgroups => $nagios_hostgroup_list,
  icon_image_alt => $operatingsystem,
  icon_image => "$operatingsystem.png",
  notifications_enabled => 1,
  statusmap_image => "$operatingsystem.gd2",
  tag => inline_template("<%=my_nagios_home.sub(' ','_')%>"), # Puppet 
doesn't like tags with spaces?!?
  notes_url => $cprt_globalzone ? {
global => "https://${hostname}-a.${my_domain}/";,
default => undef,
  },
  parents => $cprt_globalzone ? {
"" => undef,
nil => undef,
global => undef,
default => "${cprt_globalzone}.${my_domain}",
  },
  use => [ $productname ? {
   "Sun Fire X4140" => "host-x4140-template",
       default => "host-generic-template" },
   "host-pnp-template"
   ],
 
 
  }




On Mar 2, 2011, at 6:55 AM, Martijn Grendelman wrote:

> On 02-03-11 14:49, Brian Gallew wrote:
>> Sadly, signs point to "no".
> 
> Too bad. But since I run a patched Puppetmaster anyway, I can do what I
> want :-)
> 
> Unfortunately, it doesn't solve my problem.
> 
> I am trying to do the same thing as Gabriel Filion in this post:
> http://groups.google.com/group/puppet-users/browse_thread/thread/276e6e694520224d
> 
> So, I have a nagios-target class, that defines a virtual resource:
> 
>@@nagios_host { "$hostname":
>use => "generic-host",
>address => $fqdn,
>alias => $hostname,
>ensure => present,
>hostgroups => [],
>}
> 
> and I would like to do something along the lines of this: in a different
> class (not a subclass of nagios-target), for example in the class that
> configures the MTA:
> 
>Nagios_host [$hostname] {
>hostgroups +> "mail-satellite-servers",
>}
> 
> which results in this error:
> 
> "Only subclasses can override parameters at ..."
> 
> which sounds logical, but...
> 
> Is there any way to do what I want? I can't really think of anything,
> since (variable) scoping will always be in my way, as far as I can see...
> 
> Best regards,
> Martijn.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> 
>> On Wed, Mar 2, 2011 at 5:15 AM, Martijn Grendelman > <mailto:mart...@iphion.nl>> wrote:
>> 
>>Hi,
>> 
>>A question for the devs. Will this:
>> 
>>http://projects.puppetlabs.com/issues/4020
>> 
>>make it into a release any time soon?
>> 
>>Best regards,
>>Martijn.
>> 
>>--
>>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
>><mailto:puppet-users@googlegroups.com>.
>>To unsubscribe from this group, send email to
>>puppet-users+unsubscr...@googlegroups.com
>><mailto:puppet-users%2bunsubscr...@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+unsubscr...@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 Us

Re: [Puppet Users] Nagios configuration arrays

[Brian Gallew]

Sadly, signs point to "no".

On Wed, Mar 2, 2011 at 5:15 AM, Martijn Grendelman wrote:

> Hi,
>
> A question for the devs. Will this:
>
> http://projects.puppetlabs.com/issues/4020
>
> make it into a release any time soon?
>
> Best regards,
> Martijn.
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Where to put External Nodes in Multiple Environments?

[Brian Gallew]

Doug, there's a command-line tool called "ack" which is an enhanced grep
replacement.  It will probably do what you wat with finding your nodes.

On Mon, Feb 28, 2011 at 4:43 PM, Douglas Garstang
wrote:

>
>
> On Mon, Feb 28, 2011 at 1:17 PM, Alan Barrett  wrote:
>
>> On Mon, 28 Feb 2011, Douglas Garstang wrote:
>>
>>> How is it possible to use external nodes as local files?  I was under the
 impression that node_terminus=exec or node_terminus=ldap were the only ways
 of using external nodes.

>>>
>>> Really? That might be because everyone seems to be on the LDAP external
>>> node bandwagon. You can put a "external_nodes = 

Re: [Puppet Users] Re: Config Deployment: baseline manifest to all hosts, different sudoers,autofs..etc(manifest) to hosts, by hostname?

[Brian Gallew]

For the way you are doing thing, the easiest answer is: use templates.  Here
is an example from my sshd_config.erb file that may be of use to you:

- CUT HERE -
pps = cprt_classes.split(',') rescue []
my_login_groups = ['root', 'wheel', 'sysadmin']
my_login_groups << 'xdeploy' if pps.index('scheduler') != nil
my_login_groups << 'java' if pps.index('scheduler') != nil
my_login_groups << 'netdb' if pps.index('bind::server') != nil
my_login_groups << 'hudson' if pps.index('hudson') != nil
my_login_groups << 'jira' if pps.index('jira') != nil
my_login_groups << 'security' if fqdn == 'qlvsbild002.example.com'
my_login_groups << 'dev' if fqdn == 'qrnsoems001.example.com'
-%>
AllowGroups <%= my_login_groups.join(' ') %>
- CUT HERE -

Another way to do this would be with override classes.  Here is an (fully
contrived and untested) example.

class standard {
  file { "/etc/passwd":  source => "puppet:///modules/standard/passwd" }
}

class standard::germany inherits standard {
  File["/etc/passwd"]{source => "puppet:///modules/standard/passwd.germany"
}
}

node /^.*.de/ { include standard::germany }
node default { include standard }


On Fri, Feb 25, 2011 at 5:14 AM, Jed  wrote:

> At the least, can someone be so kind as to tell me the term to search
> about -- i've googled a bit, and I think "node override" is what im
> after?
>
> On Feb 24, 9:16 am, Jed  wrote:
> > Hi all,
> >
> > I think this has been asked in one form or another, but my problem so
> > far is i'm not sure of the terminology or nomenclature to use in my
> > search string to find out my answer...
> >
> > So, here is my question..
> >
> > I have lots of systems/instances, like most of us, and like most of
> > they are spread across different tiers and environments.
> >
> > ie. dev/stg/prod
> >
> > i've setup my puppet master to look for environment variables and
> > based off of that the client will look under /etc/puppet/development
> > or ./lab or ./prod ...etc..etc (that works great)
> >
> > Now i've reached the point where I have a global baseline config/
> > manifest that every host in each environment(dev/stg/prod) will get -
> > that works great as well.
> >
> > My problem now is that we have different host "groups", that require
> > different files set of files outside of what the global base_line
> > manifest provides.
> >
> > for intance..
> >
> > host that contain "wwwfe" in their host name need a different sudoers
> > file then hosts that contain "profile" in thier hostname
> >
> > is there a way that i can say...
> >
> > provide the base_line to every machines/instance, but only provide the
> > "www-sudoers" file to host that contain "wwwfe" in their hostname
> >
> > or...
> >
> > provide the profile_sudoers file only to hosts that contain the
> > "profile" in their host names?
> >
> > not sure if they is even the correct way to go about this
> > currently I don't have any external node configuration(ie. ldap) so
> > i'm doing everything by hand in the nodes.pp file
> >
> > Thanks guy/gals, I really appreciate all the help!
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] provisioning bare metal (best practices)

[Brian Gallew]

Never forget the DHCP does NOT necessarily mean "dynamic addresses".  Depending 
upon your corporate culture, it may be perfectly acceptable for DHCP to hand 
out statically assigned addresses to your hosts.  This would allow your build 
process to be easy, and you can have the host never DHCP again after it's up 
and running (until you rebuild it!).


On Feb 22, 2011, at 8:15 AM, Jonathan Gazeley wrote:

> We have a small pool of DHCP IP addresses for use only in the build process. 
> This is our process:
> 
> 1. We boot the servers from PXE network boot
> 
> 2. They get one of the temporary IPs
> 
> 3. They start a CentOS network install using a kickstart file with the bare 
> minimum of packages selected, including puppet
> 
> 4. The last stage of the kickstart is to set puppet running
> 
> 5. At this stage, human intervention is required to authorise the new machine 
> in puppetca. I'm aware that it is possible to have this step done 
> automatically, but it can be a security risk.
> 
> 6. Once the server is authorised in puppet, it receives a basic "common" 
> config from puppet, which gives it the proper static IP that it should have, 
> disables DHCP, sets the hostname, sets up NTP, etc.
> 
> 7. From now on, it's dead easy to use puppet to install and configure 
> everything else.
> 
> Cheers,
> Jonathan
> 
> 
> Jonathan Gazeley
> Systems Support Specialist
> ResNet | Wireless & VPN Team
> IT Services
> University of Bristol
> 
> 
> On 22/02/11 15:47, David Kavanagh wrote:
>> I'm about to start playing with Kickstart. I never really had to
>> provision bare servers beyond a normal OS install, so I need something
>> to use along with Puppet. Is there a general consensus on what the best
>> option is?
>> I'd need to set up the node with IP/hostname/role. (I have a custom fact
>> for role). I figured I'd simply ssh in to write the role file, but if
>> I'd rather not use dhcp, I suppose I'll need to get the network
>> interface configured in another way. What do folks generally do here?
>> 
>> David
>> 
>> --
>> 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+unsubscr...@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] String size limit for variables?

[Brian Gallew]

Yeah, fire up MySQL and alter the column to be of type TEXT instead of 
VARCHAR(255).  I ran into the same problem.  I believe the column you are 
looking for is fact_values.value.

On Feb 18, 2011, at 12:26 PM, Mark Stanislav wrote:

> So I had been smashing my head against a wall, unsure why I was receiving an 
> error trying to utilize a Facter fact for Munin interface generation.
> 
> err: Could not retrieve catalog from remote server: Error 400 on SERVER: 
> Duplicate definition: Munin::Interfaces[eth0] is already defined in file 
> /etc/puppet/modules/munin/manifests/init.pp at line 14; cannot redefine at 
> /etc/puppet/modules/munin/manifests/init.pp:14 on node foo.bar
> 
> This led me down many roads until I decided to use notify {} to check the 
> contents of the variable inside of my maniest...
> 
> notice: 
> eth0,eth0_0,eth0_1,eth0_2,eth0_3,eth0_4,eth0_5,eth0_6,eth0_7,eth0_8,eth0_9,eth0_10,eth0_11,eth0_12,eth0_13,eth0_14,eth0_15,eth0_16,eth0_17,eth0_18,eth0_19,eth0_20,eth0_21,eth0_22,eth0_23,eth0_24,eth0_25,eth0_26,eth0_27,eth0_28,eth0_29,eth0_30,eth0_31,eth0
> 
> Ah-ha! So it's truncating. Specifically after 256 characters.
> 
> # echo 
> "eth0,eth0_0,eth0_1,eth0_2,eth0_3,eth0_4,eth0_5,eth0_6,eth0_7,eth0_8,eth0_9,eth0_10,eth0_11,eth0_12,eth0_13,eth0_14,eth0_15,eth0_16,eth0_17,eth0_18,eth0_19,eth0_20,eth0_21,eth0_22,eth0_23,eth0_24,eth0_25,eth0_26,eth0_27,eth0_28,eth0_29,eth0_30,eth0_31,eth0"
>  | wc -c
> 256
> 
> Is this a known situation and if so, how can I augment Puppet, my manifest, 
> or otherwise to allow me to not have this limit?
> 
> Thanks!
> 
> -Mark
> 
> -- 
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Ordering

[Brian Gallew]

On Feb 3, 2011, at 10:22 AM, Adam Gibbins wrote:
> On 3 February 2011 18:14, Brian Gallew  wrote:
> Add a fact that's derived from parsing /var/lib/puppet/state/classes.txt.  It 
> will be exactly one run behind, but it will have the complete list of classes 
> as of the previous run and it's reliable.
> 
> I considered this, though as you say the run is going to be delayed which is 
> a little annoying as our puppet runs are only once every half hour.  So I'd 
> have to wait an hour for  graphing, also seems not as clean as it should be. 

Welcome to my life.  I'm building Nagios and ssh configs off of class data, and 
both suffer from this issue.  If it helps, it's only annoying when you think 
about it.  8-/

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Ordering

[Brian Gallew]

Add a fact that's derived from parsing /var/lib/puppet/state/classes.txt.  It 
will be exactly one run behind, but it will have the complete list of classes 
as of the previous run and it's reliable.

On Feb 3, 2011, at 9:58 AM, Richard Crowley wrote:

> On Thursday, February 3, 2011 at 9:53 AM, Adam Gibbins wrote:
> 
>> Hi All,
>> I'm trying to implement a template (for my collectd config) that gives 
>> different results depending on the other modules included on that machine.
>> I tried to do this by checking for the class tags but it turns out that due 
>> to bug #3049 this is a huge pain and 90% of the time the tags aren't 
>> registered by the time the template is parsed so I don't get my expected 
>> result.
> Use multiple collectd configuration files if you possibly can.  Then each 
> class can manage its own little corner of collectd.  Putting
> 
> Include "/etc/collectd.d/*.conf"
> 
> in your main /etc/collectd.conf should make this possible if it isn't by 
> default.
> 
> Rich
> 
> -- 
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Multiple external commands with puppet

[Brian Gallew]

While it's perfectly appropriate to have multiple exec{} or a single exec{} 
with a multi-line command in your puppet manifest, once you reach a certain 
level of complexity you almost invariably want to switch to a 
file{"/usr/local/scripts": ...} exec{"/usr/local/scripts/doit": ...} model.  
The script can be trivially customized for the local system by puppet giving 
you great flexibility, while allowing more complex code paths or alternate 
languages to be easily used.

On Feb 3, 2011, at 8:29 AM, Mark Stanislav wrote:

> Are you able to group these sed statements into a script and pass arguments 
> to the script to do whatever set of executions are needed for that specific 
> dataset?
> 
> I may not understand your 'need' exactly, either. Can you explain more of 
> what you are trying to accomplish and less about what you've chosen to 
> accomplish it with. May help stir-up better answers.
> 
> -Mark
> 
> On Feb 3, 2011, at 11:23 AM, linuxbsdfreak wrote:
> 
>> Hi,
>> 
>> I want to execute multiple sed commands using the exec commands within
>> puppet. I can only setup one command parameter. For now i have to give
>> a long list of commands separated with ";"  in order to use the single
>> command parameter. I know there are other efficient ways to solve this
>> problem. But my requirement is such i need to execute multiple
>> commands using the exec tool within  puppet. Any one have who can give
>> me a hint how this problem could be solved.
>> 
>> NOTE: I need only the command parameter of exec. I dont need the other
>> parameters
>> 
>> Regards,
>> Kevin
>> 
>> -- 
>> 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+unsubscr...@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: How to include the Scope(...) in a generated string?

[Brian Gallew]

My experience with it is that it only includes declared/included classes
(which matches my desire anyway), but that the list of classes is ...
somewhat random.  It will always include the classes in the chain of the
test, but other classes are more random.  A short example:

class one{ include two;include three}
class two {notice "two: $classes"}
class three {notice "three: $classes" }


There will be two notices printed, with two possible variations each,
depending upon what the compiler chooses to do this time:

two: one two
two: one two three (order may vary)

three: one three
three: one two three (again, order may vary)


In my case, I'm evaluating template("ssh/sshd_config.erb") inside my
"minimal" class, because *every* host has ssh, but the set of users allowed
to login to each host varies depending upon the total set of classes
involved.  If I include role::web_server, then the web server manager needs
to be able to login.  If I include role::dev, then all of the developers
should have access.  A host may have multiple roles, and thus the need for
some reasonable way of determining what classes are associated with the
node.  When I ran 2.6.1, this worked as desired (I *think*).  After updating
to 2.6.3, it almost never worked as desired.

If I had to guess, I'd say that the evaluation of templates (and possibly
inline_templates) previously happened after the first pass at parsing when
the list of classes would be complete except for those whose inclusion is
predicated on the inline_template() evaluations.  Now it's clear that all
the templates (inline or not) are evaluated at the point they are
encountered, which should be(!) in a fixed order, though it seems (sorry, I
haven't exhaustively tested) to vary somewhat from run to run.


On Wed, Feb 2, 2011 at 6:00 PM, Nick Fagerlund <
nick.fagerl...@puppetlabs.com> wrote:

> *EXPERIMENTS*
>
> Huh, it seems to return the DECLARED classes, not the defined ones,
> i.e. it can only see the modules and classes that are being applied to
> this particular node. OK, I could see an argument for that making
> sense. BUT: It also includes the names of any `node` constructs that
> match it (these are nodes defined in manifests, not from an ENC), and
> for some reason classes set via an ENC show up twice. I don't
> understand that. Also, there's one mystery class from Mars in there
> called "settings." What's THAT about.
>
> On Feb 2, 5:50 pm, Nick Fagerlund 
> wrote:
> > On it. (Thanks for the example, Dan; that's pretty sweet.)
> >
> > Brian, what problem do you tend to see with the classes array? Does it
> > look like an order dependency? Is it just a crapshoot as to whether a
> > given class is in the list, or is there a method to it?
> >
> > On Feb 2, 5:18 pm, Brian Gallew  wrote:
> >
> >
> >
> >
> >
> >
> >
> > > On Feb 2, 2011, at 4:57 PM, John Warburton wrote:
> >
> > > > I would love to see that inhttp://
> docs.puppetlabs.com/guides/templating.htmlinthe "Access to defined tags
> and classes" section. I have created a ticket for that -
> https://projects.puppetlabs.com/issues/6124
> >
> > > Sadly, there's also a great need to update that section to reflect the
> reality that the classes variable can never be relied upon to be in any way
> complete.
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] How to include the Scope(...) in a generated string?

[Brian Gallew]

On Feb 2, 2011, at 4:57 PM, John Warburton wrote:

> I would love to see that in http://docs.puppetlabs.com/guides/templating.html 
> in the "Access to defined tags and classes" section. I have created a ticket 
> for that -https://projects.puppetlabs.com/issues/6124

Sadly, there's also a great need to update that section to reflect the reality 
that the classes variable can never be relied upon to be in any way complete.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] RE: each clients classes.txt on the server

[Brian Gallew]

It's a pretty trivial function:

Facter.add(:cprt_classes) do
setcode do
open('/var/lib/puppet/state/classes.txt').read().split().join(',') 
rescue ""
end
end

You'll want to change cprt_classes to match your naming scheme.

2 caveats:
1) If you have more than a handful of classes, you'll need to alter the 
fact_values.value field to be of type TEXT (or at least varchar(1024)).
2) If you reference this fact in your templates, be aware that the very first 
run will have no information and that it will, in fact, always lag one 
interation (e.g. you add a new class ssh:foo, it will take 2 puppet agent runs 
before that class shows up in the fact list) 


On Jan 30, 2011, at 1:43 PM, Sukh Khehra wrote:

> Thank you Brian. Would you mind sharing the code for your custom fact that 
> reads in /var/lib/puppet/classes.txt and presents it as a csv fact value. 
> This would really save me some time as I am not a ruby developer.
>  
> From: puppet-users@googlegroups.com [mailto:puppet-users@googlegroups.com] On 
> Behalf Of Brian Gallew
> Sent: Thursday, January 27, 2011 9:08 PM
> To: puppet-users@googlegroups.com
> Subject: Re: [Puppet Users] RE: each clients classes.txt on the server
>  
> Interestingly enough, I wrote a custom fact to do that.  In my case, I have 
> and sshd_config.erb where I want to set the AllowGroups stanza based on all 
> the classes applied to a node.  With 2.6.1 I could achieve that effect simply 
> by moving adding a class to the "post" stage (which is run after main) and 
> have that class contain the relevant file{}.  When I updated to 2.6.3 it 
> started parsing the template the moment it encountered the resource, rather 
> than waiting for the relevant stage to be reached.  Now I just pass back a 
> comma-separated list of all classes for each host and my erb knows how to 
> handle that.  A word or warning: as shipped, the fact_value field is 
> VARCHAR($SMALL_VALUE) characters long.  I had to change it to be a TEXT field 
> because otherwise it truncated my data.
> 
> On Thu, Jan 27, 2011 at 6:38 PM, Sukh Khehra  wrote:
> Forgot to mention that we’re running 2.6.4 on the server and in the process 
> of migrating all clients from 0.25.5 to 2.6.4.
>  
> From: puppet-users@googlegroups.com [mailto:puppet-users@googlegroups.com] On 
> Behalf Of Sukh Khehra
> Sent: Thursday, January 27, 2011 6:33 PM
> To: puppet-users@googlegroups.com
> Subject: [Puppet Users] each clients classes.txt on the server
>  
> We have a lot of includes in our code so it takes some digging around to find 
> the resultant set of classes that apply to a puppet clients. I was thinking 
> of somehow copying classes.txt file from the client to the server for easier 
> analysis. Anyone have any art on how to go about doing that? I’d appreciate 
> any ideas.
>  
> Regards,
> Sukh Khehra
> Sys Admin
> -- 
> 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+unsubscr...@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+unsubscr...@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+unsubscr...@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Puppet 2.6 on Solaris

[Brian Gallew]

Interestingly enough, it's pretty easy to make a Solaris package.  More than
that, it may well be necessary that you do so since your package would
depend on Ruby, which could be in one of several places, and your own
organization's policies on where addons go might differ from someone
else's.  Also, if you look carefully, you'll notice that none of those
packages were created by Puppetlabs.  That being the case, you might want to
ask the people who built them if the were going to update them.  Finally, as
John pointed out, gems are packages, too.

On Mon, Jan 31, 2011 at 5:49 AM, John Lyman  wrote:

> Gems are always an option.
>
> On Jan 31, 4:06 am, David Schmitt  wrote:
> > Hi all,
> >
> > I'm looking for current puppet packages for Solaris and found only
> > blastwave (0.25.5), opencsw (http://www.opencsw.org/packages/CSWpuppet/,
> > 0.25.4) and Gary Law's repo (http://garylaw.net/packages/, 0.25.1).
> >
> > Are there any current (2.6.x) packages for Solaris?
> >
> > http://projects.puppetlabs.com/projects/1/wiki/Puppet_Solarisseems to
> > need some love too.
> >
> > Best Regards, David Schmitt
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] RE: each clients classes.txt on the server

[Brian Gallew]

Interestingly enough, I wrote a custom fact to do that.  In my case, I have
and sshd_config.erb where I want to set the AllowGroups stanza based on all
the classes applied to a node.  With 2.6.1 I could achieve that effect
simply by moving adding a class to the "post" stage (which is run after
main) and have that class contain the relevant file{}.  When I updated to
2.6.3 it started parsing the template the moment it encountered the
resource, rather than waiting for the relevant stage to be reached.  Now I
just pass back a comma-separated list of all classes for each host and my
erb knows how to handle that.  A word or warning: as shipped, the fact_value
field is VARCHAR($SMALL_VALUE) characters long.  I had to change it to be a
TEXT field because otherwise it truncated my data.

On Thu, Jan 27, 2011 at 6:38 PM, Sukh Khehra  wrote:

>  Forgot to mention that we’re running 2.6.4 on the server and in the
> process of migrating all clients from 0.25.5 to 2.6.4.
>
>
>
> *From:* puppet-users@googlegroups.com [mailto:
> puppet-users@googlegroups.com] *On Behalf Of *Sukh Khehra
> *Sent:* Thursday, January 27, 2011 6:33 PM
> *To:* puppet-users@googlegroups.com
> *Subject:* [Puppet Users] each clients classes.txt on the server
>
>
>
> We have a lot of includes in our code so it takes some digging around to
> find the resultant set of classes that apply to a puppet clients. I was
> thinking of somehow copying classes.txt file from the client to the server
> for easier analysis. Anyone have any art on how to go about doing that? I’d
> appreciate any ideas.
>
>
>
> Regards,
>
> Sukh Khehra
>
> Sys Admin
>
> --
> 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+unsubscr...@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] How to deal with a slightly changing file?

[Brian Gallew]

Either comment it out for the one run or delete the target file manually.  
Neither solution is really good.

On Jan 27, 2011, at 10:34 AM, Mohamed Lrhazi wrote:

> Thanks Brian...
> Looks like 2 and 3 are my options
> 
> 2) Add "replace=>false" so that Puppet will create the file but never
> update it if it exists.  Of course, that breaks when you have updates
> that you really do need puppet to apply.
> 
> When I need to force the update, I would simply comment out the
> 'replace" for one run? is there a better way?
> 
> Mohamed.
> 
> 
> 
> On Thu, Jan 27, 2011 at 12:00 PM, Brian Gallew  wrote:
>> Not really.  There are a couple ways to handle this:
>> 1) Make use of includes.  Have the puppet-managed file include the 
>> app-managed file.  Of course, this requires the app to be friendly to this 
>> kind of setup.
>> 2) Add "replace=>false" so that Puppet will create the file but never update 
>> it if it exists.  Of course, that breaks when you have updates that you 
>> really do need puppet to apply.
>> 3) Install/use augeas.  You'll probably need to write an appropriate lens, 
>> but if done correctly, this is very robust.
>> 4) Use an exec to modify the file in-place.  This is fugly.
>> 5) Use an exec with the application's CLI to to have the application make 
>> the updates.  Better than 4, but still not exactly beautiful.
>> 
>> On Jan 27, 2011, at 8:26 AM, Mohamed Lrhazi wrote:
>> 
>>> I have a file that is part of a software I am installing via puppet...
>>> the file is constructed from a template, as it has a couple of fields
>>> I wanna be able to change in the future.
>>> The file is updated by the app itself, upon restart, which changes
>>> just one field, in a key=val line...the result is that puppet rebuilds
>>> the file, and becuase of depnedecy, restarts the app at each run.
>>> 
>>> Can I somehow say ignore that one line?
>>> 
>>> file { "splunk_outputs":
>>>   owner   => splunk,
>>>   group   => splunk,
>>>   mode=> 644,
>>>   require => [Package["splunk"]],
>>>   path => "/opt/splunk/etc/system/local/outputs.conf",
>>>   content => template("gu_splunk/outputs.conf.erb"), #but please
>>> ignore line starting with: sslPassword=
>>>   notify => Exec["restart"],
>>>   }
>>> 
>>> Thanks a lot.
>>> Mohamed.
>>> 
>>> --
>>> 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+unsubscr...@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+unsubscr...@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] How to deal with a slightly changing file?

[Brian Gallew]

Not really.  There are a couple ways to handle this:
1) Make use of includes.  Have the puppet-managed file include the app-managed 
file.  Of course, this requires the app to be friendly to this kind of setup.
2) Add "replace=>false" so that Puppet will create the file but never update it 
if it exists.  Of course, that breaks when you have updates that you really do 
need puppet to apply.
3) Install/use augeas.  You'll probably need to write an appropriate lens, but 
if done correctly, this is very robust.
4) Use an exec to modify the file in-place.  This is fugly.
5) Use an exec with the application's CLI to to have the application make the 
updates.  Better than 4, but still not exactly beautiful.

On Jan 27, 2011, at 8:26 AM, Mohamed Lrhazi wrote:

> I have a file that is part of a software I am installing via puppet...
> the file is constructed from a template, as it has a couple of fields
> I wanna be able to change in the future.
> The file is updated by the app itself, upon restart, which changes
> just one field, in a key=val line...the result is that puppet rebuilds
> the file, and becuase of depnedecy, restarts the app at each run.
> 
> Can I somehow say ignore that one line?
> 
> file { "splunk_outputs":
>   owner   => splunk,
>   group   => splunk,
>   mode=> 644,
>   require => [Package["splunk"]],
>   path => "/opt/splunk/etc/system/local/outputs.conf",
>   content => template("gu_splunk/outputs.conf.erb"), #but please
> ignore line starting with: sslPassword=
>   notify => Exec["restart"],
>   }
> 
> Thanks a lot.
> Mohamed.
> 
> -- 
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] How to deal with a slightly changing file?

[Brian Gallew]

Not really.  There are a couple ways to handle this:
1) Make use of includes.  Have the puppet-managed file include the app-managed 
file.  Of course, this requires the app to be friendly to this kind of setup.
2) Add "replace=>false" so that Puppet will create the file but never update it 
if it exists.  Of course, that breaks when you have updates that you really do 
need puppet to apply.
3) Install/use augeas.  You'll probably need to write an appropriate lens, but 
if done correctly, this is very robust.
4) Use an exec to modify the file in-place.  This is fugly.
5) Use an exec with the application's CLI to to have the application make the 
updates.  Better than 4, but still not exactly beautiful.

On Jan 27, 2011, at 8:26 AM, Mohamed Lrhazi wrote:

> I have a file that is part of a software I am installing via puppet...
> the file is constructed from a template, as it has a couple of fields
> I wanna be able to change in the future.
> The file is updated by the app itself, upon restart, which changes
> just one field, in a key=val line...the result is that puppet rebuilds
> the file, and becuase of depnedecy, restarts the app at each run.
> 
> Can I somehow say ignore that one line?
> 
> file { "splunk_outputs":
>owner   => splunk,
>group   => splunk,
>mode=> 644,
>require => [Package["splunk"]],
>path => "/opt/splunk/etc/system/local/outputs.conf",
>content => template("gu_splunk/outputs.conf.erb"), #but please
> ignore line starting with: sslPassword=
>notify => Exec["restart"],
>}
> 
> Thanks a lot.
> Mohamed.
> 
> -- 
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Syncing /modules --dir via Puppet

[Brian Gallew]

Since my manifests are all in Subversion, all my puppet masters run a job every 
hour that updates all of the local branches (prod, dev, etc).

On Jan 25, 2011, at 8:46 AM, CraftyTech wrote:

> Hello All,
> 
>  For those who run multiple Puppetmasters; what's your method of syncing 
> the modules directory? NFS, rsync, etc?  I'm asking, because I'd like to use 
> puppet itself to sync up the modules.  I know that the normally the modules 
> dir gets shared automatically, but what would be the implications to file 
> serve the entire modules dir via /etc/puppet/fileserver.conf, to sync up with 
> other masters? What's the best practices way of syncing modules dir across 
> masters?
> 
> Thanks,
> 
> 
> 
> -- 
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Get resource from http

[Brian Gallew]

"You are not authorized to access this page.

On Wed, Jan 5, 2011 at 12:07 PM, Daniel Pittman  wrote:

> ...ideally, that answer should be "for now", because every second
> person seems to want this feature.  Which will be helped if someone
> filed a feature request.  So, um, I did:
> https://projects.puppetlabs.com/issue_moves/new/5783
>
> If you want this please watch that ticket and/or add comments about
> what you need it to do.  Obviously no promises, but that makes it more
> uniform (and, to my surprise, there wasn't already an obvious one...)
>
> Regards,
>Daniel
>
> On Wed, Jan 5, 2011 at 00:57, Patrick  wrote:
> > On Jan 4, 2011, at 10:13 PM, Dmytro Bablinyuk wrote:
> >
> >> How can I get resource from http?
> >
> > Short answer: You can't.
> >
> > Longer answer: You need to wrap a program that can (like curl or wget) in
> an exec.
> >
> > --
> > 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.
> >
> >
>
>
>
> --
> ✉ Daniel Pittman 
> ⌨ dan...@rimspace.net (XMPP)
> ☎ +1 503 893 2285
> ♻ made with 100 percent post-consumer electrons
>
> --
> 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.
>
>

-- 
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.

Re: [Puppet Users] Multiple AllowGroups entries in sshd_config with Puppet and Augeas

[Brian Gallew]

So, once again usability is sacrificed in favor of purity.

If you are using Puppet 2.6.1, you can move evaluation of the
sshd_config.erb template to a "post" stage, and then generate your
AllowGroups stanza from the class list (which will be complete).  Here's an
excerpt from my sshd_config.erb that I used before upgrading to 2.6.3 (which
broke this behavior):

# This is where the access control bits live
<%
my_login_groups = ['root', 'wheel', 'sysadmin']
my_login_groups << 'oinstall' if classes.index('oracle') != nil
my_login_groups << 'dba' if classes.index('oracle') != nil
my_login_groups << 'puppet' if classes.index('puppet::master') != nil
my_login_groups << 'jboss' if classes.index('jboss') != nil
my_login_groups << 'nagios' if classes.index('nagios::server') != nil
# more deleted
%>
AllowGroups <%= my_login_groups.join(' ') %>

With 2.6.3, you have to do this in a two-stage process.  First, write a
custom fact that returns the contents of classlist.txt on the client.  Then
change the above code to work with that fact.  In my environment, the
equivalent to the above looks like this:

# This is where the access control bits live
<%
### "pps" stands for "Puppet purity sucks"
pps = cprt_classes.split(',')
my_login_groups = ['root', 'wheel', 'sysadmin']
my_login_groups << 'oinstall' if pps.index('oracle') != nil
my_login_groups << 'dba' if pps.index('oracle') != nil
my_login_groups << 'puppet' if pps.index('puppet::master') != nil
my_login_groups << 'jboss' if pps.index('jboss') != nil
my_login_groups << 'nagios' if pps.index('nagios::server') != nil
# more deleted
%>
AllowGroups <%= my_login_groups.join(' ') %>


My irritation with the behavioral change aside, this works just as well as
the code above, except that it takes two Puppet runs to be correct.

If the Puppet DSL had some kind of useful container type, we could put all
the configuration bits in the manifests instead of duplicating this crazy
templating all over the place.


On Wed, Dec 22, 2010 at 5:21 PM, Hugo Cisneiros (Eitch) <
hugo.cisnei...@gmail.com> wrote:

> Hi,
>
> After extensively looking into puppet + augeas for managing the
> AllowGroups in sshd_config, I came to the conclusion that it won't
> work as I expected :( So I'm sharing my thoughts here.
>
> The main objective is allowing multiple groups per-node, depending on
> what the security team wants. Since I want this to be dynamic, I
> created a define in a class:
>
> class ssh::server::config inherits ssh::config {
>define addallowgroup() {
>augeas {
>"sshd_conf_group_${name}":
>context => "/files/etc/ssh/sshd_config",
>require => File["/etc/ssh/sshd_config"],
>notify => Service["sshd"],
>changes => "set AllowGroups/*[last()+1] ${name}",
>onlyif => " match AllowGroups/*[.='${name}'] size == 0";
>}
>}
> }
>
> Then on a node, I can use this:
>
> node "webserver" {
>ssh::server::config::addallowgroup { ["test1", "test2", "test3"]: }
> }
>
> Sadly, the "changes" and "onlyif" lines in the augeas type does not
> work because the sshd_config's lens creates a unique node/label for
> each option. Quoting Augeas' website:
>
> "
> http://augeas.net/page/Adding_nodes_to_the_tree
>
> You can use a special trick to append to a list of nodes that all have
> the same name, for example to append a new alias to an entry in
> /etc/hosts:
>
> set $hosts/1/alias[last()+1] myhost.example.com
>
> The predicate [last()+1] forces set to create a new node. Of course,
> after the node is created, it is now reachable as
> $hosts/1/alias[last()]. It's important to remember that creating nodes
> with set can only work if the labels for all the nodes that need to be
> created are known explicitly. In particular, you can't add a new host
> entry using something like set $hosts/*[last()+1]/ipaddr 192.168.0.1 —
> there's no way for Augeas to know what the new node for *[last()+1]
> should be called.
> "
>
> In the example on hosts, the "alias" label is already named. So I
> can't think on adding another node/label dynamically.
>
> The alternative could be creating one augeas type for each group and
> using them on the nodes, like this:
>
> augeas {
>"sshd_conf_group_test1":
>context => "/files/etc/ssh/sshd_config",
>require => File["/etc/ssh/sshd_config"],
>notify => Service["sshd"],
>changes => "set AllowGroups/1 test1",
>onlyif => " match AllowGroups/1[.='test1'] size == 0";
>
>"sshd_conf_group_test2":
>context => "/files/etc/ssh/sshd_config",
>require => File["/etc/ssh/sshd_config"],
>notify => Service["sshd"],
>changes => "set AllowGroups/2 test2",
>onlyif => " match AllowGroups/2[.='test2'] size == 0";
>
>"sshd_conf_group_test1":
>context => "/files/etc/ssh/sshd_config",
>require => File["/etc/ssh/sshd_config"],
>notify => Service["sshd"],
>changes => "set AllowGroup

Re: [Puppet Users] Re: Recent (unfun) experience with cron resource on Solaris 10 with puppet 0.25.5

[Brian Gallew]

In general, "cron != vixie-cron".  It turns out that most of the Unix world
pre-dates Linux and for various reasons (not the least of which are legal
issues, branding, and in-product compatibility) it is generally *extremely*
poor form to assume Linux-isms.  Clearly, the cron provider should be
updated to reflect this reality.  Perhaps filing a bug report is in order?

On Sat, Dec 18, 2010 at 11:02 AM, russell.fulton
wrote:

> little historical note for the record
>
> Solaris cron is old -- system V or BSD 4.2.  Most (all ?) Linux
> distros  and modern *BSDs use Paul Vixie's Cron which has all the
> flexibility that we know and love.
>
> I suspect that AIX will be similar to Solaris -- painful.
>
> Russell
>
> --
> 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.
>
>

-- 
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.

Re: [Puppet Users] foreman issue

[Brian Gallew]

Foreman's report agent, for some reason, doesn't update as many of the
Foreman DB fields as one might wish.  I submitted a patch on this, but as
Mark pointed out, the approved way to do this is to run a rake periodically
to re-import all of the reports and/or classes.

If you are interested in hacking it for yourself, you should look at
app/models/report.rb.  You'll specifically be looking at self.import(yaml).
Here is the meat of my patch:

host.environment =
Environment.find_or_create_by_name(host.fv(:environment))
host.hostgroup =
Hostgroup.find_or_create_by_name(host.fv(:cprt_globalzone))
host.architecture =
Architecture.find_or_create_by_name(host.fv(:hardwareisa))

val = host.fv(:productname)
val = host.fv(:virtual) if val == nil
host.model = Model.find_or_create_by_name(val)

major, minor = host.fv(:operatingsystemrelease).split(".",2)
v = Operatingsystem.first(:conditions => "name =
\"#{host.fv(:operatingsystem)}\" and major = \"#{major}\" and minor =
\"#{minor}\"")
if v
  host.os = v
else
  host.os = Operatingsystem.create({:name =>
host.fv(:operatingsystem),
 :major => major,
 :minor => minor})
end

host.puppetclasses = host.fv(:cprt_classes).split(',').map() do |c|
  Puppetclass.find_or_create_by_name(c)
end



On Mon, Dec 20, 2010 at 5:05 AM, Mark Stanislav wrote:

> You need to run the rake again. Setup a cronjob to execute it every so
> often if you need new hosts regularly (e.g. Auto scaling)
>
> -Mark
>
>
>
> On Dec 20, 2010, at 6:58 AM, walexey  wrote:
>
> > Hello!
> > I try to use foreman. It's successfuly import current nodes from
> > puppet storeconfig. Nodes hostname stored in short form, without
> > domain.
> > After that, i run puppet on newly  created additional 5 nodes. They
> > shows in foreman with full fqdn. Os, environment, architecture for
> > this nodes not shown.
> > How can i fix this issue?
> >
> > --
> > 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.
> >
>
> --
> 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.
>
>

-- 
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.

[Puppet Users] 2.6.3 differs in behavior from 2.6.1

[Brian Gallew]

Before I go and write yet another custom fact, I just want to be sure that
the behavior I'm seeing is "as designed" rather than a regression.

When I ran 2.6.1, I had the following snippets working as expected:
base/manifests/minimal.pp:

  class {"ssh::sshd_config": stage => post}


ssh/manifests/init.pp:

class ssh::sshd_config {
  service{"sshserver":
name => $operatingsystem ? {
  Solaris => "/network/ssh",
  default => "sshd"
},
ensure => running
  }

  file{"/etc/ssh/sshd_config":
content => template("ssh/sshd_config.erb"),
notify => Service["sshserver"],
owner => root, group => root, mode => 0644,
  }
}


ssh/template/sshd_config.erb:

<%
my_login_groups = ['root', 'wheel', 'sysadmin']
my_login_groups << 'netdb' if classes.index('bind::server') != nil
my_login_groups << 'jira' if classes.index('jira') != nil
my_login_groups << 'archiva' if classes.index('archiva') != nil
my_login_groups << 'maven' if classes.index('maven') != nil
my_login_groups << 'oinstall' if classes.index('oracle') != nil
my_login_groups << 'dba' if classes.index('oracle') != nil
my_login_groups << 'puppet' if classes.index('puppet::master') != nil
my_login_groups << 'jboss' if classes.index('jboss') != nil
my_login_groups << 'nagios' if classes.index('nagios::server') != nil
%>
AllowGroups <%= my_login_groups.join(' ') %>


IN 2.6.1, this generated an AllowGroup stanza based on the complete set of
classes assigned to any given puppet client.  In 2.6.3, however, when the
template is parsed classes contains *only* the classes that were included in
minimal.pp before the ssh:sshd_config stanza.  I was under the impression
that the intention was that evaluation order wasn't supposed to matter, so
toplevel variables like classes should be *complete* before any templates
are evaluated.

If this *is* the desired behavior then I'll just create a custom fact that
will extract the data from the classes.txt file on the client which will be
fugly but functional.  If it's not, let me know and I'll open a bug report.

-- 
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.

Re: [Puppet Users] easy to way to track clients checking in?

[Brian Gallew]

Personally, I like Foreman for doing that, especially once I've patched it
to make certain Foreman-specific variables set by the report processor.  In
theory Dashboard will do the same thing, though I've never been able to get
it to work reliably (incompatible gem set).

And of course, there's always the old standby of looking in
/var/lib/puppet/reports for directories that haven't been updated in a
while.

On Mon, Nov 29, 2010 at 12:55 PM, David Birdsong
wrote:

> I've been wrestling to get the puppet ca server to sign client certs
> and have them successfully reconnect later.  I think I've done:
> find /var/lib/puppet/ -type f  -delete ; sudo find /etc/puppet/ssl
> -type f -delete ;  sudo /usr/sbin/puppetd --server puppet -d -o
> --no-daemonize  --waitforcert 2
> ...to all my hosts at least 10 times now.
>
> Occasionally I get the:
> err: Could not retrieve catalog from remote server: undefined method
> `closed?' for nil:NilClass
>
> ...which, if I simply restart puppetmasterd, resolves the issue for a
> given host.
>
> In debugging all of this, I had to come up with a way to detect hosts
> out of sync--ie hosts that should have had an update, but for whatever
> reason are unable to fetch or apply their catalog.  What I've been
> doing is to distribute /etc/sudoers via puppet, make a change to
> sudoers (which happens naturally anyway), wait for the client poll
> interval to pass(actually 2x the poll interval), then run through the
> fleet looking for out of date md5sums of /etc/sudoers to flag a host
> that is having puppet agent problems.
>
> I am in cert hell, but I'm faithful that I can climb out of this hell.
>  Is there any tool on the server side that could help indicate failing
> puppet agents?  cfengine had --last-seen and displayed how long since
> an agent had successfully pulled down cf files.  If not tools, what in
> the logs could I use to write my own tool?
>
> --
> 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.
>
>

-- 
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.

Re: [Puppet Users] Monitor puppet runs on clients with nagios

[Brian Gallew]

I've been thinking about this myself, and I've come up with a few
possibilities.

1) Leverage the reports on the puppet master.  This could be done with a
daemon that watched /var/lib/puppet/reports, for instance.
2) Leverage the reports on the puppet clients.  Each puppet run could ship
the report of the previous puppet run off to nagios via a custom function.
It would run behind, though, which is an issue.
3) Leverage Dashboard/Foreman.  Both of those have APIs that can be queried
to determine host status and get the errors from the report.
4) Leverage puppet's report subsystem: create another report (e.g. "nagios")
and have it send Nagios the correct information.

Of all the choice here, I like 4 the best, and it's what I'm planning on
implementing when I've got a stock of round tuits.  Basically, I'll get the
report status and use send_nsca to send the results to Nagios.

Alternatively, if the rest of the team insists that Nagios should do active
polling, then I'll write a check that will query either Foreman or ask the
DB directly (which ever is easier).

2010/11/15 Nicolas Szalay 

> Le jeudi 11 novembre 2010 à 06:09 -0800, Tim a écrit :
> > Hi,
>
> Hello,
>
> > Anyway what other approaches are there? I'd like to simply see 2
> > things:
> > 1) If there were any failures during the puppet run on the client
> > 2) When the last puppet run on each client was (ie. if it was more
> > than 50 mins ago raise a warning)
>
> I check point 2 with the help of mcollective and its puppetd agent. See
> http://www.rottenbytes.info/?p=387 for more information.
>
> Regards,
>
> Nico.
>
>

-- 
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.

Re: [Puppet Users] Making edits to /etc/system on Solaris

[Brian Gallew]

I've basically ended up with one /etc/system to rule them all (and in the
darkness bind them?).  Fortunately for me, my systems are large enough to
support this and there have been no conflicting requirements.  I'm sure I'm
losing some tiny bit of performance and memory, but I really can't work up
enough  concern to do anything about it.

On Mon, Sep 13, 2010 at 5:29 PM, John Warburton wrote:

> Hi All
>
> Just wondering what everyone else does when editing /etc/system on Solaris
>
> It is on the Augeas To Do list (http://augeas.net/page/Augeas_on_Solaris)
> - has anyone tried a lens for it? I tried to start but the file format is
> almost free form and there would always be an exception causing the parse to
> fail
>
> So, apart from
> http://projects.puppetlabs.com/projects/1/wiki/Simple_Text_Patterns, I
> don't see any other solution
>
> Thanks
>
> John
>
> --
> 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.
>

-- 
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.

Re: [Puppet Users] Spaces in templates

[Brian Gallew]

Is there any reason why you don't just do it the easy way?

host <%= users_ldap_servers.join(" ") %>

On Fri, Sep 10, 2010 at 5:50 AM, Al @ Lab42  wrote:

> Hi all,
> I've a silly problem that it's driving me crazy and I'm almost sure
> the solution is quick and easy.
> Still it doesn't seem at my reach.
>
> I've a variable with an array of values, such as:
> users_ldap_servers = [ "ldapm.example42.com" , "ldaps.example42.com" ]
>
> I want to use these values in a single line of a template:
>
> host <% users_ldap_servers.each do |ldap| %> <%= ldap %> <% end %>
>
> No matter how many spaces I place around, no matter the absence of
> trimming -%> I always get something like:
>
> host  ldapm.example42.comldaps.example42.com
> instead of:
> host  ldapm.example42.com ldaps.example42.com
>
> I think a solution could be to add a whitespace to "ldap" before
> yielding it... but I haven't found the needed "few chars combo" (I
> suppose).
>
> Any help?
> Al
>
> --
> 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.
>
>

-- 
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.

Re: [Puppet Users] Re: Cross definition dependancies.

[Brian Gallew]

There are two standard answers for conflicting items like this.
1) Break out the conflicting items into their own class/definition.
2) Learn to love virtual resources and realize them as necessary.

On Mon, Sep 6, 2010 at 12:30 PM, Douglas Garstang
wrote:

> On Mon, Sep 6, 2010 at 12:12 PM, Douglas Garstang
>  wrote:
> > Yikes.
> >
> > I have two different definitions, one installing components for jboss,
> > and the other installing components for tomcat. I've used a definition
> > rather than a class, because we are running multiple copies of each. I
> > have files and packages in jboss that are needed by files in tomcat.
> > Since objects in the scope of one definition aren't visible to other
> > definitions, how can I make the files in tomcat require => packages
> > that are defined in jboss?
>
> Well, I know I've used definitions in a require before, ones with
> simple, non qualified names. It appears you can't use ones with
> qualified, autoloaded names, because doing this:
>
> require => Jboss::server::instance["${name}"]
>
> yields this:
>
> Sep  6 19:16:17 s_...@app01.pax.livegamer.com puppet-agent[24812]:
> Could not retrieve catalog from remote server: Error 400 on SERVER:
> Syntax error at '::server::instance'; expected ']' at
> /etc/puppet/modules/starterkit/manifests/setup.pp:94 on node
> app01.pax.livegamer.com
>
> *sigh*
>
> Doug.
>
> --
> 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.
>
>

-- 
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.

Re: [Puppet Users] Using "service" with a specific user

[Brian Gallew]

The way you make the service start/stop by a specific user is to make sure
the OS-standard start/stop script do su/sudo at the correct point.

On Mon, Aug 30, 2010 at 6:43 AM, Daniel Pittman  wrote:

> Matt  writes:
>
> > I would like to use the type "service" to ensure that a service is
> currently
> > started. Is there a way to specify a user that must run start or stop
> > command?
>
> No.  Traditionally, the start and stop commands would ensure that the
> software
> ran as the correct user internally — most of them map directly to the OS
> facilities that start and stop services at boot time, which require that.
>
> I would strongly advise you follow that same path, because otherwise you
> risk a tiny typo or user-error resulting in your daemon running as root.
>
>Daniel
> --
> ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155
> 707
>   ♽ made with 100 percent post-consumer electrons
>
> --
> 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.
>
>

-- 
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.

Re: [Puppet Users] Re: Centralised Graphing?

[Brian Gallew]

If you have shared storage, it's pretty trivial to collect all the
relationship files.  If not, you might consider the simple expedient of scp
or curl in an exec{} to get them where you want them.

On Thu, Aug 26, 2010 at 12:47 AM, Matt Wallace
wrote:

> On Wednesday 25 Aug 2010 19:17:18 Phips wrote:
> > puppet-dashboard?
>
> Could do, but we use Cobbler as our extnode source and I don't really want
> to
> fire up an additional management web interface just for a few graphs... :(
>
> Cheers,
>
> 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.
>
>

-- 
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.

Re: [Puppet Users] puppet and cpan

[Brian Gallew]

Sorry, when you use Gmail you end up top-posting whether you like it or not.

On Mon, Aug 16, 2010 at 8:45 PM, Daniel Pittman  wrote:

> Brian Gallew  writes:
>
> It is always nice if y'all follow the existing quoting style in mails; it
> makes it much less confusing to follow later.
>
> > I have to agree with Daniel on this one.  While it's annoying to build
> > Solaris (in my case) packages for every CPAN package you want to install,
> > then end result is that I can control the installed version *precisely*.
> > While it may never have been a problem for you, I've been bitten more
> than
> > once by CPAN upgrades that break my software, so "old" systems work while
> > new systems don't.
>
> FWIW, at work we gave up on that despite using Debian and having pretty
> good
> support tools to do the job.  We settled on packaging all the Perl bits we
> use
> as a single package and landing that everywhere.
>
> That gives us a good balance between the two paths, and has worked out well
> to
> date.  Plus it keeps system Perl and company Perl separate...
>
>Daniel
>
> --
> ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155
> 707
>   ♽ made with 100 percent post-consumer electrons
>
> --
> 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.
>
>

-- 
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.

Re: [Puppet Users] puppet and cpan

[Brian Gallew]

I have to agree with Daniel on this one.  While it's annoying to build
Solaris (in my case) packages for every CPAN package you want to install,
then end result is that I can control the installed version *precisely*.
While it may never have been a problem for you, I've been bitten more than
once by CPAN upgrades that break my software, so "old" systems work while
new systems don't.

On Sun, Aug 15, 2010 at 7:55 PM, Daniel Pittman  wrote:

> Bram Enning  writes:
>
> > I have the class below and it doens;t work. That it is, it does work if I
> > run it twice.  On the second puppet-run everything works, on the first it
> > doesn't run the third, because of failed dependencies.
> >
> > Any suggestions?
>
> Well, the first one is that you would be much, much, much, much better off
> not
> doing this on each host: this is utterly non-deterministic.
>
> Instead, package your Perl code somehow and deploy *that* to the systems.
> When you need to upgrade, upgrade the package and redeploy.
>
> This could be as unsophisticated as a tarball you unpack, although I would
> strongly suggest you use whatever platform packaging you have to manage
> things.
>
>
> That way you gain the ability to have *exactly* the same configuration
> deployed to your systems, with the same versions, every time you deploy.
> (Your current code will upgrade Net::Amazon::EC2 automatically, which will
>  eventually break your application, I promise. ;)
>
>Daniel
>
> --
> ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155
> 707
>   ♽ made with 100 percent post-consumer electrons
>
> --
> 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.
>
>

-- 
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.

Re: [Puppet Users] Files & Exec

[Brian Gallew]

Mark your exec with "refreshonly => true".

On Mon, Jul 5, 2010 at 9:53 AM, Peter Berghold wrote:

> Hi folks,
>
> I have a few rules in my manifests that take the form:
>
> file {
> some-file:
>   source => "puppet://puppet/some/path",
>   -- etc--
> }
>
> exec {
> sync-action:
>cwd => "/some/path",
>command=> "/some/command",
>subscribe => [File[some-file]]
> }
>
> My intent is that anytime "some-file" is changed I trigger "sync-action".
>
> What I've discovered is that the sync action is being executed with every
> run of puppetd which for some sync actions could lead to trouble.
>
> What am I missing in terms of only triggering on a change?
>
>
>
> --
> Peter L. Berghold
> Owner, Shark River Technical Solutions LLC
>
> --
> 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.
>

-- 
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.

Re: [Puppet Users] Recipes release management : separate test and prod

[Brian Gallew]

First of all, if your sysadmins aren't advocates of version control (even
more so than your developers), fire them now, Now, NOW.  Or at least hire a
competent senior sysadmin to train them properly.

Back to the topic at hand.  We have only two environment (production and
development).  Since the puppet.conf file is itself managed by puppet,
adding "environment = <%= environment %>" to the [puppetd] stanza means that
switching a system between production and development is as simple as
"puppetd --test --environment development".  That change is "sticky", in
that it won't revert without explicitly doing "puppetd --test --environment
production".

We keep our manifests in Bazaar.  When we've got a successfully
tested/reviewed set of changes in development, we do a "bzr commit" on the
development side, and then a "bzr merge bzr://bzr/puppet/puppet-dev;bzr
commit" on the production side.  The only real down side is that moving code
to production means that either *everything* in development is now ready for
production, or that you can isolate the interesting changes for the
commit/merge.  Since there's really only one of us working on manifests at
the moment, it's not a big deal.

For future needs, we've got a 2nd puppetmaster set up identically that we
can use if we're afraid the changes might crash the production
puppetmaster.

On Mon, Jul 5, 2010 at 9:40 AM, Dan Carley  wrote:

> On 5 July 2010 11:01, Jean-Baptiste Barth wrote:
>
>> For the moment we only have 1 puppetmaster here. I noticed that if I have
>> a syntax error in one of my included .pp, then puppet runs fail on all nodes
>> (even if they do not use this recipe), which is not acceptable. More
>> generally, working directly on production recipes seems too riskee, since
>> people who will manage those recipes are not devs but sysadmins, which means
>> poor development skills (and no versionning for the moment).
>>
>> I found the documentation about puppet "environments" (
>> http://docs.puppetlabs.com/guides/environment.html ) : does anybody use
>> it here ? I also read some of you have 2 puppetmasters running on different
>> ports, for test and prod : how do you do that (init scripts available
>> somewhere? different conf/manifests directories? sync between test and
>> prod?). Do you have a pool of client machines dedicated to your tests ? Do
>> you handle this kind of problems directly with your version control system
>> (post hooks?), or maybe at an other level in your external node provider ?
>>
>
> Mostly echoing Daniel Pittman's comments..
>
>  - We use environments a lot. The default production environment is for,
> well, production. All other environments are for development use. Each has
> their own SVN branch and Puppet `manifest`/`modulepath`/extlookup
> directives.
>
>  - In addition to custom types, providers and facts, flapping back and
> forth between environments. It's also not possible to have separate
> fileservers for additional paths between environments. But it's probably not
> something that will affect you at this stage.
>
>  - We have virtualised dev/staging machines which reflect the roles of our
> production machines, only on a slightly smaller scale. Any changes get
> pushed here and monitored first. We also have some shell scripts which are a
> shorthand for `--test --noop` to quickly review what is going to happen for
> a given machine. When we're happy with the results then the changes get
> merged to production.
>
>  - Syntax errors are caught by a pre-commit hook. It won't guard against
> stupid yet syntactically correct code. But it does vastly reduce the time
> spent dealing with simple humanoid typos.
>
>  - Be sure to version control your manifests from day one. Without doing
> so, you'll have no way of knowing who changed what and when. Nor the ability
> to roll back to a point in history. It will also provide you with an easy
> mechanism to peer review any code that you're not confident with, as Daniel
> notes.
>
> --
> 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.
>

-- 
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.