Oh, and I forgot to mention, it appears that unfortunately --config is 
also one of the ignored arguments.

David Sowder wrote:
> Is there a bug filed for this ignored command-line argument issue?  Is 
> it no longer an issue on 0.25?
>
> I've done further testing based on your message and it appears that if 
> puppetd.conf exists, even if its contents are identical to those of 
> the puppet.conf file placed there by the RPM, the command-line 
> arguments are ignored.  Perhaps the RPM should migrate old 
> puppetd.conf files to puppet.conf or at the least move it out of the 
> way.  (I'll probably mod my RPM to move it out of the way since there 
> are no local changes in our puppetd.conf files nor do we currently 
> think any are needed to the RPM provided puppet.conf file.)
>
> Tools designed to make a system administrator's life easier shouldn't 
> cause such confusion... :)
>
> Neil Prockter wrote:
>> puppetd.conf is no more, use puppet.conf
>>
>> Many people have had the same confusing situation with --noop being
>> similarly ignored.
>>
>> Neil
>> David Sowder wrote:
>>  
>>> I'm in the process of upgrading a bunch of our Puppet clients from 
>>> 0.22.4 to 0.24.8 after recently upgrading our puppetmaster similarly.
>>>
>>> I've run into a problem that seems like it'd be so likely seen by 
>>> someone else that if the problem isn't local, I'd be somewhat 
>>> surprised, yet at the same time, my install is simply a locally 
>>> compiled copy of a source RPM from Fedora's EPEL project IIRC (from 
>>> the .spec file changelog: "Mon Mar 23 2009 Todd Zullinger 
>>> <t...@pobox.com> - 0.24.8-1.1").
>>>
>>> The client is a RHEL 5 x86_64 box and the issue seems to boil down 
>>> to "--server puppet.uta.edu" not working as a command-line argument 
>>> to /usr/sbin/puppetd (with no complaint about an unknown argument 
>>> like it does with "--Server puppet.uta.edu") but working fine if I 
>>> specify a "server = puppet.uta.edu" line in my 
>>> /etc/puppet/puppetd.conf file.  It looks like there is some sort of 
>>> systematic problem since both "--genconfig" and "--configprint all" 
>>> don't seem to have any effect.
>>>
>>> An example of "--server" failing to recognized:
>>>
>>> # /usr/sbin/puppetd --server puppet.uta.edu --test
>>> warning: Certificate validation failed; consider using the certname 
>>> configuration option
>>> err: Could not retrieve catalog: Certificates were not trusted: 
>>> hostname not match with the server certificate (hostname: puppet  
>>> CNs: puppet.uta.edu, )
>>> warning: Not using cache on failed catalog
>>> #
>>>
>>> (The stuff in parenthesis at the end was a local hack I made to 
>>> /usr/lib/ruby/1.8/openssl/ssl.rb when trying to track down the issue.)
>>>
>>> "/usr/sbin/puppetd --test --configprint all" gives the same output 
>>> as above.
>>>
>>> Any ideas on what I may have screwed up that causes these 
>>> command-line options to be ignored?  "--test" is not ignored, so it 
>>> might have something to do with how the options are defined.
>>>
>>>     
>>
>>   
>


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to