RE: [Puppet Users] Re: Inheritance and parameterized classes
You are about to blow your foot off, or at least your little toe. You
cannot include a parameterized class twice, not even with the same
parameters, and certainly not with different parameters. That will
scuttle catalog compilation for node nfsserver.
If you abandon class parameterization then you can do this with class
inheritance, but the two do not work well together. The class
inheritance approach might look something like this:
class nfs {
include nfs::params, nfs::install, nfs::config, nfs::service
}
class nfs::service::enabled inherits nfs::service {
# Override Service['nfs'] to ensure it enabled and running
}
node basenode {
include nfs
...
}
node nfsserver inherits basenode {
include nfs::service::enabled
}
That looks good to me, easy to understand, which makes me feel stupid for not
thinking about it myself.
Alternatively, you can make basenode not include class nfs, leaving
the choice of class parameters to the more specific node types, but
then every one of them must include class nfs itself.
Or you could use external data, such as obtained via extlookup() or
hiera, to define whether nodes should be enabled as NFS servers. That
would not only allow you to dispense with class nfs's parameters, but
probably you could also drop node nfsserver.
Extlookup has been on my todo-list for a while, I just figured I'd try to get a
better feel for the basics before I go there.
In general (says me), you should avoid defining class parameters whose
purpose is to tweak the *meaning* of the class, such as your $client
and $server parameters. That sort of purpose is better served by
providing distinct classes. As a rule of thumb, do not define class
parameters whose values are not intended to end up as [part of]
resource property values. (That's supposing you have already decided
to ignore my maxim #1 of Puppet class parameterization: don't do it.)
I haven't really decided anything yet, I'm certainly not set on using
parameterized classes, I'm mostly trying to find the Right Way to do things.
Using external data to tweak the meaning of a class is at least better
than using parameters for the same purpose. It causes the same kind
of ambiguation of the class's meaning, but at least it doesn't
introduce the practical limitations that come with class
parameterization.
John
Thanks for the input, I'll see if I can make the first way you suggested
working, seems easy enough. :)
Oh and sorry for the mail formatting...Outlook...
Regards
Johan
--
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: Custom providers - instalation and usage of an executable
I tested the optional_command solution with success. The virtual machine could be provisioned but the first time, any reference to the asadmin provider failed even though the binary was present. I presume that once the prefetch of providers has been done and failed, then that type and provider become unusable at that provisioning. I am quite sure that the response to my next question will be 'no' but I'll try anyway... It is possible to force a new binary check at each provider or type execution? The first check would fail but optional_command would handle it and at the real execution stage, the check would be successful and the command would be executed. Otherwise, two runs will be necessary at first provision :) On 28 oct, 14:47, jcbollinger john.bollin...@stjude.org wrote: On Oct 27, 2:35 pm, Stefan Schulte stefan.schu...@taunusstein.net wrote: On Thu, Oct 27, 2011 at 08:00:05AM -0700, David Campos wrote: Hello all, I am facing a problem while dealing with acustomprovider and its requirements. I have included acustomprovider (with itscustom types) into my puppet deployment that is expected to deal with all tasks related to glassfish. This provider is able to create domains, deploy applications and other features. This provider also requires a glassfish executable named 'asadmin' that is available after glassfish is installed. If the executable is available at the machine where agent is executed all works fine but if it is not available a message like '[default] ←[0;37mdebug: Puppet::Type::Domain::ProviderAsadmin: file asadmin does not exist←[0m Could not find a default provider for domain' is returned. All that behaviour is normal since there are not alternative providers for my resources and then the provider is not appliable but the problem appears when I want to install the application AND THEN work with the provider. In the theoretical scenario, puppet should install glassfish, deal with path and finally do some work with the provider but the real scenario is not that. The real scenario is that puppet does a prefetch of all resources that deal with providers and tries to load them. Since 'asadmin' is not yet available, the execution fails. Do anyone knows any way to let puppet skip that (or delay it until glassfish has been installed) and finish successfully? Would stages do a trick here? The only workaround that I have found has been perform the installation in a first provision and then, at the second provision, deal with resources. Scenario: - Install Glassfish - Configure Glassfish - Deal with resources (provider) Stages does not change a thing. At first I would suggest you watchhttps://projects.puppetlabs.com/issues/6907 I can see three possibilities: - write a dummy provider that doesn't do anything but also doesn't need anything. During the first puppet run puppet will pick the dummy provider. When you run puppet the next time your glassfish binary is already installed and puppet can choose between two providers. IIRC puppet tries to pick the one that is the most specific and that is the one with the most confines (so in your case it will probably work as desired) - use optional_commands :foo = '/bin/foo' instead of commands :foo = '/bin/foo'. This way the provider is still suitable even if your binary is not installed. But prefetching will fail on the first run (but puppet should apply the catalog so the second run should work ok) - use acustomfact that tells you if the binary of your provider is installed. Wrap each resource in your manifest in an if clause. Now you also need two puppet runs but the first run does not throw an error. I think Stefan has covered the field pretty well. Personally, I don't much like the dummy provider, though: it will prevent the error message, but because it doesn't actually do anything, it lies to the Puppet agent whenever it claims to have synchronized a resource. This may cause dependent resources to fail, and it results in two runs being required to achieve the target state, if that's an issue. The optional_commands approach is pretty smooth, and the prefetch problem is only relevant if it's possible for there to be existing resources when the needed binary is not already present. If you can use some alternative mechanism to prefetch resources then there doesn't have to be a prefetching problem at all. If you make the provider a do-nothing in the event that asadmin is missing then this option becomes a superset of the dummy provider option; that would allow you to avoid multiple providers. (I still don't like the dummy option even when implemented this way, however: better to fail a resource if asadmin is not available when the time comes to sync it.) Thecustomfact approach is pretty easy to add on top of your existing provider and manifests. Also, if you arrange
[Puppet Users] Re: Unable to define order of modules
On Nov 4, 7:20 am, Baptiste Grenier baptiste.gren...@gmail.com
wrote:
Hello,
Le 03/11/11 15:45, jcbollinger t l scripta :
[...]
There are several ugly ways you could do this. The clean way would be
to pull the $aptdater::client::sudo_allow_aptdater_user variable out
to a separate class that both class sudo and class aptdater::client
can safely include (which implies that it is not parameterized),
I tried it quickly, with a test like this in the separate class:
-8
if (inline_template(%= classes.include?('aptdater::client') %) ==
'true') {
$sudo_allow_aptdater_user = true
} else {
$sudo_allow_aptdater_user = false
}
-8
But it still dependent of the order of the include of the classes...
For the record, that is not an implementation of my recommendation.
It is not safe for class sudo::apdater to include that new class,
except in the most technical of senses.
The point is to have a source of truth separate from apdater::client
for that class and class sudo both to draw on, but you have that
relationship reversed on one side. That just lengthens the dependency
chain you already had (now sudo depends on newclass depends on
apdater::client), which doesn't gain you anything. For this to work
you need {sudo, apdater::client} depends on newclass.
Replace newclass with global variable or external data as you
like.
The separate class option is great, but it is distinct from the other
two only if the new class can choose the variable's value based only
on nodes' facts.
It does not seem to be possible for me.
Whatever logic you use now either to set $sudo_allow_aptdater_user or
to choose whether to include class apdater::client can certainly be
put in a separate class. Depending on what the logic is, it might be
ugly / unmaintainable / painful to move it there, but not impossible.
By the way I was able to order the module application using run stages,
so thanks for pointing me to this direction.
I don't find this to be the perfect/cleanest solution for my problem,
but at least it is working as needed and expected :)
I am glad you have found a solution.
Good luck,
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Default sysctl.conf with augeas.
On Nov 4, 2011, at 3:21 PM, Douglas Garstang wrote: I have a tricky problem. I'm going to use Augeas, like here http://projects.puppetlabs.com/projects/1/wiki/Puppet_Augeas#/etc/sysctl.conf to maintain sysctl.conf. That doesn’t look like a very good example in my opinion. For one thing, the test defined in the onlyif is unnecessary. The Augeas type does that inherently. Second, by wrapping the changes in a define, you’d be forcing a call to `sysctl -p` for every single change. Better to just create your own Augeas resources that lists *all* of the changes and then have it notify an Exec. However, since iptables is already disabled, when I add more lines to sysctl.conf with augeas and run sysctl -p, the following lines (which are already there) cause a failure. # Disable netfilter on bridges. net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-call-arptables = 0 So if you call set net.bridge.bridge-nf-call-ip6tables 0, it will get added to the file, even if it’s already defined? So, I figured I'd staty with a default sysctl.conf (which didn't have these lines), and then add more lines to it with augeas. However, even if I get the dependancies right and push the file out before running augeas, augeas will re-add the lines every time because they aren't there. Can you show the section of your manifests that mess with the above three lines? -- Rob McBroom http://www.skurfer.com/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Puppet ruby error
Hi, I've got a new install of Ubuntu lucid lynx with backport puppet 2.6.1, but when i try to run my templates i get this error. /usr/lib/ruby/1.8/timeout.rb:60:in `open': execution expired (Timeout::Error) from /usr/lib/ruby/1.8/net/http.rb:560:in `connect' from /usr/lib/ruby/1.8/timeout.rb:53:in `timeout' from /usr/lib/ruby/1.8/timeout.rb:93:in `timeout' from /usr/lib/ruby/1.8/net/http.rb:560:in `connect' from /usr/lib/ruby/1.8/net/http.rb:553:in `do_start' from /usr/lib/ruby/1.8/net/http.rb:542:in `start' from /usr/lib/ruby/1.8/open-uri.rb:242:in `open_http' from /usr/lib/ruby/1.8/open-uri.rb:616:in `buffer_open' from /usr/lib/ruby/1.8/open-uri.rb:164:in `open_loop' from /usr/lib/ruby/1.8/open-uri.rb:162:in `catch' from /usr/lib/ruby/1.8/open-uri.rb:162:in `open_loop' from /usr/lib/ruby/1.8/open-uri.rb:132:in `open_uri' from /usr/lib/ruby/1.8/open-uri.rb:518:in `open' from /usr/lib/ruby/1.8/open-uri.rb:30:in `open' from /usr/lib/ruby/1.8/facter/ec2.rb:10:in `can_connect?' from /usr/lib/ruby/1.8/facter/ec2.rb:10:in `can_connect?' from /usr/lib/ruby/1.8/facter/ec2.rb:33 from /usr/lib/ruby/1.8/facter/util/loader.rb:72:in `load' from /usr/lib/ruby/1.8/facter/util/loader.rb:72:in `load_file' from /usr/lib/ruby/1.8/facter/util/loader.rb:38:in `load_all' from /usr/lib/ruby/1.8/facter/util/loader.rb:33:in `each' from /usr/lib/ruby/1.8/facter/util/loader.rb:33:in `load_all' from /usr/lib/ruby/1.8/facter/util/loader.rb:30:in `each' from /usr/lib/ruby/1.8/facter/util/loader.rb:30:in `load_all' from /usr/lib/ruby/1.8/facter/util/collection.rb:94:in `load_all' from /usr/lib/ruby/1.8/facter.rb:91:in `to_hash' from /usr/lib/ruby/1.8/puppet/indirector/facts/facter.rb:71:in `find' from /usr/lib/ruby/1.8/puppet/indirector/indirection.rb:193:in `find' from /usr/lib/ruby/1.8/puppet/indirector.rb:50:in `find' from /usr/lib/ruby/1.8/puppet/application/apply.rb:88:in `main' from /usr/lib/ruby/1.8/puppet/application/apply.rb:35:in `run_command' from /usr/lib/ruby/1.8/puppet/application.rb:300:in `run' from /usr/lib/ruby/1.8/puppet/application.rb:397:in `exit_on_fail' from /usr/lib/ruby/1.8/puppet/application.rb:300:in `run' from /usr/lib/ruby/1.8/puppet/util/command_line.rb:55:in `execute' from /usr/bin/puppet:4 Do you have any idea what can be the cause of 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: Custom providers - instalation and usage of an executable
On Mon, Nov 07, 2011 at 03:25:33AM -0800, David Campos wrote: I tested the optional_command solution with success. The virtual machine could be provisioned but the first time, any reference to the asadmin provider failed even though the binary was present. I presume that once the prefetch of providers has been done and failed, then that type and provider become unusable at that provisioning. I am quite sure that the response to my next question will be 'no' but I'll try anyway... It is possible to force a new binary check at each provider or type execution? The first check would fail but optional_command would handle it and at the real execution stage, the check would be successful and the command would be executed. Can you please provide some debug output of your first puppetrun? In general I think that just ignoring prefetching is pretty bad because all resources are treated as initially absent (even though that might not be the case) so create is run for every resource. I thought that this is the behaviour we have right now, so some debug logs would be helpful. -Stefan pgpa0kBbV1aWf.pgp Description: PGP signature
[Puppet Users] Puppet Dashboard 1.2.2; node report; change sort in log tab
The sorting in the log tab on a node report seems to be on the level column, which is hard to read when multiple changes take place, as notice and info of the actions are on the top and bottom of the log. Can this be adjusted so its displayed as 'puppet agent --test' does (sort on time and line column). -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Hiera - How to set a parameter to the value false
Hello, I've been using hiera for a few weeks now, but I'm stuck now trying to set a value to false Basically, I have a class that read its parameter in hiera, and in a yaml file I have the following code: --- use_ecrypt_fs: true server_region: fr puppet_enable: false This ultimately leads to the following error: err: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not find data item puppet_enable in any Hiera data file and no default supplied at When I set puppet_enable: true this works fine, but I can't figure out how to pass a false value (tried false, False, nil ) Any help would be greatly appreciated -- Bruno Leon -- 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: Unable to define order of modules
Hello,
Le 07/11/11 à 15:30, jcbollinger téléscripta :
For the record, that is not an implementation of my recommendation.
It is not safe for class sudo::apdater to include that new class,
except in the most technical of senses.
Indeed.
The point is to have a source of truth separate from apdater::client
for that class and class sudo both to draw on, but you have that
relationship reversed on one side. That just lengthens the dependency
chain you already had (now sudo depends on newclass depends on
apdater::client), which doesn't gain you anything. For this to work
you need {sudo, apdater::client} depends on newclass.
Replace newclass with global variable or external data as you
like.
OK.
The separate class option is great, but it is distinct from the other
two only if the new class can choose the variable's value based only
on nodes' facts.
It does not seem to be possible for me.
Whatever logic you use now either to set $sudo_allow_aptdater_user or
to choose whether to include class apdater::client can certainly be
put in a separate class. Depending on what the logic is, it might be
ugly / unmaintainable / painful to move it there, but not impossible.
For now the logic is that I manually add the adapter::client to the
concerned nodes, so it is quite difficult to put this as it is in
another class. (I am sure it would be possible, I can have the separate
class that extlookup a file to see if the node should have the
adapter::client class, but now, for my present need, it seems to be too
much)
By the way I was able to order the module application using run stages,
so thanks for pointing me to this direction.
I don't find this to be the perfect/cleanest solution for my problem,
but at least it is working as needed and expected :)
I am glad you have found a solution.
Thanks for your time/help.
Good luck,
Do I look so lost? ;)
John
Regards,
Baptiste
--
\,,/_[-_-]_\,,/
http://asocial.ws/gwarf
Down to the Banana Republics,
Down to the tropical sun.
Go the expatriated Americans,
Hoping to find some fun.
Some of them go for the sailing,
Caught by the lure of the sea.
Trying to find what is ailing,
Living in the land of the free.
Some of them are running from lovers,
Leaving no forward address.
Some of them are running tons of ganja,
Some are running from the IRS.
Late at night you will find them,
In the cheap hotels and bars.
Hustling the senoritas,
While they dance beneath the stars.
-- Jimmy Buffet, Banana Republics
--
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] why puppet template erb convert On to true, Off to false?
Dear all,
I have a parameterized class and I have my ECN in perl as followed:
classes{'myclass'} = { abc = On,};
and in my template erb:
SecRuleEngine %= abc %
When I applied this to my puppet agent, I would then get:
SecRuleEngine true.
How is that On becomes true and Off becomes false? How can I fix
this?
Thank you very much.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] why puppet template erb convert On to true, Off to false?
On Mon, Nov 7, 2011 at 1:45 PM, midair77 midai...@gmail.com wrote:
Dear all,
I have a parameterized class and I have my ECN in perl as followed:
classes{'myclass'} = { abc = On,};
and in my template erb:
SecRuleEngine %= abc %
When I applied this to my puppet agent, I would then get:
SecRuleEngine true.
How is that On becomes true and Off becomes false? How can I fix
this?
Do you get exactly the same thing if you quote On so it's actually a
string?
I'm not sure which part of Ruby is doing the magical translation that you
don't want, but you definitely shouldn't get it if you tell Puppet that
On is a string.
--
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] Status of 2.7.7rc
We have found 3 bugs we want tracked down before cutting the next Puppet RC. (2.7.7rc2) File serving performance issue with large numbers of files: https://projects.puppetlabs.com/issues/9671 Agent may crash when attempting to manage permissions on non-NTFS filesystems (on Windows) https://projects.puppetlabs.com/issues/10614 There is a pull request for this issue (binary mode on Windows) https://projects.puppetlabs.com/issues/9983 Just wanted to let everybody know, in case you're on the edge of your seat for 2.7.7. Mike -- 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: why puppet template erb convert On to true, Off to false?
I actually put On in double quote in my ECN and I did not get the
desired output.
This is quite weird as why On/Off has been converted to true/false in
erb template.
Thank you, Nigel.
On Nov 7, 2:39 pm, Nigel Kersten ni...@puppetlabs.com wrote:
On Mon, Nov 7, 2011 at 1:45 PM, midair77 midai...@gmail.com wrote:
Dear all,
I have a parameterized class and I have my ECN in perl as followed:
classes{'myclass'} = { abc = On,};
and in my template erb:
SecRuleEngine %= abc %
When I applied this to my puppet agent, I would then get:
SecRuleEngine true.
How is that On becomes true and Off becomes false? How can I fix
this?
Do you get exactly the same thing if you quote On so it's actually a
string?
I'm not sure which part of Ruby is doing the magical translation that you
don't want, but you definitely shouldn't get it if you tell Puppet that
On is a string.
--
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] nss_ldap breaks puppet
I have installed and configured the puppet client nodes to use LDAP to authenicate users. LDAP connection is OK and user can be authenicated via LDAP. I use nscd and with my ldap config setting specify on /etc/ldap.conf However, puppet is not happy; and in the /var/log/messages it gives tons of puppet-agent[27499]: nss_ldap: could not search LDAP server puppet-agent[27499]: nss_ldap: reconnecting to LDAP server I guess LDAP server connection is slow or timeout, but could we configure puppet client NOT to use LDAP specify on nsswitch.conf I search previous post; and somebody suggests to fix LDAP locally. I think that is the ideal way; but if I don't have control on LDAP. Give up Puppet or LDAP? I think should have way to configure puppet not to use the host setting set on nsswitch.conf. /etc/sysconfig/puppet or /etc/puppet/puppet.conf --- anywhere we can tell puppet to use alternative auth way other than the default system /etc/nsswitch.conf -- 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 facter timeout
I have a problem with a new Ubuntu server (2.6.32-33-server) and
facter.
Facter Version 1.5.6
root@web002:~# facter
/usr/lib/ruby/1.8/timeout.rb:60:in `open': execution expired
(Timeout::Error)
from /usr/lib/ruby/1.8/net/http.rb:560:in `connect'
from /usr/lib/ruby/1.8/timeout.rb:53:in `timeout'
from /usr/lib/ruby/1.8/timeout.rb:93:in `timeout'
from /usr/lib/ruby/1.8/net/http.rb:560:in `connect'
from /usr/lib/ruby/1.8/net/http.rb:553:in `do_start'
from /usr/lib/ruby/1.8/net/http.rb:542:in `start'
from /usr/lib/ruby/1.8/open-uri.rb:242:in `open_http'
from /usr/lib/ruby/1.8/open-uri.rb:616:in `buffer_open'
from /usr/lib/ruby/1.8/open-uri.rb:164:in `open_loop'
from /usr/lib/ruby/1.8/open-uri.rb:162:in `catch'
from /usr/lib/ruby/1.8/open-uri.rb:162:in `open_loop'
from /usr/lib/ruby/1.8/open-uri.rb:132:in `open_uri'
from /usr/lib/ruby/1.8/open-uri.rb:518:in `open'
from /usr/lib/ruby/1.8/open-uri.rb:30:in `open'
from /usr/lib/ruby/1.8/facter/ec2.rb:10:in `can_connect?'
from /usr/lib/ruby/1.8/facter/ec2.rb:10:in `can_connect?'
from /usr/lib/ruby/1.8/facter/ec2.rb:33
from /usr/lib/ruby/1.8/facter/util/loader.rb:72:in `load'
from /usr/lib/ruby/1.8/facter/util/loader.rb:72:in `load_file'
from /usr/lib/ruby/1.8/facter/util/loader.rb:38:in `load_all'
from /usr/lib/ruby/1.8/facter/util/loader.rb:33:in `each'
from /usr/lib/ruby/1.8/facter/util/loader.rb:33:in `load_all'
from /usr/lib/ruby/1.8/facter/util/loader.rb:30:in `each'
from /usr/lib/ruby/1.8/facter/util/loader.rb:30:in `load_all'
from /usr/lib/ruby/1.8/facter/util/collection.rb:94:in `load_all'
from /usr/lib/ruby/1.8/facter.rb:91:in `to_hash'
from /usr/bin/facter:138
facter with strace:
It stops 1-2s, thats the output of strace.
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
fcntl(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)= 0
connect(3, {sa_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr(169.254.169.254)}, 16) = -1 EINPROGRESS
(Operation now in progress)
select(5, [], [3], [3], {1, 969055}^C unfinished ...
Puppet says, there is a problem with local facts, and I'm sure thats
the facter problem ;)
And there is no problem with dns, all other servers with the same
version of facter and puppet have no problems... The only thing I did
on this server is an upgrade with apt-get, but facter and puppet are
the same version as they are on the other servers
Thanks for your help
--
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] can we alter the 30-min run time?
Hi , How about an option for throttling number of max puppet clients being active - then puppet client time to run has come it registers at the puppetmaster - and once there is below max allowed active puppet clients running - puppetmaster initiates the client run (puppet client needs to have listen=true for that to work). Priorities can also be added easily. This also gives you easy visibility on then running puppet every X minutes becomes a bottleneck. This ca be probably done with mcollective - but requires a separate daemon process to manage the queue waiting puppet clients. The advanate of separate daemon is that it can have a view of more than one puppetmaster. The disadvantage is that puppet clients can still connect directly puppetmaster avoiding the queue altogether. So it looks like a builtin puppet queue functionality is a better choice. wdyt? Alex On 11/05/2011 06:42 PM, Nigel Kersten wrote: On Thu, Nov 3, 2011 at 12:41 PM, Jo Rhett jrh...@netconsonance.com mailto:jrh...@netconsonance.com wrote: Nigel, As you've said, the time chosen for the run cycle will be consistent. All of these settings are already set -- this isn't a question of how to change how often to run, it's how to affect the chosen runtime? I've got an awful lot of systems ( 100) which have decided to all roll at 28 and 58 minutes after the hour. How can I rebalance them? This should be what the splay settings do for you Jo. Even though those agents all roll at 28/58 minutes past the hour, if you set splay to true, they'll then wait a random amount of time up to splaylimit before they *actually* perform the run. The default setting for splay is off, so you won't see this behavior unless you explicitly turn it on. Does that make more sense? On Nov 3, 2011, at 8:38 AM, Nigel Kersten wrote: On Thu, Nov 3, 2011 at 8:36 AM, Jo Rhett jrh...@netconsonance.com mailto:jrh...@netconsonance.com wrote: For a long time it appeared that run cycles were fairly balanced -- a few every 30 seconds over the 30 minute period. Right now I'm seeing more than 100 systems hit in the same minute: 28 and 58 minutes after the hour. Is there some way to alter the spread of these systems back to even out the load? Or passenger options which could limit the effects of this? In your puppet.conf agent block: # How often puppet agent applies the client configuration; in seconds. # Note that a runinterval of 0 means run continuously rather than # never run. If you want puppet agent to never run, you should start # it with the `--no-client` option. # The default value is '1800'. runinterval = 1800 ... # The maximum time to delay before runs. Defaults to being the same as the # run interval. # The default value is '$runinterval'. splaylimit = 1800 ... # Whether to sleep for a pseudo-random (but consistent) amount of time before # a run. splay = false -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness -- 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 mailto:puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com mailto:puppet-users%2bunsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Nigel Kersten Product Manager, 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 mailto:puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com mailto:puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness -- 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 mailto:puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com mailto:puppet-users%2bunsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Nigel Kersten Product Manager, Puppet Labs -- You received this message because you
Re: [Puppet Users] puppet facter timeout
On 2011-11-07 05:50 , raffis wrote:
I have a problem with a new Ubuntu server (2.6.32-33-server) and
facter.
Facter Version 1.5.6
root@web002:~# facter
/usr/lib/ruby/1.8/timeout.rb:60:in `open': execution expired
(Timeout::Error)
from /usr/lib/ruby/1.8/net/http.rb:560:in `connect'
from /usr/lib/ruby/1.8/timeout.rb:53:in `timeout'
from /usr/lib/ruby/1.8/timeout.rb:93:in `timeout'
from /usr/lib/ruby/1.8/net/http.rb:560:in `connect'
from /usr/lib/ruby/1.8/net/http.rb:553:in `do_start'
from /usr/lib/ruby/1.8/net/http.rb:542:in `start'
from /usr/lib/ruby/1.8/open-uri.rb:242:in `open_http'
from /usr/lib/ruby/1.8/open-uri.rb:616:in `buffer_open'
from /usr/lib/ruby/1.8/open-uri.rb:164:in `open_loop'
from /usr/lib/ruby/1.8/open-uri.rb:162:in `catch'
from /usr/lib/ruby/1.8/open-uri.rb:162:in `open_loop'
from /usr/lib/ruby/1.8/open-uri.rb:132:in `open_uri'
from /usr/lib/ruby/1.8/open-uri.rb:518:in `open'
from /usr/lib/ruby/1.8/open-uri.rb:30:in `open'
from /usr/lib/ruby/1.8/facter/ec2.rb:10:in `can_connect?'
from /usr/lib/ruby/1.8/facter/ec2.rb:10:in `can_connect?'
from /usr/lib/ruby/1.8/facter/ec2.rb:33
from /usr/lib/ruby/1.8/facter/util/loader.rb:72:in `load'
from /usr/lib/ruby/1.8/facter/util/loader.rb:72:in `load_file'
from /usr/lib/ruby/1.8/facter/util/loader.rb:38:in `load_all'
from /usr/lib/ruby/1.8/facter/util/loader.rb:33:in `each'
from /usr/lib/ruby/1.8/facter/util/loader.rb:33:in `load_all'
from /usr/lib/ruby/1.8/facter/util/loader.rb:30:in `each'
from /usr/lib/ruby/1.8/facter/util/loader.rb:30:in `load_all'
from /usr/lib/ruby/1.8/facter/util/collection.rb:94:in `load_all'
from /usr/lib/ruby/1.8/facter.rb:91:in `to_hash'
from /usr/bin/facter:138
facter with strace:
It stops 1-2s, thats the output of strace.
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
fcntl(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)= 0
connect(3, {sa_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr(169.254.169.254)}, 16) = -1 EINPROGRESS
(Operation now in progress)
select(5, [], [3], [3], {1, 969055}^C unfinished ...
Puppet says, there is a problem with local facts, and I'm sure thats
the facter problem ;)
And there is no problem with dns, all other servers with the same
version of facter and puppet have no problems... The only thing I did
on this server is an upgrade with apt-get, but facter and puppet are
the same version as they are on the other servers
Thanks for your help
You'll want to keep an eye on the Ubuntu bug for this[0].
[0] https://bugs.launchpad.net/ubuntu/+source/facter/+bug/885998
--
Jacob Helwig
http://about.me/jhelwig
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] Re: why puppet template erb convert On to true, Off to false?
On Mon, Nov 7, 2011 at 3:38 PM, midair77 midai...@gmail.com wrote: I actually put On in double quote in my ECN and I did not get the desired output. This is quite weird as why On/Off has been converted to true/false in erb template. Ah, I missed that you've got a Perl ENC. Can you run your ENC by hand and paste the YAML output of the node definition like this? e.g. /path/to/enc nodename and you should get the YAML output. -- Nigel Kersten Product Manager, 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: puppet facter timeout
Yep thanks, the ubuntu package 1.5.6-2ubuntu2.2 was the problem. Roll-
back to 1.5.6-2ubuntu2 solved the facter bug.
On Nov 8, 2:21 am, Jacob Helwig ja...@puppetlabs.com wrote:
On 2011-11-07 05:50 , raffis wrote:
I have a problem with a new Ubuntu server (2.6.32-33-server) and
facter.
Facter Version 1.5.6
root@web002:~# facter
/usr/lib/ruby/1.8/timeout.rb:60:in `open': execution expired
(Timeout::Error)
from /usr/lib/ruby/1.8/net/http.rb:560:in `connect'
from /usr/lib/ruby/1.8/timeout.rb:53:in `timeout'
from /usr/lib/ruby/1.8/timeout.rb:93:in `timeout'
from /usr/lib/ruby/1.8/net/http.rb:560:in `connect'
from /usr/lib/ruby/1.8/net/http.rb:553:in `do_start'
from /usr/lib/ruby/1.8/net/http.rb:542:in `start'
from /usr/lib/ruby/1.8/open-uri.rb:242:in `open_http'
from /usr/lib/ruby/1.8/open-uri.rb:616:in `buffer_open'
from /usr/lib/ruby/1.8/open-uri.rb:164:in `open_loop'
from /usr/lib/ruby/1.8/open-uri.rb:162:in `catch'
from /usr/lib/ruby/1.8/open-uri.rb:162:in `open_loop'
from /usr/lib/ruby/1.8/open-uri.rb:132:in `open_uri'
from /usr/lib/ruby/1.8/open-uri.rb:518:in `open'
from /usr/lib/ruby/1.8/open-uri.rb:30:in `open'
from /usr/lib/ruby/1.8/facter/ec2.rb:10:in `can_connect?'
from /usr/lib/ruby/1.8/facter/ec2.rb:10:in `can_connect?'
from /usr/lib/ruby/1.8/facter/ec2.rb:33
from /usr/lib/ruby/1.8/facter/util/loader.rb:72:in `load'
from /usr/lib/ruby/1.8/facter/util/loader.rb:72:in `load_file'
from /usr/lib/ruby/1.8/facter/util/loader.rb:38:in `load_all'
from /usr/lib/ruby/1.8/facter/util/loader.rb:33:in `each'
from /usr/lib/ruby/1.8/facter/util/loader.rb:33:in `load_all'
from /usr/lib/ruby/1.8/facter/util/loader.rb:30:in `each'
from /usr/lib/ruby/1.8/facter/util/loader.rb:30:in `load_all'
from /usr/lib/ruby/1.8/facter/util/collection.rb:94:in `load_all'
from /usr/lib/ruby/1.8/facter.rb:91:in `to_hash'
from /usr/bin/facter:138
facter with strace:
It stops 1-2s, thats the output of strace.
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
fcntl(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr(169.254.169.254)}, 16) = -1 EINPROGRESS
(Operation now in progress)
select(5, [], [3], [3], {1, 969055}^C unfinished ...
Puppet says, there is a problem with local facts, and I'm sure thats
the facter problem ;)
And there is no problem with dns, all other servers with the same
version of facter and puppet have no problems... The only thing I did
on this server is an upgrade with apt-get, but facter and puppet are
the same version as they are on the other servers
Thanks for your help
You'll want to keep an eye on the Ubuntu bug for this[0].
[0]https://bugs.launchpad.net/ubuntu/+source/facter/+bug/885998
--
Jacob Helwighttp://about.me/jhelwig
signature.asc
1KViewDownload
--
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: What's the canonical way to enforce permissions/ownership on a directory subtree?
On Nov 4, 9:42 pm, Christopher Wood christopher_w...@pobox.com
wrote:
I think you still want chown -R here:
command = /bin/chown -R jetty:users ${jetty_install_dir},
Of course I do, I fat-fingered it. That's why it wasn't working.
Thanks for that (also, thanks to Stefan for the advice about
refreshonly=true.)
Cheers, Robert.
--
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.
