[Puppet Users] Re: Cross-module dependencies
I don't have that directory. However I came across this module
https://github.com/camptocamp/puppet-sudo which among many things
enlightened me to the new feature in sudo-1.7.2+ of using includedir
and /etc/sudoers.d that you mentioned. Everything I am using is
defined there except now my backuppc_client module has this...
sudo::directive { backuppc:
ensure = present,
source = puppet:///modules/backuppc_client/
backuppc_sudocmd,
}
The backuppc_sudocmd file contains the sudo lines.
Thanks!
- Trey
On May 24, 11:00 pm, Patrick kc7...@gmail.com wrote:
On May 24, 2011, at 7:58 PM, treydock wrote:
I have a similar problem I can't seem to solve...here's what I'm
trying to do.
I have two modules, backuppc_client and sudo. Right now I have a node
variable that I assign to each node that is used in the sudo module's
template to add the necessary entry. For example
---manifests/node.pp
node 'client1' {
$backuppc_sudocmd = backupuser ALL=NOPASSWD: /usr/bin/rsync
include baseclass
include backuppc_client::base
}
---modules/sudo/templates/sudoers.erb has...
% if has_variable?(backuppc_sudocmd) then %
%= backuppc_sudocmd %
% end %
Is there a way for the sudo module to find out or be aware if a client
has the include backuppc_client in their definition? Basically I'd
like the backuppc_client module's to alter the contents of sudoers
file which I can't imagine how to do as sudoers is defined by the sudo
module which is part of baseclass and applied to all systems.
First, do you have a /etc/sudoers.d/ directory? That would make things
much easier.
If not, you might want to look into puppet_concat which allows you to build
fragments that can be templated to build your file.
--
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: Cross-module dependencies
Glad to hear it worked.
On May 24, 2011, at 11:40 PM, treydock wrote:
I don't have that directory. However I came across this module
https://github.com/camptocamp/puppet-sudo which among many things
enlightened me to the new feature in sudo-1.7.2+ of using includedir
and /etc/sudoers.d that you mentioned. Everything I am using is
defined there except now my backuppc_client module has this...
sudo::directive { backuppc:
ensure = present,
source = puppet:///modules/backuppc_client/
backuppc_sudocmd,
}
The backuppc_sudocmd file contains the sudo lines.
Thanks!
- Trey
On May 24, 11:00 pm, Patrick kc7...@gmail.com wrote:
On May 24, 2011, at 7:58 PM, treydock wrote:
I have a similar problem I can't seem to solve...here's what I'm
trying to do.
I have two modules, backuppc_client and sudo. Right now I have a node
variable that I assign to each node that is used in the sudo module's
template to add the necessary entry. For example
---manifests/node.pp
node 'client1' {
$backuppc_sudocmd = backupuser ALL=NOPASSWD: /usr/bin/rsync
include baseclass
include backuppc_client::base
}
---modules/sudo/templates/sudoers.erb has...
% if has_variable?(backuppc_sudocmd) then %
%= backuppc_sudocmd %
% end %
Is there a way for the sudo module to find out or be aware if a client
has the include backuppc_client in their definition? Basically I'd
like the backuppc_client module's to alter the contents of sudoers
file which I can't imagine how to do as sudoers is defined by the sudo
module which is part of baseclass and applied to all systems.
First, do you have a /etc/sudoers.d/ directory? That would make things
much easier.
If not, you might want to look into puppet_concat which allows you to
build fragments that can be templated to build your file.
--
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] Puppet fileserver path
Hi, Is it possible, to change the default puppet file server path. *[files] path /var/lib/puppet/files* -- * Regards*** * Sumith** * -- 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 fileserver path
On Wednesday, May 25, 2011 at 8:10 AM, Sumith Sudhakaran wrote: Hi, Is it possible, to change the default puppet file server path. [files] path /var/lib/puppet/files -- Regards Sumith Yes. You can any location / multiple locations in /etc/puppet/fileserver.conf. I use the following: [files] path /opt/files allow *.sub.domain.org ~ -- Peter M. Bukowinski Systems Engineer Janelia Farm Research Campus, HHMI -- 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: PC EU feedback: unpack array variables in string interpolation
On May 24, 8:54 pm, vagn scott vagnsc...@gmail.com wrote:
What should this do?
$array = [ one, two ]
$greeting = [ hello, howdy ]
@file { host_$array$greeting }
or this?
$array = [ one, two ]
@file { $array_blah }
seems like we would need delimiters
host_${array}_${greeting}
and some form of expansion control.
Should it expand zipper-wise or combinatorially?
Probably all of that belongs in functions,
not in the resource or string syntax.
+1
Moreover, consider the juxtaposition of this proposal with those that
seek to make the language less idiosyncratic and magical. This one
proposes a move in the opposite direction.
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: Applying Catalogs
On May 24, 5:18 pm, Yushu Yao y...@lbl.gov wrote: Thanks John, My case is a little bit different. Because my webserver might need the IP address of the mysql node, and before mysql node is deployed and configured, it's IP address is not known. As Peter wrote, you can probably use an exported resource to feed configuration details of one server into the configuration of another. That has the added advantage of automatically updating the second server if the first's configuration should ever change. Even if you don't want to set up storeconfigs (to support exported resources), I still don't see the problem. If you need configuration details from the mysql server to configure the webserver, then just configure the mysql server first. You can still write all the manifests together, in advance, and just plug in the appropriate data when you know them. You can even use extlookup() to feed in the data at runtime, so that you don't need to modify the manifests themselves. Really, it seems like you're making this a lot harder than it needs to be. 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] Puppet fileserver path
thanks Peter On Wed, May 25, 2011 at 6:10 PM, Peter Bukowinski pmb...@gmail.com wrote: On Wednesday, May 25, 2011 at 8:10 AM, Sumith Sudhakaran wrote: Hi, Is it possible, to change the default puppet file server path. [files] path /var/lib/puppet/files -- Regards Sumith Yes. You can any location / multiple locations in /etc/puppet/fileserver.conf. I use the following: [files] path /opt/files allow *.sub.domain.org ~ -- Peter M. Bukowinski Systems Engineer Janelia Farm Research Campus, HHMI -- 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. -- * Regards*** * Sumith** * -- 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] mode on private_keys file for nagios / func integration
Hi, I've successfully hooked up func to use the puppet certs, mostly nicely. I'm now looking at using func to perform nagios checks (instead of installing nrpe, which is more pants than func). Here the nagios service runs as the nagios user, and so func also runs as that user, I thought I was sorted but making the private key mode 640 so func could read the private as the nagios user, but the puppet private key is always changed to mdoe 600 then puppet runs. How can a non root / puppet user access the private key for func? I can't see any way to disable to rights and chattr-ing it makes puppet choke. Is there a better way I could be approaching this overall? sudoing as part of the check doesn't sound like fun to me. Thanks Chris -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] mode on private_keys file for nagios / func integration
On Wed, May 25, 2011 at 7:11 AM, Chris Phillips ch...@untrepid.com wrote:
Hi,
I've successfully hooked up func to use the puppet certs, mostly nicely.
I'm now looking at using func to perform nagios checks (instead of
installing nrpe, which is more pants than func). Here the nagios service
runs as the nagios user, and so func also runs as that user, I thought I was
sorted but making the private key mode 640 so func could read the private as
the nagios user, but the puppet private key is always changed to mdoe 600
then puppet runs.
You should be able to do this in your puppet.conf
[agent]
privatekeydir = /etc/puppet/ssl/private_keys { mode = 0750 }
hostprivkey = /etc/puppet/ssl/private_keys/$certname.pem { mode = 0640 }
and Puppet will ensure those permissions. There may be some edge cases here,
as this isn't a widely used feature.
For those of you following along with the bug where we overwrite symlinks,
http://projects.puppetlabs.com/issues/650, you can't use this to ensure that
a given file is actually a symlink. Sorry.
How can a non root / puppet user access the private key for func? I can't
see any way to disable to rights and chattr-ing it makes puppet choke.
Is there a better way I could be approaching this overall? sudoing as part
of the check doesn't sound like fun to me.
Thanks
Chris
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
Nigel Kersten
Product, Puppet Labs
@nigelkersten
--
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] Client updates
I probably waste quite a bit of time each week restarting the puppet client, and logging systems, and tailing the messages file, to see if my puppet changes worked. Is there a better way? How do people normally do this? Sure, I can use puppetrun or mcollective to cause puppet to do a config run on the client, but I still need to log in and look at the messages file. The reports that the clients generate, and which are available on the server contain, I believe yield enough information to determine if there was any syntax errors or not. I guess they contain more, but, even though they are yaml files, they contain ruby objects, which non ruby parsers won't read. Would have been nice if it was standard yaml. Anyway ideas? Doug. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Client updates
On May 25, 2011, at 1:12 PM, Douglas Garstang wrote: I probably waste quite a bit of time each week restarting the puppet client, and logging systems, and tailing the messages file, to see if my puppet changes worked. Is there a better way? How do people normally do this? I use monit to keep the puppet agent running in case it craps out, and puppet dashboard to keep an eye on all my nodes. -bjc -- 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] Client updates
On Wed, May 25, 2011 at 10:16 AM, Brian Cully bcu...@gmail.com wrote: On May 25, 2011, at 1:12 PM, Douglas Garstang wrote: I probably waste quite a bit of time each week restarting the puppet client, and logging systems, and tailing the messages file, to see if my puppet changes worked. Is there a better way? How do people normally do this? I use monit to keep the puppet agent running in case it craps out, and puppet dashboard to keep an eye on all my nodes. Looking for a non GUI option. Doug. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Client updates
Basically the ways I know of: 1) Don't run puppet as a daemon, but run it out of cron every X mins. 2) Setup a cronjob that checks if puppet is running and restart it if not. 3) Setup a nagios job that checks to see if puppet is running 4) Presuming you are managing your puppet code in some sort of version control system, you can publish the latest timestamp of your latest commit, and also push that out via puppet, and setup a nagios check that compares them and if they ever are behind by more than X mins you can crit on it. You could take this a step further and have nagios automatically restart puppet if they are behind, but if you think it might be a syntax error, I would probably skip that. (As an aside you should do syntax checking before committing. I added the commands to do so below) 5) Foreman (or dashboard) can monitor puppet runs, and flag any broken runs. Check syntax: puppet --noop --parseonly memcached.pp Check erb syntax: erb -x -T '-' memcached-sessions.erb |ruby -c We use a combination of 2,3,4 and 5. Cheers, Brian On Wed, May 25, 2011 at 1:12 PM, Douglas Garstang doug.garst...@gmail.com wrote: I probably waste quite a bit of time each week restarting the puppet client, and logging systems, and tailing the messages file, to see if my puppet changes worked. Is there a better way? How do people normally do this? Sure, I can use puppetrun or mcollective to cause puppet to do a config run on the client, but I still need to log in and look at the messages file. The reports that the clients generate, and which are available on the server contain, I believe yield enough information to determine if there was any syntax errors or not. I guess they contain more, but, even though they are yaml files, they contain ruby objects, which non ruby parsers won't read. Would have been nice if it was standard yaml. Anyway ideas? Doug. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] enabling of 'thin_storeconfigs'
So if Nagios configs are the only thing you use stored configs for, thin stored configs will work just fine? If so, I forsee a switch in our future. :) Also, since you mentioned it... how difficult is it to upgrade from 0.25 to 2.6 / 2.7? I've been curious to upgrade but for the most part everything's been working fine so I've been holding off. Will I need to rewrite parts of my config? (I'm not doing much fancy, mostly user/service/package/file management with a side of Nagios.) -- Nathan Clemons http://www.livemocha.com The worlds largest online language learning community On Wed, May 25, 2011 at 10:16 AM, Gabriel Filion lelu...@gmail.com wrote: On 11-05-22 05:22 AM, Brice Figureau wrote: On 22/05/11 01:10, Gabriel Filion wrote: Hello, I found out that a puppetmaster I manage is currently not using the thin_storeconfigs option and suggested to the other admins that we use this in order to reduce puppet run times a little. Thin storeconfigs won't reduce your puppet agent run time, only the master compilation time. thanks for the precision. still there's a little gain in comparison. I would probably gain more performance in upgrading from 0.25.5 to 2.6.x, but that will come later since it requires more effort. Is it recommended to purge the [mysql] database once the option is enabled on the puppetmaster? I don't think so. The next run with thin_storeconfigs should get rid of all the extraneous data. great, that's good to know. p.s. on another note: I can't grasp the advantage of not using thin_storeconfigs. Since we'll be parsing the manifests on every change anyway, having all info replicated into a database doesn't seem to bring us anything. Is there any use case where not using this option would make sense? Having all the data in the database can help write inventory applications. If you don't have such application, thin storeconfig is way better. On another hand, if you don't use exported resources/collection, you really don't care about storeconfigs at all and you should disable it altogether. thanks to everyone for details on this subject. since we currently don't use the extra info (and don't plan to use it in the near future), but do use exported resources (nagios configs, ssh keys), using storeconfigs with thin_storeconfigs will fit just great. -- Gabriel Filion -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
RE: [Puppet Users] changing the default key length and hash
Ah. I was thinking in the broader scope of getting us away from
insecure hashes elsewhere in the product. From a strictly certificate
POV, indeed, it should be just fine.
I'm trying to configure FIPS-compliant servers, and I've run into segfaults
thrown by the Ruby interpreter when Puppet tries to use MD5. I think this is a
problem somewhere else in my system, not Puppet, but it highlights the issue
that I need Puppet to be able to use other hashing algorithms in its system
configuration work, not merely in its certificates.
I've got an internal patch that replaces Digest::MD5 with Digest::SHA2 in
puppet/util/checksums.rb and in puppet/parser/functions/md5.rb, but this method
lacks finesse. The DSL function is still called md5, and the string
representation of a file still starts with '{md5}' even though the rest is an
SHA256 sum.
It appears that puppet/util/checksums.rb was a start at adding hash algorithm
flexibility, but the '{md5}' is added on elsewhere.
Has someone else already done things about this?
--
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] Client updates
Mcollective with mc-puppet should work if you patch it to not daemonize (you'll need to adjust the timeouts as well, of course). Errors running will bubble up to the list of nodes that failed the run. -- Nathan Clemons http://www.livemocha.com The worlds largest online language learning community On Wed, May 25, 2011 at 10:20 AM, Douglas Garstang doug.garst...@gmail.comwrote: On Wed, May 25, 2011 at 10:16 AM, Brian Cully bcu...@gmail.com wrote: On May 25, 2011, at 1:12 PM, Douglas Garstang wrote: I probably waste quite a bit of time each week restarting the puppet client, and logging systems, and tailing the messages file, to see if my puppet changes worked. Is there a better way? How do people normally do this? I use monit to keep the puppet agent running in case it craps out, and puppet dashboard to keep an eye on all my nodes. Looking for a non GUI option. Doug. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Client updates
- Original Message - Basically the ways I know of: 1) Don't run puppet as a daemon, but run it out of cron every X mins. 2) Setup a cronjob that checks if puppet is running and restart it if not. 3) Setup a nagios job that checks to see if puppet is running 4) Presuming you are managing your puppet code in some sort of version control system, you can publish the latest timestamp of your latest commit, and also push that out via puppet, and setup a nagios check that compares them and if they ever are behind by more than X mins you can crit on it. You could take this a step further and have nagios automatically restart puppet if they are behind, but if you think it might be a syntax error, I would probably skip that. (As an aside you should do syntax checking before committing. I added the commands to do so below) 5) Foreman (or dashboard) can monitor puppet runs, and flag any broken runs. 6) use the last run summary # cat /var/lib/puppet/state/last_run_summary.yaml --- time: group: 0.000852 last_run: 1306343446 class: 0.002389 yumrepo: 0.037513 service: 2.300486 schedule: 0.002291 cron: 0.001797 config_retrieval: 18.9993901252747 total: 37.9802451252747 package: 0.371819 filebucket: 0.00032 file: 15.664177 exec: 0.593368 user: 0.005843 resources: total: 384 events: total: 0 changes: -- 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] Client updates
On Wed, May 25, 2011 at 10:22 AM, Brian Gupta brian.gu...@brandorr.comwrote: Basically the ways I know of: 1) Don't run puppet as a daemon, but run it out of cron every X mins. 2) Setup a cronjob that checks if puppet is running and restart it if not. 3) Setup a nagios job that checks to see if puppet is running 4) Presuming you are managing your puppet code in some sort of version control system, you can publish the latest timestamp of your latest commit, and also push that out via puppet, and setup a nagios check that compares them and if they ever are behind by more than X mins you can crit on it. You could take this a step further and have nagios automatically restart puppet if they are behind, but if you think it might be a syntax error, I would probably skip that. (As an aside you should do syntax checking before committing. I added the commands to do so below) 5) Foreman (or dashboard) can monitor puppet runs, and flag any broken runs. Check syntax: puppet --noop --parseonly memcached.pp Check erb syntax: erb -x -T '-' memcached-sessions.erb |ruby -c We use a combination of 2,3,4 and 5. I must have phrased my question wrong, because it seems to have been misinterpreted. We're pretty much doing everything you suggested, with the exception of Foreman, which I don't like. I just need a way to confirm that the changes I made to the config were executed successfully. I also need to know if other changes snuck in somehow, and everything has gone south for one reason or another. The only way I can think of to do this, is to actually force puppet to do a run, and then eyeball /var/log/messages immediately. Doug. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Client updates
On Wed, May 25, 2011 at 10:26 AM, Nathan Clemons nat...@livemocha.comwrote: Mcollective with mc-puppet should work if you patch it to not daemonize (you'll need to adjust the timeouts as well, of course). Errors running will bubble up to the list of nodes that failed the run. Failed both for syntax errors AND dependency errors? Don't know what you mean by 'bubble up'. Doug. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
RE: [Puppet Users] Client updates
-Original Message- From: puppet-users@googlegroups.com [mailto:puppet-users@googlegroups.com] On Behalf Of Brian Cully Sent: Wednesday, May 25, 2011 11:16 AM To: puppet-users@googlegroups.com Subject: Re: [Puppet Users] Client updates On May 25, 2011, at 1:12 PM, Douglas Garstang wrote: I probably waste quite a bit of time each week restarting the puppet client, and logging systems, and tailing the messages file, to see if my puppet changes worked. Is there a better way? How do people normally do this? We log to a central syslog server, and send out a daily email of any changes/failures. I use monit to keep the puppet agent running in case it craps out, and puppet dashboard to keep an eye on all my nodes. We also use storedconfigs and can just query the compiled time to see if any clients stopped reporting. -bjc -- 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 email communication and any files transmitted with it may contain confidential and or proprietary information and is provided for the use of the intended recipient only. Any review, retransmission or dissemination of this information by anyone other than the intended recipient is prohibited. If you receive this email in error, please contact the sender and delete this communication and any copies immediately. Thank you. http://www.encana.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] Client updates
On Wed, May 25, 2011 at 10:26 AM, R.I.Pienaar r...@devco.net wrote: - Original Message - Basically the ways I know of: 1) Don't run puppet as a daemon, but run it out of cron every X mins. 2) Setup a cronjob that checks if puppet is running and restart it if not. 3) Setup a nagios job that checks to see if puppet is running 4) Presuming you are managing your puppet code in some sort of version control system, you can publish the latest timestamp of your latest commit, and also push that out via puppet, and setup a nagios check that compares them and if they ever are behind by more than X mins you can crit on it. You could take this a step further and have nagios automatically restart puppet if they are behind, but if you think it might be a syntax error, I would probably skip that. (As an aside you should do syntax checking before committing. I added the commands to do so below) 5) Foreman (or dashboard) can monitor puppet runs, and flag any broken runs. 6) use the last run summary # cat /var/lib/puppet/state/last_run_summary.yaml --- time: group: 0.000852 last_run: 1306343446 class: 0.002389 yumrepo: 0.037513 service: 2.300486 schedule: 0.002291 cron: 0.001797 config_retrieval: 18.9993901252747 total: 37.9802451252747 package: 0.371819 filebucket: 0.00032 file: 15.664177 exec: 0.593368 user: 0.005843 resources: total: 384 events: total: 0 changes: We're using puppet 2.6.4, and we don't have that file... [fre] root@prov01 ~:# ls -l /var/lib/puppet/state total 56 -rw-r--r-- 1 root root 112 Apr 17 21:18 classes.txt drwxr-xr-x 2 root root 4096 Apr 10 17:14 graphs -rw-rw 1 root root 47421 May 25 17:25 state.yaml [fre] root@prov01 ~:# Doug. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Client updates
Mcollective hides successes and only shows you failures, keeping the signal to noise ratio very high. If you run puppet without daemonizing, anything that causes the config to not be applied successfully is going to show up as an error. -- Nathan Clemons http://www.livemocha.com The worlds largest online language learning community On Wed, May 25, 2011 at 10:30 AM, Douglas Garstang doug.garst...@gmail.comwrote: On Wed, May 25, 2011 at 10:26 AM, Nathan Clemons nat...@livemocha.comwrote: Mcollective with mc-puppet should work if you patch it to not daemonize (you'll need to adjust the timeouts as well, of course). Errors running will bubble up to the list of nodes that failed the run. Failed both for syntax errors AND dependency errors? Don't know what you mean by 'bubble up'. Doug. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Client updates
On Wed, May 25, 2011 at 10:35 AM, Nathan Clemons nat...@livemocha.comwrote: Mcollective hides successes and only shows you failures, keeping the signal to noise ratio very high. If you run puppet without daemonizing, anything that causes the config to not be applied successfully is going to show up as an error. Yes, but then, when there is an error, the daemon stops running. Assuming you had nagios checking for that, you've still got to wait for the nagios alert to find out, and in the mean time, the guy who is on call this week, who gets the texts is going to be even more pissed than he already is for getting alerts at 3am. Doug. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Client updates
On Wed, May 25, 2011 at 1:29 PM, Douglas Garstang doug.garst...@gmail.com wrote: On Wed, May 25, 2011 at 10:22 AM, Brian Gupta brian.gu...@brandorr.com wrote: Basically the ways I know of: 1) Don't run puppet as a daemon, but run it out of cron every X mins. 2) Setup a cronjob that checks if puppet is running and restart it if not. 3) Setup a nagios job that checks to see if puppet is running 4) Presuming you are managing your puppet code in some sort of version control system, you can publish the latest timestamp of your latest commit, and also push that out via puppet, and setup a nagios check that compares them and if they ever are behind by more than X mins you can crit on it. You could take this a step further and have nagios automatically restart puppet if they are behind, but if you think it might be a syntax error, I would probably skip that. (As an aside you should do syntax checking before committing. I added the commands to do so below) 5) Foreman (or dashboard) can monitor puppet runs, and flag any broken runs. Check syntax: puppet --noop --parseonly memcached.pp Check erb syntax: erb -x -T '-' memcached-sessions.erb |ruby -c We use a combination of 2,3,4 and 5. I must have phrased my question wrong, because it seems to have been misinterpreted. We're pretty much doing everything you suggested, with the exception of Foreman, which I don't like. I just need a way to confirm that the changes I made to the config were executed successfully. I also need to know if other changes snuck in somehow, and everything has gone south for one reason or another. The only way I can think of to do this, is to actually force puppet to do a run, and then eyeball /var/log/messages immediately. Doug. What do you mean by executed successfully? Assuming I understand your question correctly, if it is untested code, and it passes a syntax checker, and doesn't generate errors, you pretty much need to spot check at least one one system that the code in question does what you intended. Many folks do this in a dev environment, before pushing it to their puppetmaster. I don't really see a way around this that wouldn't end up being a lot more work than it's worth. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] enabling of 'thin_storeconfigs'
On Wed, May 25, 2011 at 10:23 AM, Nathan Clemons nat...@livemocha.comwrote: So if Nagios configs are the only thing you use stored configs for, thin stored configs will work just fine? If so, I forsee a switch in our future. :) Also, since you mentioned it... how difficult is it to upgrade from 0.25 to 2.6 / 2.7? I've been curious to upgrade but for the most part everything's been working fine so I've been holding off. Will I need to rewrite parts of my config? (I'm not doing much fancy, mostly user/service/package/file management with a side of Nagios.) You shouldn't have to rewrite anything to go from 0.25 to 2.6.x. -- 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] Client updates
It depends on how you use it. In our environment, we don't leave the Puppet daemon running. We only do on-demand runs... that way changes only happen when we push them out. Your mileage obviously may vary, but if you're looking for tight control, that's something to consider. -- Nathan Clemons http://www.livemocha.com The worlds largest online language learning community On Wed, May 25, 2011 at 10:39 AM, Douglas Garstang doug.garst...@gmail.comwrote: On Wed, May 25, 2011 at 10:35 AM, Nathan Clemons nat...@livemocha.comwrote: Mcollective hides successes and only shows you failures, keeping the signal to noise ratio very high. If you run puppet without daemonizing, anything that causes the config to not be applied successfully is going to show up as an error. Yes, but then, when there is an error, the daemon stops running. Assuming you had nagios checking for that, you've still got to wait for the nagios alert to find out, and in the mean time, the guy who is on call this week, who gets the texts is going to be even more pissed than he already is for getting alerts at 3am. Doug. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Client updates
On Wed, May 25, 2011 at 10:40 AM, Brian Gupta brian.gu...@brandorr.comwrote: On Wed, May 25, 2011 at 1:29 PM, Douglas Garstang doug.garst...@gmail.com wrote: On Wed, May 25, 2011 at 10:22 AM, Brian Gupta brian.gu...@brandorr.com wrote: Basically the ways I know of: 1) Don't run puppet as a daemon, but run it out of cron every X mins. 2) Setup a cronjob that checks if puppet is running and restart it if not. 3) Setup a nagios job that checks to see if puppet is running 4) Presuming you are managing your puppet code in some sort of version control system, you can publish the latest timestamp of your latest commit, and also push that out via puppet, and setup a nagios check that compares them and if they ever are behind by more than X mins you can crit on it. You could take this a step further and have nagios automatically restart puppet if they are behind, but if you think it might be a syntax error, I would probably skip that. (As an aside you should do syntax checking before committing. I added the commands to do so below) 5) Foreman (or dashboard) can monitor puppet runs, and flag any broken runs. Check syntax: puppet --noop --parseonly memcached.pp Check erb syntax: erb -x -T '-' memcached-sessions.erb |ruby -c We use a combination of 2,3,4 and 5. I must have phrased my question wrong, because it seems to have been misinterpreted. We're pretty much doing everything you suggested, with the exception of Foreman, which I don't like. I just need a way to confirm that the changes I made to the config were executed successfully. I also need to know if other changes snuck in somehow, and everything has gone south for one reason or another. The only way I can think of to do this, is to actually force puppet to do a run, and then eyeball /var/log/messages immediately. Doug. What do you mean by executed successfully? Assuming I understand your question correctly, if it is untested code, and it passes a syntax checker, and doesn't generate errors, you pretty much need to spot check at least one one system that the code in question does what you intended. Many folks do this in a dev environment, before pushing it to their puppetmaster. I don't really see a way around this that wouldn't end up being a lot more work than it's worth. Executed successfully = a) No syntax errors b) No dependency errors c) No other weird stuff Just because there are no dependency errors on one system, doesn't mean that there won't be dependency errors on another system. No two systems are ever identical, so spot checks won't cover all bases. We're a startup with limited resources, with the typical total lack of resources. We don't have the luxury of a dev environment. We have 4 data centres, different rules for each, and one is PCI compliant, which is akin to having a root canal done every time you touch it. Even if we did, that doesn't preclude making sure everything ran ok. It's still needed. Doug. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Client updates
Foreman can email error reports automatically. (Without having to use the
GUI..) IIRC you can also make it email actions (changes) - if not, it
shouldn't be that hard to add.
We use nagios to check puppet's state file for age - if it is too old,
puppet hasn't run. Between those two, afaict, we're covering basically
everything. And once a day, foreman also emails a status summary
('interesting' hosts - changes, failures, outdated/no report, etc)
Puppet tries to run, finds a problem: Foreman emails the report.
Puppet runs and makes changes, no errors: Do you want email? It'll show on
the 'active hosts' page, and in the nightly summary email.
Puppet doesn't run: Nagios alerts on that host
And FWIW I'm the only sysadmin (also at a startup w/ no dev environment for
puppet) and its really not impossible to get identical servers. (In fact,
our first answer to wtf is wrong with server21-foo is meh, whatever,
trash the vm and recreate it.. Well.. thats first after lets make sure it
didn't get hacked of course..) My workload went -way- down once puppet was
working properly (complete manifests) and even more when I got foreman's vm
deployments going.
On Wed, May 25, 2011 at 1:48 PM, Douglas Garstang
doug.garst...@gmail.comwrote:
Executed successfully =
a) No syntax errors
b) No dependency errors
c) No other weird stuff
Just because there are no dependency errors on one system, doesn't mean
that there won't be dependency errors on another system. No two systems are
ever identical, so spot checks won't cover all bases.
We're a startup with limited resources, with the typical total lack of
resources. We don't have the luxury of a dev environment. We have 4 data
centres, different rules for each, and one is PCI compliant, which is akin
to having a root canal done every time you touch it. Even if we did, that
doesn't preclude making sure everything ran ok. It's still needed.
Doug.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] enabling of 'thin_storeconfigs'
On 11-05-25 01:28 PM, Nigel Kersten wrote: On Wed, May 25, 2011 at 10:23 AM, Nathan Clemons nat...@livemocha.com mailto:nat...@livemocha.com wrote: So if Nagios configs are the only thing you use stored configs for, thin stored configs will work just fine? If so, I forsee a switch in our future. :) Also, since you mentioned it... how difficult is it to upgrade from 0.25 to 2.6 / 2.7? I've been curious to upgrade but for the most part everything's been working fine so I've been holding off. Will I need to rewrite parts of my config? (I'm not doing much fancy, mostly user/service/package/file management with a side of Nagios.) You shouldn't have to rewrite anything to go from 0.25 to 2.6.x. Like Nigel said, if you don't use too much fancy features combined with funky inheritance, you shouldn't have much problems upgrading. You could try things out first to see how things go and to be able to make corrections to your manifests if needed. Set up a new puppet master with 2.6/2.7, copy your modules and manifests to that new server and setup a few virtual servers to use different setups from your nodes. This testing phase will be the longest, but it's always better to be safe than sorry ;) After that, upgrade your puppet master, wait a couple of days just to see if it holds up well. Finally upgrade your clients. -- Gabriel Filion -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] enabling of 'thin_storeconfigs'
On May 25, 2011, at 10:23 AM, Nathan Clemons wrote: So if Nagios configs are the only thing you use stored configs for, thin stored configs will work just fine? If so, I forsee a switch in our future. :) Also, since you mentioned it... how difficult is it to upgrade from 0.25 to 2.6 / 2.7? I've been curious to upgrade but for the most part everything's been working fine so I've been holding off. Will I need to rewrite parts of my config? (I'm not doing much fancy, mostly user/service/package/file management with a side of Nagios.) I'd avoid any version of puppet that ends in a 0 like the plague if you want stability. Other than that, I haven't run into almost any problems upgrading except that, in my experience, each time you upgrade the major version, puppet seems to use up 20% more RAM. (compounding) It also seems to get faster and use less disk IO each time I upgrade the major version. For more speed improvements, take a look at recurse = remote in File. -- 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] Output of puppet master --compile
Hi Experts,
When I use puppet master --compile, it will spit out some notice information
to the beginning of the output:
# puppet master --manifest root/tt.pp --compile
vm_0009_270e41c5-4242-416d-80ad-38dc85469076
notice: Compiled catalog for
vm_0009_270e41c5-4242-416d-80ad-38dc85469076 in environment
production in 0.02 seconds
{
data: {
edges: [
... ...
When I try to apply this yaml, it returns some PSON error. I have to remove
everything before the first { to make it work.
Just wondering is there a way in puppet to avoid this?
Thanks
-Yushu
+-+
| Yushu Yao
| Ph:1-510-486-4690
|
| Lawrence Berkeley National Lab
| 1 Cyclotron Road
| Berkeley CA 94720 - USA
+-+
--
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] Output of puppet master --compile
I think that putting --no-verbose might work, but I can't test it.
On May 25, 2011, at 12:18 PM, Yushu Yao wrote:
Hi Experts,
When I use puppet master --compile, it will spit out some notice information
to the beginning of the output:
# puppet master --manifest root/tt.pp --compile
vm_0009_270e41c5-4242-416d-80ad-38dc85469076
notice: Compiled catalog for
vm_0009_270e41c5-4242-416d-80ad-38dc85469076 in environment
production in 0.02 seconds
{
data: {
edges: [
... ...
When I try to apply this yaml, it returns some PSON error. I have to remove
everything before the first { to make it work.
Just wondering is there a way in puppet to avoid this?
Thanks
-Yushu
+-+
| Yushu Yao
| Ph:1-510-486-4690
|
| Lawrence Berkeley National Lab
| 1 Cyclotron Road
| Berkeley CA 94720 - USA
+-+
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] changing the default key length and hash
On Wed, May 25, 2011 at 10:23, Jennings, Jared L CTR USAF AFMC 46
SK/CCI jared.jennings@eglin.af.mil wrote:
Ah. I was thinking in the broader scope of getting us away from
insecure hashes elsewhere in the product. From a strictly certificate
POV, indeed, it should be just fine.
I'm trying to configure FIPS-compliant servers, and I've run into segfaults
thrown by the Ruby interpreter when Puppet tries to use MD5. I think this is
a problem somewhere else in my system, not Puppet, but it highlights the
issue that I need Puppet to be able to use other hashing algorithms in its
system configuration work, not merely in its certificates.
O_o At this point I would be pretty worried; that sounds like a nasty
bug, and the worry that it is from some sort of memory corruption that
is going to be making a mess of other things along the way. That
said, I agree that being able to use a different digest would be
great.
I've got an internal patch that replaces Digest::MD5 with Digest::SHA2 in
puppet/util/checksums.rb and in puppet/parser/functions/md5.rb, but this
method lacks finesse. The DSL function is still called md5, and the string
representation of a file still starts with '{md5}' even though the rest is an
SHA256 sum.
Yeah. You will also hit troubles if you don't have a uniformly
patched solution out there, or even if...
It appears that puppet/util/checksums.rb was a start at adding hash algorithm
flexibility, but the '{md5}' is added on elsewhere.
...you fixed this, and you needed to run against unpatched clients.
We don't generically match the checksum at all, so that assumption is
going to be baked into a whole bunch of places.
Has someone else already done things about this?
Not that we are aware of. If you delivered support for configuring
that through the product, though, we would almost certainly support it
without any other compatibility support. (As in, I think it has value
in that form alone, even though we want to support multiple hashes,
etc.)
Daniel
--
⎋ Puppet Labs Developer – http://puppetlabs.com
✉ Daniel Pittman dan...@puppetlabs.com
✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775
♲ Made with 100 percent post-consumer electrons
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] changing the default key length and hash
Just noting that we are moving forward on the original ticket.
It does appear that we've drifted onto other issues, I'd like to remind
people to please file bugs/feature requests on those so we don't lose track
of them.
On Wed, May 25, 2011 at 12:41 PM, Daniel Pittman dan...@puppetlabs.comwrote:
On Wed, May 25, 2011 at 10:23, Jennings, Jared L CTR USAF AFMC 46
SK/CCI jared.jennings@eglin.af.mil wrote:
Ah. I was thinking in the broader scope of getting us away from
insecure hashes elsewhere in the product. From a strictly certificate
POV, indeed, it should be just fine.
I'm trying to configure FIPS-compliant servers, and I've run into
segfaults thrown by the Ruby interpreter when Puppet tries to use MD5. I
think this is a problem somewhere else in my system, not Puppet, but it
highlights the issue that I need Puppet to be able to use other hashing
algorithms in its system configuration work, not merely in its certificates.
O_o At this point I would be pretty worried; that sounds like a nasty
bug, and the worry that it is from some sort of memory corruption that
is going to be making a mess of other things along the way. That
said, I agree that being able to use a different digest would be
great.
I've got an internal patch that replaces Digest::MD5 with Digest::SHA2 in
puppet/util/checksums.rb and in puppet/parser/functions/md5.rb, but this
method lacks finesse. The DSL function is still called md5, and the string
representation of a file still starts with '{md5}' even though the rest is
an SHA256 sum.
Yeah. You will also hit troubles if you don't have a uniformly
patched solution out there, or even if...
It appears that puppet/util/checksums.rb was a start at adding hash
algorithm flexibility, but the '{md5}' is added on elsewhere.
...you fixed this, and you needed to run against unpatched clients.
We don't generically match the checksum at all, so that assumption is
going to be baked into a whole bunch of places.
Has someone else already done things about this?
Not that we are aware of. If you delivered support for configuring
that through the product, though, we would almost certainly support it
without any other compatibility support. (As in, I think it has value
in that form alone, even though we want to support multiple hashes,
etc.)
Daniel
--
⎋ Puppet Labs Developer – http://puppetlabs.com
✉ Daniel Pittman dan...@puppetlabs.com
✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775
♲ Made with 100 percent post-consumer electrons
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
Nigel Kersten
Product, Puppet Labs
@nigelkersten
--
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] Client updates
Douglas,
I have to concur with disconnect, now that we are using Foreman, many
of the things we setup in the past to catch these things are now
redundant. I don't know why you don't like Foreman, but I have to
say along with our initial decision to use puppet, and managing our
configs with version control, adopting Foreman stands up there as one
of our big infrastructure management wins. (And we aren't even
using Foreman's provisioning capabilities).
May I ask why you don't like Foreman? (We were for a long time
hesitant to use Foreman, as it wasn't an official project, but we
had reached a point where we needed a new ENC, and a technical
evaluation of both Foreman and Dashboard lead us to the realization
that functionality-wise it was a lot closer to what we needed. (And I
suspect your needs may be similar to ours.)
Cheers,
Brian
On Wed, May 25, 2011 at 1:54 PM, Disconnect dc.disconn...@gmail.com wrote:
Foreman can email error reports automatically. (Without having to use the
GUI..) IIRC you can also make it email actions (changes) - if not, it
shouldn't be that hard to add.
We use nagios to check puppet's state file for age - if it is too old,
puppet hasn't run. Between those two, afaict, we're covering basically
everything. And once a day, foreman also emails a status summary
('interesting' hosts - changes, failures, outdated/no report, etc)
Puppet tries to run, finds a problem: Foreman emails the report.
Puppet runs and makes changes, no errors: Do you want email? It'll show on
the 'active hosts' page, and in the nightly summary email.
Puppet doesn't run: Nagios alerts on that host
And FWIW I'm the only sysadmin (also at a startup w/ no dev environment for
puppet) and its really not impossible to get identical servers. (In fact,
our first answer to wtf is wrong with server21-foo is meh, whatever,
trash the vm and recreate it.. Well.. thats first after lets make sure it
didn't get hacked of course..) My workload went -way- down once puppet was
working properly (complete manifests) and even more when I got foreman's vm
deployments going.
On Wed, May 25, 2011 at 1:48 PM, Douglas Garstang doug.garst...@gmail.com
wrote:
Executed successfully =
a) No syntax errors
b) No dependency errors
c) No other weird stuff
Just because there are no dependency errors on one system, doesn't mean
that there won't be dependency errors on another system. No two systems are
ever identical, so spot checks won't cover all bases.
We're a startup with limited resources, with the typical total lack of
resources. We don't have the luxury of a dev environment. We have 4 data
centres, different rules for each, and one is PCI compliant, which is akin
to having a root canal done every time you touch it. Even if we did, that
doesn't preclude making sure everything ran ok. It's still needed.
Doug.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
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] Managing netgroups in /etc/passwd with Puppet via Augeas
Hi all,
I'm relatively new to both Puppet and Augeas. I'm currently stuck
trying to figure out how to manage hosts' netgroup entries in /etc/
passwd. I've got it working to ensure a single specified netgroup is
the only one in /etc/passwd:
class ldap {
define netgroups {
augeas { netgroups:
context = /files/etc/passwd,
changes = [
rm @nis,
set @nis[1] $name,
],
}
}
}
In my nodes.pp:
node host1 {
ldap::netgroups { admins: }
}
I'd like to generalize this so I can list multiple netgroups, e.g.:
node host1 {
ldap::netgroups { admins dbas devs: }
}
I've been hunting around looking for similar concepts and I've come
somewhat close using split() with a variable recipe name, e.g.:
class ldap {
$netgroups = split($name, )
$context = /files/etc/passwd
augeas { cleanup-netgroups:
context = $context,
changes = rm @nis,
}
augeas { $netgroups:
context = $context,
changes = [
set @nis[last()+1] $name,
],
}
}
though I'm running into an ordering problem here.
Am I even on the right path here or is there a better approach to this
sort of problem?
Thanks,
Justin
--
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] Variable inheritance in Stages
The pre classes are definately getting defined before the variable is being
declared in my node definition:
node 'deploy.nrg.mir' {
$deployment = true
$deploy_environment = development
$deploy_hostname = testhost
$deploy_fqdn = testhost.nrg.mir
$deploy_netadapters = 2
notify { node:deploy:
message = deploy_fqdn: $deploy_fqdn
}
include baseclass
include deploy
}
In my site.pp:
lines deleted...
import templates.pp
import nodes/*
import classes/*
import os/*
import common
stage { [pre, post]: }
Stage[pre] - Stage[main] - Stage[post]
class {
network: stage = pre;
pre_baseclass: stage = pre;
postclass: stage= post;
}
In my network class I want to use deploy_* variables defined in the node.
I not sure how to get puppet to always load the node definition before all
other classes. Almost seems like a bug.
-Chip
--
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] Variable inheritance in Stages
On Tue, May 24, 2011 at 9:46 AM, Chip Schweiss chip.schwe...@gmail.com wrote:
The pre classes are definately getting defined before the variable is being
declared in my node definition:
node 'deploy.nrg.mir' {
$deployment = true
$deploy_environment = development
$deploy_hostname = testhost
$deploy_fqdn = testhost.nrg.mir
$deploy_netadapters = 2
notify { node:deploy:
message = deploy_fqdn: $deploy_fqdn
}
include baseclass
include deploy
}
In my site.pp:
lines deleted...
import templates.pp
import nodes/*
import classes/*
import os/*
import common
stage { [pre, post]: }
Stage[pre] - Stage[main] - Stage[post]
class {
network: stage = pre;
pre_baseclass: stage = pre;
postclass: stage= post;
}
In my network class I want to use deploy_* variables defined in the node.
I not sure how to get puppet to always load the node definition before all
other classes. Almost seems like a bug.
Well it's not a bug, your variables are nested in node scope and it's
not available because the class is declared in top scope. You
effectively are doing:
node sample {
$var = 'value'
}
class { 'network': }
Declare the class in the node scope and you should have access to $var.
node sample {
$var = 'value'
class { 'network': }
}
Another options is to access the variable with it's explicit scope $sample::var.
Thanks,
Nan
--
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] Client updates
On 05/25/2011 01:12 PM, Douglas Garstang wrote: I probably waste quite a bit of time each week restarting the puppet client, and logging systems, and tailing the messages file, to see if my puppet changes worked. Is there a better way? How do people normally do this? Sure, I can use puppetrun or mcollective to cause puppet to do a config run on the client, but I still need to log in and look at the messages file. The reports that the clients generate, and which are available on the server contain, I believe yield enough information to determine if there was any syntax errors or not. I guess they contain more, but, even though they are yaml files, they contain ruby objects, which non ruby parsers won't read. Would have been nice if it was standard yaml. Anyway ideas? Doug. We use the tagmail report to catch reports tagged Err and email that to us. This in addition to last run nagios checks seem to cover the bases for us. We run puppet as a daemon. -Doug signature.asc Description: OpenPGP digital signature
[Puppet Users] Re: Managing netgroups in /etc/passwd with Puppet via Augeas
Hmm, I think I may have found a more tractable approach in the template() and inline_template() functions. -- 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 with Facter 1.5.9 on Ubuntu
It looks like there's a fairly critical bug with Facter 1.5.9, when it comes to Ubuntu[1]. Facter ends up reporting the wrong value for 'operatingsystem', which can cause problems with the manifest. If you're dependent on being able to switch in your manifests based on Ubuntu vs Debian, then you shouldn't upgrade to Facter 1.5.9. [1] https://projects.puppetlabs.com/issues/7670 -- Jacob Helwig signature.asc Description: Digital signature
Re: [Puppet Users] enabling of 'thin_storeconfigs'
On Wed, May 25, 2011 at 11:52 AM, Patrick kc7...@gmail.com wrote: I'd avoid any version of puppet that ends in a 0 like the plague if you want stability. The project has been steadily improving in this regard, but it's definitely been a problem. I have great hopes for 2.7.0 though, and the more people that test out our RCs (hint! hint!) the better it's going to be. http://www.puppetlabs.com/downloads/puppet/puppet-2.7.0rc3.tar.gz http://www.puppetlabs.com/downloads/puppet/puppet-2.7.0rc3.tar.gz.asc -- Nigel Kersten Product, Puppet Labs @nigelkersten -- 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] Changing up some things around Puppet Labs's Open Source Software
One of the largest challenges we've continually faced at Puppet labs is trying to find a good balance in splitting the development team's time between the (currently small amount of) commercial software, and the (much larger amount of) open source software. This balancing act has, unfortunately, affected being able to get a number of the excellent contributions from people outside of Puppet Labs the attention that they deserve, and also affected being able to give the internal commercial development the attention it deserves to further Puppet Labs as a business. As a step towards simplifying the decision towards how to divide our time, we're dividing our responsibilities instead. We're splitting the team to form one dedicated to owning the open source projects, focused on their quality, frequency of delivery, and ease of contribution. This team's long-term goal is to build outside contribution, and generally ensure that we have a healthy and active open source community. One of the short-term effects of this is that it will be much clearer who will be responsible to the community for making sure that you get the interactions you're looking for, and that the things you care about are making their way into the various open source projects. Right now this Open Source team consists of Josh Cooper, Nick Lewis, and myself. As the Open Source team, we're planning on sending periodic updates to the puppet-dev mailing list (and possibly user) with the results of our planning meeting (what we roughly plan on working on over the coming iteration), and with information similar to Git's What's Cooking updates[1] (what's in the repository pending release). We haven't figured out with what frequency to send these updates (other than the results of the iteration planning meeting). If you have any thoughts on how frequently you think this information would be useful, we'd love the input. We're also toying around with some ideas on how to get better visibility into the daily stand-ups we have. We haven't had time to think about this one too much, but so far we've got three rough proposals. * Have each person do their stand-up check-in on the puppet-dev mailing list. * Have someone send a stand-up summary to the mailing list after each stand-up. * Do something akin to the Pivotal Labs stand-up summary blog posts[2]. Again, if you have any ideas, we'd love to hear them. This isn't exactly a change (we've just been forgetting to mention it), but you can see what the current community patch backlog looks like by going to our Patchwork instance[3]. We've been using Patchwork for a while to keep track of the patches that go through the dev mailing list, to try and prevent them from slipping through the cracks. One of our goals is to get this backlog down to zero, and keep it as close to that as possible. Another long-term change that has been mentioned in passing, but hasn't really been fleshed out is moving the other teams to be just normal contributors. Having them go through the same contribution process as everyone outside of Puppet Labs (though with the ability to walk over or holler, instead of having to email if they need something). We'll likely be making more changes in the future to further achieve the goal of having a strong/vibrant/healthy open source community, though we haven't figured any of this out yet. If you have any ideas for things you'd like to see, or comments/suggestions/questions about anything I've mentioned please feel free to bring them up here, or contact me personally. [1] http://article.gmane.org/gmane.comp.version-control.git/171013 [2] http://pivotallabs.com/blabs/categories/standup [3] https://patchwork.puppetlabs.com/ -- Jacob Helwig signature.asc Description: Digital signature
[Puppet Users] Re: Ensure a package is newer than version X
Check out yum-versionlock for RHEL/CentOS, its a yum plugin. We use it to lock down versions and then just have ensure = latest in our manifests.. Regards, Josh On May 24, 8:26 pm, Felix Frank felix.fr...@alumni.tu-berlin.de wrote: On 05/17/2011 09:37 PM, Doug Warner wrote: On Gentoo we would handle this by putting a mask in place to mask versions 1.7.1, then just ensure = installed on the package. Come to think of it, Debian would do this using apt pinning. There are probably yum/zypper counterparts for the RPM world. 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] Concat Module posted to Onyx Point Github.
Hi Trevor Thanks for the module. I've been testing out the concat module, thanks, but the only issue I see is files keep getting 'executed successfully' each round. Is there any way to not have it do this? I haven't really looked that your ruby logic yet. -- 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.
