On Wed, 8 Sep 2010 12:13:04 -0700, Nigel Kersten <[email protected]> wrote:
> On Wed, Sep 8, 2010 at 12:05 PM, James Cammarata <[email protected]> wrote:
>>
>> On Wed, 8 Sep 2010 12:02:09 -0700, Nigel Kersten <[email protected]>
>> wrote:
>>> On Wed, Sep 8, 2010 at 11:39 AM, James Cammarata <[email protected]> wrote:
>>>>
>>>>> Just for the record, I have many tens of thousands of 0.25.4-1
>>>>> clients, and I've never ever seen this problem with pluginsync.
>>>>
>>>> Yep, just upgraded to 0.25.5-1 from EPEL and the issue/URL is the
same:
>>>>
>>>> [2010-09-08 14:34:51] myserver - - [08/Sep/2010:14:34:51 EDT] "GET
>>>>
>>
/production/file_metadatas/plugins?recurse=true&&ignore=---+%0A++-+.svn%0A++-+CVS%0A++-+.git&links=manage
>>>> HTTP/1.1" 400 45
>>>> [2010-09-08 14:34:51] - ->
>>>>
>>
/production/file_metadatas/plugins?recurse=true&&ignore=---+%0A++-+.svn%0A++-+CVS%0A++-+.git&links=manage
>>>>
>>>>
>>>> The odd thing is, I'm not using environments, but the production entry
>> is
>>>> in that url... I wonder if it's secretly using them somehow, but
>>>> frankly
>>>> I'm out of ideas at this point.
>>>
>>> production is the default environment, so that does make some sense.
>>>
>>> So I take it you've defined a default modulepath underneath
>>> [puppetmasterd] but haven't defined any environments?
>>>
>>> Are you sure your client is connecting to the modulepath that you're
>>> adding facts to? Have you confirmed that with a manifest and
>>> --no-pluginsync ?
>>
>> Yes, that is how I have things setup. Even with the gsub error, the
>> client
>> continues to parse the manifest and apply it correctly, it just doesn't
>> pull down the custom facts. We've had a working puppet setup for
>> months,
>> it was only yesterday that I started trying out custom facts, so I know
>> everything was working up until then. I had noticed issues in the past
>> with recursive directories though, and had just ignored it and not used
>> them (not much need for it), but it seems that this would be the
>> underlying
>> issue.
>
> I wonder if things start working for you if you define a [production]
> environment with the same modulepath?
Definitely ruby's fault on this one, apparently. The original system I was
testing on is RHEL4, with ruby 1.8.1-7. I just tested the exact same
configs on a RHEL5 box with ruby 1.8.5-5 and it worked flawlessly:
# /usr/sbin/puppetd --no-daemonize --onetime --ignoreschedules
--color=false --reports=false --verbose --no-usecacheonfailure --noop
info: Retrieving plugin
info: Caching certificate_revocation_list for ca
notice: /File[/var/lib/puppet/lib/facter]/ensure: created
notice: /File[/var/lib/puppet/lib/facter/hw_type.rb]/ensure: content
changed '{md5}02adcd0c46df8d655b52b57d40f24e2c' to
'{md5}02adcd0c46df8d655b52b57d40f24e2c'
So, the question is, obviously it's a problem with an older ruby version,
but should puppet be more careful about the URLs it crafts and sends so
that this problem doesn't come up? RHEL4 is still supported, isn't it?
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
