Re: [Puppet Users] locking puppet runs
On 09/05/14 20:33, jcbollinger wrote: On Thursday, May 8, 2014 8:58:52 AM UTC-5, Dirk Heinrichs wrote: Am 08.05.2014 15:34, schrieb Jonathan Gazeley: I suppose it would be possible to disable the agent from running as a daemon and use cron, and the cron job could easily use a MySQL handle as a locking device. But it still doesn't stop me from simply sshing to each of the nodes and forcing a puppet run, and breaking the cluster. Has anyone done anything like this before? Hope to have some interesting ideas from you all :) You could 1. enable splay on the client node No, that would at best be unhelpful. Splay well tend to spread out the client load seen by the master over time, but it contributes nothing to avoiding runs on specific clients coinciding. In fact, it might increase the likelihood of /specific/ pairs (or triples) of clients' runs coinciding. Yes, I read about the splay option and it seems like it wouldn't help in this case. 1. use mcollective to orchestrate the agent runs. For example: Update config file on all MariaDB servers, but only one at a time. That, on the other hand, could be just the ticket, provided that it is acceptable to run the agent only via that mechanism (which itself could perhaps be triggered via cron to give automation). Even that, however, would not actively prevent client runs from coinciding if someone manually ran the agent on one of the sensitive systems. We are in the very early stages of looking at what MCollective can do for us. It looks promising but at the time of writing we have basically zero experience with it :) Consider this, however: puppet already employs a lock file to prevent multiple catalog runs from overlapping on the same system. What Jonathan asks is simply an extension of that mechanism. It could be achieved relatively easily if the systems in question shared the same lock file, and it turns out that the lock file name and location are configurable http://docs.puppetlabs.com/references/latest/configuration.html#agentcatalogrunlockfile. If the configured location where on a shared filesystem accessible to all the machines involved then I think the requested behavior would fall out pretty naturally. This crossed my mind. NFS-mounted lock files seem like a disaster waiting to happen, though. I suppose the puppetmaster could host the NFS share and then if the puppetmaster or the network is down, the node wouldn't have been able to check in anyway. I was also wondering if PuppetDB could be used for this way, or even a general purpose database with lock rows. Note, however, that nothing is foolproof. A sufficiently authorized person could still override the lock file (simply by deleting it, for example) to allow multiple catalog runs to proceed simultaneously. At some point you just have to decide that your safeguards are good enough. Indeed. There are only two of us that work full-time on puppet infrastructure and neither of us would delete a lock file without good reason. It just has to prevent accidentally starting a run by mistake, or cron/puppetd starting a run automatically. There's a lot to be said for good enough in the world of IT operations. Cheers, Jonathan John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com mailto:puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/3f93cc53-c867-4976-b071-b7ce5838417c%40googlegroups.com https://groups.google.com/d/msgid/puppet-users/3f93cc53-c867-4976-b071-b7ce5838417c%40googlegroups.com?utm_medium=emailutm_source=footer. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/53708C9D.3090404%40bristol.ac.uk. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: Serious performance issues with Puppet 3.5.x when using Directory Environments
Hi Josh, hi all, So, I have set the environment_timeout setting to a couple of test values, including 30s, 1h and unlimited: - *30s* - No performance boost. Too short for me, my Puppet runs are distributed every 37s - *1h* - Very good results, fast config retrieval, even slighly better than with config-based environments - *unlimited* - same as above Regarding performance issues please ignore my previous message, I had some other troubles in my vSphere environment which caused these CPU and memory peaks. *My Puppet master behaves in a very stable way now*. Cheers, -- Toni -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/7ed02dd8-8dfe-4ea2-bcc1-d864132aa761%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Is --noop supposed to override noop param?
Hi,
I had an issue with my --noop run actually overwriting files on machine
it is run on.
After looking into it, I found that some of my modules have 'noop' param
on resources. For example:
class something ( $noops = false ) {
file { '/etc/something':
noop = $noops,
}
}
After running 'puppet agent -t --verbose --noop', /etc/something gets
overwritten.
Is this supposed to happen, or is it a bug? If this is intended
behaviour then I have to remove all noop parameters from my resources...
PS. This was observed with puppet 3.5.1 on ubuntu 12.04.
--
You received this message because you are subscribed to the Google Groups Puppet
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/5370C0AB.9070506%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] using ruby dsl in puppet manifest
On Saturday, May 10, 2014 7:49:18 PM UTC-5, Ritesh Nanda wrote: Hello John, Thanks for your reply , ruby code i was trying to run was on client , so i am doing with inline_template right now , yeah but your idea seems good to have a plugin to do it . A plugin or an Exec is the *only* place to do it. As I wrote, templates are evaluated on the master, so *inline_template() will not do what you want*. If your code must run on the agent then it must be in a custom fact or in the provider of a custom type, it must be run via an Exec resource. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/753fb5f8-0394-4be7-9a64-9d2a8fcc6ecf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Is --noop supposed to override noop param?
I get the same behaviour in 3.4.3, however:
The noop setting allows you to globally enable or disable noop mode, but it
will not override the noop metaparameter on individual resources.
http://docs.puppetlabs.com/references/latest/metaparameter.html#noop
No-op being false means that yes-op is (metaphorically) true, right? It looks
like your module writer thinks that --noop should never override this resource.
On Mon, May 12, 2014 at 02:38:03PM +0200, Jakov Sosic wrote:
Hi,
I had an issue with my --noop run actually overwriting files on
machine it is run on.
After looking into it, I found that some of my modules have 'noop'
param on resources. For example:
class something ( $noops = false ) {
file { '/etc/something':
noop = $noops,
}
}
After running 'puppet agent -t --verbose --noop', /etc/something
gets overwritten.
Is this supposed to happen, or is it a bug? If this is intended
behaviour then I have to remove all noop parameters from my
resources...
PS. This was observed with puppet 3.5.1 on ubuntu 12.04.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an
email to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/5370C0AB.9070506%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/20140512131619.GA9701%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Chocolatey Powerhshell not working with 32 bit puppet agent
I have updated chocolateyinstall.ps1 in my chocolatey package to perform some steps at the time of installation. It works fine when I run it on a 64 bit command prompt. But, when i run it from puppet its not working. I'm pretty sure its got to do with the puppet agent running on 32 bit. The modules that I'm using in the chocolateyinstall.ps1 are not available on the 32 bit command. Just wondering if anyone faced similar issues? Would I end up creating separate packages for 32 bit and 64 bit ? Cheers, Gobin -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/6ce5e7ea-bc7b-4f51-aa1f-1441ac9313dd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] locking puppet runs
On Monday, May 12, 2014 3:55:57 AM UTC-5, Jonathan Gazeley wrote: On 09/05/14 20:33, jcbollinger wrote: On Thursday, May 8, 2014 8:58:52 AM UTC-5, Dirk Heinrichs wrote: Am 08.05.2014 15:34, schrieb Jonathan Gazeley: I suppose it would be possible to disable the agent from running as a daemon and use cron, and the cron job could easily use a MySQL handle as a locking device. But it still doesn't stop me from simply sshing to each of the nodes and forcing a puppet run, and breaking the cluster. Has anyone done anything like this before? Hope to have some interesting ideas from you all :) You could 1. enable splay on the client node No, that would at best be unhelpful. Splay well tend to spread out the client load seen by the master over time, but it contributes nothing to avoiding runs on specific clients coinciding. In fact, it might increase the likelihood of *specific* pairs (or triples) of clients' runs coinciding. Yes, I read about the splay option and it seems like it wouldn't help in this case. 1. use mcollective to orchestrate the agent runs. For example: Update config file on all MariaDB servers, but only one at a time. That, on the other hand, could be just the ticket, provided that it is acceptable to run the agent only via that mechanism (which itself could perhaps be triggered via cron to give automation). Even that, however, would not actively prevent client runs from coinciding if someone manually ran the agent on one of the sensitive systems. We are in the very early stages of looking at what MCollective can do for us. It looks promising but at the time of writing we have basically zero experience with it :) Consider this, however: puppet already employs a lock file to prevent multiple catalog runs from overlapping on the same system. What Jonathan asks is simply an extension of that mechanism. It could be achieved relatively easily if the systems in question shared the same lock file, and it turns out that the lock file name and location are configurablehttp://docs.puppetlabs.com/references/latest/configuration.html#agentcatalogrunlockfile. If the configured location where on a shared filesystem accessible to all the machines involved then I think the requested behavior would fall out pretty naturally. This crossed my mind. NFS-mounted lock files seem like a disaster waiting to happen, though. I suppose the puppetmaster could host the NFS share and then if the puppetmaster or the network is down, the node wouldn't have been able to check in anyway. I was also wondering if PuppetDB could be used for this way, or even a general purpose database with lock rows. Note, however, that nothing is foolproof. A sufficiently authorized person could still override the lock file (simply by deleting it, for example) to allow multiple catalog runs to proceed simultaneously. At some point you just have to decide that your safeguards are good enough. Indeed. There are only two of us that work full-time on puppet infrastructure and neither of us would delete a lock file without good reason. It just has to prevent accidentally starting a run by mistake, or cron/puppetd starting a run automatically. There's a lot to be said for good enough in the world of IT operations. Cheers, Jonathan John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com javascript:. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/3f93cc53-c867-4976-b071-b7ce5838417c%40googlegroups.comhttps://groups.google.com/d/msgid/puppet-users/3f93cc53-c867-4976-b071-b7ce5838417c%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/e2cf7652-9a58-4e0c-bc50-cb0407ac9e22%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] locking puppet runs
On Monday, May 12, 2014 3:55:57 AM UTC-5, Jonathan Gazeley wrote: This crossed my mind. NFS-mounted lock files seem like a disaster waiting to happen, though. I suppose the puppetmaster could host the NFS share and then if the puppetmaster or the network is down, the node wouldn't have been able to check in anyway. I was also wondering if PuppetDB could be used for this way, or even a general purpose database with lock rows. For what it's worth, Puppet appears to use straight O_EXCL lockinghttps://github.com/puppetlabs/puppet/blob/fd78c22fe07500dedc254f02389cb0954d7e5540/lib/puppet/util/lockfile.rb, which, indeed, does not work reliably on NFS file systems. It might be amusing to file an RFE ticket for this, but that won't get you a solution in time to serve your present need. I'd be surprised if PuppetDB would serve this purpose. It's an interesting problem. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/f40696ed-5b86-471f-bf49-d4a32663ae7a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] no child process
Occasionally one of my osx servers will fail a puppet run. If I run it again manually it works fine. It happens about once per day. Puppet agent runs every hour. Any Ideas what this means? All I'm doing is writing a string value to a plist file. Here's what the puppet log says in Dashboard. errCould not evaluate: No child processes/Stage[main]/Osx_management::Munki_settings_hq/Mac-defaults[installapplesoftwareupdates]/Exec[defaults write /Library/Preferences/ManagedInstalls InstallAppleSoftwareUpdates -bool 'true']/etc/puppet/modules/macdefaults/manifests/init.pp172014-05-12 10:03 CDTerrCould not evaluate: No child processes/Stage[main]/Reposado::Repo_cat_mav_stable_server_hq/Mac-defaults[sus]/Exec[defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL -string 'http://reposado2.orchard.fruit.com/content/catalogs/others/index-10.9-mountainlion-lion-snowleopard-leopard.merged-1_server.sucatalog'] /etc/puppet/modules/macdefaults/manifests/init.pp172014-05-12 10:03 CDTerrCould not evaluate: No child processes/Stage[main]/Osx_management::Munki_settings_hq/Mac-defaults[softwarerepourl]/Exec[defaults write /Library/Preferences/ManagedInstalls SoftwareRepoURL -string 'http://munkiserver1.orchard.fruit.com/munki_repo'] /etc/puppet/modules/macdefaults/manifests/init.pp172014-05-12 10:03 CDTerrCould not evaluate: No child processes/Stage[main]/Osx_management::Location_hq_main/Mac-defaults[location]/Exec[defaults write /Library/Preferences/com.apple.RemoteDesktop Text3 -string 'HQ_Main_Building']/etc/puppet/modules/macdefaults/manifests/init.pp172014-05-12 10:03 CDTerrCould not evaluate: No child processes /Stage[main]/Osx_management::Cfpropertylist_install/Package[CFPropertyList] /etc/puppet/modules/osx_management/manifests/cfpropertylist_install.pp62014-05-12 10:03 CDTerrCould not evaluate: No child processes/Stage[main]/Osx_management::Munki_settings_hq/Mac-defaults[clientidentifer]/Exec[defaults write /Library/Preferences/ManagedInstalls ClientIdentifier -string 'C07L900PF4MJ']/etc/puppet/modules/macdefaults/manifests/init.pp172014-05-12 10:03 CDT -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/f8e2bbd9-22ae-4d68-b003-b3f7f5cc88e2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: Puppet first run timing out
Any chance you can share what configuration options were non-optimal?
We're having some timeout issues as well on CentOS.
On Thursday, 5 September 2013 14:32:56 UTC-4, Pete Hartman wrote:
Being able to set the timeout long enough gave us enough data to find the
problem.
Our SPARC build of OpenSSL used some configuration options that were,
shall we say, non-optimal :-).
On a corrected OpenSSL build the SPARC times are now in the same ballpark
as the x86 times.
Thanks again for your help Cory.
Pete
On Wednesday, September 4, 2013 6:56:34 PM UTC-5, Cory Stoker wrote:
We have lots of puppet clients on crappy bandwidth that would time out
like this as well. The option we changed to fix this is:
#Specify the timeout to wait for catalog in seconds
configtimeout = 600
The default time is like 60 or 120 secs. Another thing you should do
is check out the logs of the web server if you are using passenger.
You should see a ton of GET requests when you need to sync plugins.
To force your puppet agent to redownload stuff remove the $vardir/lib
directory on the agent.
On Wed, Sep 4, 2013 at 1:48 PM, Pete Hartman pete.h...@gmail.com
wrote:
I'm having a similar problem.
I know for a fact that I am not contending with other agents, because
this
is in a lab environment and none of my agents is scheduled for periodic
runs
(yet).
I have successfully run puppet agent -t first time, signed the cert,
and run
it a second time to pull over stdlib and other modules on agents
running
RHEL 6 and Solaris 10u10 x86.
But I'm getting this timeout on a Solaris 10u10 box running on a T4-1
SPARC
system.
This was my third run:
# date;puppet agent -t;date
Wed Sep 4 14:12:05 CDT 2013
Info: Retrieving plugin
Notice:
/File[/var/lib/puppet/lib/puppet/parser/functions/count.rb]/ensure:
defined content as '{md5}9eb74eccd93e2b3c87fd5ea14e329eba'
Notice:
/File[/var/lib/puppet/lib/puppet/parser/functions/validate_bool.rb]/ensure:
defined content as '{md5}4ddffdf5954b15863d18f392950b88f4'
Notice:
/File[/var/lib/puppet/lib/puppet/parser/functions/get_module_path.rb]/ensure:
defined content as '{md5}d4bf50da25c0b98d26b75354fa1bcc45'
Notice:
/File[/var/lib/puppet/lib/puppet/parser/functions/is_ip_address.rb]/ensure:
defined content as '{md5}a714a736c1560e8739aaacd9030cca00'
Error:
/File[/var/lib/puppet/lib/puppet/parser/functions/is_numeric.rb]/ensure:
change from absent to file failed: execution expired
Error: Could not retrieve plugin: execution expired
Info: Caching catalog for AGENT
Info: Applying configuration version '1378322110'
Notice: Finished catalog run in 0.11 seconds
Wed Sep 4 14:15:58 CDT 2013
Each time I've run it, I get about 10 or so files and then I get
execution
expired.
What I'd really like to see is whether I can increase the expiry
timeout.
Some other details: The master is RHEL 6 on a Sun/Oracle X4800, lots
and
lots of fast cores and memory. I'm using Puppet Open Source. I'm using
passenger. I have no real modules other than some basic forge modules
I've
installed to start out with.
[root@MASTER audit]# cd /etc/puppet/modules
[root@MASTER modules]# ls
apache concat epel firewall inifile passenger puppet puppetdb
ruby
stdlib
I briefly disabled SELinux on the master, but saw no change in
behavior.
I'm certain that the firewall is right because other agents have had no
problems. iptables IS enabled, however.
The master and the agent are on the same subnet, so I don't suspect a
network performance issue directly.
On Solaris, because the vendor supplied OpenSSL is antique and doesn't
include SHA256, we have built our own OpenSSL and our own Ruby using
that
OpenSSL Library. Even though SPARC is a 64 bit architecture, Ruby
seems to
default to a 32 bit build, so we built OpenSSL as 32 bit as well to
match.
I've got an open question to the guy responsible for that to see how
hard it
would be to try to build Ruby as 64 bit, that's likely a next test.
I have not yet run snoop on the communication to see what's going on
the
network side, but as I say I don't really expect the network to be the
problem, between being on the same subnet and success on other systems
with
higher clock speeds.
Any pointers to other possible causes or somewhere I can (even
temporarily)
increase the timeout would be appreciated.
On Thursday, August 8, 2013 8:56:33 AM UTC-5, jcbollinger wrote:
On Wednesday, August 7, 2013 11:46:06 AM UTC-5, Cesar Covarrubias
wrote:
I am already using Passenger. My master is still being minimally
utilized, as I'm just now beginning the deployment process. In terms
of
specs, it is running 4 cores and 8GB of mem and 4GB of swap. During a
run,
Re: [Puppet Users] Re: Puppet first run timing out
I doubt the problem I was referring to would have any impact on
CentOS. The problem was that we were building on SPARC, and had used
compile options that caused the build to go to a lowest common
denominator architecture of SPARC V7, which does not have a lot of
important SPARC V9 assembly instructions for doing block copies and
math. This slowed the crypto routines a LOT.
I suppose there might be some kind of similar behavior under CentOS
with the wrong build options, but I'd be at a complete loss to suggest
what they might be.
On Mon, May 12, 2014 at 10:13 AM, Mathew Winstone
mwinst...@coldfrontlabs.ca wrote:
Any chance you can share what configuration options were non-optimal?
We're having some timeout issues as well on CentOS.
On Thursday, 5 September 2013 14:32:56 UTC-4, Pete Hartman wrote:
Being able to set the timeout long enough gave us enough data to find the
problem.
Our SPARC build of OpenSSL used some configuration options that were,
shall we say, non-optimal :-).
On a corrected OpenSSL build the SPARC times are now in the same ballpark
as the x86 times.
Thanks again for your help Cory.
Pete
On Wednesday, September 4, 2013 6:56:34 PM UTC-5, Cory Stoker wrote:
We have lots of puppet clients on crappy bandwidth that would time out
like this as well. The option we changed to fix this is:
#Specify the timeout to wait for catalog in seconds
configtimeout = 600
The default time is like 60 or 120 secs. Another thing you should do
is check out the logs of the web server if you are using passenger.
You should see a ton of GET requests when you need to sync plugins.
To force your puppet agent to redownload stuff remove the $vardir/lib
directory on the agent.
On Wed, Sep 4, 2013 at 1:48 PM, Pete Hartman pete.h...@gmail.com wrote:
I'm having a similar problem.
I know for a fact that I am not contending with other agents, because
this
is in a lab environment and none of my agents is scheduled for periodic
runs
(yet).
I have successfully run puppet agent -t first time, signed the cert,
and run
it a second time to pull over stdlib and other modules on agents
running
RHEL 6 and Solaris 10u10 x86.
But I'm getting this timeout on a Solaris 10u10 box running on a T4-1
SPARC
system.
This was my third run:
# date;puppet agent -t;date
Wed Sep 4 14:12:05 CDT 2013
Info: Retrieving plugin
Notice:
/File[/var/lib/puppet/lib/puppet/parser/functions/count.rb]/ensure:
defined content as '{md5}9eb74eccd93e2b3c87fd5ea14e329eba'
Notice:
/File[/var/lib/puppet/lib/puppet/parser/functions/validate_bool.rb]/ensure:
defined content as '{md5}4ddffdf5954b15863d18f392950b88f4'
Notice:
/File[/var/lib/puppet/lib/puppet/parser/functions/get_module_path.rb]/ensure:
defined content as '{md5}d4bf50da25c0b98d26b75354fa1bcc45'
Notice:
/File[/var/lib/puppet/lib/puppet/parser/functions/is_ip_address.rb]/ensure:
defined content as '{md5}a714a736c1560e8739aaacd9030cca00'
Error:
/File[/var/lib/puppet/lib/puppet/parser/functions/is_numeric.rb]/ensure:
change from absent to file failed: execution expired
Error: Could not retrieve plugin: execution expired
Info: Caching catalog for AGENT
Info: Applying configuration version '1378322110'
Notice: Finished catalog run in 0.11 seconds
Wed Sep 4 14:15:58 CDT 2013
Each time I've run it, I get about 10 or so files and then I get
execution
expired.
What I'd really like to see is whether I can increase the expiry
timeout.
Some other details: The master is RHEL 6 on a Sun/Oracle X4800, lots
and
lots of fast cores and memory. I'm using Puppet Open Source. I'm using
passenger. I have no real modules other than some basic forge modules
I've
installed to start out with.
[root@MASTER audit]# cd /etc/puppet/modules
[root@MASTER modules]# ls
apache concat epel firewall inifile passenger puppet puppetdb
ruby
stdlib
I briefly disabled SELinux on the master, but saw no change in
behavior.
I'm certain that the firewall is right because other agents have had no
problems. iptables IS enabled, however.
The master and the agent are on the same subnet, so I don't suspect a
network performance issue directly.
On Solaris, because the vendor supplied OpenSSL is antique and doesn't
include SHA256, we have built our own OpenSSL and our own Ruby using
that
OpenSSL Library. Even though SPARC is a 64 bit architecture, Ruby
seems to
default to a 32 bit build, so we built OpenSSL as 32 bit as well to
match.
I've got an open question to the guy responsible for that to see how
hard it
would be to try to build Ruby as 64 bit, that's likely a next test.
I have not yet run snoop on the communication to see what's going on
the
network side, but as I say I don't really expect the network to be the
problem, between being on the same subnet and success on other systems
with
higher clock
Re: [Puppet Users] Re: Serious performance issues with Puppet 3.5.x when using Directory Environments
That's great to hear; thank you for testing that Antoine! - Josh On Mon, May 12, 2014 at 3:24 AM, Antoine Cotten tonio.cot...@gmail.comwrote: Hi Josh, hi all, So, I have set the environment_timeout setting to a couple of test values, including 30s, 1h and unlimited: - *30s* - No performance boost. Too short for me, my Puppet runs are distributed every 37s - *1h* - Very good results, fast config retrieval, even slighly better than with config-based environments - *unlimited* - same as above Regarding performance issues please ignore my previous message, I had some other troubles in my vSphere environment which caused these CPU and memory peaks. *My Puppet master behaves in a very stable way now*. Cheers, -- Toni -- You received this message because you are subscribed to a topic in the Google Groups Puppet Users group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/wzy8NPWauu4/unsubscribe. To unsubscribe from this group and all its topics, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/7ed02dd8-8dfe-4ea2-bcc1-d864132aa761%40googlegroups.comhttps://groups.google.com/d/msgid/puppet-users/7ed02dd8-8dfe-4ea2-bcc1-d864132aa761%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- Josh Partlow jpart...@puppetlabs.com Developer, Puppet Labs Join us at PuppetConf 2014, September 22-24 in San Francisco - http://puppetconf.com Register by May 30th to take advantage of the Early Adopter discount —save $349! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CADxAQ5p6oN6BUyNjMw0DN3QtkHmr%2BCQmz9AnKxYKyoA0ffrq_g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Puppet User Administration, set password only at creating of user-accounts
Is there an issue with using subscribe? So in my virtual resource
definition I have:
define accounts::virtual ($uid,$realname,$pass) {
user { $title:
ensure= 'present',
uid = $uid,
gid = $title,
shell = '/bin/bash',
home = /home/${title},
comment = $realname,
#password = $pass,
password_max_age = '90',
password_min_age = '0',
groups = ['sudo'],
managehome= true,
require = Group[$title],
}
group { $title:
gid = $uid,
}
exec { /usr/sbin/usermod -p \'$pass\' $title:
refreshonly = true,
subscribe = User[$title],
#logoutput = true,
}
...
...
...
And this is starting from Scott Lowe's blog:
http://blog.scottlowe.org/2012/11/25/using-puppet-for-account-management/
I guess the only gotcha I see is if something changes and causing the user
to get updated, it will reset the password to the default
On Monday, January 13, 2014 5:30:01 PM UTC-6, house_mann wrote:
Ygor, thanks to the scripting. I'll try this later, looks good.
And thanks to those other hints and opinions...
ako
Am Montag, 13. Januar 2014 18:35:20 UTC+1 schrieb house_mann:
HI their,
i'm very new to puppet and can't find an solutions to get this up and
running...
User creation works well. But when the user devop (or all others)
change his password, it will overwrite after next 'puppet-run' to the
hardcoded-one.
Correctly, because there is no setup/config to prevent this, when users
exists on the node.
Is there a simple setup for this case? Only set password for non-existing
users!?
Thanks.
ako
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/0e10dc12-4e96-40c3-b133-61b676b454a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] no child process
That looks like a puppet bug of the exec rype. see e.g. http://stackoverflow.com/a/14381862/4918 for how this message can be triggered. Another possibility might be that the machine in question is running out of resources or is being shutdown while the agent is running? Regards, David On 2014-05-12 17:13, Jason Hatman wrote: Occasionally one of my osx servers will fail a puppet run. If I run it again manually it works fine. It happens about once per day. Puppet agent runs every hour. Any Ideas what this means? All I'm doing is writing a string value to a plist file. Here's what the puppet log says in Dashboard. |err| |Could not evaluate: No child processes| |/Stage[main]/Osx_management::Munki_settings_hq/Mac-defaults[installapplesoftwareupdates]/Exec[defaults write /Library/Preferences/ManagedInstalls InstallAppleSoftwareUpdates -bool 'true']| |/etc/puppet/modules/macdefaults/manifests/init.pp| |17| |2014-05-12 10:03 CDT| |err| |Could not evaluate: No child processes| |/Stage[main]/Reposado::Repo_cat_mav_stable_server_hq/Mac-defaults[sus]/Exec[defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL -string 'http://reposado2.orchard.fruit.com/content/catalogs/others/index-10.9-mountainlion-lion-snowleopard-leopard.merged-1_server.sucatalog']| |/etc/puppet/modules/macdefaults/manifests/init.pp| |17||2014-05-12 10:03 CDT| |err| |Could not evaluate: No child processes| |/Stage[main]/Osx_management::Munki_settings_hq/Mac-defaults[softwarerepourl]/Exec[defaults write /Library/Preferences/ManagedInstalls SoftwareRepoURL -string 'http://munkiserver1.orchard.fruit.com/munki_repo']| |/etc/puppet/modules/macdefaults/manifests/init.pp| |17||2014-05-12 10:03 CDT| |err| |Could not evaluate: No child processes| |/Stage[main]/Osx_management::Location_hq_main/Mac-defaults[location]/Exec[defaults write /Library/Preferences/com.apple.RemoteDesktop Text3 -string 'HQ_Main_Building']| |/etc/puppet/modules/macdefaults/manifests/init.pp| |17||2014-05-12 10:03 CDT| |err| |Could not evaluate: No child processes| |/Stage[main]/Osx_management::Cfpropertylist_install/Package[CFPropertyList]| |/etc/puppet/modules/osx_management/manifests/cfpropertylist_install.pp| |6| |2014-05-12 10:03 CDT| |err| |Could not evaluate: No child processes| |/Stage[main]/Osx_management::Munki_settings_hq/Mac-defaults[clientidentifer]/Exec[defaults write /Library/Preferences/ManagedInstalls ClientIdentifier -string 'C07L900PF4MJ']||/etc/puppet/modules/macdefaults/manifests/init.pp| |17||2014-05-12 10:03 CDT| -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com mailto:puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/f8e2bbd9-22ae-4d68-b003-b3f7f5cc88e2%40googlegroups.com https://groups.google.com/d/msgid/puppet-users/f8e2bbd9-22ae-4d68-b003-b3f7f5cc88e2%40googlegroups.com?utm_medium=emailutm_source=footer. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/5370F6BC.80201%40dasz.at. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] using ruby dsl in puppet manifest
Hello John, I made a mistake in writing , i am using exec resource to execute that script. Regards, Ritesh On Mon, May 12, 2014 at 7:05 AM, jcbollinger john.bollin...@stjude.orgwrote: On Saturday, May 10, 2014 7:49:18 PM UTC-5, Ritesh Nanda wrote: Hello John, Thanks for your reply , ruby code i was trying to run was on client , so i am doing with inline_template right now , yeah but your idea seems good to have a plugin to do it . A plugin or an Exec is the *only* place to do it. As I wrote, templates are evaluated on the master, so *inline_template() will not do what you want*. If your code must run on the agent then it must be in a custom fact or in the provider of a custom type, it must be run via an Exec resource. John -- You received this message because you are subscribed to a topic in the Google Groups Puppet Users group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/3lD1tChZQJw/unsubscribe. To unsubscribe from this group and all its topics, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/753fb5f8-0394-4be7-9a64-9d2a8fcc6ecf%40googlegroups.comhttps://groups.google.com/d/msgid/puppet-users/753fb5f8-0394-4be7-9a64-9d2a8fcc6ecf%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- * With Regards * * Ritesh Nanda* http://www.ericsson.com/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAO5CbpAsD%3D74cACwoMm32fCb-P9%2B2JC5SxAooR4OJ66iB6umNg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Is --noop supposed to override noop param?
On 05/12/2014 03:16 PM, Christopher Wood wrote: I get the same behaviour in 3.4.3, however: The noop setting allows you to globally enable or disable noop mode, but it will not override the noop metaparameter on individual resources. http://docs.puppetlabs.com/references/latest/metaparameter.html#noop No-op being false means that yes-op is (metaphorically) true, right? It looks like your module writer thinks that --noop should never override this resource. OK so if noop setting/cli param doesn't override resource param(s), then changing default from false to undef in modules seems to be the solution. Thank you! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/53710DAA.4030405%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Parsing issues in 3.5
Hi Henrik, On Saturday, May 10, 2014 2:56:19 PM UTC-4, Henrik Lindberg wrote: In 3.5 the new evaluator was added and it is on by default when using --parser future. If you want to turn it off you can use --evaluator current in addition to --parser future) If it works under --evaluator current but not under --evaluator future, we like to hear about it, please file a ticket in that case. I apologize for the late reply! Thank you for your reply and information. I'm away from the office this week, but will try this out as soon as I have a chance. Thanks again, Joe -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/0bfa296d-54f8-49cf-b9e5-5a585909bd22%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
