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 <b...@thewortmans.org> 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.
>
>
> On Wednesday, November 14, 2012 9:10:21 AM UTC-5, jcbollinger wrote:
>>
>>
>>
>> On Tuesday, November 13, 2012 1:46:13 PM UTC-6, Bret Wortman wrote:
>>>
>>>
>>>
>>> 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
>>>
>>> #chown<#13b03fd1ef5eda4b_c319397b-d8eb-46de-b5e7-7ed754ac7872@googlegroups.com_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.
>>>
>>
>>
>> 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
>>
>> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
--
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.
