Date: Sat, 31 Jul 2004 17:56:16 +0300 From: Mike Makonnen <mtm@identd.net> To: Oliver Eikemeier <eikemeier@fillmore-labs.com> Cc: current@freebsd.org Subject: Re: RFC: Alternate patch to have true new-style rc.d scripts in ports (without touching localpkg) Message-ID: <20040731145616.GA14576@rogue.acs-et.com> In-Reply-To: <03C7D82F-E2F5-11D8-9C56-00039312D914@fillmore-labs.com> References: <20040731104933.GA1312@rogue.acs-et.com> <03C7D82F-E2F5-11D8-9C56-00039312D914@fillmore-labs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jul 31, 2004 at 03:24:56PM +0200, Oliver Eikemeier wrote:
> Mike Makonnen wrote:
>
>
> Lets be realistic: Nearly nobody wants his scripts to be sourced in the
> startup shell, especially not in /usr/local/etc/rc.d. People who really
> want to do this are experts that exactly know what they are doing, and
> are not easily confused.
*sigh* You cannot arbitrarily declare that "nearly nobody wants his
scripts to be sourced in the startup shell". You have no idea of knowing
what a user might want to do with his system and what his level of
expertise is.
> >>Legacy script were never executed when put in
> >>/etc/rc.d, and won't after this patch. I can't really follow your
> >>argument here.
> >
> >I'm not talking about legacy scripts. I mean local rc.d scripts.
>
> Local rc.d scripts will continue to be executed as before.
except if they have a .sh extension.
>
> I'm not exactly concerned with NetBSD compatibility here, especially
> considering the facts that (a) rc.subr has already set_rcvar with `case
> ${OSTYPE}' in it (only in the FreeBSD version, I can't find that in
> NetBSD), which doesn't exist in NetBSD, (b) The only two scripts with
> an `.sh' extension (early.sh rcconf.sh) are FreeBSD specific, while the
> only NetBSD script with an `.sh' extension (bootconf.sh) doensn't exist
> in FreeBSD. Compatibility with NetBSD seems to be a myth, especially
> since they never bothered to merge the changes back from FreeBSD.
I don't mean source code compatibility. I don't really care *too much*
about that either. What I am concerned with is compatibility
behaviour-wise.
>
> >>>Also, a sysadmin
> >>>might have a local script in /usr/local/etc/rc.d that may for example,
> >>>load a different rc.conf depending on circumstances.
> >>
> >>{He,She} might, although I consider such a functionality to be exotic
> >>and fragile. Anyway, /etc/rc.d could be used for that purpose.
> >
> >You have no way of knowing what users want to do or what their
> >circumstances
> >are. This would be be an instance of enforcing policy instead of
> >providing mechanisms for users to do what they want.
>
> When you have no way of knowing what users want to do, how can you
> provide mechanisms for them to do so?
By leaving their options open. By not forcing them to do it one way.
> (a) I want rc.d scripts in /usr/local/etc/rc.d to behave exactly like
> they do in /etc/rc.d, namely participate in rcorder(8). This was the
> most common reason to move scripts from /usr/local/etc/rc.d to /etc/rc.d.
If ports rc.d scripts with .sh extensions aren't sourced in the same shell,
then they don't behave "exactly like they do in /etc/rc.d". Participating
in the boot ordering is not the stick by which the "rc.d'ness" (for lack
of a better word) of a script is measured.
>
> (b) While doing this, I want to keep documented behaviour, so users can
> keep what worked for them before.
Correction-- what worked for them in most of 5-CURRENT up to now.
> We shouldn't break backwards compatibility for no good reason.
> Compatibility with NetBSD in aspects we never have been compatible is
> not a good reason to introduce an incompatiblity with -CURRENT.
We *have* been compatible with respect to behaviour of an rc.d script.
While we have digressed somewhat by *adding* features, the base behaviour
is the same.
Additionaly, compatibility with -CURRENT is not a valid
excuse for introducing hacks or allowing buggy behaviour to continue.
>
> >>>2. Sourcing of ports rc.d scripts with the base sytem scripts to be
> >>> put behind a knob. If the knob is enabled rc.d/localpkg does not
> >>> run rc.d scripts in the local_startup directories. If it is turned
> >>> off, then rc.d/localpkg does ports rc.d scripts in addition to the
> >>> legacy scripts.
> >>
> >>I see no reason why localpkg should do rc.d scripts. It was always
> >>meant
> >>to execute old-style scripts, and this behavior shouldn't be changed.
> >>Why do you want to introduce a semantic split here, that you seem to
> >>try
> >>to avoid above?
> >
> >This feature MUST be put behind a knob. It
> >might have been okay if we had discussed this earlier in the 5-CURRENT
> >lifecycle, but not just before 5-STABLE. We need more time to evaluate
> >the impact of ordering ports rc.d scripts with the base system scripts.
> >Two weeks is not enough time.
>
> I see absolutely no problems with having this feature now. You wanted
> similar behaviour of scripts in /etc/rc.d and /usr/local/etc/rc.d, and
> this is what this patch provides.
*sigh* No, it doesn't. It hacks rc.d to treat /usr/local/etc/rc.d scripts
with a .sh extension as old style scripts. That is not the same thing.
> It is completely backwards compatible,
> so we don't have to fear breakage. Every new port that starts to
> participate in rcorder(8) could be tested individually by the maintainer
> before submitting, so this should be pretty save.
NO, because it's impossible for the maintainer to test it with even a
fraction of the possible combinations. Remember that the script has to
play nice with the scripts as they are currently in /etc/rc.d, with any
future changes we might have to make to the ordering, with any
new scripts we might add in the future (or we might have to remove
a script the script depends on), with current ports rc.d scripts,
with future ports rc.d scripts, and with any local rc.d scripts
written by a user. By defenition, it is impossible for a maintainer
to be absolutely certain that his script will not break something.
> And we have time for
> an adequate migration phase, which will help us detect problems. What
> should be the issues of ordering ports rc.d scripts with the base system
> scripts, especially when we require that nearly every of them has a
> `REQUIRE: LOGIN' line? I except very few have the need for something
> else, but the base will greatly benefit from them.
>
1. Not all ports require that they be ordered with the base system scripts. As
such not all users will benefit from ports being ordered along with the
base system. It makes sense that these people be able to reduce their
security exposure by keeping the ports startup order as it is now
(i.e. somewhat separate from the base system scripts).
2. This is a major change that requires more than just 2 weeks of testing.
If it should happen to break something users should be able to turn it
off.
>
> Ah, no: They where relying on documented behaviour in rc(8). localpkg is
> not buggy, and should not be changed. The scripts are not buggy either,
> they are simply old-style scripts that source rc.subr and use some of
> its features. They have never been tested as rc.d scripts, but it should
> be easy to convert them to become that, since they are pretty similar.
> Nevertheless one should not be confused of their character because of
> their similarity to rc.d scripts: they are not, and should not be
> treated so. Read rc(8) on how they should be handled. What we are trying
> to do here is to introduce a *new* functionality, which requires new
> scripts (although they conversion should be easy in most cases).
>
Oh please, let's not get into semantic arguments here. If they
source /etc/rc.subr and implement the functionality that typically
defines rc.d scripts, then thay are rc.d scripts (or atleast
they are trying to be).
And since you brought up rc(8), these rc.d scripts you want to treat
as old style scripts violate one of the rules of old-style scripts:
o The output from each script is traditionally a space character, fol-
lowed by the name of the software package being started or shut down,
without a trailing newline character (see the EXAMPLES section).
rc(8) also gives a clear example of what an old-style ports script should
look like:
The following is a simple, hypothetical example of an old-style
/usr/local/etc/rc.d/ script, which would start a daemon at boot time, and
kill it at shutdown time.
#!/bin/sh -
#
# initialization/shutdown script for foobar package
case "$1" in
start)
/usr/local/sbin/foo -d && echo -n ' foo'
;;
stop)
kill `cat /var/run/foo.pid` && echo -n ' foo'
;;
*)
echo "unknown option: $1 - should be 'start' or 'stop'" >&2
;;
esac
>
> The only proposal I made in changing the behavior of rc.d is changing
> the extension to something more well thought out, like `.rc'. Said that,
> I can live with keeping `.sh' as the extension for sourcing rc.d
> scripts, although it will do us no good. Anyway, I'm not a big fan of
> changing documented behavior, be it -CURRENT or not. I think this is a
> pretty reasonable attitude, but YMMV.
Ok, can you do the following then:
1. When you (portmgr) are ready put back the rc.d/localpkg changes
2. Put the ordering of ports scripts with base system
scripts behind an rc.conf(5) knob, and modify your patch so both
/etc/rc and /etc/rc.d/localpkg do the right thing depending on whether
it's on or off.
Cheers.
--
Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
mtm@identd.net | Fingerprint: AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55
mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon !
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040731145616.GA14576>