I''m trying to make puppet disable and stop some services on a bunch of Debian boxes, but I''m running into some problems. The puppet server is running 2.6.4, downloaded from puppetlabs.com, the Deb5 clients do as well, while the Deb6 clients use 2.6.2 as shipped in the Deb6 repos(though I did try 2.6.4 on one Deb6 box just to rule that out, no difference). Debian 5/Lenny: Things mostly work fine here, the exception being nfs-common which won''t be shutdown. I assume this is because puppet runs ps -ef to try to find the process rather than using the init script. I can work around this by providing more parameters for the nfs-common service in the manifest, but I''m still curious why Puppet won''t just use the init script when the service provider is Debian? Debian 6/Squeeze: Same thing with stopping nfs-common here. Disabling services doesn''t work at all though. "puppet agent -t -d" says it''s running f.e "/usr/sbin/update-rc.d -f nfs-common remove", this command works fine if I run it on the command line, so I really have no idea why it doesn''t work. Though unless I''m missing something a saner way to disable services would be to run "update-rc.d $service disable" in Debian 6, though I suppose maybe this simply isn''t implemented yet since Squeeze isn''t released yet? If so, does anyone know if this is in the works for say 2.6.5? On that note I''ve noticed that puppet will claim to run the same update-rc.d command under Debian 5 while it really doesn''t seem to, since under Deb5 it will actually change the S links to K links, whereas "update-rc.d -f $service" remove" will remove the rcX.d symlinks alltogether. Anyways, I guess in the end what I would really like is some clarification on how this all works under Debian so I will know what to expect. I did find some bugs filed against older puppet versions running on Debian, but nothing against 2.6. Thanks. Johan -- 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.
On Wed, Jan 26, 2011 at 22:52, Johan Sunnerstig <Johan.Sunnerstig@auriga.se> wrote:> I''m trying to make puppet disable and stop some services on a bunch of > Debian boxes, but I''m running into some problems. > The puppet server is running 2.6.4, downloaded from puppetlabs.com, the Deb5 > clients do as well, while the Deb6 clients use 2.6.2 as shipped in the Deb6 > repos(though I did try 2.6.4 on one Deb6 box just to rule that out, no > difference). > > Debian 5/Lenny: > Things mostly work fine here, the exception being nfs-common which won''t be > shutdown. I assume this is because puppet runs ps -ef to try to find the > process rather than using the init script. I can work around this by > providing more parameters for the nfs-common service in the manifest, but > I''m still curious why Puppet won''t just use the init script when the service > provider is Debian?...because a whole bunch of init scripts on Debian didn''t provide a functional ''status'' method, which meant that puppet would fail in a whole other exciting way. :(> Debian 6/Squeeze: > Same thing with stopping nfs-common here. Disabling services doesn''t work at > all though. "puppet agent -t -d" says it''s running f.e > "/usr/sbin/update-rc.d -f nfs-common remove", this command works fine if I > run it on the command line, so I really have no idea why it doesn''t work. > Though unless I''m missing something a saner way to disable services would be > to run "update-rc.d $service disable" in Debian 6, though I suppose maybe > this simply isn''t implemented yet since Squeeze isn''t released yet? If so, > does anyone know if this is in the works for say 2.6.5?We already have a bug report about this, and the problem is that we can''t just tell users of stable to stick with older version of puppet – so the Debian provider needs to support both r5 and r6, which means detecting the availability of the ''disable'' option and using it when possible. Given we are under some release pressure at the moment ourselves you can move this along by providing concrete information about how we can determine if ''disable'' is supported, ideally without mistaking "failed to disable" for "can''t disable". Patches also happily accepted, of course. :)> Anyways, I guess in the end what I would really like is some clarification > on how this all works under Debian so I will know what to expect. I did find > some bugs filed against older puppet versions running on Debian, but nothing > against 2.6.You seem to pretty much have it nailed down; the only other consideration is that puppet is often backported in Debian, and we do expect to support non-Debian packages and custom backports (more or less) in the code. Regards, Daniel -- ⎋ Puppet Labs Developer – http://puppetlabs.com ✉ Daniel Pittman <daniel@puppetlabs.com> ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775 ♲ Made with 100 percent post-consumer electrons -- 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.
> ...because a whole bunch of init scripts on Debian didn''t provide a > functional ''status'' method, which meant that puppet would fail in a > whole other exciting way. :(So I guess the best way to solve it on my end would be to simply specify hasstatus and such per service I guess?> We already have a bug report about this, and the problem is that we > can''t just tell users of stable to stick with older version of puppet > – so the Debian provider needs to support both r5 and r6, which means > detecting the availability of the ''disable'' option and using it when > possible. > > Given we are under some release pressure at the moment ourselves you > can move this along by providing concrete information about how we can > determine if ''disable'' is supported, ideally without mistaking "failed > to disable" for "can''t disable".> Patches also happily accepted, of course. :)Aside from being a pretty horrible programmer, I also know next to nothing about Ruby. :) That said, the only things I can think of off the top of my head are ugly(checking for the enable/disable syntax line, checking /etc/debian_version, etc). I guess the "least ugly" thing I can think of is to check the sys-rc version with something like "dpkg-query -W -f=''${Version}\n'' sysv-rc", seems like enable/disable was included in 2.87, Deb5 runs 2.86 and Deb6 runs 2.88. Then again, with the subversions that''s gonna be annoying unless you cut it off at 4 characters, and that''s ugly. Ah well, like I said, I''m a pretty horrible programmer. :)> You seem to pretty much have it nailed down; the only other > consideration is that puppet is often backported in Debian, and we do > expect to support non-Debian packages and custom backports (more or > less) in the code.Any idea how people in general are dealing with this on Deb6 boxes? I guess a pair of enable/disable parameters with custom commands to enable or disable service would solve it in a way. Then again I can just use an exec for that myself.> Regards, > Daniel > -- > ⎋ Puppet Labs Developer – http://puppetlabs.com > ✉ Daniel Pittman <daniel@puppetlabs.com> > ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775 > ♲ Made with 100 percent post-consumer electronsThanks for the reply, much appreciated. Oh and sorry for the horrible formatting, I''m stuck in Outlook Web Access hell. -- 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.
On Jan 27, 2011 4:58 AM, "Johan Sunnerstig" <Johan.Sunnerstig@auriga.se> wrote:> > > ...because a whole bunch of init scripts on Debian didn''t provide a > > functional ''status'' method, which meant that puppet would fail in a > > whole other exciting way. :( > > So I guess the best way to solve it on my end would be to simply specifyhasstatus and such per service I guess? Uh-huh. If the status argument to init scripts becomes more robustly available we might look to being smarter, but for now you need to check that and tell puppet. Sorry.> > We already have a bug report about this, and the problem is that we > > can''t just tell users of stable to stick with older version of puppet > > – so the Debian provider needs to support both r5 and r6, which means > > detecting the availability of the ''disable'' option and using it when > > possible. > > > > Given we are under some release pressure at the moment ourselves you > > can move this along by providing concrete information about how we can > > determine if ''disable'' is supported, ideally without mistaking "failed > > to disable" for "can''t disable". > > > Patches also happily accepted, of course. :) > > Aside from being a pretty horrible programmer, I also know next to nothingabout Ruby. :) Well, I figure it never hurts to ask. :) Regards, Daniel -- Puppet Labs Developer –http://puppetlabs.com Daniel Pittman <daniel@puppetlabs.com> Contact me via gtalk, email, or phone: +1 (877) 575-9775 Sent from a mobile device. Please forgive me if this is briefer than usual. -- 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.