--DBIVS5p969aUjpLe
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Feb 10, 2007 at 11:20:10AM -0600, Jeremy C. Reed wrote:
  | As discussed in December and January, here are a few patches (including=
=20
  | for man page) so rc.subr doesn't check rcvar for YES except at=20
  | boot/shutdown. (This was the "admin script for ipfilter" thread. Note t=
hat=20
  | this patch does not add any "enable" or "disable" option and this doesn=
't=20
  | add a new rcadmin(8) command.)
  |=20
  | This means the default usage of rc.subr changes. (This adds an "only"=
=20
  | prefix.)
  |=20
  | As an example, this means that running "status" of a disabled rc.d scri=
pt=20
  | will give output.
  |=20
  | This also means that the admin can run "start" and "stop" on some=20
  | arbritary rc.d script and it will attempt to do what they expect.
  |=20
  | Note if you don't update your rc and rc.shutdown accordingly, it will=
=20
  | really attempt to start and stop all rc.d services.
  |=20
  | Also using "one" prefix now makes no sense.
  |=20
  | I have only tested this a little. Your feedback is appreciated.
  |=20
  | By the way, I have taught our rc.d usage in several FreeBSD and NetBSD=
=20
  | admin classes and I use our rc.subr system in my Linux distribution.=20
  | Having to preconfigure or use the "force" or newer "one" prefix isn't=
=20
  | consistent with what many admins, including myself, expect.

I'm ambivalent about the proposed user-interface change.

I understand the argument about the behaviour being closer to what
(Linux) sysadmins expect, but don't forget that such Linux systems
usually don't install the rc.d script for an uninstalled service,
and they usually automatically start and enable a service upon
installation.

(This difference of behaviour with Linux (not that there was any
reasonable consistent standard in UNIX when we developed rc.d(8))
is why the directory is /etc/rc.d and not /etc/init.d.)

Having the ability to control whether the existing NetBSD practice
or your proposed practice (via an rc.conf(5) var?) may be useful.

Have you considered discussing this with the FreeBSD folks, since
they use a derivative of rc.d(8) in their system?

In any case, _if_ this change is performed, it should be noted in
an obvious place as a "Behaviour Change" so that people don't get
bitten as easily. (I.e, don't just commit changes to rc.subr and
rc.conf.5 and note the change in para 5591 of the release notes :-)



cheers,
Luke.

--DBIVS5p969aUjpLe
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (NetBSD)

iD8DBQFF0PeNpBhtmn8zJHIRApGfAJ9YHTLVQrQGMF3VqMb/Vs3tdNawiACeJ/NP
oPH+4ssEZ/Vh5gZJGYHzQ/c=
=GB6o
-----END PGP SIGNATURE-----

--DBIVS5p969aUjpLe--