Tomoyuki Sakurai wrote:> Hi,
>
> I''d like to hear opinions from FreeBSD users. I''ve wrote
a freebsd service
> provider, which is available as Ticket #837.
>
> http://reductivelabs.com/trac/puppet/ticket/837
>
> This hack extends init service provider, by adding enable method. With
> freebsd.rb, you can enable services like other service providers do.
>
> service { foo:
> ensure => running,
> enable => true,
> ...
> }
>
> service { foo:
> ensure => stopped, # no need to modify rc.conf
> enable => false,
> ...
> }
>
> To apply the patch, download and save the patch, copy it
> under /usr/ports/sysutils/puppet/files
> (or, /usr/ports/sysutils/puppet-devel/files if you''re using
puppet-devel),
> update and restart puppet.
>
> freebsd.rb invokes an external script to enable or disable services. The
> attached file to this message is rc-update, which modifies rc.conf. To give
> it a try, simply copy it under /usr/local/sbin, execute "rc-update
enable
> the-service-name-to-enable".
>
> etc-update is meant to be used to enable or disable by adding
foo_enable="..."
> in rc.conf. The problem I am trying to solve is, when you want to start a
> service, foo_enable must be set to YES. Another problem is, when you want
to
> stop and disable a running service, you must *NOT* set foo_enable to NO
> before stopping the service.
>
> * you make a change to rc.conf, foo_enable to "NO", preventing if
from running
> at boot
> * stop the service in site.pp, service { foo: ensure => stopped }
> * commit the changes to the repository
> * the service doesn''t stop (you should have stopped it before
modifying
> rc.conf!)
I think this whole problem can be avoided by just using the forcestop init
target for
ensure => stopped. That way the service will be stopped regardless of the
setting in
rc.conf and avoids the race condition.
>
> My solution is a hack in that it cannot use templates for rc.conf
(actually,
> it can, but a mess). Proper use of rc.conf.local might solve the issue.
>
> This patch and rc-update are not in Puppet tree nor in Ports tree (FreeBSD
> commiter doesn''t like rc-update).
Why not just implement this in the provider (i.e. in ruby)? More generally, we
just need a
general text processing facility that handles adding/removing/modifying
key=value pairs
and have the provider use that.
>
> Another solution to the issue is to distribute each rc.conf with puppet.
See
> scott''s solution.
>
> [Puppet-users] handling rc.conf / freebsd init scripts
> http://mail.madstop.com/pipermail/puppet-users/2007-September/004315.html
>
> IMO, his solution is better in that you can manage both rc.conf and
services
> well. However, I''d like to manage services like other service
providers do.
The correct solution is for the service provider to manage the service states
IMO.
Managing the rest of rc.conf should be left to other providers.
>
> What do you think?
Generating the rc.conf file from a template seems ugly. Perhaps a better
approach would be
to have a rc.conf.d with one service per file and have an rc.conf.local with
code to
source each fragment. Either that or do the append_if_no_such_line/delete_line
text
munging (rc.conf.services?) but without the external rc-update script.
--
Russell A. Jackson <raj@csub.edu>
Network Analyst
California State University, Bakersfield
So much food, and so little time!
_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users