[Puppet Users] Initial run problems

On Tuesday, November 13, 2012 2:32:24 PM UTC-5, Bret Wortman wrote:
I'm working on setting things up so that I can use Cobbler to kickstart a
basic system and then use Puppet to roll out the majority of packages based
on the role a particular system will be playing for us. I've got a
kickstarter file running (a thinly modified version of the Cobbler
sample.ks) but after it runs and installs around 444 packages including
puppet, I get this after booting into the system the first time (and after
doing the certificate exchange bit):

# puppet agent -t
Info: Retrieving plugin
Timed out seeking value for ipaddress
Timed out seeking value for ipaddress
Error: Could not autoload puppet/provider/package/rpm: No child processes
Error: Could not autoload puppet/type/package: Could not autlooad
puppet/provider/package/rpm: No child processes
Error: Could not retrieve catalog from remote server: Could not intern
from pson: Could not autoload puppet/type/package: Could not autload
puppet/provider/package/rpm: No child processes
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog: skipping run
#

I've seen notes about ip addresses before, but I can ping, scp, and ssh
out of the box without issue (and can reach the puppet server, since we
performed the certificate request-sign-download thing).

Any ideas?

D'Oh. Solved this one myself via

On Tuesday, November 13, 2012 1:46:13 PM UTC-6, Bret Wortman wrote:

#chown <#38664afa-359d-43cc-b948-5c828265aba9@googlegroups.com_> -R
puppet:puppet /etc/puppet

Not sure why the RPM package missed that, but it did. I'm adding a
double-check to my kickstart for this.

On Wednesday, November 14, 2012 9:10:21 AM UTC-5, jcbollinger wrote:



The "puppet" user should not need to own that directory, and it's probably
not a good idea for it to do. It should, however, be able to *read* that
directory. If you have some policy in place that could have prevented it
from reading it or any of its content, then that might explain the problem.


John

On Thu, Nov 15, 2012 at 7:13 AM, Bret Wortman wrote:

It's continuing even after the ownership "fix", though it's intermittent.
Some runs will consist of long runs of messages in the client like these:

Error: Could not prefetch package provider 'yum': No child processes
Error: Could not set 'present' on ensure: No child processes at
105:/etc/puppet/moduels/workstation/manifests/init.pp
Error: /Stage[main]/Workstation/Secure[sendmail-off]:" Could not evaluate:
No child processes

over and over (with different classes/packages each time.

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/-/lrwqsbuaECEJ.

To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thursday, November 15, 2012 7:47:53 AM UTC-5, Edson Manners wrote:

Bret,
I'm doing the same thing without any issues. Give us csome basic
info. What OS, puppet version, RPMs or tarballs,
which yum repo, SELNIUX enforcing status and so forth.

On Thu, Nov 15, 2012 at 7:13 AM, Bret Wortman <br...@thewortmans.org<javascript:>

On Thursday, November 15, 2012 7:56:43 AM UTC-5, Bret Wortman wrote:
F17, Puppet 3.0.1 installed from RPM from a copy of the puppetlabs repos.
SELinux disabled, iptables disabled.

I just added this line to /etc/security/limits.conf:

puppet hard nproc -1

And it seems to have solved the above issue.

On Nov 15, 1:38 pm, Bret Wortman wrote:
*Sigh*. Something will work for a short while, then I'm back staring at
errors again.

# puppet agent -t
Info: Retrieving plugin
Timed out seeking value for ipaddress
Timed out seeking value for ipaddress
Error: Could not autoload puppet/provider/package/rpm: No child processes
Error: Could not autoload puppet/provider/package/zypper: Could not
autolaod puppet/provider/package/rpm: No child processes
Error: Could not autoload puppet/type/package: Error: Could not autoload
puppet/provider/package/zypper: Could not autolaod
puppet/provider/package/rpm: No child processes
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog: skipping run
# cat /etc/security/limits.conf
puppet     hard    nproc    -1
#

Puppet 3.0.1 installed from RPM from a copy of the puppetlabs repos.
SELinux disabled, iptables disabled.

On Thu, Nov 15, 2012 at 3:14 PM, Gmoney wrote:

On the cobbler side do you have the folliwng in your /etc/cobbler/
settings file?

# if enabled, this setting ensures that puppet is installed during
# machine provision, a client certificate is generated and a
# certificate signing request is made with the puppet master server
puppet_auto_setup: 1

# when puppet starts on a system after installation it needs to have
# its certificate signed by the puppet master server. Enabling the
# following feature will ensure that the puppet server signs the
# certificate after installation if the puppet master server is
# running on the same machine as cobbler. This requires
# puppet_auto_setup above to be enabled
sign_puppet_certs_automatically: 1
repos.
--
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thursday, November 15, 2012 3:22:09 PM UTC-5, Bret Wortman wrote:

I do now (I was using ksmeta to set puppet_auto_setup but this is so much
easier & cleaner!); I'll reattempt a build and see what happens.

**
*

Bret Wortman***
http://bretwortman.com/
http://twitter.com/BretWortman

On Thursday, November 15, 2012 3:04:57 PM UTC-6, Bret Wortman wrote:
Nope. Same outcome. Numerous "No child processes" errors.

On Friday, November 16, 2012 9:47:28 AM UTC-5, jcbollinger wrote:

I'm not up to performing a code dive at the moment to find out where those
messages may be emitted, but that might be useful information to have.

It might also be illuminating to strace an agent run to get a low-level
view of what's failing.

I'm inclined to think that this is a provisioning problem, not inherently
a Puppet problem, but there's not enough information to be sure.


John

I ran this with strace, and it produced 840K of output. It's on another

On Friday, November 16, 2012 11:44:38 AM UTC-6, Bret Wortman wrote:
network and I can't transfer the file to here for various reasons. Is there
something I can look for and transcribe that might be illustrative?