--pgp-sign-Multipart_Wed_Mar_28_13:36:03_2007-1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

At Tue, 20 Mar 2007 21:26:25 -0700, Scott Ellis wrote:
Subject: Re: rc local [patches]
>=20
> Greg A. Woods wrote:
> > At Mon, 19 Mar 2007 20:10:12 -0700,
> > Scott Ellis wrote:
> >>   The root of what is being proposed is the ability to use rc.d/ stype
> >> scripts rather than the rc.local file.  The proposal to extend rc.local
> >> into "modern" NetBSD times by allowing rc.local.d/ seems reasonable, a=
nd
> >> preserves the differentiation between 'OS' and 'local' scripts.
> >>
> >> I for one welcome the thought of an rc.local.d/ .
> >=20
> > I can assure you that such artificial separation of things that are best
> > kept together is a very BAD idea.  It leads to frustration and
> > unnecessary complexity, and those things _always_ lead to very serious
> > mistakes even by the most careful of system managers.
>=20
> That same argument can be made against the current (and historic)=20
> rc.local.

Well, not exactly.  The current /etc/rc.local and /etc/rc.shutdown.local
hooks are for the inevitable exceptions that crop up in the real-life
needs of production systems.  I.e. it's for hacks that don't demand full
start/stop/status/etc controls, etc.

For example with the buggy aac(4) driver I've got the following in
/etc/rc.local on my Dell PE2650 to work around it:

	nohup sh -c 'while : ; do dd if=3D/dev/rld0d of=3D/dev/null count=3D1; sle=
ep 1; done' &

>  Are you proposing that rc.local support be removed?  (I don't=20
> think you are, but I'm failing to see the difference between rc.local=20
> and rc.local.d in concept.)

No definitely not.

rc.local.d is different because it doesn't add anything we don't already
have.  The local one-off hacks belong in rc[.shutdown].local where
certain assumptions can be made about the state of the system and where
those hacks don't have to be fully compliant with the full /etc/rc.d
interface.

Meanwhile real start/stop scripts that do conform to the full /etc/rc.d
interfaces belong in /etc/rc.d _only_.

> > The current system is very simple and very easy to manage (when used
> > correctly), regardless of whether add-on packages are installed manually
> > or via pkg_*.
>=20
> That is a bit subjective (as is the majority of the discussion).

I'm not sure what you mean by that.  It is easy to show _objectively_
how the current system is managable with clearly simple tools and
concepts and without adding the complexity of another rc.local.d
subdirectory, including for meeting all of the requirements that have
been stated or alluded to in this thread.  Neither you nor anyone else
have shown any hint of any issues or problems with how the current
system and tools can be used to easily meet any of the stated
requirements without infrastructure changes or additions.

>  I believe the original proposal was to overcome a (at least perceived)=20
> problem.

No doubt.  However the same perceived problem is equally well overcome
with grep.

>  Does adding rc.local.d (or whatever) preclude doing it the=20
> current 'very simple and very easy' way?

Indeed it does, demonstrably.  I and others have already explained the
many problems it raises.

>  I didn't see that it did.  At=20
> the same time, it makes life easier for some folks (who for whatever=20
> reason choose not to use the current unified rc.d).

Well, they might _perceive_ that it makes one tiny aspect of managing
their systems easier.  However it's easy to show that appropriate uses
of "grep" or similar tools will bring the very same benefits without any
of the downfalls.

> I'm not arguing _for_ and rc.local.d, just chiming in that I've found it =

> an odd thing to be missing, and personally prefer that model of keeping=20
> vendor-supplied scripts separated from site-specific scripts.

Local "live" copies of vendor-supplied (e.g. pkg supplied) rc.d scripts
get installed directly into /etc/rc.d, just like other vendor-supplied
config files get installed directly into /etc and/or /etc/<a-pkg-nm>/*

The model of keeping vendor-supplied stuff separate from site-specific
stuff (and presumably separate from original system stuff) is seriously
flawed, and demonstrably adds to the complexity of both the design and
implementation of the system as well as its management.  Complexity is
sometimes a necessary evil, but in this case it is entirely unnecessary
since a conceptual separation of vendor, site, and system stuff is
trivial to implement and use without acuatally requiring separate
directories or files, or other forms of physical separation.

--=20
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>       Secrets of the Weird <woods@weird.com>

--pgp-sign-Multipart_Wed_Mar_28_13:36:03_2007-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: RZkvZAbEBwVPg1byXasDY9qtm3vZiU8w

iQA/AwUBRgq1lGZ9cbd4v/R/EQK2xgCfUCz+L2mqw7PuHO8KYdktx/f77nAAoNpV
RVjLqpz/mYp8FVeElzD+3vih
=D8Ix
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Wed_Mar_28_13:36:03_2007-1--