David Sowder
2009-Sep-17 19:53 UTC
[Puppet Users] puppetd --server and server option in puppetd.conf
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 <tmz@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. -- David R. Sowder, Linux Systems Admin (Software Systems Specialist II) Office of Information Technology, University of Texas at Arlington Work: 817-272-1081 davids@uta.edu http://www.uta.edu/ davids@talk.uta.edu (Jabber) Personal: david@sowder.com http://david.sowder.com/ --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Neil Prockter
2009-Sep-17 21:33 UTC
[Puppet Users] Re: puppetd --server and server option in puppetd.conf
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 <tmz@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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
jcbollinger
2009-Sep-18 13:37 UTC
[Puppet Users] Re: puppetd --server and server option in puppetd.conf
On Sep 17, 2:53 pm, David Sowder <davidrsow...@gmail.com> 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.I have no idea what you may have done wrong, if anything, but for my CentOS 5 / x86(32) environment I downloaded the 0.24.8 source tarball from ReductiveLabs, updated the included rpm spec file slightly (reply to me by e-mail if you want details), and built it. The resulting RPM works for me, including puppetd command-line options. It is perhaps relevant that I have /etc/puppet/puppet.conf on my systems, but no / etc/puppet/puppetd.conf. John --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Neil Prockter
2009-Sep-18 14:06 UTC
[Puppet Users] Re: puppetd --server and server option in puppetd.conf
jcbollinger wrote:> > > On Sep 17, 2:53 pm, David Sowder <davidrsow...@gmail.com> 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. > > I have no idea what you may have done wrong, if anything, but for my > CentOS 5 / x86(32) environment I downloaded the 0.24.8 source tarball > from ReductiveLabs, updated the included rpm spec file slightly (reply > to me by e-mail if you want details), and built it. The resulting RPM > works for me, including puppetd command-line options. It is perhaps > relevant that I have /etc/puppet/puppet.conf on my systems, but no / > etc/puppet/puppetd.conf. >without any shame for quoting myself... puppetd.conf is no more, use puppet.conf Many people have had the same confusing situation with --noop being similarly ignored. Neil 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Todd Zullinger
2009-Sep-18 14:35 UTC
[Puppet Users] Re: puppetd --server and server option in puppetd.conf
jcbollinger wrote:> I have no idea what you may have done wrong, if anything, but for my > CentOS 5 / x86(32) environment I downloaded the 0.24.8 source tarball > from ReductiveLabs, updated the included rpm spec file slightly (reply > to me by e-mail if you want details), and built it.May I ask (if I haven''t already asked you before :) if any of the changes you made might be suitable for the included puppet.spec file and/or the Fedora/EPEL packaging? -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If the human mind was simple enough to understand, we''d be too simple to understand it. -- Emerson Pugh
David Sowder
2009-Sep-22 15:47 UTC
[Puppet Users] Re: puppetd --server and server option in puppetd.conf
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 <tmz@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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
David Sowder
2009-Sep-22 15:50 UTC
[Puppet Users] Re: puppetd --server and server option in puppetd.conf
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 >>> <tmz@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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
R.I.Pienaar
2009-Sep-22 16:01 UTC
[Puppet Users] Re: puppetd --server and server option in puppetd.conf
hello, ----- "David Sowder" <davidrsowder@gmail.com> wrote:> Is there a bug filed for this ignored command-line argument issue? Is > it no longer an issue on 0.25?http://projects.reductivelabs.com/issues/2176 -- R.I.Pienaar --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Neil Prockter
2009-Sep-22 16:07 UTC
[Puppet Users] Re: puppetd --server and server option in puppetd.conf
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 >>> <tmz@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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
R.I.Pienaar
2009-Sep-22 16:11 UTC
[Puppet Users] Re: puppetd --server and server option in puppetd.conf
hello, ----- "Neil Prockter" <n.prockter@lse.ac.uk> wrote:> 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)Take another look, it does not create this file if you''re just adding a new package on a clean machine: %ghost %config(noreplace,missingok) %{_sysconfdir}/puppet/puppetd.conf From the RPM docs: " As we mentioned in the Section called The %files List, if a file is specified in the %files list, that file will automatically be included in the package. There are times when a file should be owned by the package but not installed - log files and state files are good examples of cases you might desire this to happen. The way to achieve this, is to use the %ghost directive. By adding this directive to the line containing a file, RPM will know about the ghosted file, but will not add it to the package. However it still needs to be in the buildroot." but if you had a package prior to this behavior and you upgrade it wont delete your old {puppetd,puppetmasterd}.conf files, however the bug - that''s fixed already in 0.25 - caused that to be a problem, its a common FAQ one that would have been solved in about a minute on the IRC channel. Problem some kind of release not on the RPM should mention this, but as this is a known bug and a very simple search for "puppetd.conf" on projects.reductivelabs.com would have found the issue I dont know why this is such a big issue. -- R.I.Pienaar --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Todd Zullinger
2009-Sep-22 16:15 UTC
[Puppet Users] Re: puppetd --server and server option in puppetd.conf
Neil Prockter wrote:> 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)The EPEL package only provides default permissions and let''s rpm know that it is a config file. It does not install it or provide any content for it, the file is marked as %ghost in the spec file). I''ve not looked closely at whether we can or should remove that entirely at this point, but it shouldn''t hurt anything as is. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Duct tape is like the Force. It has a light side, a dark side, and it holds the universe together.... -- Carl Zwanzig
David Sowder
2009-Sep-22 17:05 UTC
[Puppet Users] Re: puppetd --server and server option in puppetd.conf
I realized after sending the bit about there being a bug filed that I should have checked myself. As for the RPM, perhaps I''m a little spoiled from the Debian world (though not all packages are of equal upgrade automation) and this is not the paradigm used by most RPM authors, but I''m used to the upgrading of a package taking various steps to smooth the upgrade for me. R.I.Pienaar wrote:> hello, > > > ----- "Neil Prockter" <n.prockter@lse.ac.uk> wrote: > > >> 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) >> > > > Take another look, it does not create this file if you''re just adding a new package on a clean machine: > > %ghost %config(noreplace,missingok) %{_sysconfdir}/puppet/puppetd.conf > > From the RPM docs: > > " As we mentioned in the Section called The %files List, if a file is specified in the %files list, that file will automatically be included in the package. There are times when a file should be owned by the package but not installed - log files and state files are good examples of cases you might desire this to happen. > > The way to achieve this, is to use the %ghost directive. By adding this directive to the line containing a file, RPM will know about the ghosted file, but will not add it to the package. However it still needs to be in the buildroot." > > but if you had a package prior to this behavior and you upgrade it wont delete your old {puppetd,puppetmasterd}.conf files, however the bug - that''s fixed already in 0.25 - caused that to be a problem, its a common FAQ one that would have been solved in about a minute on the IRC channel. > > Problem some kind of release not on the RPM should mention this, but as this is a known bug and a very simple search for "puppetd.conf" on projects.reductivelabs.com would have found the issue I dont know why this is such a big issue. > >--~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---