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