Re: [Puppet Users] Re: Correct way to handle node-specific variable values in puppet 2.7
Hi, On 06/19/2012 10:24 PM, Jon Schewe wrote: Node scope is staying a thing, because it has to for the time being. - It's unfortunately anonymous, so there's no way to address it directly. You have to use the variable's short name to get there. - But you can most assuredly get there. - However, some versions in the 2.7.x series issue a false warning when you're trying to get to node scope. more recent versions should have that fixed. Did that clear things up? So what I'm currently doing is perfectly valid and should continue to work with 2.8, I've just got a version that's giving me extra warnings. Correct? I don't like to be the naysayer, but I don't like to let that stand - hiera is not some third party mashup you can loosely tie to puppet. It's been designed by our very own R.I. Pienaar for the sole purpose of *relieving* you from the burden of managing your data inside nodes.pp (of course, as long as it works, you're free to choose to do that anyway). My understanding is that come puppet 3.0, hiera will be a first classe citizen and part of the puppet core proper. It's actually a supposedly superior way to store node data than manifest variables. Please don't get me wrong - everyone should find what works best for themselves, and by all means stick to it. Only meant to point out that hiera is an awesome concept that shouldn't be dismissed. 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.
Re: [Puppet Users] facter plugin requires cause catalog failure, prevent setting up new clients
On 06/20/2012 01:34 AM, Jo Rhett wrote: by bootstrap i mean kickstart or whatever, ie. before you run puppet. I should have some other system that configures my system before I run the software to configure my system? ;-) Humm, I believe it's fair to assume that most people have some way of puppet provisioning that will be able to take care of this configuration detail. That being said, I concur that it would be sane design to allow a module to compile in the absence of the custom facts etc. it may deploy to agents during the first run. Just my 2c. -- 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] facter plugin requires cause catalog failure, prevent setting up new clients
- Original Message - From: Felix Frank felix.fr...@alumni.tu-berlin.de To: puppet-users@googlegroups.com Sent: Wednesday, June 20, 2012 9:03:48 AM Subject: Re: [Puppet Users] facter plugin requires cause catalog failure, prevent setting up new clients On 06/20/2012 01:34 AM, Jo Rhett wrote: by bootstrap i mean kickstart or whatever, ie. before you run puppet. I should have some other system that configures my system before I run the software to configure my system? ;-) Humm, I believe it's fair to assume that most people have some way of puppet provisioning that will be able to take care of this configuration detail. That being said, I concur that it would be sane design to allow a module to compile in the absence of the custom facts etc. it may deploy to agents during the first run. I agree but its also quite hard, the proposed fix is using the masters vardir location as default for where servers must put their snippets, this is ridiculous and not a usable fix. There is no default really for where nodes put their vardir, we can assume /var/lib/puppet or something but that just doesn't hold true always and will in those cases just fail again during a run. Pluginsync is well understood and so widely used that I think more or less everyone has figured out how to enable it either first run or use a first run environment that bootstraps puppet - though how you would do that without the ability to edit the config file is a good question. -- 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] Augeas resources not being saved
On 19/06/12 22:02, Guy Knights wrote:
I can now confirm that Dominic was correct. I'm upgraded to puppet
2.7.16 now and the augeas resources are working. One thing I can also
confirm is that Alan's observation about the context not working and to
use the full path in the set command was also correct, at least for the
sudoers config change I made. However, the other augeas resource I had
that was making changes to /etc/ssh/ssh_config worked using the context
setting, so I don't know what the problem is there.
Is it this resource from one of your original posts?
augeas { 'set_sudoers':
context= '/files/etc/sudoers/spec[user=%sudo]',
changes= 'set /host_group/command/tag NOPASSWD',
}
The issue here is the / before host_group. Because the / is there,
it believes this is an absolute path rather than being underneath the
context. Remove the leading / and the context will be applied.
--
Dominic Cleal
Red Hat Consulting
m: +44 (0)7817 878113
--
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] mathematical operation
HI everyone, I am trying to use the ruby modulo function but without any success, here is the template: -- $tt=regsubst($::hostname,'.*front(\d+).*','\1') notice($tt) notice(inline_template(% tt.to_i.modulo(60) %)) -- Here is the result: notice: Scope(Class[main]): 04 notice: Scope(Class[main]): notice: Finished catalog run in 0.22 seconds Any idea? Regards, JM -- 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] Puppet 2.7.16 errors on OS X
Updated to puppet 2.7.16 and Facter 1.6.10 and I am seeing errors on all my 10.6 and 10.7 machines - err: Could not create resources for managing Puppet's files and directories in sections [:main, :agent, :ssl]: undefined method `strip' for #StringIO:0x1022ab1a8 info: Retrieving plugin err: Could not run Puppet configuration client: Could not retrieve local facts: undefined method `strip' for #StringIO:0x101f069a8 My previously installed versions were 2.7.14 and 1.6.6. Anyone seeing anything similar to this? I haven't made any other changes to my deployment. 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/-/1-4NW5QrSFYJ. 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] mathematical operation
Hi, - notice(inline_template(% tt.to_i.modulo(60) %)) + notice(inline_template(%= tt.to_i.modulo(60) %)) Best regards henk signature.asc Description: PGP signature
Re: [Puppet Users] Re: Reducing system load
Hi,
I really think the original question is very good: why do you need to
compile all manifests again and again when there is no change on the
sources (files/ENC/whatever input)?
Tricks like the proposed ones are clearly not the solution, and even if
the language is not prepared for that today, this is probably something
worth developing for the future. How many changes do you perform to the
system? I believe 95% of the compile time (probably closer to 99%)
produces exactly the same output again and again.
BR/Pablo
On 19/06/12 15:59, Brian Gallew wrote:
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
john.bollin...@stjude.org mailto:john.bollin...@stjude.org 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
Re: [Puppet Users] Re: Reducing system load
But the way I'm reading this, the question of the OP is to reduce cpu
load on the agents, not the master. Puppet is currently unable to see
wether or not something changed on the machine since last run without
actually checking. I guess there's a bunch of indications that you
could use depending on the OS, but I doubt you can make that 100%
waterproof.
Walter
On Wed, Jun 20, 2012 at 5:34 PM, Pablo Fernandez
pablo.fernan...@cscs.ch wrote:
Hi,
I really think the original question is very good: why do you need to
compile all manifests again and again when there is no change on the sources
(files/ENC/whatever input)?
Tricks like the proposed ones are clearly not the solution, and even if the
language is not prepared for that today, this is probably something worth
developing for the future. How many changes do you perform to the system? I
believe 95% of the compile time (probably closer to 99%) produces exactly
the same output again and again.
BR/Pablo
On 19/06/12 15:59, Brian Gallew wrote:
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 john.bollin...@stjude.org
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
Re: [Puppet Users] mathematical operation
Thx, it helps :D On Wed, Jun 20, 2012 at 11:24 AM, Hendrik Jäger puppet-us...@henk.geekmail.org wrote: Hi, - notice(inline_template(% tt.to_i.modulo(60) %)) + notice(inline_template(%= tt.to_i.modulo(60) %)) Best regards henk -- 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] Could not run Puppet configuration client: execution expired
Hello, I'm running Puppet 2.7.6 and currently expanding the number of servers managed by Puppet. At around the 160-170 host mark (with a 5-minute run interval + splay), my puppetmaster server is starting to die. Is this normal? What I'm getting in the agent logs is the following: Wed Jun 20 12:15:08 +0200 2012 Puppet (debug): Failed to load library 'selinux' for feature 'selinux' Wed Jun 20 12:15:08 +0200 2012 Puppet (debug): Puppet::Type::File::ProviderWindows: feature microsoft_windows is missing Wed Jun 20 12:15:09 +0200 2012 Puppet (debug): Failed to load library 'ldap' for feature 'ldap' Wed Jun 20 12:15:10 +0200 2012 Puppet (debug): Failed to load library 'shadow' for feature 'libshadow' Wed Jun 20 12:15:10 +0200 2012 /File[/opt/SP/apps/dca/puppet/config/puppet.conf] (debug): Autorequiring File[/opt/SP/apps/dca/puppet/config] Wed Jun 20 12:15:10 +0200 2012 /File[/opt/SP/apps/dca/puppet/config/ssl/certs/ca.pem] (debug): Autorequiring File[/opt/SP/apps/dca/puppet/config/ssl/certs] Wed Jun 20 12:15:10 +0200 2012 /File[/var/SP/data/dca/puppet/log] (debug): Autorequiring File[/var/SP/data/dca/puppet] Wed Jun 20 12:15:10 +0200 2012 /File[/var/SP/data/dca/puppet/client_data] (debug): Autorequiring File[/var/SP/data/dca/puppet] Wed Jun 20 12:15:10 +0200 2012 /File[/opt/SP/apps/dca/puppet/config/ssl/public_keys/host-name.pem] (debug): Autorequiring File[/opt/SP/apps/dca/puppet/config/ssl/public_keys] Wed Jun 20 12:15:10 +0200 2012 /File[/var/SP/data/dca/puppet/clientbucket] (debug): Autorequiring File[/var/SP/data/dca/puppet] Wed Jun 20 12:15:10 +0200 2012 /File[/opt/SP/apps/dca/puppet/config/ssl/private_keys/host-name.pem] (debug): Autorequiring File[/opt/SP/apps/dca/puppet/config/ssl/private_keys] Wed Jun 20 12:15:10 +0200 2012 /File[/var/SP/data/dca/puppet/state/graphs] (debug): Autorequiring File[/var/SP/data/dca/puppet/state] Wed Jun 20 12:15:10 +0200 2012 /File[/opt/SP/apps/dca/puppet/config/ssl/certificate_requests] (debug): Autorequiring File[/opt/SP/apps/dca/puppet/config/ssl] Wed Jun 20 12:15:10 +0200 2012 /File[/opt/SP/apps/dca/puppet/config/ssl/crl.pem] (debug): Autorequiring File[/opt/SP/apps/dca/puppet/config/ssl] Wed Jun 20 12:15:10 +0200 2012 /File[/opt/SP/apps/dca/puppet/config/ssl/public_keys] (debug): Autorequiring File[/opt/SP/apps/dca/puppet/config/ssl] Wed Jun 20 12:15:10 +0200 2012 /File[/opt/SP/apps/dca/puppet/config/ssl/private] (debug): Autorequiring File[/opt/SP/apps/dca/puppet/config/ssl] Wed Jun 20 12:15:10 +0200 2012 /File[/var/SP/data/dca/puppet/state/state.yaml] (debug): Autorequiring File[/var/SP/data/dca/puppet/state] Wed Jun 20 12:15:10 +0200 2012 /File[/var/SP/data/dca/puppet/client_yaml] (debug): Autorequiring File[/var/SP/data/dca/puppet] Wed Jun 20 12:15:10 +0200 2012 /File[/opt/SP/apps/dca/puppet/config/ssl/certs] (debug): Autorequiring File[/opt/SP/apps/dca/puppet/config/ssl] Wed Jun 20 12:15:10 +0200 2012 /File[/var/SP/data/dca/puppet/run] (debug): Autorequiring File[/var/SP/data/dca/puppet] Wed Jun 20 12:15:10 +0200 2012 /File[/opt/SP/apps/dca/puppet/config/ssl/private_keys] (debug): Autorequiring File[/opt/SP/apps/dca/puppet/config/ssl] Wed Jun 20 12:15:11 +0200 2012 /File[/var/SP/data/dca/puppet/facts] (debug): Autorequiring File[/var/SP/data/dca/puppet] Wed Jun 20 12:15:11 +0200 2012 /File[/var/SP/data/dca/puppet/state] (debug): Autorequiring File[/var/SP/data/dca/puppet] Wed Jun 20 12:15:11 +0200 2012 /File[/var/SP/data/dca/puppet/state/last_run_report.yaml] (debug): Autorequiring File[/var/SP/data/dca/puppet/state] Wed Jun 20 12:15:11 +0200 2012 /File[/opt/SP/apps/dca/puppet/config/ssl/certs/host-name.pem] (debug): Autorequiring File[/opt/SP/apps/dca/puppet/config/ssl/certs] Wed Jun 20 12:15:11 +0200 2012 /File[/var/SP/data/dca/puppet/state/classes.txt] (debug): Autorequiring File[/var/SP/data/dca/puppet/state] Wed Jun 20 12:15:11 +0200 2012 /File[/var/SP/data/dca/puppet/state/last_run_summary.yaml] (debug): Autorequiring File[/var/SP/data/dca/puppet/state] Wed Jun 20 12:15:11 +0200 2012 /File[/var/SP/data/dca/puppet/state/resources.txt] (debug): Autorequiring File[/var/SP/data/dca/puppet/state] Wed Jun 20 12:15:11 +0200 2012 /File[/opt/SP/apps/dca/puppet/config/ssl] (debug): Autorequiring File[/opt/SP/apps/dca/puppet/config] Wed Jun 20 12:15:11 +0200 2012 /File[/var/SP/data/dca/puppet/lib] (debug): Autorequiring File[/var/SP/data/dca/puppet] Wed Jun 20 12:15:12 +0200 2012 Puppet (debug): Finishing transaction 2161242520 Wed Jun 20 12:15:12 +0200 2012 Puppet (notice): Reopening log files Wed Jun 20 12:15:13 +0200 2012 /File[/opt/SP/apps/dca/puppet/config/ssl/crl.pem] (debug): Autorequiring File[/opt/SP/apps/dca/puppet/config/ssl] Wed Jun 20 12:15:13 +0200 2012 /File[/opt/SP/apps/dca/puppet/config/ssl/public_keys] (debug): Autorequiring File[/opt/SP/apps/dca/puppet/config/ssl] Wed Jun 20 12:15:13 +0200 2012 /File[/opt/SP/apps/dca/puppet/config/ssl/certificate_requests] (debug): Autorequiring
[Puppet Users] Re: Puppet Versioning
Thanks a lot John! yes you got my point. I think I will better implement version control of my manifests, as you suggest. This will help for sure, but what I was wondering, was to revert node configurations. cheers On Tuesday, June 19, 2012 6:59:58 PM UTC+2, jcbollinger wrote: On Tuesday, June 19, 2012 10:01:42 AM UTC-5, MrTeleBird wrote: Hello everyone, everytime I run on a puppet host: #puppet agent --test I see this commet: info: Applying configuration version '01' then lets say I deploy a new package from my local repository, from which I would get a different configuration version. #puppet agent --test info: Applying configuration version '02' ...question: is there a way to deploy back an older version, in this case '01'? and how? Not as far as I know, and anyway, it wouldn't have the result you are probably thinking of. In particular, the message might be more precisely worded applying *catalog* version foo. Applying an older catalog would not reliably revert the client to the configuration originally produced by that catalog -- that is, it would not revert changes applied in later catalogs. It cannot do so because earlier catalogs cannot contain full information about the content of later catalogs. What you can and should do is store all your manifests in a version-control system such as git or subversion. That will give you, among other things, the ability to revert your manifests to reflect some earlier point in time. Given identical node facts, the master will then compile and serve catalogs identical to those previously compiled from those manifests. (But that still won't revert *node configurations* the way I suspect you were hoping.) 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/-/o7-K5WCsNAYJ. 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] Reducing system load
On Tue, 2012-06-19 at 03:23 -0700, 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? It depends on what you really want to achieve. Part of the CPU consumption is to make sure the configuration on the node is correct. I see a possibility where: * you don't care if there is some configuration drift on the agent (ie manual modifications for instance) * you run the agent on demand when you need a change This can be done with something like MCollective where you can decide to remotely launch some puppet runs as you see fit. Now you need to have a way to map from manifest modification to a set of hosts where you need a puppet run (which might not be that trivial). -- Brice Figureau Follow the latest Puppet Community evolutions on www.planetpuppet.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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Custom facts and hyphens
Hi all,
Possibly related to http://projects.puppetlabs.com/issues/10146 but I
wanted to get a second opinion.
I have a custom fact that iteratse through the disks on a
given EC2 node and creates facts for block devices based on
their /dev/disk/by-path/ links. I had to come up with this as a
work-around for an existing RH bug in which a kernel upgrade can
magically move block device names and terminally break an awful lot.
Anyway, the fact is simple, produces output like this:
xen-vbd-2049 = /dev/xvda1
xen-vbd-2050 = /dev/xvda2
xen-vbd-2051 = /dev/xvda3
Those facts in conjunction with a virtual resource like this:
@disks::virtual::setlabel { root:
devicename = $::xen-vbd-2049,
devicelabel= root,
}
lets me work around the problem on first run regardless whether that
block device is called /dev/xvda1, /dev/xvdf1, /dev/foobarbaz1 or whatever
after a reboot.
Anyway, this worked certainly in Puppet = 2.7.14 but now breaks in .16
and .17. It does appear to be variable related as the exec that is
called by the realize is this:
debug: Exec[e2label -vbd-2049 root](provider=posix): Executing check 'test -e
-vbd-2049'
so clearly the variable isn't being treated correctly. I tried $::
{xen-vbd-2049} but no dice there.
Are hyphens now officially bad practice? I have a nagging half-memory
that I read that they're not good in facts, indeed all of the normal
facts are underscore'd but I can't remember where I read it.
Any thoughts or comments would be appreciated!
Cheers,
Steph
--
Steph Gosling st...@chuci.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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Reducing system load
Hello, On Wed, Jun 20, 2012 at 5:48 PM, Brice Figureau brice-pup...@daysofwonder.com wrote: Now you need to have a way to map from manifest modification to a set of hosts where you need a puppet run (which might not be that trivial). One possible approach here http://www.devco.net/archives/2012/04/28/trigger-puppet-runs.php -- 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] Custom facts and hyphens
- Original Message -
From: Steph Gosling st...@chuci.org
To: puppet-users@googlegroups.com
Sent: Wednesday, June 20, 2012 1:20:12 PM
Subject: [Puppet Users] Custom facts and hyphens
Hi all,
Possibly related to http://projects.puppetlabs.com/issues/10146 but I
wanted to get a second opinion.
I have a custom fact that iteratse through the disks on a
given EC2 node and creates facts for block devices based on
their /dev/disk/by-path/ links. I had to come up with this as a
work-around for an existing RH bug in which a kernel upgrade can
magically move block device names and terminally break an awful lot.
Anyway, the fact is simple, produces output like this:
xen-vbd-2049 = /dev/xvda1
xen-vbd-2050 = /dev/xvda2
xen-vbd-2051 = /dev/xvda3
Those facts in conjunction with a virtual resource like this:
@disks::virtual::setlabel { root:
devicename = $::xen-vbd-2049,
devicelabel= root,
}
lets me work around the problem on first run regardless whether that
block device is called /dev/xvda1, /dev/xvdf1, /dev/foobarbaz1 or
whatever
after a reboot.
Anyway, this worked certainly in Puppet = 2.7.14 but now breaks in
.16
and .17. It does appear to be variable related as the exec that is
called by the realize is this:
debug: Exec[e2label -vbd-2049 root](provider=posix): Executing check
'test -e -vbd-2049'
so clearly the variable isn't being treated correctly. I tried $::
{xen-vbd-2049} but no dice there.
Are hyphens now officially bad practice? I have a nagging half-memory
that I read that they're not good in facts, indeed all of the normal
facts are underscore'd but I can't remember where I read it.
They've always been a bad idea, used to be documented to be supported for
a short while but they never worked well, I think the agreement is that
they will just not be allowed soon in any variable or class name
--
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: Correct way to handle node-specific variable values in puppet 2.7
On Tuesday, June 19, 2012 4:07:56 PM UTC-5, Nick Fagerlund wrote: On Tuesday, June 19, 2012 7:19:20 AM UTC-7, jcbollinger wrote: Have I missed a change in plan for node variables, so that in Puppet 3 they remain accessible outside node declarations? Does that form of dynamic scoping live on? Yeah, they're effectively a tiny island of dynamic scoping in the otherwise-static sea. It turned out we had to do it that way -- we're working on replacing node definitions as we know them with something better, but we couldn't do everything in one fell swoop, so we're in a bit of an awkward stage for the moment. Great, thanks for clearing that up. What I've been trying to tell people is: [...] - oh, and don't ever use node inheritance. Why not? I mean, is that just to avoid the known issues with dynamic scope, or does node inheritance introduce special problems in this context? 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/-/D7zQ9XCZ98QJ. 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] Re: Could not run Puppet configuration client: execution expired
On Wednesday, June 20, 2012 5:35:39 AM UTC-5, Kmbu wrote: Hello, I'm running Puppet 2.7.6 and currently expanding the number of servers managed by Puppet. At around the 160-170 host mark (with a 5-minute run interval + splay), my puppetmaster server is starting to die. Is this normal? If you're using the master's built-in WEBrick based server, then yes, it's normal. In fact, you're getting pretty high throughput. The default run interval is six times longer (30 minutes), and at *that* interval people sometimes report problems by the time they get to the number of hosts you are successfully supporting. The next level of Puppet scaling is to run Puppet inside a 'real' web server, with Apache + passenger being the usual choice. That could increase your capacity by several times, depending on the host hardware and the characteristics of your manifests. I've already gone through a few threads mentioning this same error, but it's still not clear to me where the failure is happening exactly (I'm thinking as the agent tries to send the report to the puppetmaster?) or whether anything can be done about it. The puppetmasterd process seems to be using 90-100% of one CPU, but there is another one. The puppetmaster is not natively multithreaded, but running it via passenger will allow multiple instances to operate in parallel. If you're maxing out one of two available CPUs, then that would probably give you about a factor of two improvement, provided enough RAM is available. Are there any parameters I can tweak on the puppetmaster server to help it handle the load better? See above. Quicker and easier, however, would be to lengthen the clients' run interval. Five minutes is *very* short. 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/-/hUyujcV1xR4J. 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] Puppet's data encryption
Hello, could someone tell me how to know what encryption algorithm and what version is used by Puppet for data encryption ? I already know that Puppet supplies data encryption by SSL/TLS (https://groups.google.com/forum/?hl=enfromgroups#!topic/puppet-users/-LFLE_bj_NA). Thanks a lot! -- 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/-/ygFO3qMKJs8J. 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] Puppet lock files on Opensuse 12.1
The puppet packages on Opensuse 12.1 are broken...well not broken exactly but slightly damaged. There is a problem report about it at https://bugzilla.novell.com/show_bug.cgi?id=714649 which says that puppet uses /var/lock/subsys which is unsupported on openSUSE. Now as far as I can see there is a trivial 1-line fix, which is to edit the startup scripts /etc/init.d/puppetmasterd and /etc/init.d/puppet, replacing the lockfile location with one in /var/run/puppet. Is this the case, or does some other component expect the lock file to be in that hard-coded place? Regards, Bob -- 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/-/caXYaWPWHAMJ. 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] Re: Could not run Puppet configuration client: execution expired
Thanks for your support. Please find my responses below. On Wednesday, 20 June 2012 15:18:17 UTC+2, jcbollinger wrote: On Wednesday, June 20, 2012 5:35:39 AM UTC-5, Kmbu wrote: Hello, I'm running Puppet 2.7.6 and currently expanding the number of servers managed by Puppet. At around the 160-170 host mark (with a 5-minute run interval + splay), my puppetmaster server is starting to die. Is this normal? If you're using the master's built-in WEBrick based server, then yes, it's normal. In fact, you're getting pretty high throughput. The default run interval is six times longer (30 minutes), and at *that* interval people sometimes report problems by the time they get to the number of hosts you are successfully supporting. The next level of Puppet scaling is to run Puppet inside a 'real' web server, with Apache + passenger being the usual choice. That could increase your capacity by several times, depending on the host hardware and the characteristics of your manifests. I'm already running apache/passenger. Is there anything else I can do? I've already gone through a few threads mentioning this same error, but it's still not clear to me where the failure is happening exactly (I'm thinking as the agent tries to send the report to the puppetmaster?) or whether anything can be done about it. The puppetmasterd process seems to be using 90-100% of one CPU, but there is another one. The puppetmaster is not natively multithreaded, but running it via passenger will allow multiple instances to operate in parallel. If you're maxing out one of two available CPUs, then that would probably give you about a factor of two improvement, provided enough RAM is available. Are there any parameters I can tweak on the puppetmaster server to help it handle the load better? See above. Quicker and easier, however, would be to lengthen the clients' run interval. Five minutes is *very* short. Yeah. I guess I can do that, but my number of servers is going to go up quickly very fast. I expect to have over 1000 servers within the next week or two. I hope it can hold. I'm also looking into load-balancing options. 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/-/CMy_YclG2BgJ. 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] Send Reports to Puppet Dashboard
If your hosts do not appear to be reporting, and you're seeing some background tasks pending (top left in the puppet dashboard web gui), then you probably need to start the delayed_job tasks on your puppet dashboard server in order to process the reports. Run this: *env RAILS_ENV=production /usr/share/puppet-dashboard/script/delayed_job -p dashboard -n 4 -m start* where -n 4 refers to the number of cores. I added this line to /etc/init.d/puppet-dashboard so it gets fired after dashboard starts, and so I don't forget to run it. Not sure if this is the best method, but it works for me. See http://docs.puppetlabs.com/dashboard/manual/1.2/bootstrapping.html#starting-and-managing-delayed-job-workers. On Thursday, January 13, 2011 9:10:11 AM UTC-5, (unknown) wrote: Patrick, This is what I have setup in the puppet.conf files on the master and client. Both servers are running puppet 2.6.4 On the Master in /etc/puppet/puppet.conf [master] reports = http, store reporturl = http://fedorahost.ocfl.net:3000/reports node_terminus = exec external_nodes = /etc/puppet/bin/external_node in external_node I have changed the localhost default to: BASE = “http://fedorahost.ocfl.net:3000” On the client in /etc/puppet/puppet.conf [agent] report = true Thanks for your help. I hope you see something I might have done wrong. Mike *From:* puppet-users@googlegroups.com [mailto: puppet-users@googlegroups.com] *On Behalf Of *Patrick *Sent:* Wednesday, January 12, 2011 5:02 PM *To:* puppet-users@googlegroups.com *Subject:* Re: [Puppet Users] Send Reports to Puppet Dashboard On Jan 12, 2011, at 11:37 AM, michael.itc...@ocfl.net wrote: Hi Daniel, I have already done the setup which you mention below. I followed the puppet-dashboard configuration guide to the tee, which is why I’m surprised that this feature is not working. I have verified that the puppet.conf entries on the client and master are correct. I’m wondering if this problem is a bug? Thanks for your help. At this point, I don't think you're going to get much help unless you post a lot more from your puppet.conf files. For instance, we should be seeing section names. At this point, you're saying you did everything right, but evidently something isn't right so that doesn't help us much. -- 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. _ PLEASE NOTE: Florida has a very broad public records law (F. S. 119). All e-mails to and from County Officials are kept as a public record. Your e-mail communications, including your e-mail address may be disclosed to the public and media at any time. On Thursday, January 13, 2011 9:10:11 AM UTC-5, (unknown) wrote: Patrick, This is what I have setup in the puppet.conf files on the master and client. Both servers are running puppet 2.6.4 On the Master in /etc/puppet/puppet.conf [master] reports = http, store reporturl = http://fedorahost.ocfl.net:3000/reports node_terminus = exec external_nodes = /etc/puppet/bin/external_node in external_node I have changed the localhost default to: BASE = “http://fedorahost.ocfl.net:3000” On the client in /etc/puppet/puppet.conf [agent] report = true Thanks for your help. I hope you see something I might have done wrong. Mike *From:* puppet-users@googlegroups.com [mailto: puppet-users@googlegroups.com] *On Behalf Of *Patrick *Sent:* Wednesday, January 12, 2011 5:02 PM *To:* puppet-users@googlegroups.com *Subject:* Re: [Puppet Users] Send Reports to Puppet Dashboard On Jan 12, 2011, at 11:37 AM, michael.itc...@ocfl.net wrote: Hi Daniel, I have already done the setup which you mention below. I followed the puppet-dashboard configuration guide to the tee, which is why I’m surprised that this feature is not working. I have verified that the puppet.conf entries on the client and master are correct. I’m wondering if this problem is a bug? Thanks for your help. At this point, I don't think you're going to get much help unless you post a lot more from your puppet.conf files. For instance, we should be seeing section names. At this point, you're saying you did everything right, but evidently something isn't right so that doesn't help us much. -- 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
Re: [Puppet Users] Augeas resources not being saved
Oh ok, thanks Dominic. I'll give that a go.
Regards,
Guy
On Wed, Jun 20, 2012 at 1:37 AM, Dominic Cleal dcl...@redhat.com wrote:
On 19/06/12 22:02, Guy Knights wrote:
I can now confirm that Dominic was correct. I'm upgraded to puppet
2.7.16 now and the augeas resources are working. One thing I can also
confirm is that Alan's observation about the context not working and to
use the full path in the set command was also correct, at least for the
sudoers config change I made. However, the other augeas resource I had
that was making changes to /etc/ssh/ssh_config worked using the context
setting, so I don't know what the problem is there.
Is it this resource from one of your original posts?
augeas { 'set_sudoers':
context= '/files/etc/sudoers/spec[user=%sudo]',
changes= 'set /host_group/command/tag NOPASSWD',
}
The issue here is the / before host_group. Because the / is there,
it believes this is an absolute path rather than being underneath the
context. Remove the leading / and the context will be applied.
--
Dominic Cleal
Red Hat Consulting
m: +44 (0)7817 878113
--
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.
--
Guy Knights
Systems Administrator
Eastside Games
www.eastsidegamestudio.com
g...@eastsidegamestudio.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.
[Puppet Users] Re: Could not run Puppet configuration client: execution expired
Check my reply in https://groups.google.com/forum/?fromgroups#!searchin/puppet-users/USPS/puppet-users/q3bFvenGueI/hQExZ1X7pcwJ I'll add that we do loadbalance across multiple puppetmasters. At first we were using DNS round-robin to do it, and now use haproxy which a good article on utilizing was written up not too long ago http://blog.ronvalente.net/blog/2012/05/19/puppet/. Regards, Jake -- 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/-/Vm1lttvbHuIJ. 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: Could not run Puppet configuration client: execution expired
On 06/20/2012 05:39 PM, Jake - USPS wrote: I'll add that we do loadbalance across multiple puppetmasters. At first we were using DNS round-robin to do it, and now use haproxy which a good article on utilizing was written up not too long ago http://blog.ronvalente.net/blog/2012/05/19/puppet/. Fascinating. What I don't get is: This describes an active/passive setup (note how one server is configured as 'backup' in haproxy), yet speaks of loadbalancing. Would you elaborate on how you manage to go active/active (especially seeing as DRBD is involved)? Thanks, 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.
Re: [Puppet Users] Re: Could not run Puppet configuration client: execution expired
Sorry ... I didn't really follow that link in my setup ... just thought it would be a good reference as I don't have anything documented. Another good thing to note is that article uses NGINX. I'm cheating and am not FULLY redundant. We have a single CA PM that is not balanced against or redundant for other 'workhorse' PMs. And I don't worry about CRLs right now. :( It's something I want to get addressed, but not a priority atm. As for doing an active/active the way I am, my haproxy looks similar to the one in the link except no lines have 'backup' in them. Again, no DRBD which is mainly for the cert stuff and that is all handled by a single node (I set ca_server to my CA PM on all nodes). But, maybe you could have a shared NFS/storage for the certificates to address it? Regards, Jake On Wednesday, June 20, 2012 10:44:19 AM UTC-5, Felix.Frank wrote: On 06/20/2012 05:39 PM, Jake - USPS wrote: I'll add that we do loadbalance across multiple puppetmasters. At first we were using DNS round-robin to do it, and now use haproxy which a good article on utilizing was written up not too long ago http://blog.ronvalente.net/blog/2012/05/19/puppet/. Fascinating. What I don't get is: This describes an active/passive setup (note how one server is configured as 'backup' in haproxy), yet speaks of loadbalancing. Would you elaborate on how you manage to go active/active (especially seeing as DRBD is involved)? Thanks, Felix -- 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/-/3pDdbJw-s4YJ. 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] facter plugin requires cause catalog failure, prevent setting up new clients
On Jun 20, 2012, at 1:03 AM, Felix Frank wrote: Humm, I believe it's fair to assume that most people have some way of puppet provisioning that will be able to take care of this configuration detail. Okay, I've worked at 4 different shops using puppet over the last 6 years (one is a non-profit I work at part time). In not one of those shops was bare-metal provisioning something I set up (so the following decision was not mine and never has been) and in every case, the system kickstarts to install puppet rpm, then uses puppet to configure the rest of the system based on the system name. This goes back to this funny thing, where people keep saying I should be using a different configuration management system to handle things outside of puppet. Should we boot to install cfengine and use that to set up puppet? :p -- 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.
Re: [Puppet Users] Re: Reducing system load
puppet kick from your master after you make a change -- 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] Puppet Configuration - Running --configprint generates long list of values
Hello all, I fairly new to puppet and google groups so I'll apologize in advance for not conforming to normal posting methods. I've recently installed puppetmaster on a fresh copy of Ubuntu 10.04LTS and after running: sudo puppet --configprint all, I get a long list of parameters and values echoed back to my shell. My question is where do these parameters and values come from? I've taken a look at my puppet.conf file (which I believe is located in the proper place of: /etc/puppet/puppet.conf) and it looks like this: [main] logdir=/var/log/puppet vardir=/var/lib/puppet ssldir=/var/lib/puppet/ssl rundir=/var/run/puppet factpath=$vardir/lib/facter templatedir=$confdir/templates [master] # These are needed when the puppetmaster is run by passenger # and can safely be removed if webrick is used. ssl_client_header = SSL_CLIENT_S_DN ssl_client_verify_header = SSL_CLIENT_VERIFY Clearly these values of the ''--configprint -all command are coming from somewhere else and I can't seem to find the answer. I've read that puppet will read values from a users home directory if the puppet service is not running as root but I'm not sure that's something I should be concerned with at the moment. My thanks to everybody's help in advance. Cheers, Mike -- 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/-/H2P51DT0WfMJ. 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 Configuration - Running --configprint generates long list of values
On Jun 20, 2012, at 12:38 PM, Mike Reed wrote: Hello all, I fairly new to puppet and google groups so I'll apologize in advance for not conforming to normal posting methods. I've recently installed puppetmaster on a fresh copy of Ubuntu 10.04LTS and after running: sudo puppet --configprint all, I get a long list of parameters and values echoed back to my shell. My question is where do these parameters and values come from? I've taken a look at my puppet.conf file (which I believe is located in the proper place of: /etc/puppet/puppet.conf) and it looks like this: [main] logdir=/var/log/puppet vardir=/var/lib/puppet ssldir=/var/lib/puppet/ssl rundir=/var/run/puppet factpath=$vardir/lib/facter templatedir=$confdir/templates [master] # These are needed when the puppetmaster is run by passenger # and can safely be removed if webrick is used. ssl_client_header = SSL_CLIENT_S_DN ssl_client_verify_header = SSL_CLIENT_VERIFY Clearly these values of the ''--configprint -all command are coming from somewhere else and I can't seem to find the answer. I've read that puppet will read values from a users home directory if the puppet service is not running as root but I'm not sure that's something I should be concerned with at the moment. --configprint will supplement anything not specifically configured in puppet.conf with its own defaults. Thus you can 'override' any of the defaults by specifically declaring them in the appropriate section of puppet.conf Craig -- 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] Re: Puppet Configuration - Running --configprint generates long list of values
On Wednesday, June 20, 2012 12:38:58 PM UTC-7, Mike Reed wrote: My question is where do these parameters and values come from? I've taken a look at my puppet.conf file... Defaults! Even if you only SET a few settings in puppet.conf, all of the POSSIBLE settings still have values. These default values are set in a file called defaults.rb, which is part of Puppet's code. See it here: https://github.com/puppetlabs/puppet/blob/master/lib/puppet/defaults.rb Or you can see the config reference at http://docs.puppetlabs.com/references/latest/configuration.html --- that explains most of the default values. You'll notice that many settings are set *in terms of* other settings, so that you end up only really having to set a small core group of settings. What is that small core group? Well... that's kind of tricky to tease out, actually. The historical context is that we've tended to make every global constant in Puppet's code into a configurable setting, and the result is that we have over 200 of them. We know that's a problem; a lot of the work we're doing these days can be summarized as reduce configuration, make things more knowable. But once you add a configurable knob, someone might start using it, and removing it becomes a lot harder than not having put it in would have been. But the list of the most important settings here (http://docs.puppetlabs.com/guides/configuring.html#puppets-settings) is a good place to start. You won't need to know much more than that for a while. -- 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/-/8MhASUWbz4MJ. 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] Problem using subversion module
Hi guys, I'm trying to use the Subversion module here: https://github.com/duritong/puppet-subversion I have unzipped it to my modules folder but I am having problems calling the definitions from elsewhere in my manifests. I get the following error: err: Could not retrieve catalog from remote server: Error 400 on SERVER: Puppet::Parser::AST::Resource failed with error ArgumentError: Invalid resource type subversion::svnserve at /etc/puppet/modules/mw-web-suite/manifests/httpd.pp:391 on node *** I can make it work by redefining the svnserve definition as subversion::svnserve, but I wonder why that would be necessary in a properly written module. Sorry, I don't know a whole lot about puppet inheritance so any help is awesome. 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/-/dBtXowT76TUJ. 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] Conditional with variable from facter
The :: refer to scope, in this case it's saying variables at the very top
scope of what puppet knows about. This is because you can have:
$::operatingsystem
$module::class::operatingsystem
And it's not sure which one you mean. By adding the :: you're making sure
it knows to check the fact and not something you might have set in a
specific class.
On Wed, Jun 20, 2012 at 4:22 PM, Jakov Sosic jso...@srce.hr wrote:
On 06/18/2012 03:25 PM, Jakov Sosic wrote:
Hi.
I have the following facts available:
# facter | grep oper
operatingsystem = CentOS
operatingsystemrelease = 6.2
Now, if I wish to use conditionals on these facts, I have to do it like
this:
case $operatingsystem {}
case $::operatingsystemrelease {}
I'm puzzled as to why can't I just use $operatingsystemrelease, and what
do these two semicolons mean?
Any ideas?! :) Anyone?!?!
--
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] How to iterate over an array? (with a counter)
Given an array, I'd like to iterate over it with a counter to produce something like this from a template: foo.0 = ARRAYVALUE0 foo.1 = ARRAYVALUE1 foo.2 = ARRAYVALUE2 (where ARRAYVALUEn is replaced by the value, and the foo.n is incremented for each value) The puppet templates support iteration, but I don't see how to also increment a counter to get the behaviour above? Is this possible? Thanks. -- James Patterson jamespatter...@operamail.com -- http://www.fastmail.fm - Or how I learned to stop worrying and love email again -- 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 iterate over an array? (with a counter)
- Original Message - From: James Patterson jamespatter...@operamail.com To: puppet-users@googlegroups.com Sent: Wednesday, June 20, 2012 10:39:02 PM Subject: [Puppet Users] How to iterate over an array? (with a counter) Given an array, I'd like to iterate over it with a counter to produce something like this from a template: foo.0 = ARRAYVALUE0 foo.1 = ARRAYVALUE1 foo.2 = ARRAYVALUE2 (where ARRAYVALUEn is replaced by the value, and the foo.n is incremented for each value) The puppet templates support iteration, but I don't see how to also increment a counter to get the behaviour above? Is this possible? Thanks. array.each_with_index do |item, index| ... end item will be each item and index will increment from 0 upward -- 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] Problem dealing with multi role servers/manifests. resource already declared.
Hey All,
Im running into a road block with a server that is going to to be
multi role.
Example:
I want to run a nagios server and a repo server on one box.
My nagios manifest has two services defined:
class nagios::server {
...
service { nagios:
ensure = running,
...
}
service { httpd:
ensure = running
...
}
...
}
Now I also want to assign my reposerver manifest to a server already
running the nagios manifest
class repo::server {
...
service { httpd:
ensure = running
}
...
}
Now in each case I have files where httpd is notified to refresh...
Is there a way to work around this without creating a custom module
just for this one case? As you can see from the below error message I
tried changing the name and using an alias.. but it does not like that
either.
There error message:
Could not retrieve catalog from remote server: Error 400 on SERVER:
Puppet::Parser::AST::Resource failed with error ArgumentError: Cannot
alias Service[reposerver-httpd] to [httpd] at /etc/puppet/
environments/dev/modules/repo/manifests/init.pp:113; resource
[Service, httpd] already declared at /etc/puppet/environments/dev/
modules/nagios/manifests/init.pp:217 at /etc/puppet/environments/dev/
modules/opservers/manifests/init.pp:113 on node mynode.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.
Re: [Puppet Users] Puppet Configuration - Running --configprint generates long list of values
Thank you for the reply Craig. That makes sense and points me in the right direction. Thanks again, Mike On Wednesday, June 20, 2012 1:06:09 PM UTC-7, Craig White wrote: On Jun 20, 2012, at 12:38 PM, Mike Reed wrote: Hello all, I fairly new to puppet and google groups so I'll apologize in advance for not conforming to normal posting methods. I've recently installed puppetmaster on a fresh copy of Ubuntu 10.04LTS and after running: sudo puppet --configprint all, I get a long list of parameters and values echoed back to my shell. My question is where do these parameters and values come from? I've taken a look at my puppet.conf file (which I believe is located in the proper place of: /etc/puppet/puppet.conf) and it looks like this: [main] logdir=/var/log/puppet vardir=/var/lib/puppet ssldir=/var/lib/puppet/ssl rundir=/var/run/puppet factpath=$vardir/lib/facter templatedir=$confdir/templates [master] # These are needed when the puppetmaster is run by passenger # and can safely be removed if webrick is used. ssl_client_header = SSL_CLIENT_S_DN ssl_client_verify_header = SSL_CLIENT_VERIFY Clearly these values of the ''--configprint -all command are coming from somewhere else and I can't seem to find the answer. I've read that puppet will read values from a users home directory if the puppet service is not running as root but I'm not sure that's something I should be concerned with at the moment. --configprint will supplement anything not specifically configured in puppet.conf with its own defaults. Thus you can 'override' any of the defaults by specifically declaring them in the appropriate section of puppet.conf Craig -- 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/-/64QGtHcvLRQJ. 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] Custom facts and hyphens
On Jun 20, 2012, at 3:02 PM, Nick Fagerlund wrote: What R.I. said. Hyphens in variable names and class names are a no-no, although they kinda work in some versions of Puppet. Use underscores instead. (Why are hyphens a problem? Well, partly because you can subtract variables in expressions. The ambiguity turned out to be a problem.) Sorry, I replied to RIP because I didn't see your reply yet. I'm not saying that you're wrong, but I'm still struggling to see this. Every place that class names are used should be single quoted, according to your style guide. And it's very easy in a syntax to tell the different between 'test-jo + 2' and 'test - jo + 2'. Those are not ambiguous. The problems with not supporting dashes is the incredible lack of party between the packages/services/files they manage and the name of the class. It's pretty much guaranteed human error, and pretty much wipes out auto-generating puppet policies without a hundred lines of try this name instead, okay try this other name instead... -- 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.
[Puppet Users] Re: Puppet Configuration - Running --configprint generates long list of values
Hey Nick, Thank you for the reply. I'll take a look at the defaults.rb file and see what I can make of it. The explanation regarding the core group settings is most helpful and makes perfect sense. Again, thanks for the informative links and the info. Cheers, Mike On Wednesday, June 20, 2012 1:20:08 PM UTC-7, Nick Fagerlund wrote: On Wednesday, June 20, 2012 12:38:58 PM UTC-7, Mike Reed wrote: My question is where do these parameters and values come from? I've taken a look at my puppet.conf file... Defaults! Even if you only SET a few settings in puppet.conf, all of the POSSIBLE settings still have values. These default values are set in a file called defaults.rb, which is part of Puppet's code. See it here: https://github.com/puppetlabs/puppet/blob/master/lib/puppet/defaults.rbOr you can see the config reference at http://docs.puppetlabs.com/references/latest/configuration.html --- that explains most of the default values. You'll notice that many settings are set *in terms of* other settings, so that you end up only really having to set a small core group of settings. What is that small core group? Well... that's kind of tricky to tease out, actually. The historical context is that we've tended to make every global constant in Puppet's code into a configurable setting, and the result is that we have over 200 of them. We know that's a problem; a lot of the work we're doing these days can be summarized as reduce configuration, make things more knowable. But once you add a configurable knob, someone might start using it, and removing it becomes a lot harder than not having put it in would have been. But the list of the most important settings here ( http://docs.puppetlabs.com/guides/configuring.html#puppets-settings) is a good place to start. You won't need to know much more than that for a while. -- 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/-/s2yDN87HwEoJ. 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] Conditional with variable from facter
With in the class I used something like this to get the facts into my
nagios templates:
define host($ip = $::fqdn, $short_alias = $::fqdn, $hostgroup =
$::product_info, $product_domain = $::product_domain) {
case $product_info {
/OneProduct/: {
$nagios_cfgdir = /usr/local/nagios/etc/objects/OneProduct/hosts
@@file {
$nagios_cfgdir/${name}.cfg:
ignore = .svn,
ensure = present,
content = template( nagios/OneProduct_host.cfg ),
mode = 644,
owner = nagios,
group = nagios,
tag = 'nagios',
notify = Service[nagios],
}
}
/YetAnotherProduct/: {
$nagios_cfgdir =
/usr/local/nagios/etc/objects/YetAnotherProduct/hosts
@@file {
$nagios_cfgdir/${name}.cfg:
ignore = .svn,
ensure = present,
content = template( nagios/YetAnotherProduct_host.cfg ),
mode = 644,
owner = nagios,
group = nagios,
tag = 'nagios',
notify = Service[nagios],
recurse = true,
replace = true,
}
I hope this helps;)
On Wed, Jun 20, 2012 at 1:57 PM, Jeff McCune j...@puppetlabs.com wrote:
On Wed, Jun 20, 2012 at 1:22 PM, Jakov Sosic jso...@srce.hr wrote:
I'm puzzled as to why can't I just use $operatingsystemrelease, and what
do these two semicolons mean?
Any ideas?! :) Anyone?!?!
http://docs.puppetlabs.com/guides/scope_and_puppet.html
-Jeff
--
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.
--
David Garvey
--
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] Conditional with variable from facter
I also use some other stuff in my nagios.pp to get puppet facts into
mcollective.
file { /usr/lib/nagios/.mcollective/etc/facts.yaml:
mode= 0644,
owner = 104,
group = 106,
loglevel = debug,
content = inline_template(%= scope.to_hash.reject { |k,v| k.to_s =~
/(uptime_seconds|timestamp|free)/ }.to_yaml %)
}
On Wed, Jun 20, 2012 at 4:30 PM, david.gar...@gmail.com
david.gar...@gmail.com wrote:
With in the class I used something like this to get the facts into my
nagios templates:
define host($ip = $::fqdn, $short_alias = $::fqdn, $hostgroup =
$::product_info, $product_domain = $::product_domain) {
case $product_info {
/OneProduct/: {
$nagios_cfgdir = /usr/local/nagios/etc/objects/OneProduct/hosts
@@file {
$nagios_cfgdir/${name}.cfg:
ignore = .svn,
ensure = present,
content = template( nagios/OneProduct_host.cfg ),
mode = 644,
owner = nagios,
group = nagios,
tag = 'nagios',
notify = Service[nagios],
}
}
/YetAnotherProduct/: {
$nagios_cfgdir =
/usr/local/nagios/etc/objects/YetAnotherProduct/hosts
@@file {
$nagios_cfgdir/${name}.cfg:
ignore = .svn,
ensure = present,
content = template( nagios/YetAnotherProduct_host.cfg ),
mode = 644,
owner = nagios,
group = nagios,
tag = 'nagios',
notify = Service[nagios],
recurse = true,
replace = true,
}
I hope this helps;)
On Wed, Jun 20, 2012 at 1:57 PM, Jeff McCune j...@puppetlabs.com wrote:
On Wed, Jun 20, 2012 at 1:22 PM, Jakov Sosic jso...@srce.hr wrote:
I'm puzzled as to why can't I just use $operatingsystemrelease, and
what
do these two semicolons mean?
Any ideas?! :) Anyone?!?!
http://docs.puppetlabs.com/guides/scope_and_puppet.html
-Jeff
--
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.
--
David Garvey
--
David Garvey
--
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: Custom facts and hyphens
Hi,
On Wed, 20 Jun 2012 15:02:43 -0700 (PDT)
Nick Fagerlund nick.fagerl...@puppetlabs.com wrote:
What R.I. said. Hyphens in variable names and class names are a no-no,
although they kinda work in some versions of Puppet. Use underscores
instead.
(Why are hyphens a problem? Well, partly because you can subtract variables
in expressions. The ambiguity turned out to be a problem.)
For me the workaround in this case then was just a string.gsub( '-',
'_') in the custom fact and corresponding changes in my modules. If
need be then I can always regsubst('_', '-', G) back again, though in my
case, I didn't have to.
I've not given it too much thought but I do have sympathy for argument
that divergence of (some of) Puppet's logical representations and their
labels from what's extant on the system reduces clarity and could
introduce error. I'm not talking about class names nor packages
really (there are already restrictions there for things like camelCase
IIRC) but lower down it gets more murky. Service names (i.e. init
scripts et al.) are *almost* an example as they're vendor controlled
but ultimately I can't think of a case where you'd use them as
variables.
It was because of OS idiocy that I had to follow the symlinks
for /dev/disk/by-path/xen-vbd-* in a custom fact, but I have no
control over what those files are called. Having to munge the result
of that file lookup with underscores and then call it as $::xen_vbd_2049 (or
whatever) does feel icky because it's a mental hoop to jump through:
the fact no-longer absolutely matches the name of the symlink. The more
I think about it having to do the rename in facter doesn't seem great
to me either as it seems to me it puts the logic in the wrong place.
The style guide does explicitly say to not use dashes but if hyphens in
variables are a no-no it may be worth explicitly saying so in the
Variables section of language guide, and putting it in big red letters
in the Reserved Words section so that idiots like don't miss it first time ;)
Cheers,
Steph
--
Steph Gosling st...@chuci.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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
