[Puppet Users] Re: puppetd
Thanks for replies, here is the info. Actually there is not much in configs,
I tried it with minimal manifest and the issue still persists.
manifest:
=
node default {
$server = "puppetmaster.local"
#
# distribute puppetd and auth configs to all managed nodes
file {
'/etc/puppet/puppet.conf': source =>
"puppet://$server/files/puppet.conf";
'/etc/puppet/puppetd.conf': source =>
"puppet://$server/files/puppet.conf";
'/etc/puppet/namespaceauth.conf': source =>
"puppet://$server/files/namespaceauth.conf";
}
#
# define default filebucket on puppetmaster server
filebucket { "main": server => $server }
File { backup => 'main' }
}
=
puppetd.conf (the same as puppet.conf) on target server:
=
[main]
# Where Puppet stores dynamic and growing data.
# The default value is '/var/puppet'.
vardir = /var/lib/puppet
# The Puppet log directory.
# The default value is '$vardir/log'.
logdir = /var/log/puppet
# Where Puppet PID files are kept.
# The default value is '$vardir/run'.
rundir = /var/run/puppet
# Where SSL certificates are kept.
# The default value is '$confdir/ssl'.
ssldir = $vardir/ssl
[puppetd]
# The file in which puppetd stores a list of the classes
# associated with the retrieved configuratiion. Can be loaded in
# the separate ``puppet`` executable using the ``--loadclasses``
# option.
# The default value is '$confdir/classes.txt'.
classfile = $vardir/classes.txt
# Where puppetd caches the local configuration. An
# extension indicating the cache format is added automatically.
# The default value is '$confdir/localconfig'.
localconfig = $vardir/localconfig
# mster server
server = puppetmaster.local
# interval
runinterval = 900
# should we send reports back to puppetmaster server?
report = true
# should we listen for incoming connections? Allowd hosts are in file
listen = true
# we want all facts to be synced from master
factsync = true
=
As to the logs, it creates only one log file during first run:
/var/log/puppet/http.log and nothing writes to it since then, so it remains
empty.
Puppetd performs all operations I add to manifest and doesn't report any
error or warning and the only problem is it produces those strange
zombies...
Target OS is Centos, tried versions 3,4 and 5 - the issue is on all of them.
I have few instances of puppet running on Gentoo (installed from portages)
and there is no such problem.
Please let me know if I should provide any additional info.
Thanks
--
Paul Johnson
2008/12/22 Ohad Levy
>
> whats the last line you see in your puppet logfiles?
>
> I would guess its an exec or similar
>
> Ohad
>
> On 12/22/08, Paul Johnson wrote:
> > Hi All,
> >
> > I have a strange problem with running puppet as a daemon. I set it up in
> > config to wake up every 15 min and looks like it every time spawns httpd
> > process that becomes zombie, so after some time I see a long list of
> > zombies, like this:
> >
> > root 12427 0.1 0.9 39624 37408 ? Ss Dec20 4:12
> /usr/bin/ruby
> > /usr/sbin/puppetd
> > .
> > .
> > .
> > root 23654 0.0 0.0 00 ?Z15:14 0:00 \_
> [httpd]
> >
> > root 30482 0.0 0.0 00 ?Z15:29 0:00 \_
> [httpd]
> >
> > root 5389 0.0 0.0 00 ?Z15:44 0:00 \_
> [httpd]
> >
> > root 12636 0.0 0.0 00 ?Z15:59 0:00 \_
> [httpd]
> >
> > root 21618 0.0 0.0 00 ?Z16:15 0:00 \_
> [httpd]
> >
> > root 28044 0.0 0.0 00 ?Z16:30 0:00 \_
> [httpd]
> >
> > root 2363 0.0 0.0 00 ?Z16:45 0:00 \_
> [httpd]
> >
> > root 9547 0.0 0.0 00 ?Z17:00 0:00 \_
> [httpd]
> >
> > root 17770 0.0 0.0 00 ?Z17:15 0:00 \_
> [httpd]
> >
> > root 24466 0.0 0.0 00 ?Z17:30 0:00 \_
> [httpd]
> >
> > root 31275 0.0 0.0 00 ?Z17:46 0:00 \_
> [httpd]
> >
> > root 6199 0.0 0.0 00 ?Z18:01 0:00 \_
> [httpd]
> >
> > root 14349 0.0 0.0 00 ?Z18:16 0:00 \_
> [httpd]
> >
> > root 21148 0.0 0.0 00 ?Z18:31 0:00 \_
> [httpd]
> >
> >
> > When I kill puppetd all zombies die as well. I set it on about 60
> servers,
> > and see the same picture on all of them :(
> > I don't have any idea about why this happen, does someone h
[Puppet Users] Re: Understanding the "default" node.
Hi
> So the way I have implemented it is that we have a basenode node with the
> common elements that all nodes get. The basenode is then inherited by each
> of the specific nodes, therefore you get something like:
>
> import "foo"
> import "httpd"
>
> node basenode {
> include foo
> }
>
> node webnode inherits basenode {
> include httpd
> }
>
> node www1.example.com inherits webnode {}
> node www2.example.com inherits webnode {}
>
>
> Does that make sense?
yeah that will work. However sooner or later you will get one problem here:
if you use in the class httpd a variable which should be defined in the
node and you will define this variable in the definition of
www1.example.com, this variable will always be empty, as the class gets
evaluated before the variable is set in the subnode of the webnode.
So something like that, will give you problems:
node webnode inherits basenode {
include httpd
}
node www1.example.com inherits webnode {
# i'm used in the class httpd
$httpd_server_name = $fqdn
}
this is how inheritance works for nodes and which "confuses" a lot of
people. Therefore imho the best thing is to do inheritance in a bunch of
config-classes and using nodes only to set variables and include the
config class in every node _after_ setting all the variables. Or
switching over to external nodes, which will give you a lot more
flexibility than the site.pp file.
cheers pete
--~--~-~--~~~---~--~~
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] local and ldap users and packages
Hello, We have LDAP and non-LDAP nodes and some accounts that should be created only on non-LDAP nodes. I'm not sure the best way to handle this. I can remember where to put things specifically though having better checks would be nice. Like debian sudo-ldap conflicts with sudo, so only one should be installed check define of other ldap related file like a package? users manage local root of every machine - seems like nss_initgroups_ignoreusers root in ldap.conf is necessary. Maybe my nsswitch and pam config could be better as well. files some would depend on if it's an ldap node. Maybe it's best to define $hasldap somewhere. Gary --~--~-~--~~~---~--~~ 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] Highly Paid Online Surveys-Absolutely Free.
Highly Paid Online Surveys-Absolutely Free. Sign up today and start getting paid to surf & You can get up to $.75 per hour.You can give your opinion on a wide range of topics including consumer products, entertainment, health and wellness, current events and more... - http://www.milliondollarspro.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] Re: Understanding the "default" node.
On Dec 24, 2008, at 2:55 AM, Peter Meier wrote:
>
> Hi
>
>> So the way I have implemented it is that we have a basenode node
>> with the
>> common elements that all nodes get. The basenode is then inherited
>> by each
>> of the specific nodes, therefore you get something like:
>>
>> import "foo"
>> import "httpd"
>>
>> node basenode {
>> include foo
>> }
>>
>> node webnode inherits basenode {
>> include httpd
>> }
>>
>> node www1.example.com inherits webnode {}
>> node www2.example.com inherits webnode {}
>>
>>
>> Does that make sense?
>
>
> yeah that will work. However sooner or later you will get one
> problem here:
>
> if you use in the class httpd a variable which should be defined in
> the
> node and you will define this variable in the definition of
> www1.example.com, this variable will always be empty, as the class
> gets
> evaluated before the variable is set in the subnode of the webnode.
I understand this is just the way puppet works, but it's very
counterintuitive. If puppet wasn't a declarative language, it would
make perfect sense. Shouldn't puppet gather all variables and set
their values before evaluating resources? I haven't delved in to the
code to see if this is possible or not.
>
>
> So something like that, will give you problems:
>
> node webnode inherits basenode {
> include httpd
> }
>
> node www1.example.com inherits webnode {
> # i'm used in the class httpd
> $httpd_server_name = $fqdn
> }
>
> this is how inheritance works for nodes and which "confuses" a lot of
> people. Therefore imho the best thing is to do inheritance in a
> bunch of
> config-classes and using nodes only to set variables and include the
> config class in every node _after_ setting all the variables. Or
> switching over to external nodes, which will give you a lot more
> flexibility than the site.pp file.
>
> cheers pete
>
> >
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
