Re: [Puppet Users] RE: enterprise puppet architecture
On 23/02/12 07:26, Steve Shipway wrote:
Our Puppet system here is currently managing about 500 nodes. We
anticipate about 1000 eventually.
I have had to reduce the client frequency to once every 4 hours; it
seems that the maximum that can be handled by a single (dual-CPU, 8GB)
puppet master is 200 nodes. After that, performance drops quickly and
I notice many failed manifests. This is with Puppet 2.7.10 on the master.
Hi Steve,
Excuse the slight change in topic but I'm interested in the performance
stats you posted. I run Puppet 2.7.5 on a 4 CPU 4 GiB RAM KVM virtual
machine. I use Puppet Commander to evenly distribute runs and my
interval time works out to be around 15 minutes for 230 odd hosts, as
per the timestamps between MCollective discoveries below:
[root@gs2puppet01 ~]# grep Found /var/log/puppetcommander.log | tail
I, [2012-02-23T06:46:12.218853 #28284] INFO -- : Found 231 puppet
nodes, sleeping for ~3 seconds between runs
I, [2012-02-23T06:57:59.009689 #28284] INFO -- : Found 231 puppet
nodes, sleeping for ~3 seconds between runs
I, [2012-02-23T07:09:49.237810 #28284] INFO -- : Found 231 puppet
nodes, sleeping for ~3 seconds between runs
I, [2012-02-23T07:21:39.435558 #28284] INFO -- : Found 231 puppet
nodes, sleeping for ~3 seconds between runs
I, [2012-02-23T07:33:26.554525 #28284] INFO -- : Found 231 puppet
nodes, sleeping for ~3 seconds between runs
I, [2012-02-23T07:45:59.550541 #28284] INFO -- : Found 231 puppet
nodes, sleeping for ~3 seconds between runs
I, [2012-02-23T07:57:51.013245 #28284] INFO -- : Found 231 puppet
nodes, sleeping for ~3 seconds between runs
I, [2012-02-23T08:12:10.915308 #28284] INFO -- : Found 231 puppet
nodes, sleeping for ~3 seconds between runs
I, [2012-02-23T08:24:16.383794 #28284] INFO -- : Found 231 puppet
nodes, sleeping for ~3 seconds between runs
I, [2012-02-23T08:37:03.750438 #28284] INFO -- : Found 231 puppet
nodes, sleeping for ~3 seconds between runs
I allow 10 Agents to run concurrently however my catalogs are very very
light, less than a second to compile:
[root@gs2puppet01 ~]# grep 'Compiled catalog' /var/log/messages | awk
'{sum+=$14} END {print sum/NR}'
0.750115
How big are your Puppet manifests so that you've had to drop the run
time down to 4 hours? Have you considered the use of MCollective and
Puppet Commander to spread your load out more?
-Luke
We've bought a copy of ProPuppet (as Jeff Watts recommended) and
we're planning to make a distributed system as instructed in there --
one puppet dashboard/report server, multiple puppet master servers,
and one dev server. Puppet configurations held is subversion and
synchronised on all puppet masters, which would themselves be behind a
load balancer. This is still in the planning stage, though.
I'd be interested in hearing your experiences in managing your
extra-large system; I can also share our experiences in how we
implemented and manage control of this system, if you'd like to
contact me off-list. When we first implemented, we engaged a Puppet
Labs consultant for a few days to help with the initial work. I can
definitely recommend doing this if you've no puppet experience, as one
place Puppet lacks is documentation!
Steve
*Steve Shipway*
University of Auckland ITS
/UNIX Systems Design Lead/
s.ship...@auckland.ac.nz mailto:s.ship...@auckland.ac.nz
Ph: +64 9 373 7599 ext 86487
//
--
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.
--
Luke Bigum
Information Systems
luke.bi...@lmax.com | http://www.lmax.com
LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN
The information in this e-mail and any attachment is confidential and is
intended only for the named recipient(s). The e-mail 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 a named recipient please notify the sender immediately and
delete any copies of this message. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden. Any view or
opinions presented are solely those of the author and do not necessarily
represent those of the company.
--
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] Best way to test changes?
I'm worried about making bad changes to a module which will impact lots of hosts. How can I avoid this? Ideally I'd like every node to run in noop, and then to approve the changes if they look right. 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.
Re: [Puppet Users] Best way to test changes?
On Thu, Feb 23, 2012 at 11:09 PM, jimbob palmer jimbobpal...@gmail.comwrote: I'm worried about making bad changes to a module which will impact lots of hosts. How can I avoid this? Ideally I'd like every node to run in noop, and then to approve the changes if they look right. Hi Jim, We're not currently using this method, but we're planning on using a second Puppet server which will have a copy of the Puppet tree with whatever major changes have been made in development. We run Puppet from cron so every host would continue to point at the master server, but we would connect to specific hosts and try noop against the second Puppet server. I'd like to hear how other people manage this sort of thing. - 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.
Re: [Puppet Users] Best way to test changes?
Hi, On 02/23/2012 01:27 PM, Gonzalo Servat wrote: On Thu, Feb 23, 2012 at 11:09 PM, jimbob palmer jimbobpal...@gmail.com mailto:jimbobpal...@gmail.com wrote: I'm worried about making bad changes to a module which will impact lots of hosts. How can I avoid this? Ideally I'd like every node to run in noop, and then to approve the changes if they look right. Hi Jim, We're not currently using this method, but we're planning on using a second Puppet server which will have a copy of the Puppet tree with whatever major changes have been made in development. We run Puppet from cron so every host would continue to point at the master server, but we would connect to specific hosts and try noop against the second Puppet server. I'd like to hear how other people manage this sort of thing. similarly but using environments: http://docs.puppetlabs.com/guides/environment.html The nodes are made to do the noop run on their own and store their reports on the master. A simple script digests the reports. 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.
[Puppet Users] hiera for defines?
Hi,
I thinking about how I could use hiera and I cant work it out, so I
would like to ask for some enlightenment.
class a {... $x = hiera('x') ...}
define a::b ( $x = hiera('x') {...}
define a::c ( $x = hiera('x') {...}
include a
a::b { b: }
a::c { c: }
so I thought about a directory structure similar to the following,
assuming the yaml backend for now.
datadir/a/a::b/b.yaml
datadir/a/a::c/c.yaml
datadir/a/a.yaml
to achieve this I would do something like this in hiera.yaml
:hierarchy:
- %{module_name}/%{XXX}/%{name}
- %{module_name}/%{module_name}
Question 1: What do I fill in for %{XXX} that it expands to 'a::b' 'a::c' ?
And what if in addition I want to use the puppet backend? How do I
specify defaults. For class a I can do
class a::data { $x = 'bla' }
Question 2: But where would I specify defaults for a::b and a::c ?
And Question 3, finally: Does it make sense to you what I am trying to
do, actually?
--
Kind Regards, Markus
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] SSLv3 read server certificate B: certificate verify failed. -- Not time related
Just remove the certificates from the client server from /var/lib/puppet/ssl/* it will be ok. mukulm On Wed, Feb 22, 2012 at 6:26 AM, Jon Davis j...@snowulf.com wrote: I recently built, added to puppet and then nuked a server. Before I re-added the machine (after I rebuilt it, with the same name), I went to the puppet server and ran `puppet cert revoke dev-8.company.com` and `puppet cert clean dev-8.company.com`. Now when puppet runs on ANY server in my environment, they get the following error: info: Caching certificate for dev-8.company.com *err: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed. This is often because the time is out of sync on the server or client* warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run *err: Could not send report: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed. This is often because the time is out of sync on the server or client* Now I know for a fact that it isn't a time issue because the puppet server is on NTP as are the clients. The new machine is also within 1-2 seconds of server time. All of the clients are configured to run (via Cron) `/usr/sbin/puppetd --onetime --no-daemonize --logdest syslog --server puppet.company.com`. The server is named puppet-1.company.com but puppet. is a valid cname. I've tried rebooting the puppet server, I've tried upgrading it, just about anything I can think of. Any help would be greatly appreciated. -Jon PS Both clients and server are running Ubuntu: root@puppet-1:/etc/puppet# cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=11.10 DISTRIB_CODENAME=oneiric DISTRIB_DESCRIPTION=Ubuntu 11.10 root@puppet-1:/etc/puppet# uname -a Linux puppet-1 3.0.0-16-server #28-Ubuntu SMP Fri Jan 27 18:03:45 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux -- Jon [[User:ShakataGaNai]] / KJ6FNQ http://snowulf.com/ http://www.linkedin.com/in/shakataganai http://twitter.com/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.
[Puppet Users] Re: Change user password only on systems where they exist
On Feb 22, 9:49 pm, Romeo Theriault romeo.theria...@maine.edu wrote:
Hi, We're just getting started with puppet and one of the things we'd
like to automate across a mix of Solaris and RHEL boxes is resetting a
users password. But we only want to reset the users password on the
boxes they already exist on. We don't want to have their account
created on all the boxes. We also don't want to modify any of their
settings like shells, etc...
Have you considered using a centralized account service such as LDAP
or even NIS? It is much more robust to use a single central authority
than to try to synchonize data across many individual machines.
I've used puppet to create users across all our boxes and that was
straight forward but I'm not sure the best way to conditionally change
a users password is. If it was just RHEL I'd be tempted to check for
the users homedir and then do an exec { usermod -p }, but
solaris doesn't support the usermod -p (for password) option. Is there
a more puppet way to pull this off?
Do you want merely to reset the password and then ignore subsequent
changes, or do you intend to keep the password fixed to the new
value? If the former then Puppet isn't the right tool for the job.
Instead, you want MCollective or another product in that vein.
On the other hand, if you are set on synchronizing user information
across multiple machines, and you want to manage user passwords
centrally, then the most Puppetly way to approach it is to manage
users via the User resource. That does not require all machines to
have the same users, but it does require Puppet to know which users
each machine should have. I consider that a good result, in fact, but
if you have many machines with many distinct user lists then it could
be a lot of work to get there. Managing users also does not require
you to manage every property (e.g. default shell).
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.
Re: [Puppet Users] Re: SSLv3 read server certificate B: certificate verify failed. -- Not time related
Hi, On 02/22/2012 08:58 PM, Jon Davis wrote: How can I track down where the issue for this is? it's always troublesome, but the only clean approach I'm aware of is openssl s_client and openssl x509 to carefully compare what the master is presenting when the agent connects to whatever the agent is expecting (i.e. what's cached on agent side). I'd like to stress this: Not everyone is operating under testing conditions. Blasting $ssldir is typically not an option. I know people are trying to be helpful, but puppet authentication is no a good instance to endorse the KISS strategy. 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] hiera for defines?
Hi, On 02/23/2012 02:21 PM, Markus Falb wrote: Does it make sense to you what I am trying to do, actually? no. Not at that degree of obfuscation, at least ;-) -- 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: node regex not working in 2.7.9
Anyone have any ideas here? All these manifests worked fine in 2.5 puppet and
suddenly broke in 2.7.9 when we upgraded.
On Feb 22, 2012, at 8:42 PM, Christopher Johnston chjoh...@gmail.com wrote:
Anyone know of any issues in 2.7.9 when trying to use a regex pattern for
matching a hostname? If I specify the following below the client never loads
the proper class, but if I put the fully qualified name in it works fine.
Fails:
node /somehost.*/ {
include some::class
}
Works:
node /somehost.domain.com/ {
include some::class
}
--
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: node regex not working in 2.7.9
On Feb 22, 7:42 pm, Christopher Johnston chjoh...@gmail.com wrote:
Anyone know of any issues in 2.7.9 when trying to use a regex pattern for
matching a hostname? If I specify the following below the client never
loads the proper class, but if I put the fully qualified name in it works
fine.
Fails:
node /somehost.*/ {
include some::class
}
Works:
node /somehost.domain.com/ {
include some::class
}
That's very surprising, especially since you are using regex in both
cases, and any string matched by the longer should also be matched by
the shorter. Are you sure it's the shorter one that fails? If it
were the longer, then that would make some sense because hostnames are
often taken as the *unqualified* names.
I'm not aware of any issues with node regexes, and I don't see any
open issues on that subject in the bug tracker.
It should be possible to strip this down to a very simple test case.
For example, make this your whole site.pp:
node /somehost.*/ {
notify { 'node declaration': message = short regex matches '$
{hostname}' }
}
node /somehost.somedomain.com/ {
notify { 'node declaration': message = long regex matches '$
{hostname}' }
}
node default {
notify { 'node declaration': message = no regex matches '$
{hostname}' }
}
If the first regex matches then that node declaration will be used;
otherwise, if the second matches then that declaration will be used.
If neither regex matches then the default node declaration will be
used. Putting all those in one place allows you to be certain that
the same hostname is being tested against each regex, and whichever
node declaration is used, the hostname that was tested will be
displayed in the client log. If that doesn't give you enough to work
out the problem then please post the actual test manifest and the
resulting client log.
Some other things to consider:
1) if you plan to match against actual hostnames then regex is way
overkill. Just use the appropriate hostnames themselves (preferrably
quoted).
2) the period is a regex metacharacter, so the difference between /
somehost.*/ and /somehost\..*/ may be important to you
3) node regexes are not automatically anchored to the beginning or end
of the hostname. If you want that (and it looks like you probably do)
then you must put in the anchors yourself (e.g. /^somehost\..*$/).
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.
[Puppet Users] Re: Unresponsive Agents - PE 2.0
We are using RHEL - 2.6.18-238.1.1.0.1.el5xen I do not know of any recent kernel patches (let me put it this way -- I didn't make any!). If I go to the Live Management part of the dashboard I can control the agents, etc -- but they won't do anything in the dashboard view and it shows up as over 800 tasks are backlogged on them. I've searched the log files I could find for any error messages, but haven't found anything yet. It seems strange that the agents work in command-line mode, and through the live management, but aren't via the dashboard/cron process, Thanks, Robert Stinnett On Feb 22, 3:53 pm, Aaron Grewell aaron.grew...@gmail.com wrote: Are you running RHEL 5? Did you recently patch your kernel? If so, you've probably been bitten by a kernel bug. I've successfully used kernel-2.6.18-274.17.1.el5 and backrev versions from the kernel-2.6.18-238.x.x series. On 02/22/2012 12:26 PM, Robert Stinnett wrote: Hi there, I am relatively new to Puppet (totally new) and had been cruising right along for a few days until about a week ago when our puppet agents went unresponsive. I've restarted both them and the servers several times to no avail. Can anyone point me down the path of how to diagnose this issue? We are currently evaluating Puppet to bring into our Enterprise for managing server provisions/configs/etc. Thanks, Robert Stinnett -- 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] hiera for defines?
On Thu, Feb 23, 2012 at 5:21 AM, Markus Falb markus.f...@fasel.at wrote: And Question 3, finally: Does it make sense to you what I am trying to do, actually? It feels significantly simpler for you to use hiera to pick out values that you then pass to instances of defines, rather than baking hiera into the definition of the define itself? Might be easier to give advice if you post what the defined types that you're planning to do this with actually do though? -- 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: Deploying puppet via NFS
On Feb 22, 6:50 pm, Forrie for...@gmail.com wrote: I'm attempting to deploy puppet via an NFS share. It's on a local-only network, and it will contain only ruby (gems) and whatever is needed. Seems simple enough, but tonight I am having an issue with this error: # service puppet start Starting puppet: /local/lib/ruby/site_ruby/1.8/rubygems/ custom_require.rb:36:in `gem_original_require': no such file to load -- openssl (LoadError) from /local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require' from /local/lib/ruby/gems/1.8/gems/puppet-2.7.9/lib/puppet/ssl.rb:3 from /local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require' from /local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require' from /local/lib/ruby/gems/1.8/gems/puppet-2.7.9/lib/puppet.rb:155 from /local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require' from /local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require' from /local/lib/ruby/gems/1.8/gems/puppet-2.7.9/lib/puppet/ application.rb:271:in `initialize' from /local/lib/ruby/gems/1.8/gems/puppet-2.7.9/lib/puppet/ application.rb:229:in `new' from /local/lib/ruby/gems/1.8/gems/puppet-2.7.9/lib/puppet/ application.rb:229:in `[]' from /local/lib/ruby/gems/1.8/gems/puppet-2.7.9/bin/puppetd:4 from /local/bin/puppetd:19:in `load' from /local/bin/puppetd:19 I did a search for this general error and it seems to come up with different circumstances. I checked the $PATH in the startup script, I can run ruby/irb alone with no trouble. All of my other systems do not have any supplemental GEMs that deal with SSL. There's nothing else on this system, no other ruby. Seems like it might be a simple thing - but I wonder what the problem is? I've been poring over this for a while... I can't see it. This is probably not an issue with the executable search path, but rather with the Ruby path. It looks like whichever Ruby interpreter you are using to run Puppet is unable to find one of the files (probably openssl.rb) that it expects to see in the Ruby library. The Ruby interpreter in use will probably be controlled by the puppet[d] script, not directly by the initscript that launches it, and the interpreter will have its own ideas of where its library is supposed to be. If I were pursuing your approach, I would put a complete Ruby installation on the share, and install Puppet and all the needed dependencies into that. Then I would be sure to launch Puppet using *that* Ruby, not, for instance, the system's Ruby. It's not clear to me whether that's what you're already trying to do, but if so, then I don't think you've gotten it completely right. 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.
Re: [Puppet Users] Re: Unresponsive Agents - PE 2.0
If that's the case I believe your pe-puppet-dashboard-workers service died somehow in your master. --KL On 2/23/12 9:51 AM, Robert Stinnett rob...@robertstinnett.com wrote: We are using RHEL - 2.6.18-238.1.1.0.1.el5xen I do not know of any recent kernel patches (let me put it this way -- I didn't make any!). If I go to the Live Management part of the dashboard I can control the agents, etc -- but they won't do anything in the dashboard view and it shows up as over 800 tasks are backlogged on them. I've searched the log files I could find for any error messages, but haven't found anything yet. It seems strange that the agents work in command-line mode, and through the live management, but aren't via the dashboard/cron process, Thanks, Robert Stinnett On Feb 22, 3:53 pm, Aaron Grewell aaron.grew...@gmail.com wrote: Are you running RHEL 5? Did you recently patch your kernel? If so, you've probably been bitten by a kernel bug. I've successfully used kernel-2.6.18-274.17.1.el5 and backrev versions from the kernel-2.6.18-238.x.x series. On 02/22/2012 12:26 PM, Robert Stinnett wrote: Hi there, I am relatively new to Puppet (totally new) and had been cruising right along for a few days until about a week ago when our puppet agents went unresponsive. I've restarted both them and the servers several times to no avail. Can anyone point me down the path of how to diagnose this issue? We are currently evaluating Puppet to bring into our Enterprise for managing server provisions/configs/etc. Thanks, Robert Stinnett -- 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. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. -- 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: node regex not working in 2.7.9
John,
Thx for your reply, yea putting notifies in would be useful but simply
seeing the class not get run or not included in classes.txt is also an
indicator that its not working.
I actually have a few regex for standard hostnames in our company here,
simple stuff that is service oriented dev*, etc
node /^dev[1-2]\..*\.(com|int)$/ {
include server::dev
}
That is one node type that is NOT working, the regex is plain/simple and
looks like it should work to me. We make a backup of our classes.txt daily
and I looked at the day from right before the upgrade and it was working
correctly. Since the upgrade it fails.
I also just for testing purposes I loaded up the FQDN of the host in the
regex match and it works fine. But anything where we are looking for
complex (well not really) matching it fails.
Putting a node type for every single host is way overkill, regexes should
just work and are very convenient for our environment as we are very
particular about hostname standards since our servers are generally service
oriented and require a specific class for that service.
-Chris
On Thu, Feb 23, 2012 at 9:34 AM, jcbollinger john.bollin...@stjude.orgwrote:
On Feb 22, 7:42 pm, Christopher Johnston chjoh...@gmail.com wrote:
Anyone know of any issues in 2.7.9 when trying to use a regex pattern for
matching a hostname? If I specify the following below the client never
loads the proper class, but if I put the fully qualified name in it works
fine.
Fails:
node /somehost.*/ {
include some::class
}
Works:
node /somehost.domain.com/ {
include some::class
}
That's very surprising, especially since you are using regex in both
cases, and any string matched by the longer should also be matched by
the shorter. Are you sure it's the shorter one that fails? If it
were the longer, then that would make some sense because hostnames are
often taken as the *unqualified* names.
I'm not aware of any issues with node regexes, and I don't see any
open issues on that subject in the bug tracker.
It should be possible to strip this down to a very simple test case.
For example, make this your whole site.pp:
node /somehost.*/ {
notify { 'node declaration': message = short regex matches '$
{hostname}' }
}
node /somehost.somedomain.com/ {
notify { 'node declaration': message = long regex matches '$
{hostname}' }
}
node default {
notify { 'node declaration': message = no regex matches '$
{hostname}' }
}
If the first regex matches then that node declaration will be used;
otherwise, if the second matches then that declaration will be used.
If neither regex matches then the default node declaration will be
used. Putting all those in one place allows you to be certain that
the same hostname is being tested against each regex, and whichever
node declaration is used, the hostname that was tested will be
displayed in the client log. If that doesn't give you enough to work
out the problem then please post the actual test manifest and the
resulting client log.
Some other things to consider:
1) if you plan to match against actual hostnames then regex is way
overkill. Just use the appropriate hostnames themselves (preferrably
quoted).
2) the period is a regex metacharacter, so the difference between /
somehost.*/ and /somehost\..*/ may be important to you
3) node regexes are not automatically anchored to the beginning or end
of the hostname. If you want that (and it looks like you probably do)
then you must put in the anchors yourself (e.g. /^somehost\..*$/).
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.
[Puppet Users] Re: Deploying puppet via NFS
This is probably not an issue with the executable search path, but rather with the Ruby path. It looks like whichever Ruby interpreter you are using to run Puppet is unable to find one of the files (probably openssl.rb) that it expects to see in the Ruby library. The Ruby interpreter in use will probably be controlled by the puppet[d] script, not directly by the initscript that launches it, and the interpreter will have its own ideas of where its library is supposed to be. If I were pursuing your approach, I would put a complete Ruby installation on the share, and install Puppet and all the needed dependencies into that. Then I would be sure to launch Puppet using *that* Ruby, not, for instance, the system's Ruby. It's not clear to me whether that's what you're already trying to do, but if so, then I don't think you've gotten it completely right. John This is what I did, I did a make/make install into the shared location. But I wonder if there is some hard-coded PATH in there somewhere. I'll have to poke around. I don't see where I can do a trace on executing this to see what it's calling. 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.
Re: [Puppet Users] Error 400 on SERVER: Cannot append, variable node_data is defined in this scope at
Where you call the class you mention nodes_data, and inside the class
it's node_data. Unless this is not a one-to-one copy-paste that might
be your problem?
On Wed, Feb 22, 2012 at 15:21, M. Piscaer deb...@masterpe.nl wrote:
Hi,
I have an problem that I can't get resolved. I have an hash like
www.krzywanski.net/archives/703.
With this hash i whould like the add some extra hashes before passing to the
module, i have tryed the code below.
node testnode {
class { 'testclass':
nodes_data = {
'node1' = { 'server' = 'node1.some.domain.com', 'port' =
'2560' },
'node2' = { 'server' = 'node2.another.domain.com', 'port' =
'2564' },
'node3' = { 'server' = 'node3.some.domain.com', 'port' =
'2564' }
}
}
}
class testclass ( $node_data ) {
node_data += {
'node4' = { 'server' = 'node4.another.domain.com', 'port' = '2564'
},
'node5' = { 'server' = 'node5.some.domain.com', 'port' = '2564' }
}
class { 'moduletest::test':
module_variable = $node_data
}
}
But then I get the error:
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Cannot append, variable node_data is defined in this scope at
/opt/puppet/env/manifests/classes/testclass.pp:1 on node
testmp-test-04.intern
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
Without adding the information everything works fine.
Kind regards,
Michiel Piscaer
--
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.
--
Walter Heck
--
follow @walterheck on twitter to see what I'm up to!
--
Check out my new startup: Server Monitoring as a Service @ http://tribily.com
Follow @tribily on Twitter and/or 'Like' our Facebook page at
http://www.facebook.com/tribily
--
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: Deploying puppet via NFS
This must have to do with an include path, as here is where I find the code: /local/lib/ruby/site_ruby/1.8/rubygems/gem_openssl.rb it's been a while, but I think the SITE_RUBY include is configured somewhere - and that may be the 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-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: Deploying puppet via NFS
I just did a basic find statement and found:
# pwd
/local/lib/ruby/gems/1.8/gems/puppet-2.7.11
# find . -exec grep -i site_ruby {} \;
SITELIBDIR=/usr/lib/ruby/site_ruby/1.8
sitelibdir = $LOAD_PATH.find { |x| x =~ /site_ruby/ }
sitelibdir = File.join(libdir, site_ruby)
#{work}/usr/lib/ruby/site_ruby/1.8/puppet]
system(#{DITTO} #{puppet_source}/lib/ #{work}/usr/lib/ruby/
site_ruby/1.8/)
system(#{SED} -i '' \s\#{SITELIBDIR}\#/usr/lib/ruby/site_ruby/
1.8\#g\ #{@working_tree['scripts']}/preflight)
FileUtils.chmod_R(0644, #{work}/usr/lib/ruby/site_ruby/1.8/)
FileUtils.chown_R('root', 'wheel', #{work}/usr/lib/ruby/site_ruby/
1.8/)
Find.find(#{work}/usr/lib/ruby/site_ruby/1.8/) do |dir|
# into RUBY's site_ruby directory. If you run into strange problems,
make sure
Puppet should not be installed in site_ruby because all of \$LOAD_PATH
Somewhere, puppet is not inheriting the correct PATH to site_ruby.
--
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] Error 400 on SERVER: Cannot append, variable node_data is defined in this scope at
Thanks for the response, I see that I made an typo..
The parameter nodes_data needs to be node_data as I have corrected
below. But the error stands.
-- testnode.pp --
node testnode {
class { 'testclass':
node_data = {
'node1' = { 'server' = 'node1.some.domain.com', 'port'
= '2560' },
'node2' = { 'server' = 'node2.another.domain.com',
'port' = '2564' },
'node3' = { 'server' = 'node3.some.domain.com', 'port'
= '2564' }
}
}
}
-- testclass.pp --
class testclass ( $node_data ) {
node_data += {
'node4' = { 'server' = 'node4.another.domain.com', 'port'
= '2564' },
'node5' = { 'server' = 'node5.some.domain.com', 'port' =
'2564' }
}
class { 'moduletest::test':
module_variable = $node_data
}
}
--
When delete the rows:
node_data += {
'node4' = { 'server' = 'node4.another.domain.com', 'port'
= '2564' },
'node5' = { 'server' = 'node5.some.domain.com', 'port' =
'2564' }
}
everything works fine. But then I still have the problem how to make the
settings that needs to be global and node specific at one hash?
Kinds regards,
Michiel Piscaer
On 23-02-12 21:04, Walter Heck wrote:
Where you call the class you mention nodes_data, and inside the class
it's node_data. Unless this is not a one-to-one copy-paste that might
be your problem?
On Wed, Feb 22, 2012 at 15:21, M. Piscaerdeb...@masterpe.nl wrote:
Hi,
I have an problem that I can't get resolved. I have an hash like
www.krzywanski.net/archives/703.
With this hash i whould like the add some extra hashes before passing to the
module, i have tryed the code below.
node testnode {
class { 'testclass':
nodes_data = {
'node1' = { 'server' = 'node1.some.domain.com', 'port' =
'2560' },
'node2' = { 'server' = 'node2.another.domain.com', 'port' =
'2564' },
'node3' = { 'server' = 'node3.some.domain.com', 'port' =
'2564' }
}
}
}
class testclass ( $node_data ) {
node_data += {
'node4' = { 'server' = 'node4.another.domain.com', 'port' = '2564'
},
'node5' = { 'server' = 'node5.some.domain.com', 'port' = '2564' }
}
class { 'moduletest::test':
module_variable = $node_data
}
}
But then I get the error:
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Cannot append, variable node_data is defined in this scope at
/opt/puppet/env/manifests/classes/testclass.pp:1 on node
testmp-test-04.intern
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
Without adding the information everything works fine.
Kind regards,
Michiel Piscaer
--
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] hiera-redis
A Redis backend for Hiera http://github.com/reliantsecurity/hiera-redis enjoy! -- 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: Unresponsive Agents - PE 2.0
And what do we do about that? I've restarted the services, even restarted the server and nothing comes back to life. Robert On Feb 23, 9:10 am, Kenneth Lo k...@paydiant.com wrote: If that's the case I believe your pe-puppet-dashboard-workers service died somehow in your master. --KL On 2/23/12 9:51 AM, Robert Stinnett rob...@robertstinnett.com wrote: We are using RHEL - 2.6.18-238.1.1.0.1.el5xen I do not know of any recent kernel patches (let me put it this way -- I didn't make any!). If I go to the Live Management part of the dashboard I can control the agents, etc -- but they won't do anything in the dashboard view and it shows up as over 800 tasks are backlogged on them. I've searched the log files I could find for any error messages, but haven't found anything yet. It seems strange that the agents work in command-line mode, and through the live management, but aren't via the dashboard/cron process, Thanks, Robert Stinnett On Feb 22, 3:53 pm, Aaron Grewell aaron.grew...@gmail.com wrote: Are you running RHEL 5? Did you recently patch your kernel? If so, you've probably been bitten by a kernel bug. I've successfully used kernel-2.6.18-274.17.1.el5 and backrev versions from the kernel-2.6.18-238.x.x series. On 02/22/2012 12:26 PM, Robert Stinnett wrote: Hi there, I am relatively new to Puppet (totally new) and had been cruising right along for a few days until about a week ago when our puppet agents went unresponsive. I've restarted both them and the servers several times to no avail. Can anyone point me down the path of how to diagnose this issue? We are currently evaluating Puppet to bring into our Enterprise for managing server provisions/configs/etc. Thanks, Robert Stinnett -- 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. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. -- 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: node regex not working in 2.7.9
I think I found my issue, we may have had doubling of node types.
One file has node /someregex/, and another has node theactualhost, so could
be that we are duplicating node definition/namespaces.
-Chris
On Thu, Feb 23, 2012 at 1:37 PM, Christopher Johnston chjoh...@gmail.comwrote:
John,
Thx for your reply, yea putting notifies in would be useful but simply
seeing the class not get run or not included in classes.txt is also an
indicator that its not working.
I actually have a few regex for standard hostnames in our company here,
simple stuff that is service oriented dev*, etc
node /^dev[1-2]\..*\.(com|int)$/ {
include server::dev
}
That is one node type that is NOT working, the regex is plain/simple and
looks like it should work to me. We make a backup of our classes.txt daily
and I looked at the day from right before the upgrade and it was working
correctly. Since the upgrade it fails.
I also just for testing purposes I loaded up the FQDN of the host in the
regex match and it works fine. But anything where we are looking for
complex (well not really) matching it fails.
Putting a node type for every single host is way overkill, regexes should
just work and are very convenient for our environment as we are very
particular about hostname standards since our servers are generally service
oriented and require a specific class for that service.
-Chris
On Thu, Feb 23, 2012 at 9:34 AM, jcbollinger john.bollin...@stjude.orgwrote:
On Feb 22, 7:42 pm, Christopher Johnston chjoh...@gmail.com wrote:
Anyone know of any issues in 2.7.9 when trying to use a regex pattern
for
matching a hostname? If I specify the following below the client never
loads the proper class, but if I put the fully qualified name in it
works
fine.
Fails:
node /somehost.*/ {
include some::class
}
Works:
node /somehost.domain.com/ {
include some::class
}
That's very surprising, especially since you are using regex in both
cases, and any string matched by the longer should also be matched by
the shorter. Are you sure it's the shorter one that fails? If it
were the longer, then that would make some sense because hostnames are
often taken as the *unqualified* names.
I'm not aware of any issues with node regexes, and I don't see any
open issues on that subject in the bug tracker.
It should be possible to strip this down to a very simple test case.
For example, make this your whole site.pp:
node /somehost.*/ {
notify { 'node declaration': message = short regex matches '$
{hostname}' }
}
node /somehost.somedomain.com/ {
notify { 'node declaration': message = long regex matches '$
{hostname}' }
}
node default {
notify { 'node declaration': message = no regex matches '$
{hostname}' }
}
If the first regex matches then that node declaration will be used;
otherwise, if the second matches then that declaration will be used.
If neither regex matches then the default node declaration will be
used. Putting all those in one place allows you to be certain that
the same hostname is being tested against each regex, and whichever
node declaration is used, the hostname that was tested will be
displayed in the client log. If that doesn't give you enough to work
out the problem then please post the actual test manifest and the
resulting client log.
Some other things to consider:
1) if you plan to match against actual hostnames then regex is way
overkill. Just use the appropriate hostnames themselves (preferrably
quoted).
2) the period is a regex metacharacter, so the difference between /
somehost.*/ and /somehost\..*/ may be important to you
3) node regexes are not automatically anchored to the beginning or end
of the hostname. If you want that (and it looks like you probably do)
then you must put in the anchors yourself (e.g. /^somehost\..*$/).
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.
[Puppet Users] Connections from any host to puppetmaster server times out
Every time I try to do puppetd --test on a host to get configs from the puppetmaster server it fails with this error: Could not retrieve catalog from remote server: Connection timed out - connect(2) Of course running it on the puppetmaster server itself works fine, so it's some kind of networking issue. I was thinking maybe it's something with webrick, which is what I'm using now, but I've only been testing one host at a time and wasn't doing anything differently when this started happening. I'm running version 2.7.11 of both puppet and puppetmaster on Ubuntu server 10.04 LTS. I just upgraded from 2.7.10 today, but I was developing and testing modules for several hours afterward and the issue just started happening from out of nowhere. -- 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] Sorted hash in template example
I'm building a module to handle django local_settings.py and I'm using a hash to store the database settings. The problem I ran into was the if I had multiple databases defined then it was possible for the config file to be recreated as the order of the databases in the hash wasn't guaranteed. To work around this I sorted all the keys in the hash and enumerated over that. I've attached an example of what I'm doing in case anyone else bumps into this problem. Here's what I'm doing: https://gist.github.com/1895347 Does anyone have a better solution? -- 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] 32bit and 64bit version of a package
Hi,
I'm trying to write a recipe to install the latest libstdc++ in both
32bit and 64bit flavors and running into issues. Yum only wants to
install the 64bit version if I do:
yum install libstdc++
If I do something like:
package { libstdc++.i386 : ensure = latest }
It tells me nothing to do
Any suggestions on the right way to do this?
Thanks!
Alan
--
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] Announce: Facter 1.6.6 Available
Facter 1.6.6 is a maintenance release with fixes, refactoring and packaging improvements. It includes contributions from the following people: Daniel Pittman, Jeremy Katz, Josh Cooper, Moses Mendoza This release is available for download at: http://downloads.puppetlabs.com/facter/facter-1.6.6.tar.gz http://downloads.puppetlabs.com/mac/facter-1.6.6.dmg http://apt.puppetlabs.com http://yum.puppetlabs.com See the Verifying Puppet Download section at: http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet#Verifying+Puppet+Downloads Please report feedback via the Puppet Labs Redmine site, using an affected version of 1.6.6: http://projects.puppetlabs.com/projects/facter/ Full Release Notes at: https://projects.puppetlabs.com/projects/facter/wiki/Wiki Facter 1.6.6 Release Notes = Support EC2 facts on OpenStack OpenStack exports an EC2 compatible API, so make the information available via facts by knowing that OpenStack generates mac addresses beginning with 02:16:3E #12666 Make ec2 facts work on CentOS again Refactoring the ec2 facts lost the support for CentOS where the hardware address in arp -an is uppercased. Fix and add a unit test now that there are those #12362 Use Tempfile to generate temp files Previously, facter used ENV['TMP'], ENV['TEMP'], /tmp, etc as it's temp directory search path, using the first one that existed. It then used constant file names within the temp directory to re-write the files in ruby's bin directory, and bat wrappers on Windows. First, it leads to predictable temp file names, which is bad. Second, when installing facter via a non-interactive ssh shell, e.g. ssh host ruby install.rb which is what the acceptance test harness does, the TMP and TEMP environment variables are usually not defined. So facter was always defaulting to /tmp, which doesn't work when installing facter on Windows agents during acceptance tests. This commit just changes the install script to use ruby's Tempfile to generate secure temp files that works in non-interactive shells. Facter 1.6.6 Changelog Daniel Pittman (1): 7d3889d (#12079) Fix order-dependent test failure due to odd stubbing. Jeremy Katz (3): cb598aa Support EC2 facts on OpenStack 7f2a0e2 add a simple test for openstack ec2 facts c273d34 Make ec2 facts work on CentOS again (#12666) Josh Cooper (1): c218d84 (#12362) Use Tempfile to generate temp files Moses Mendoza (2): 5c5c330 Changes apple rake task to reflect package name facter instead of puppet. f6bbe14 (#12170) Adds gem spec description -- 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] 32bit and 64bit version of a package
On Thu, Feb 23, 2012 at 5:57 PM, Alan Laird a...@laird.net wrote:
I'm trying to write a recipe to install the latest libstdc++ in both
32bit and 64bit flavors and running into issues. Yum only wants to
install the 64bit version if I do:
yum install libstdc++
If I do something like:
package { libstdc++.i386 : ensure = latest }
It tells me nothing to do
What does it say if you do:
sudo yum -q install libstdc++.i386
--
Nathan Powell
Linux System Administrator
Now I see it clearly. My whole life is pointed in one direction. I
see that now. There never has been any choice for me. ~ Travis Bickle
--
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] Sorted hash in template example
On Thu, Feb 23, 2012 at 5:20 PM, Jared Curtis ja...@shift-e.info wrote:
Does anyone have a better solution?
Better? I dunno. But an array of hashes will do what you want as well.
dbs = [{:foo = 'bar'}, {:hai = 'bai'} ]
dbs[0] etc.
--
Nathan Powell
Linux System Administrator
Now I see it clearly. My whole life has pointed in one direction. I
see that now. There never has been any choice for me. ~ Travis Bickle
--
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] Mounts occasionally not applied on first run
Hi All, Strange problem specifically to do with mounts. When I run Puppet for the first time on a server, occasionally everything will get applied except for mounts, and other times mounts are applied as part of the first run. No errors in /var/log/messages unfortunately. Has anyone else experienced this? Version 2.7.9. Regards 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.
Re: [Puppet Users] Announce: Puppet 2.7.11 Available [security/maintenance update]
It says bug 12572 is fixed in 2.7.11, but this is not the case.
It seems the released RPM packages for RHEL6 (both binary and source RPM)
do not contain the real fix here at
https://github.com/puppetlabs/puppet/commit/411828be395a68d70fec634fa8d8ff12572e8501.
I still see the old code ..
On Wed, Feb 22, 2012 at 11:44 PM, Matthaus Litteken matth...@puppetlabs.com
wrote:
Puppet 2.7.11 is a maintenance and security release in the 2.7.x branch.
The security changes in 2.7.11 address CVEs 2012-1053 and 2012-1054.
The maintenance changes are to address regressions in 2.7.10.
All users of Puppet 2.7.x are encouraged to upgrade when possible to
Puppet 2.7.11.
Other information available at: http://puppetlabs.com/security
or visit http://puppetlabs.com/security/cve/cve-2012-1053 and
http://puppetlabs.com/security/cve/cve-2012-1054
Detailed feature release notes are available:
https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes#2.7.11
This release is available for download at:
http://puppetlabs.com/downloads/puppet/puppet-2.7.11.tar.gz
RPM's are available at http://yum.puppetlabs.com/el or /fedora
Debs are available on http://apt.puppetlabs.com (lenny requires
backports enabled)
Puppet is also available via Rubygems at http://rubygems.org
See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet
Please report feedback via the Puppet Labs Redmine site, using an
affected puppet version of 2.7.11
http://projects.puppetlabs.com/projects/puppet/
# Summary #
(#12457, #12459) Execs, when run with a user specified but with no
group specified will get root group, so the exec then gets unintended
privileges. This is a permanent change for the forked process. Exploit
requires access to either the command the exec will run or to the
manifests calling execs.
(#12458) Similarly unexpected privileges are given to providers and
types (egid remains as root).
(#12460) Klogin type will write to untrusted locations (write through
symlinks)
# Details #
CVE-2012-1053 GID Issues (#12457, #12458, #12459) [ Medium ]
#12457 - Real gid always present in supplementary groups
Overview
===
In Puppet::Util::SUIDManager, Puppet tries to re-init the supplementary
groups in the initgroups method. At
lib/puppet/util/suidmanager.rb:148, it reads:
Process.initgroups(Etc.getpwuid(user).name, Process.gid)
Since the real gid is probably root, this always adds the gid 0 to
the list of supplementary groups for the process as per this strace for
a change to my user account (with 7 supplementary groups):
setgroups(8, [0, 10, 14, 18, 54, 1002, 1004, 474]) = 0
This method is called by SUIDManager's change_user method, which is
called in critical places such as lib/puppet/util.rb:308 in
execute_posix (as used by lots of things including Exec resources).
#12458 - Only euid changed, not egid
Overview
===
The second problem occurs when only a target user is given to the
SUIDManager asuser method as opposed to a target user and group, as is
the case in the following places:
lib/puppet/provider/ssh_authorized_key/parsed.rb:59
lib/puppet/type/file/target.rb:46
In this case, the SUIDManager asuser method at
lib/puppet/util/suidmanager.rb:78 doesn't change the egid, only the
euid, so the egid remains as root.
#12459 - Permanent uid change doesn't drop supplementary groups
Overview
When execute_posix or similar forks and calls SUIDManager's change_user
method, it sets permanent=true to change the real uid instead of the
euid (lib/puppet/util.rb:307).
In change_user, a different code path is taken when a permanent change
is made, and so the supplementary groups aren't dropped
(lib/puppet/util/suidmanager.rb:121), even if the primary group is set.
CVE-2012-1054 Klogin write through symlink [ High ]
#12460 - Klogin File Handling Issue (Write through symlink)
High risk for users of this type. Users can symlink to arbitrary files,
causing
them to be overwritten, such as other klogin files.
2.7.11 Changelog
===
c814c6b (#12572) Fix failing last run summary test on windows
87bcf3f (#12188) Handle Win32 as well as Unix in pidfile tests.
01b57e9 (#12188) Better handling of PID file cleanup warnings.
a8b6088 (#12572) Add acceptance test to make sure no last_run_summary
diff is printed
40480ed (#12572) Revert fix for #7106 and implement a more minimal fix
0486462 (#12412) Mark symbolic file modes test as pending on Windows
115ba71 Symbolic file mode test fixes when no mode change happens.
dde3945 Disable specs that use replace_file on Windows
4272d1f Disable replace_file on Windows
4bcbad4 Remove unnecessary fallbacks in change_{user,group}
ff372fb Document uid/gid-related methods in Puppet::Util
5f8f3ba Copy owner/group in replace_file
f0c9995 (#12463) eliminate
RE: [Puppet Users] RE: enterprise puppet architecture
Your Puppet master has twice the CPU of ours; but more importantly, you have
far simpler manifests. Ours are very complex, and can take 20seconds on
average to build - some taking a minute for the whole process to finish.
We're going to completely redesign our setup, as per the instructionsin the
ProPuppet book, with multiple puppetmasters in a cluster behind a load balancer
so that we can expand indefinitely.
Steve
Steve Shipway
University of Auckland ITS
UNIX Systems Design Lead
s.ship...@auckland.ac.nzmailto:s.ship...@auckland.ac.nz
Ph: +64 9 373 7599 ext 86487
From: puppet-users@googlegroups.com [puppet-users@googlegroups.com] on behalf
of Luke Bigum [luke.bi...@lmax.com]
Sent: Thursday, 23 February 2012 9:56 p.m.
To: puppet-users@googlegroups.com
Subject: Re: [Puppet Users] RE: enterprise puppet architecture
On 23/02/12 07:26, Steve Shipway wrote:
Our Puppet system here is currently managing about 500 nodes. We anticipate
about 1000 eventually.
I have had to reduce the client frequency to once every 4 hours; it seems that
the maximum that can be handled by a single (dual-CPU, 8GB) puppet master is
200 nodes. After that, performance drops quickly and I notice many failed
manifests. This is with Puppet 2.7.10 on the master.
Hi Steve,
Excuse the slight change in topic but I'm interested in the performance stats
you posted. I run Puppet 2.7.5 on a 4 CPU 4 GiB RAM KVM virtual machine. I use
Puppet Commander to evenly distribute runs and my interval time works out to be
around 15 minutes for 230 odd hosts, as per the timestamps between MCollective
discoveries below:
[root@gs2puppet01 ~]# grep Found /var/log/puppetcommander.log | tail
I, [2012-02-23T06:46:12.218853 #28284] INFO -- : Found 231 puppet nodes,
sleeping for ~3 seconds between runs
I, [2012-02-23T06:57:59.009689 #28284] INFO -- : Found 231 puppet nodes,
sleeping for ~3 seconds between runs
I, [2012-02-23T07:09:49.237810 #28284] INFO -- : Found 231 puppet nodes,
sleeping for ~3 seconds between runs
I, [2012-02-23T07:21:39.435558 #28284] INFO -- : Found 231 puppet nodes,
sleeping for ~3 seconds between runs
I, [2012-02-23T07:33:26.554525 #28284] INFO -- : Found 231 puppet nodes,
sleeping for ~3 seconds between runs
I, [2012-02-23T07:45:59.550541 #28284] INFO -- : Found 231 puppet nodes,
sleeping for ~3 seconds between runs
I, [2012-02-23T07:57:51.013245 #28284] INFO -- : Found 231 puppet nodes,
sleeping for ~3 seconds between runs
I, [2012-02-23T08:12:10.915308 #28284] INFO -- : Found 231 puppet nodes,
sleeping for ~3 seconds between runs
I, [2012-02-23T08:24:16.383794 #28284] INFO -- : Found 231 puppet nodes,
sleeping for ~3 seconds between runs
I, [2012-02-23T08:37:03.750438 #28284] INFO -- : Found 231 puppet nodes,
sleeping for ~3 seconds between runs
I allow 10 Agents to run concurrently however my catalogs are very very light,
less than a second to compile:
[root@gs2puppet01 ~]# grep 'Compiled catalog' /var/log/messages | awk
'{sum+=$14} END {print sum/NR}'
0.750115
How big are your Puppet manifests so that you've had to drop the run time down
to 4 hours? Have you considered the use of MCollective and Puppet Commander to
spread your load out more?
-Luke
We've bought a copy of ProPuppet (as Jeff Watts recommended) and we're
planning to make a distributed system as instructed in there -- one puppet
dashboard/report server, multiple puppet master servers, and one dev server.
Puppet configurations held is subversion and synchronised on all puppet
masters, which would themselves be behind a load balancer. This is still in
the planning stage, though.
I'd be interested in hearing your experiences in managing your extra-large
system; I can also share our experiences in how we implemented and manage
control of this system, if you'd like to contact me off-list. When we first
implemented, we engaged a Puppet Labs consultant for a few days to help with
the initial work. I can definitely recommend doing this if you've no puppet
experience, as one place Puppet lacks is documentation!
Steve
Steve Shipway
University of Auckland ITS
UNIX Systems Design Lead
s.ship...@auckland.ac.nzmailto:s.ship...@auckland.ac.nz
Ph: +64 9 373 7599 ext 86487
--
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.commailto:puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.commailto:puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
Luke Bigum
Information Systems
luke.bi...@lmax.commailto:luke.bi...@lmax.com | http://www.lmax.com
LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN
The information in this e-mail and any attachment is confidential and is
intended only for the named recipient(s). The e-mail may
