I have always had /etc/puppet/puppetd.conf managed by puppet so I let puppet delete it.
I agree the RPM has /etc/puppet/puppetd.conf in it and it should not (I've only check the 0.24.8 from EPEL that I use) 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. >>> >>> >> >> > Please access the attached hyperlink for an important electronic communications disclaimer: http://www.lse.ac.uk/collections/secretariat/legal/disclaimer.htm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
