Initial run problems

739 views
Skip to first unread message

Bret Wortman

unread,
Nov 13, 2012, 2:32:24 PM11/13/12
to puppet...@googlegroups.com
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?

Bret Wortman

unread,
Nov 13, 2012, 2:46:13 PM11/13/12
to puppet...@googlegroups.com
D'Oh. Solved this one myself via 

#chown -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.

jcbollinger

unread,
Nov 14, 2012, 9:10:20 AM11/14/12
to puppet...@googlegroups.com


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

Bret Wortman

unread,
Nov 15, 2012, 7:13:31 AM11/15/12
to puppet...@googlegroups.com
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.

Edson Manners

unread,
Nov 15, 2012, 7:46:37 AM11/15/12
to puppet...@googlegroups.com
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.

--
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...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Bret Wortman

unread,
Nov 15, 2012, 7:56:43 AM11/15/12
to puppet...@googlegroups.com
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.

Bret Wortman

unread,
Nov 15, 2012, 1:38:45 PM11/15/12
to puppet...@googlegroups.com
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 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.


*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

Gmoney

unread,
Nov 15, 2012, 3:14:53 PM11/15/12
to Puppet Users
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

Bret Wortman

unread,
Nov 15, 2012, 3:21:56 PM11/15/12
to puppet...@googlegroups.com
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.
--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.

Bret Wortman

unread,
Nov 15, 2012, 4:04:56 PM11/15/12
to puppet...@googlegroups.com
Nope. Same outcome. Numerous "No child processes" errors.
To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.

jcbollinger

unread,
Nov 16, 2012, 9:47:27 AM11/16/12
to puppet...@googlegroups.com


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

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

Bret Wortman

unread,
Nov 16, 2012, 10:13:43 AM11/16/12
to puppet...@googlegroups.com
I'm absolutely ready for this to be something I've not done properly during the kickstart process. I'm just getting started with these tools, so that's definitely a strong probability. I'll do this again shortly with strace and see what it reveals.

Bret Wortman

unread,
Nov 16, 2012, 12:44:38 PM11/16/12
to puppet...@googlegroups.com
I ran this with strace, and it produced 840K of output. It's on another 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?

jcbollinger

unread,
Nov 16, 2012, 1:45:46 PM11/16/12
to puppet...@googlegroups.com


The first thing I would look for is syscalls that return an error code.  Also keep an eye out for syscall arguments that are obviously wrong -- names with wrong domains, IP numbers on the wrong subnet, etc.  Pay particular attention to the vicinity of the points where error messages are emitted.


John

Reply all
Reply to author
Forward
0 new messages