Re: [Puppet Users] Problem dealing with multi role servers/manifests. resource already declared.
On Thu, Jun 21, 2012 at 6:20 AM, trey85stang trey85st...@gmail.com wrote: Now in each case I have files where httpd is notified to refresh... Is there a way to work around this without creating a custom module just for this one case? As you can see from the below error message I tried changing the name and using an alias.. but it does not like that either. The combination of Resource type and title needs to be unique for a single node. However, you can also not have two resources managing the same thing (in this case the http service). In order to get around this properly, you'd need to extract httpd into a module of it's own (where it belongs imho anyway) and refer to the service from both your nagios and your repoman manifests. If you don't want to make that module a full fledged apache (or whichever webserver you are running), then that's okay. Just keep it very simple, but do extract it. You can always expand it later. kind regards, -- Walter Heck -- Check out my startup: Puppet training and consulting @ http://www.olindata.com Follow @olindata on Twitter and/or 'Like' our Facebook page at http://www.facebook.com/olindata -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] How to iterate over an array? (with a counter)
On Wed, Jun 20, 2012, at 10:42 PM, R.I.Pienaar wrote: - Original Message - From: James Patterson jamespatter...@operamail.com To: puppet-users@googlegroups.com Sent: Wednesday, June 20, 2012 10:39:02 PM Subject: [Puppet Users] How to iterate over an array? (with a counter) Given an array, I'd like to iterate over it with a counter to produce something like this from a template: foo.0 = ARRAYVALUE0 foo.1 = ARRAYVALUE1 foo.2 = ARRAYVALUE2 (where ARRAYVALUEn is replaced by the value, and the foo.n is incremented for each value) The puppet templates support iteration, but I don't see how to also increment a counter to get the behaviour above? Is this possible? Thanks. array.each_with_index do |item, index| ... end item will be each item and index will increment from 0 upward Excellent stuff! Just what I wanted! If I wanted to sort numerically, backwards, skip numbers, do ($i=0; $i100; $i+2), etc, where should I read about that? Thanks. -- http://www.fastmail.fm - Does exactly what it says on the tin -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] How to iterate over an array? (with a counter)
- Original Message - From: James Patterson jamespatter...@operamail.com To: puppet-users@googlegroups.com Sent: Thursday, June 21, 2012 7:31:58 AM Subject: Re: [Puppet Users] How to iterate over an array? (with a counter) On Wed, Jun 20, 2012, at 10:42 PM, R.I.Pienaar wrote: - Original Message - From: James Patterson jamespatter...@operamail.com To: puppet-users@googlegroups.com Sent: Wednesday, June 20, 2012 10:39:02 PM Subject: [Puppet Users] How to iterate over an array? (with a counter) Given an array, I'd like to iterate over it with a counter to produce something like this from a template: foo.0 = ARRAYVALUE0 foo.1 = ARRAYVALUE1 foo.2 = ARRAYVALUE2 (where ARRAYVALUEn is replaced by the value, and the foo.n is incremented for each value) The puppet templates support iteration, but I don't see how to also increment a counter to get the behaviour above? Is this possible? Thanks. array.each_with_index do |item, index| ... end item will be each item and index will increment from 0 upward Excellent stuff! Just what I wanted! If I wanted to sort numerically, backwards, skip numbers, do ($i=0; $i100; $i+2), etc, where should I read about that? The best place to look is the ruby docs for Array[1] and Enumberable[2] these are the methods available to you. Getting used to how ruby does loops and stuff can be a bit weird, it has a for loop but not one that lets you easily tweak the itteration count etc, you'd probably do that with a while or until for best readability to people who dont know ruby very well. http://www.tutorialspoint.com/ruby/ruby_loops.htm [1] http://www.ruby-doc.org/core-1.9.3/Array.html [2] http://www.ruby-doc.org/core-1.9.3/Enumerable.html -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] facter plugin requires cause catalog failure, prevent setting up new clients
On 06/20/2012 06:54 PM, Jo Rhett wrote: Humm, I believe it's fair to assume that most people have some way of puppet provisioning that will be able to take care of this configuration detail. Okay, I've worked at 4 different shops using puppet over the last 6 years (one is a non-profit I work at part time). In not one of those shops was bare-metal provisioning something I set up (so the following decision was not mine and never has been) and in every case, the system kickstarts to install puppet rpm, then uses puppet to configure the rest of the system based on the system name. This goes back to this funny thing, where people keep saying I should be using a different configuration management system to handle things outside of puppet. Should we boot to install cfengine and use that to set up puppet? :p I seem to have your personal red cloth on me ;) I'm not suggesting an additional config management system. Most (all?) bare metal provisioning tools offer some way to carbon copy some base files, so a default puppet.conf that differs from the one in the RPM would be one idea to go about it. If the site has a need to maintain its own RPM of puppet agent (I know I do, but I realize it's not commonplace), this is a non-issue. But, again, I'm totally down with using puppet to configure puppet. This should definitely be an option, and it's a bummer that an important module keeps it from Just Working. 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] Custom facts and hyphens
On 06/21/2012 12:30 AM, Jo Rhett wrote: I'm not saying that you're wrong, but I'm still struggling to see this. Every place that class names are used should be single quoted, according to your style guide. And it's very easy in a syntax to tell the different between 'test-jo + 2' and 'test - jo + 2'. Those are not ambiguous. I beg to differ: $value = 1 $value-2 = 2 $sum = $value-2 +2 As for class names - I don't really care one way or the other. It's been deprecated for so long that we rid our manifests of dashes in class names very early. The limitation seems consistent with the PHP-like syntax, though (is it heresy to say 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] Re: Could not run Puppet configuration client: execution expired
Hi, I see. So I assume your manifests are in NFS (or some other shared storage) as well? Is there anything else I should be wary of when putting my masters behind HAproxy this way? Thanks, Felix On 06/20/2012 06:45 PM, Jake - USPS wrote: As for doing an active/active the way I am, my haproxy looks similar to the one in the link except no lines have 'backup' in them. Again, no DRBD which is mainly for the cert stuff and that is all handled by a single node (I set ca_server to my CA PM on all nodes). But, maybe you could have a shared NFS/storage for the certificates to address it? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Custom facts and hyphens
- Original Message - From: Felix Frank felix.fr...@alumni.tu-berlin.de To: puppet-users@googlegroups.com Sent: Thursday, June 21, 2012 10:18:50 AM Subject: Re: [Puppet Users] Custom facts and hyphens On 06/21/2012 12:30 AM, Jo Rhett wrote: I'm not saying that you're wrong, but I'm still struggling to see this. Every place that class names are used should be single quoted, according to your style guide. And it's very easy in a syntax to tell the different between 'test-jo + 2' and 'test - jo + 2'. Those are not ambiguous. I beg to differ: $value = 1 $value-2 = 2 $sum = $value-2 +2 As for class names - I don't really care one way or the other. It's been deprecated for so long that we rid our manifests of dashes in class names very early. You probably should as class names are variable names $foo::bar vs $foo-foo::bar The limitation seems consistent with the PHP-like syntax, though (is it heresy to say this?;) Also ruby, and this is significant, allowing people to make variable names that they cannot use in a template is not doing them any favours as it force them to do scope.lookupvar(foo-foo). In the 0.24 days -'s were documented as not supported but they worked in a few scenarios and others they didn't. I requested then that the parser fail on -'s but instead the docs were updated and a cycle of bug fixes around - in varnames started. This went on for countless releases and while trying to get this to work everywhere there was this multi year flip flop between sets of bugs with ever changing behaviour making even small dot release upgrades a nightmare where old templates and code suddenly produce different results. To the point where I ended up writing a widely used tool to diff 2 catalogs to highlight any differences in content of files etc. I do not think this has done anyone any favours so I very much welcome the change if it means more certainty and stability. I only wish the change didnt get introduced in a release this late in 2.7.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.
[Puppet Users] keeping local accounts up to date
Hi guys, Just started to look at Puppet. Is there a way I can have a user log into a Puppet Server box, and change their own password? Wondered if there was a script out there already that monitored for changes to the /etc/passwd and /etc/shadow entry for the user and extract the string to populate it to all Puppet clients. We plan to implement LDAP but that's a little way off, I just need an easy way in the meantime to keep my clients up to date with local accounts. Thanks Mark -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/XIGHmKIxXT4J. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, 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] Problem using subversion module
On 06/20/2012 10:31 PM, elliott wrote: I have unzipped it to my modules folder but I am having problems calling the definitions from elsewhere in my manifests. I get the following error: err: Could not retrieve catalog from remote server: Error 400 on SERVER: Puppet::Parser::AST::Resource failed with error ArgumentError: Invalid resource type subversion::svnserve at /etc/puppet/modules/mw-web-suite/manifests/httpd.pp:391 on node *** I can make it work by redefining the svnserve definition as subversion::svnserve, but I wonder why that would be necessary in a properly written module. Agreed, I'm puzzled why it's not named thus in the upstream module. Perhaps it's only suitable for specific puppet versions? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, 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] Apparently service not restarted although is supposed to
A dirty debian based workaround just in case somebody is experiencing
same issue:
class snmp::service {
exec { SNMP custom restart:
command = /etc/init.d/snmpd restart,
subscribe = Class[snmp::config],
refreshonly = true
}
}
Best regards
2012/6/19 Javi Legido j...@legido.com:
Amazing!
Many thanks, I will check all your suggestions, but I use similar
modules for other services (such as puppet, ssh, ntp...) On debian
nodes (all of them are clones) smoothly, but SNMP init script can be
buggy.
Thanks again
On 19/06/2012, jcbollinger john.bollin...@stjude.org wrote:
On Monday, June 18, 2012 4:53:23 AM UTC-5, Javi wrote:
Scenario: install SNMP (agent and daemon), change config file and restart
of service.
What's wrong? The logs showed that AFTER the new config file is applied,
the service (snmpd) is restarted, but looks like this is not true.
The log you presented shows that Puppet took the action it thought
appropriate for refreshing the service, and that action returned a success
code. If that didn't actually (re)start the service then probably your
declarations for it are inconsistent with the actual service implementation
(most likely with the initscript), or else something else happening on the
node is interfering.
Jun 15 17:08:21 test-3 puppet-agent[1219]:
(/Stage[main]/Apt::Service/Exec[/usr/bin/apt-get update]/returns) executed
successfully
Jun 15 17:08:44 test-3 puppet-agent[1219]:
(/Stage[main]/Snmp::Install/Package[snmp]/ensure) ensure changed 'purged'
to 'present'
[... many complaints from snmpd ...]
Why is snmpd logging anything at that point? Does installing the package
automatically start the service? That would be horrible!
Jun 15 17:09:01 test-3 puppet-agent[1219]:
(/Stage[main]/Snmp::Install/Package[snmpd]/ensure) ensure changed 'purged'
to 'present'
Jun 15 17:09:01 test-3 puppet-agent[1219]: FileBucket adding
/etc/snmp/snmpd.conf as {md5}a5007383dd9c4ef73500e3df8c080665
Jun 15 17:09:01 test-3 puppet-agent[1219]:
(/Stage[main]/Snmp::Config/File[/etc/snmp/snmpd.conf]) Filebucketed
/etc/snmp/snmpd.conf to puppet with sum a5007383dd9c4ef73500e3df8c080665
Jun 15 17:09:02 test-3 puppet-agent[1219]:
(/Stage[main]/Snmp::Config/File[/etc/snmp/snmpd.conf]/content) content
changed '{md5}a5007383dd9c4ef73500e3df8c080665' to
'{md5}6a797811e82b5f411af1093ea6336a04'
Jun 15 17:09:02 test-3 puppet-agent[1219]:
(/Stage[main]/Snmp::Config/File[/etc/snmp/snmpd.conf]) Scheduling refresh
of Service[snmpd]
Jun 15 17:09:02 test-3 puppet-agent[1219]:
(/Stage[main]/Snmp::Service/Service[snmpd]/ensure) ensure changed
'stopped'
to 'running'
The refresh Puppet performed was an attempt to change the service from
the stopped state to the running state. For Debian-family distros,
that probably means running '/etc/init.d/snmpd start'. Note: not *re*start,
because Puppet doesn't think the service is running yet. That's
suspicious, because snmpd was just observed logging all sorts of complaints
about its config file.
Jun 15 17:09:02 test-3 puppet-agent[1219]:
(/Stage[main]/Snmp::Service/Service[snmpd]) Triggered 'refresh' from 1
events
Jun 15 17:09:02 test-3 puppet-agent[1219]: Finished catalog run in 73.61
seconds
So the order of operations appears correct, but the refresh of
Service['snmpd'] doesn't seem to take. I see a couple of plausible
explanations:
- The snmpd service is already running when Puppet tries to refresh it,
but Puppet thinks it's stopped. Puppet therefore issues the 'start'
command to the initscript, which typically does nothing if the service is
already running. I'd put my bet here.
- The initscript 'start' command returns an exit code indicating
success, even though it failed to start the service for some unknown
reason.
Let's focus now on the service declaration:
puppet-1.dev.jj.com:/etc/puppet/modules/snmp/manifests/service.pp
class snmp::service {
service { $snmp::params::snmp_service_name:
ensure = running,
hasstatus = true,
hasrestart = true,
Those 'hasstatus' and 'hasrestart' declarations tell Puppet that the
service's init script supports the 'restart' and 'status' commands, and
that they return codes at least approximately consistent with those
specified by the LSB. In particular, Puppet pays attention to whether the
those commands' exit codes are zero or nonzero. You should verify that the
'status' command returns 0 if and only if the service is already running,
and that the 'restart' command returns 0 if and only if the service is
successfully (re)started.
# Boot time
enable = true,
require = Class[snmp::config],
That require is mostly redundant, but harmless.
}
}
Overall, the manifests look good, subject to the caveats I already
discussed.
If the problem is
Re: [Puppet Users] Dashboard not working (406 Not Acceptable)
Old thread, but I ran into the same problem so figured I'll post my
solution here. In my case, I added more verbose logging which pointed me to
the missing spool directory. Running the following commands fixed it:
mkdir -p /usr/share/puppet-dashboard/spool
chown puppet-dashboard:puppet-dashboard spool
Regards,
James T.
On Monday, November 21, 2011 2:13:27 PM UTC+1, Galed Friedmann wrote:
Anybody? Any ideas?
Thanks again
On Sun, Nov 13, 2011 at 2:45 PM, Galed Friedmann
galed.friedm...@onavo.com wrote:
Hi all,
I've created a replication of my puppet environment in order to set it up
in a new location.
I've created an exact replication of my master server which is running
the puppet master, dashboard server, and mysql.
Everything is working fine except for the dashboard. The master is
configured to send reports to dashboard and indeed is sending them, but
looking at production.log in dashboard I see this:
Processing ReportsController#upload (for 127.0.0.1 at 2011-11-13
12:43:26) [POST]
Parameters: {action=upload, controller=reports}
Completed in 1ms (View: 0, DB: 0) | 406 Not Acceptable [
http://localhost/reports/upload]
For every attempt of the master to send a report.
This is a working configuration so I guess I missed something when I
changed the setting of the new server, any idea what might be wrong here?
puppet master configuration:
[master]
storeconfigs = true
dbadapter = mysql
dbuser = ...
dbpassword = ...
dbserver = localhost
dbsocket = /var/run/mysqld/mysqld.sock
reports = store, http
reporturl = http://localhost:3000/reports/upload
Thanks!
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/mGPKjqlxWY0J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, 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 view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/EG58eV8AwFEJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Reducing system load
On Wednesday, June 20, 2012 1:50:38 PM UTC-5, IndyMichaelB wrote: puppet kick from your master after you make a change Combining normal agent behavior with periodic kicks would increase the workload of all parties, so I suppose you are suggesting to configure agents to update only when kicked, or perhaps to combine listening for kicks with a much longer run interval. At least half the reason for periodic agent runs is to *maintain* client nodes in the declared state, however, regardless of whether manifests have changed on the master. Relying exclusively on kicks would give up that state maintenance, and lengthening the run interval would increase the window in which misconfiguration of managed resources can persist. These may be acceptable tradeoffs for some, but given that the OP is already using an unusually short run interval, I would guess that they are not acceptable for him. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/L5nc8RpjOYwJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Could not run Puppet configuration client: execution expired
On Wednesday, June 20, 2012 9:52:21 AM UTC-5, Kmbu wrote: [...] I'm already running apache/passenger. Is there anything else I can do? It is suspicious that you say you are using passenger, but the workload is not being spread over both CPUs. Make sure your clients are accessing the puppetmaster via apache, and not some standalone puppetmaster. One way to do that is to make sure no standalone puppetmaster is running in the first place (passenger will start its own puppetmaster instances as needed). In any case, the logs should reveal what master process is servicing your clients. If all your clients are indeed going through apache, then perhaps you have a configuration problem on the apache / passenger side. You will find a lot of advice on it in this group and elsewhere. Or maybe RAM is your limiting resource. Throughput will really tank when the master(s) run out of physical RAM and start swapping to disk, and all that I/O could lead to CPU idle time that you wouldn't otherwise see. Once you get both CPUs loaded up, the next level of scaling is higher-capacity hardware, load balancing across multiple masters, or both. Just two cores is pretty wimpy these days, so I'd look first at moving to better hardware. Is the master running in a VM? In that case there might be some improvement available from running it directly on a physical machine, or else it should be easy to assign more cores and / or more RAM to it. Alternatively, you can accommodate more clients by reducing the work required to support each one. Some ways to do that are - lengthening the interval between agent runs - minimizing the number of managed resources - using a lighter-weight checksum method (md5lite, mtime, etc.) for managed File content Whether any of those are viable depends on your requirements for nodes. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/zhcD91teLgwJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, 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] Problem dealing with multi role servers/manifests. resource already declared.
Sounds good, not the way I was hoping to have to do it.. but that will work. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/Ld0sFBSIFnwJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, 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] Problem dealing with multi role servers/manifests. resource already declared.
Actually, one more question to spawn off this... Is there a way in my nagios/repo class to say if you have this class go ahead and assign yourself to my new services:httpd class? Can that be done with inheritance? I have never used inheritance so I am not sure. On Thursday, June 21, 2012 9:01:24 AM UTC-5, trey85stang wrote: Sounds good, not the way I was hoping to have to do it.. but that will work. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/8-pcqQeLB4sJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, 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] Problem using subversion module
Agreed, I'm puzzled why it's not named thus in the upstream module. Perhaps it's only suitable for specific puppet versions? Okay, good enough for me :) So the standard practice then would be to fully-qualify all classes, definitions and types declared within modules? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/6VVMkTwe7tIJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Could not run Puppet configuration client: execution expired
I'm going to admit I don't have the best setup here! :) There are things I want to do to improve what I have now, just need to get room on the plate to do it. Right now my 'CA PM' is also a PM for the other PMs ... :-\ So my PMs that are behind HAproxy have a puppet::master class assigned to them and have their modules directory as a managed resource and are force to have in puppet.conf server='CA PM' instead of the VIP I used for everything else. This then gets updated from the 'CA PM'. Basically I deploy updates to a special dir on my 'CA PM' and then all my other PM will receive the updates from there. This works for us although like I said I want to make it better, doing what you assumed I am doing ... shared storage. But since we can only make changes with a CHG ticket I basically make the update and then force a puppet run on my PMs (remote execution) and everything is updated in like 5 minutes. This is done during a time when the rest of the environment is not accessing the PMs. But yes, the way I am doing it now could cause issues. If I updated on my CA PM and then didn't follow up on my other PMs they could get out of sync. Then when an agent is accessing the VIP it would go to perhaps an updated PM initially and throughout the puppet run go between different nodes, some potentially updated others not and could cause issues. The only other issue I've ran into is if apache on a PM restarts or a PM restarts while agents are accessing it sometimes I'll get failed runs. Out of 4800+ systems this usually amounts to like ~200 failures until the next batch of runs (every 30 minutes here) which clears it up (even if apache/node still down). I'm not sure if this is a limitation of something I am doing, or if its just to be expected. Before using haproxy I had a VIP in DNS that would round robin between systems. Doing that I would get like ~1000 failures under such a situation as DNS doesn't know when a node goes down, and that would continue until everything was back up. So since what I have isn't bullet proof I don't have anything documented ... but eventually ... :) Regards, Jake -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/NBICiQ3H0TwJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Could not run Puppet configuration client: execution expired
On Thursday, 21 June 2012 15:54:59 UTC+2, jcbollinger wrote: On Wednesday, June 20, 2012 9:52:21 AM UTC-5, Kmbu wrote: [...] I'm already running apache/passenger. Is there anything else I can do? It is suspicious that you say you are using passenger, but the workload is not being spread over both CPUs. Make sure your clients are accessing the puppetmaster via apache, and not some standalone puppetmaster. One way to do that is to make sure no standalone puppetmaster is running in the first place (passenger will start its own puppetmaster instances as needed). In any case, the logs should reveal what master process is servicing your clients. If all your clients are indeed going through apache, then perhaps you have a configuration problem on the apache / passenger side. You will find a lot of advice on it in this group and elsewhere. Or maybe RAM is your limiting resource. Throughput will really tank when the master(s) run out of physical RAM and start swapping to disk, and all that I/O could lead to CPU idle time that you wouldn't otherwise see. Once you get both CPUs loaded up, the next level of scaling is higher-capacity hardware, load balancing across multiple masters, or both. Just two cores is pretty wimpy these days, so I'd look first at moving to better hardware. Is the master running in a VM? In that case there might be some improvement available from running it directly on a physical machine, or else it should be easy to assign more cores and / or more RAM to it. Alternatively, you can accommodate more clients by reducing the work required to support each one. Some ways to do that are - lengthening the interval between agent runs - minimizing the number of managed resources - using a lighter-weight checksum method (md5lite, mtime, etc.) for managed File content Whether any of those are viable depends on your requirements for nodes. John Wow! I think you're right. I've set up Apache/Passenger but I use it for Dashboard, not the puppetmaster itself :-) Let me see if I can push my luck. Is there a quick guide to moving Puppet to Passenger when Apache/Passenger are already in place? Thanks a bunch, John. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/3uTFBRCugLMJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Reducing system load
Some thoughts from our similar environment: 1. Puppet client runs are like bugs and a light, they will tend to cluster together. If some client runs are slow, other clients wait, over time, they all end up trying to run at the same time. This was easily observed on the foreman run distribution over the last 30 minutes We solved by restarting the client puppet service weekly and using the splay option. 2. Some resources types use more CPU than others, I've observed anything using yum (ensure latest for example) and recursive directories of course. 3. Foreman report metrics is a good tool, I just looked at a few of my systems and config_retrieval is about 50% of the ET on the systems sampled. 4. Are modifications happening? Sometimes a class will re-do each puppet run. Those need to be fixed. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Reducing system load
- Original Message - From: Len Rugen lenru...@gmail.com To: puppet-users@googlegroups.com Sent: Thursday, June 21, 2012 5:02:37 PM Subject: Re: [Puppet Users] Re: Reducing system load Some thoughts from our similar environment: 1. Puppet client runs are like bugs and a light, they will tend to cluster together. If some client runs are slow, other clients wait, over time, they all end up trying to run at the same time. This was easily observed on the foreman run distribution over the last 30 minutes We solved by restarting the client puppet service weekly and using the splay option. is this really still happening? I thought that got fixed ages ago -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, 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] keeping local accounts up to date
On Thu, Jun 21, 2012 at 02:29:50AM -0700, Marshie8 wrote: Hi guys, Just started to look at Puppet. Is there a way I can have a user log into a Puppet Server box, and change their own password? Wondered if there was a script out there already that monitored for changes to the /etc/passwd and /etc/shadow entry for the user and extract the string to populate it to all Puppet clients. We plan to implement LDAP but that's a little way off, I just need an easy way in the meantime to keep my clients up to date with local accounts. Thanks Mark This could be done by having a custom fact that exports the value of the hash back to the master, but this would be best only running on one single box, which would be the 'password changing box'. IMO, passing hashes around like this would not be a great idea from a security perspective, nor particularly scalable. Something along the lines of https://github.com/crayfishx/hiera-gpg and a script to make usage of GPG's multi-key encryption may be better - where the YAML file for a user definition that contains the hash is encrypted both with both hiera's key and the users GPG key, thus allowing for users to set their password, and for hiera to decrypt the hash, but you may find that your time is better spent getting LDAP up and running.. Dependent on how your infrastructure is setup, and where/how you're actually using passwords, it may be better to make use of SSH keys (which puppet can manage) and set local user accounts on servers to random, unknown passwords that are never actually used. See http://docs.puppetlabs.com/references/2.7.0/type.html#user for more infos on the user type. Cheers, -- Richard Clark rich...@fohnet.co.uk -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, 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 on unsupported platform
Sorry if this is documented somewhere, couldn't find it... Just wondering how an agent behaves if it's unsupported (ie, not in the supported platforms list)? I'm hoping to use Puppet to manage some embedded/custom Linux routers. With it, I just need to ensure files are on them, cron entries, maybe manage users. Will Puppet work if it detects the platform isn't supported or does it have some default behaviour for generic Linux? Thank you -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/csW6gfm2p40J. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, 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 Windows: scheduled_task : TypeError
Hi Greg,
I believe this is issue https://projects.puppetlabs.com/issues/13008, which
I have fixed in my topic branch and is awaiting to be merged into 2.7.x. It
would be great if you could try it out and let me know how it goes.
Josh
On Thu, Jun 21, 2012 at 9:00 AM, Greg Swift gregsw...@gmail.com wrote:
Mohamed,
Did you get anywhere with this? I'm running into the exact same issue.
-greg
On Wednesday, November 23, 2011 7:29:34 PM UTC-6, Jacob Helwig wrote:
On 2011-11-23 15:53 , Mohamed Lrhazi wrote:
Thanks JacobDid that answer my TypeError as well?
No, a stack trace would help for that.
--
Jacob Helwig
http://about.me/jhelwig
Mohamed.
On Wed, Nov 23, 2011 at 5:28 PM, Jacob Helwig wrote:
On 2011-11-23 13:02 , Mohamed Lrhazi wrote:
am trying this:
scheduled_task { 'Puppet Run':
ensure= present,
enabled = true,
command = 'C:\\ruby187\\bin\\puppet.bat'**,
arguments = 'agent --verbose --logdest C:\\Temp\puppet.log',
trigger = {
schedule = daily,
#every = 2 # Defaults to 1
#start_date = '2011-08-31', # Defaults to 'today'
start_time = '16:00', # Must be specified
}
}
And getting this error:
err: /Stage[main]/Gu_splunk/**Scheduled_task[Puppet Run]/ensure:
change
from absent to present failed: Could not set 'present on ensure:
TypeError at /etc/puppet/
environments/windows/modules/**gu_splunk/manifests/init.pp:84
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/cIrGZR2XNjYJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
Josh Cooper
Developer, Puppet Labs
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: keeping local accounts up to date
On Thursday, June 21, 2012 4:29:50 AM UTC-5, Marshie8 wrote: Hi guys, Just started to look at Puppet. Is there a way I can have a user log into a Puppet Server box, and change their own password? Wondered if there was a script out there already that monitored for changes to the /etc/passwd and /etc/shadow entry for the user and extract the string to populate it to all Puppet clients. If the machines of interest are all similar, and if users are going to be able to log in to the machine running the puppetmaster process, then it shouldn't be too hard to persuade Puppet to synchronize the master's account database (e.g. files /etc/passwd and /etc/shadow) with clients. Note, however, that doing so may require giving the puppetmaster process read access to files that ordinarily would be inaccessible to it, such as /etc/shadow. Also, I wouldn't consider it a good idea to allow user logins on the puppetmaster machine, much less to build a solution based on *all*users being able to log in to it. As an alternative, and supposing you don't have to worry about Windows clients, you could consider deploying NIS. It's pretty easy to set up, and I don't know any Unix without at least some support, including OS X. NIS has server-side support for processing password changes, too, and at least Solaris and some Linux distros (such as RedHat / Fedora) have the client-side pieces needed for that as well. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/0qsh1-CJXpUJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, 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] Facter facts updated at start of puppet run only?
Hi all, I use a custom fact to determine and build custom reports on the version of certain packages on a system. If the package is updated, the fact is not updated during that run, falsely reporting the previous version until the next puppet run. Is there a way to make facter facts update at the end of a puppet run? Or is there something else I might be overlooking? Let me know if any additional info is needed. Thanks, Zach -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/oJbJlDMx254J. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, 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 the Puppet type user
My question is about using
resources { 'user':
purge = true,
}
On http://docs.puppetlabs.com/references/stable/type.html#resources it mentions
a parameter unless_system_user :
This keeps system users from being purged. By default, it does not purge
users
whose UIDs are less than or equal to 500, but you can specify a different
UID
as the inclusive limit. Valid values are true, false. Values can match
/^\d+$/.
Are the following examples valid ? !! with the understanding that only ONE
would be used !!
# the first two are obvious, but I prefer to have the examples
resources { 'user':
purge = true,
unless_system_user = false,
}
resources { 'user':
purge = true,
unless_system_user = true,
}
# this is the REAL question
resources { 'user':
purge = true,
unless_system_user = '1000',
}
“Sometimes I think the surest sign that intelligent life exists elsewhere in
the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin Hobbes)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Reducing system load
Hopefully, in the future, this feature will be added and you can determine what is taking the longest. http://projects.puppetlabs.com/issues/2576 -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/_3_hdaObcScJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, 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] Running inherited node manifest first
Hi, What is the best way to ensure that when a node inherits another node, that the inherited node's manifest runs first? Is there was a to ensure this happens? Thanks, Guy -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/UCHxRp5AUtgJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Custom facts and hyphens
On Wednesday, June 20, 2012 8:02:26 PM UTC-5, Steph wrote: I've not given it too much thought but I do have sympathy for argument that divergence of (some of) Puppet's logical representations and their labels from what's extant on the system reduces clarity and could introduce error. I'm not talking about class names nor packages really (there are already restrictions there for things like camelCase IIRC) but lower down it gets more murky. Service names (i.e. init scripts et al.) are *almost* an example as they're vendor controlled but ultimately I can't think of a case where you'd use them as variables. It was because of OS idiocy that I had to follow the symlinks for /dev/disk/by-path/xen-vbd-* in a custom fact, but I have no control over what those files are called. Having to munge the result of that file lookup with underscores and then call it as $::xen_vbd_2049 (or whatever) does feel icky because it's a mental hoop to jump through: the fact no-longer absolutely matches the name of the symlink. This is just a special case of a wider problem. Pretty much any character can appear in a Unix file name, but a lot of them (and combinations of them) cannot appear in Puppet variable names. Space characters are an especially good and not altogether uncommon example. Hypothetically, double-colons are another example, though I've never seen them in a file name. It's not reasonable to suppose that you should be able to make variable names exactly match file names, unless you're in control of the file names. The more I think about it having to do the rename in facter doesn't seem great to me either as it seems to me it puts the logic in the wrong place. Taking the approach you chose as given, Facter seems to me exactly the right place: as the data intermediary between nodes and the puppetmaster, it's Facter's job to package node data into a form that the master can digest. What I think is odd is the choice to use file names as variable names in the first place. Compatibility problems aside, it doesn't seem to me that file names would meet my personal expectations for abstraction and comprehensibility. The style guide does explicitly say to not use dashes but if hyphens in variables are a no-no it may be worth explicitly saying so in the Variables section of language guide, and putting it in big red letters in the Reserved Words section so that idiots like don't miss it first time ;) I fully agree there. The language guide should be specific about the allowed form of variable names, including, but not limited to, the fact that variable names must not contain hyphens. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/qaNjA9H0EykJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, 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 Windows: scheduled_task : TypeError
So.. now I'm getting your error instead of mine.
On Thursday, June 21, 2012 12:46:08 PM UTC-5, Greg Swift wrote:
I believe you are correct. I removed the arguments key/value pair and it
ran fine. I'm patching in your changes to try it with the arguments option.
thank you very much
On Thursday, June 21, 2012 11:53:40 AM UTC-5, Josh Cooper wrote:
Hi Greg,
I believe this is issue https://projects.puppetlabs.com/issues/13008,
which I have fixed in my topic branch and is awaiting to be merged into
2.7.x. It would be great if you could try it out and let me know how it
goes.
Josh
On Thu, Jun 21, 2012 at 9:00 AM, Greg Swift wrote:
Mohamed,
Did you get anywhere with this? I'm running into the exact same issue.
-greg
On Wednesday, November 23, 2011 7:29:34 PM UTC-6, Jacob Helwig wrote:
On 2011-11-23 15:53 , Mohamed Lrhazi wrote:
Thanks JacobDid that answer my TypeError as well?
No, a stack trace would help for that.
--
Jacob Helwig
http://about.me/jhelwig
Mohamed.
On Wed, Nov 23, 2011 at 5:28 PM, Jacob Helwig wrote:
On 2011-11-23 13:02 , Mohamed Lrhazi wrote:
am trying this:
scheduled_task { 'Puppet Run':
ensure= present,
enabled = true,
command = 'C:\\ruby187\\bin\\puppet.bat'**,
arguments = 'agent --verbose --logdest
C:\\Temp\puppet.log',
trigger = {
schedule = daily,
#every = 2 # Defaults to 1
#start_date = '2011-08-31', # Defaults to 'today'
start_time = '16:00', # Must be specified
}
}
And getting this error:
err: /Stage[main]/Gu_splunk/**Scheduled_task[Puppet Run]/ensure:
change
from absent to present failed: Could not set 'present on ensure:
TypeError at /etc/puppet/
environments/windows/modules/**gu_splunk/manifests/init.pp:84
--
You received this message because you are subscribed to the Google
Groups Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/cIrGZR2XNjYJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
Josh Cooper
Developer, Puppet Labs
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/CG9Sa5hf2jYJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, 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] Gentoo package provider
Hi,
I recently looked at the gentoo package provider and I think it has a
few problems and I'm interested in how gentoo people tackle these
problems:
1) The package provider puts a dependency on eix. While chances are good
that eix is installed it is not part of the base system (AFAIK).
Puppet will not immediatly fail though. If you have e.g. ruby
installed you might ask yourself why puppet tries to install
app-editors/vim with the gem provider.
2) The package provider makes a few assumption where the eix cache is
stored and about PORTDIR beeing /usr/portage. A while ago I saw a
discussion on gentoo-users were multiple people said they place
there portagetree in /var/portage
3) Packagenames are not unique in gentoo. While you can e.g. specify
package { 'rubygems':
ensure = latest,
category = 'dev-ruby',
}
this still seems to confuse puppet (in my case puppet wants to update
the package saying the installed version is 1.8.24 [which is true] and
the latest version beeing 4 (which is the latest version of
virtual/rubygems, not dev-ruby/rubygems).
To be on the safe side you really have to specify
package { 'dev-ruby/rubygems':
ensure = latest,
}
and ignore the category parameter.
4) running puppet resource package does create resources with only
the packagename, without the category. So you don't see the true result
if you have two packages installed that come from different
categories.
# portageq match / '*/rubygems'
dev-ruby/rubygems-1.8.24
virtual/rubygems-4
# puppet resource package |grep -A 2 rubygems
package { 'rubygems':
ensure = '1.8.24',
}
#
5) The provider sometimes lies which seems to be caused by the --stable
flag which is passed to eix. In my case puppet thinks that tar is not
installed.
# portageq match / tar
app-arch/tar-1.26
# puppet resource package tar
package { 'tar':
ensure = 'absent',
}
So I'd like to change the following:
- query with portageq not with eix, e.g.:
packagelist:
# portageq match / ''
version of a specific package
# portageq match / dev-ruby/rubygems
latest version of a specific package
# portageq best_visible / dev-ruby/rubygems
- drop/deprecate the category parameter
- encourage people to include the category in the resource title
- when using puppet resource package also include the category in the
packagename
In my opinion these changes should fix all the issues above. One issue will
still exists though: You can install multiple versions of the same package
(slots):
# portageq match / autoconf
sys-devel/autoconf-2.13
sys-devel/autoconf-2.69
I don't really now what puppet should return as the current version
here.
I'd love to know what you think about the current portage provider and the
proposed changes.
-Stefan
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, 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 Windows: scheduled_task : TypeError
Can you try running with --trace and --debug, and adding the stack trace to the
ticket?
On Jun 21, 2012, at 10:57 AM, Greg Swift gregsw...@gmail.com wrote:
So.. now I'm getting your error instead of mine.
On Thursday, June 21, 2012 12:46:08 PM UTC-5, Greg Swift wrote:
I believe you are correct. I removed the arguments key/value pair and it ran
fine. I'm patching in your changes to try it with the arguments option.
thank you very much
On Thursday, June 21, 2012 11:53:40 AM UTC-5, Josh Cooper wrote:
Hi Greg,
I believe this is issue https://projects.puppetlabs.com/issues/13008, which I
have fixed in my topic branch and is awaiting to be merged into 2.7.x. It
would be great if you could try it out and let me know how it goes.
Josh
On Thu, Jun 21, 2012 at 9:00 AM, Greg Swift wrote:
Mohamed,
Did you get anywhere with this? I'm running into the exact same issue.
-greg
On Wednesday, November 23, 2011 7:29:34 PM UTC-6, Jacob Helwig wrote:
On 2011-11-23 15:53 , Mohamed Lrhazi wrote:
Thanks JacobDid that answer my TypeError as well?
No, a stack trace would help for that.
--
Jacob Helwig
http://about.me/jhelwig
Mohamed.
On Wed, Nov 23, 2011 at 5:28 PM, Jacob Helwig wrote:
On 2011-11-23 13:02 , Mohamed Lrhazi wrote:
am trying this:
scheduled_task { 'Puppet Run':
ensure= present,
enabled = true,
command = 'C:\\ruby187\\bin\\puppet.bat',
arguments = 'agent --verbose --logdest C:\\Temp\puppet.log',
trigger = {
schedule = daily,
#every = 2 # Defaults to 1
#start_date = '2011-08-31', # Defaults to 'today'
start_time = '16:00', # Must be specified
}
}
And getting this error:
err: /Stage[main]/Gu_splunk/Scheduled_task[Puppet Run]/ensure: change
from absent to present failed: Could not set 'present on ensure:
TypeError at /etc/puppet/
environments/windows/modules/gu_splunk/manifests/init.pp:84
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/cIrGZR2XNjYJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
Josh Cooper
Developer, Puppet Labs
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/CG9Sa5hf2jYJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, 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] Custom facts and hyphens
On Jun 21, 2012, at 2:18 AM, Felix Frank wrote: On 06/21/2012 12:30 AM, Jo Rhett wrote: I'm not saying that you're wrong, but I'm still struggling to see this. Every place that class names are used should be single quoted, according to your style guide. And it's very easy in a syntax to tell the different between 'test-jo + 2' and 'test - jo + 2'. Those are not ambiguous. I beg to differ: $value = 1 $value-2 = 2 $sum = $value-2 +2 I don't see the problem. Those aren't ambiguous for a parser properly configured. $sum = 4. The limitation seems consistent with the PHP-like syntax, though (is it heresy to say this?;) No, because php prefers camelCase, and that explicitly won't work in puppet. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Running inherited node manifest first
On Thursday, June 21, 2012 12:38:14 PM UTC-5, Guy Knights wrote: What is the best way to ensure that when a node inherits another node, that the inherited node's manifest runs first? Is there was a to ensure this happens? In principle, the leaf node can declare relationships between all the classes it declares and all those declared by the inherited node. In practice, you probably don't want that, because you'll end up with dependency cycles unless you're either very careful or very lucky. It's also hard to maintain. All that underscores the fact that you're thinking about the problem the wrong way. Whether one resource needs to be applied before another is a function only of those resources, not of which node declaration caused them to be added to the catalog. Set up appropriate relationships between your resources, and Puppet will find an agreeable order in which to apply them. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/Z1aEid4PCYgJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, 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: Managing the Puppet type user
On Thursday, June 21, 2012 12:32:29 PM UTC-5, Ygor wrote:
Are the following examples valid ? !! with the understanding that only
ONE would be used !!
# the first two are obvious, but I prefer to have the examples
resources { 'user':
purge = true,
unless_system_user = false,
}
That looks valid. It declares that *all* unmanaged users should be purged.
resources { 'user':
purge = true,
unless_system_user = true,
}
That also looks valid. It declares that all unmanaged users whose UIDs are
at least 501 should be purged.
# this is the REAL question
resources { 'user':
purge = true,
unless_system_user = '1000',
}
And that looks valid, too. It declares that all unmanaged users whose UIDs
are at least 1001 should be purged.
Resource purging can be useful, but it is also dangerous. I urge you to
test carefully.
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/IpW3GmZE-b0J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Puppet on unsupported platform
On Thursday, June 21, 2012 11:16:33 AM UTC-5, Brendan wrote:
Sorry if this is documented somewhere, couldn't find it...
Just wondering how an agent behaves if it's unsupported (ie, not in the
supported platforms list)?
It depends on how similar the system is to anything Puppet knows about.
The Puppet agent adapts dynamically to the node on which it runs, based to
a significant extent on the tools it finds available.
I'm hoping to use Puppet to manage some embedded/custom Linux routers.
With it, I just need to ensure files are on them, cron entries, maybe
manage users.
Puppet should have no problem managing files on such systems. It probably
will be able to manage cron entries and maybe users out of the box. For
anything it doesn't by default know how to manage on your particular
systems, it is possible to write and automatically distribute plugins
('providers') that teach the agent how to manage particular types of
resources.
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/iVZ8KpxKch0J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Could not run Puppet configuration client: execution expired
On Thursday, June 21, 2012 10:46:51 AM UTC-5, Kmbu wrote: I've set up Apache/Passenger but I use it for Dashboard, not the puppetmaster itself :-) Let me see if I can push my luck. Is there a quick guide to moving Puppet to Passenger when Apache/Passenger are already in place? As far as I know, there isn't much special to distinguish that case. The first step in performing a Puppet / passenger installation is to get the puppetmaster running standalone, and the next is to get Apache / passenger installed. It sounds like you're ready to move on from there. Google can help you find some docs on the Puppetlabs site, but they're a bit dated. As an alternative, this looks like a pretty good description of the whole process: http://www.tomhayman.co.uk/linux/install-puppet-modpassenger-mysql-stored-procs-centos-6-rhel6/ (don't overlook parts 2 and 3 of that series, where you'll find most of the details of interest to you at this point). John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/jwls3UufxVYJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] facter plugin requires cause catalog failure, prevent setting up new clients
On Jun 21, 2012, at 12:55 PM, Ramin K wrote: Surprised no one has mentioned this, but anything you can set in puppet.conf can be passed on the command line. Adding --pluginsync to whatever Puppet first run command you use solves the problem, no? And pluginsource too. Gets a bit unweildy. I'm still trying to figure out how I did the bootstrap environment to shorten the catalog at a previous shop. Memory fail. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Problem dealing with multi role servers/manifests. resource already declared.
On Thursday, June 21, 2012 7:24:59 AM UTC-7, trey85stang wrote: Actually, one more question to spawn off this... Is there a way in my nagios/repo class to say if you have this class go ahead and assign yourself to my new services:httpd class? Can that be done with inheritance? I have never used inheritance so I am not sure. You shouldn't need inheritance -- you can do this with plain old include services::httpd. Unlike when you declare a resource, include can be safely used multiple times on a single class, pretty much for this exact reason. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/uZe07BASzP4J. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Correct way to handle node-specific variable values in puppet 2.7
On Wednesday, June 20, 2012 6:00:04 AM UTC-7, jcbollinger wrote:
- oh, and don't ever use node inheritance.
Why not? I mean, is that just to avoid the known issues with dynamic
scope, or does node inheritance introduce special problems in this
context?
Well... because inevitably, everyone always wants to try this:
node 'base' {
$ntpserver = 0.pool.ntp.org
include ntp
}
node 'special' inherits 'base' {
$ntpserver = ntp.local.example.com
}
See how dynamic scope is being perfectly well-behaved here, but it still
does the exact opposite of what they were hoping for? :[ The underlying
model of how node defs work is corrupt -- we just copied the logic we use
for classes, and it was a bad match for that problem space.
I think I'm convinced now that the long-term answer is to gradually replace
node definitions with something better but just as easy to get started
with. And we're moving in that direction, especially now that we have hiera
baked in. In the meantime... awkward stage.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/QMwONSlnGBoJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
