rc, rc.shutdown proposed change
Aidan Cully
monthly.local, &c., why not rc.d.local?
--- rc.orig Sat Mar 11 20:27:29 2000
+++ rc Sat Mar 11 20:25:53 2000
@@ -28,7 +28,7 @@
trap : 2
trap "echo 'Boot interrupted.'; exit 1" 3
-files=`rcorder /etc/rc.d/*`
+files=`rcorder /etc/rc.d/* /etc/rc.d.local/*`
for i in $files; do
run_rc_script $i start
--- rc.shutdown.orig Sat Mar 11 20:27:40 2000
+++ rc.shutdown Sat Mar 11 20:26:08 2000
@@ -24,7 +24,7 @@
trap : 2
trap "echo 'Shutdown interrupted.'; exit 1" 3
-files=`rcorder /etc/rc.d/*`
+files=`rcorder /etc/rc.d/* /etc/rc.d.local/*`
for i in $files; do # reverse order of files
nfiles="$i $nfiles"
done
--aidan
Nathan J. Williams
> I hope this isn't too controversial... We've got rc.local.conf,
> monthly.local, &c., why not rc.d.local?
What's wrong with just putting local files in /etc/rc.d itself? While
the system-supplied files in /etc/rc.d might reasonably considered
system-owned code rather than user-tweakable configuration, the
contents of /etc/rc.d are fully adjustable by the sysadmin.
- Nathan
Scott Aaron Bamford
i quite like to seperate what is mine, and what is the systems. What if,
say ssh (openssh) became intergrated with the core system, and was added
to /etc/rc.d. Yes make build will not override it, but i think the point
is that things under /etc/rc.d i would know had been configured pretty
well by the system (may need tweeking but...) while everything under
/etc/rc.d.local/ was under my control. So i dont come back in 6 months
after the system has been upgraded and wounder just which files were under
my control again...
- Scott
--------------------------------------
s...@zeekuschrist.com | s...@ansic.net
Aidan Cully
"What he said." I think that if an admin wants to create his own rc.d
scripts, he'll want to have an easy way to identify which scripts are
his own, and which came with the system (or pkgsrc, or whatever). It
should only help if NetBSD provided an easy way to do that.
--aidan
Andrew Brown
>scripts, he'll want to have an easy way to identify which scripts are
>his own, and which came with the system (or pkgsrc, or whatever). It
>should only help if NetBSD provided an easy way to do that.
grep -l THISISMINE /etc/rc.d/*
??? :)
--
|-----< "CODE WARRIOR" >-----|
codew...@daemon.org * "ah! i see you have the internet
twof...@graffiti.com (Andrew Brown) that goes *ping*!"
and...@crossbar.com * "information is power -- share the wealth."
Simon J. Gerraty
>monthly.local, &c., why not rc.d.local?
Umm if you do this, please use rc.local.d so that the convention that
a directory name ending in .d contains files to process is maintained.
--sjg
Martin Husemann
> >scripts, he'll want to have an easy way to identify which scripts are
> >his own, and which came with the system (or pkgsrc, or whatever). It
> >should only help if NetBSD provided an easy way to do that.
>
> grep -l THISISMINE /etc/rc.d/*
Besides being able to tell which are mine, I don't like new invented system
files overwriting my local extensions with the same name by pure chance (or
bad naming conventions).
Martin
Hubert Feyrer
Yeah. and this is exactly we we don't put pkgs into /usr/bin. :-)
- Hubert
--
Microsoft: "Where do you want to go today?"
Linux: "Where do you want to be tomorrow?"
BSD: "Are you guys coming, or what?"
Jaromir Dolecek
> > >"What he said." I think that if an admin wants to create his own rc.d
> > >scripts, he'll want to have an easy way to identify which scripts are
> > >his own, and which came with the system (or pkgsrc, or whatever). It
> > >should only help if NetBSD provided an easy way to do that.
> >
> > grep -l THISISMINE /etc/rc.d/*
>
> Besides being able to tell which are mine, I don't like new invented system
> files overwriting my local extensions with the same name by pure chance (or
> bad naming conventions).
Exactly. I think adding /etc/rc.local.d/ too (with hook in rc and a note
in manpage) would be a good thing.
Jaromir
--
Jaromir Dolecek <jdol...@NetBSD.org> http://www.ics.muni.cz/~dolecek/
@@@@ Wanna a real operating system ? Go and get NetBSD, damn! @@@@
Frank van der Linden
> > grep -l THISISMINE /etc/rc.d/*
>
> Besides being able to tell which are mine, I don't like new invented system
> files overwriting my local extensions with the same name by pure chance (or
> bad naming conventions).
That sounds like a good idea at first glance, but imagine a situation where
you want to stop/start/restart a subsystem. Now you'll have to first
remember if it's a system-delivered system, or a package, or a "local"
one, because you need to grab it from either /etc/rc.d, /etc/rc.pkg.d
or /etc/rc.local.d. And you don't want those in your $PATH either.
That's not a good thing. Though it may seem less elegant at first, putting
them all into /etc/rc.d is the best idea.
Or: you can create /etc/rc.local.d and /etc/rc.pkg.d and symlink them
from /etc/rc.d. In that case you can still easily see which ones
are "yours".
- Frank
Luke Mewburn
> I hope this isn't too controversial... We've got rc.local.conf,
> monthly.local, &c., why not rc.d.local?
As someone else mentioned, rc.local.d is more consistent.
I'm going to make the following changes:
a) Rename the dummy placeholder scripts daemon, login and servers
to DAEMON, LOGIN and SERVERS (respectively). This makes it far
more obvious that they're placeholder nodes to depend other
nodes from. E.g, you can have a local script that depends upon
LOGIN.
b) Add support for /etc/rc.local.d, and ensure that that directory
is created during installation.
This is for local scripts.
c) Add support for /etc/rc.pkg.d, and ensure that that directory
is created during installation.
This is for packages. After a package installation a user should
copy the script from /usr/pkg/share/examples/rc.d/ to /etc/rc.pkg.d
to enable the startup.
Some people have commented that we should use /usr/pkg/etc/rc.d.
There are problems with this:
* /usr may not be mounted by the time rcorder is run.
* That directory has already being used for scripts, and
they're not using the same conventions that the new
rc.d stuff uses (e.g, don't support `stop', will cause
problems because the `.sh' filename suffix means the
script is sourced into the current environment not a
child, thus potentially causing lossage, etc).
d) Complete and commit the documentation for this project.
e) Announce it.
Luke.
Hubert Feyrer
> c) Add support for /etc/rc.pkg.d, and ensure that that directory
> is created during installation.
> This is for packages. After a package installation a user should
> copy the script from /usr/pkg/share/examples/rc.d/ to /etc/rc.pkg.d
> to enable the startup.
>
> Some people have commented that we should use /usr/pkg/etc/rc.d.
> There are problems with this:
>
> * /usr may not be mounted by the time rcorder is run.
Which could be argued as a design flaw in rcorder.
> * That directory has already being used for scripts, and
> they're not using the same conventions that the new
> rc.d stuff uses (e.g, don't support `stop', will cause
> problems because the `.sh' filename suffix means the
> script is sourced into the current environment not a
> child, thus potentially causing lossage, etc).
Which could be fixed - we'll have to touch all pkgs now anyways.
BTW, it would be nice to have one location to have all services available
at - sorta like /etc/init.d on some systems. This change moves away from
that.
Luke Mewburn
> BTW, it would be nice to have one location to have all services available
> at - sorta like /etc/init.d on some systems. This change moves away from
> that.
The problem with that (as previously mentioned) is the same reason
we install pacakges in /usr/pkg/bin and not /usr/bin; potential name
conflicts between system stuff and package stuff. Also, there's been a
convincing argument for people wanting to keep stuff separate.
If we support /etc/rc.d /etc/rc.local.d /etc/rc.pkg.d and you decide
to put everything in /etc/rc.d, then you are quite welcome to, since
the latter two directories are empty in a netbsd install anyway, and
shouldn't be modified by netbsd's installation or update procedures
since they're local stuff.
der Mouse
>> Besides being able to tell which are mine, I don't like new invented
>> system files overwriting my local extensions with the same name by
>> pure chance (or bad naming conventions).
> That sounds like a good idea at first glance, but imagine a situation
> where you want to stop/start/restart a subsystem. Now you'll have to
> first remember if it's a system-delivered system, or a package, or a
> "local" one, [...]
> That's not a good thing.
Neither is having your localisms destroyed by a system "upgrade" that
happens to provide something with the same name as what you picked.
> Though it may seem less elegant at first, putting them all into
> /etc/rc.d is the best idea.
Which way is "best" depends on whether you consider the inconvenience
of having to remember the list of script directories and searching
through them worse than the inconvenience of having localisms destroyed
by an upgrade due to name clashes.
Personally, I consider the latter worse. Thus, of these alternatives,
I favor separate directories for localisms and packages. (Not that I
like either one, myself; I use, and will continue to use, monolithic
scripts.)
der Mouse
mo...@rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Jason R Thorpe
> c) Add support for /etc/rc.pkg.d, and ensure that that directory
> is created during installation.
> This is for packages. After a package installation a user should
> copy the script from /usr/pkg/share/examples/rc.d/ to /etc/rc.pkg.d
> to enable the startup.
This is a lose. Once the user installs a package, he shouldn't have
to copy stuff around to make it go. I think this is going to be a serious
negative for our pkg system.
At the very least, this change should be VERY CEARLY AND LOUDLY
documented in our packages documentation.
--
-- Jason R. Thorpe <tho...@shagadelic.org>
Michael Richardson
>>>>> "Jason" == Jason R Thorpe <tho...@shagadelic.org> writes:
Jason> On Mon, Mar 13, 2000 at 09:08:32AM +1100, Luke Mewburn wrote:
>> c) Add support for /etc/rc.pkg.d, and ensure that that directory
>> is created during installation.
>> This is for packages. After a package installation a user should
>> copy the script from /usr/pkg/share/examples/rc.d/ to /etc/rc.pkg.d
>> to enable the startup.
Jason> This is a lose. Once the user installs a package, he shouldn't have
Jason> to copy stuff around to make it go. I think this is going to be a serious
Jason> negative for our pkg system.
I agree with what you are saying, but we have conflicting requirements.
What are the choices?
1) put /usr/pkg/etc/rc.d on the RC list.
PRO: nothing for the user to do/configure
CON: configuration info not in /etc.
/usr/pkg becomes hard to share since all clients will
run the server as well.
2) have pkg-system copy into /etc/rc.d or /etc/rc.pkg.d etc.
PRO: nothing for the user to do/configure
configuration info is in /etc.
CON: an NFS mount of /usr/pkg is not complete. The clients
that do wish to run servers/etc. won't have the scripts.
3) copy/ln -s from /etc/rc.d to /usr/pkg/etc/rc.d
PRO: configure info is in /etc.
clients have entire package
CON: users have to do something
I prefer #3. Perhaps the link from /etc/rc.d to /usr/pkg/etc/rc.d
should occur automatically on "make install" for pkgsrc. Then, on the client
(if there is one) the link has to be made if desired. This is a no-op for
machines with a private /usr/pkg. Maybe we should have "pkg_enable foo"
to do this for us, and perhaps create any accounts, etc. (ssh host key...) that
is required.
:!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease?
Michael Richardson | Cow#2: No. I'm a duck.
Home: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">m...@sandelman.ottawa.on.ca</A>. PGP key available.
David Brownlee
> That sounds like a good idea at first glance, but imagine a situation where
> you want to stop/start/restart a subsystem. Now you'll have to first
> remember if it's a system-delivered system, or a package, or a "local"
> one, because you need to grab it from either /etc/rc.d, /etc/rc.pkg.d
> or /etc/rc.local.d. And you don't want those in your $PATH either.
>
> That's not a good thing. Though it may seem less elegant at first, putting
> them all into /etc/rc.d is the best idea.
>
> Or: you can create /etc/rc.local.d and /etc/rc.pkg.d and symlink them
> from /etc/rc.d. In that case you can still easily see which ones
> are "yours".
Recommend '/etc/rc.d/<pkg>.local' ? :)
David/absolute
Nathan J. Williams
> > That sounds like a good idea at first glance, but imagine a situation
> > where you want to stop/start/restart a subsystem. Now you'll have to
> > first remember if it's a system-delivered system, or a package, or a
> > "local" one, [...]
>
> > That's not a good thing.
>
> Neither is having your localisms destroyed by a system "upgrade" that
> happens to provide something with the same name as what you picked.
>
> > Though it may seem less elegant at first, putting them all into
> > /etc/rc.d is the best idea.
>
> Which way is "best" depends on whether you consider the inconvenience
> of having to remember the list of script directories and searching
> through them worse than the inconvenience of having localisms destroyed
> by an upgrade due to name clashes.
The solution to both of these problems is to define the namespace of
/etc/rc.d, and reserve parts of the namespace for packages and for
local code.
The people who suggested /etc/rc.local.d and /etc/rc.pkg.d are trying
to solve this namespace problem by creating two new namespaces. I
would prefer to solve it by separating out the namespace within
/etc/rc.d.
Declaring '.' or '-' as a separator, and then having
"/etc/rc.d/foo.pkg" or "/etc/rc.d/bar.local" seems reasonable.
Another method (used in other contexts) would be to declare that
system packages will always have an uppercase letter in them, and that
all others must not. I don't think people would want to type those,
though.
- Nathan
Nathan J. Williams
> > c) Add support for /etc/rc.pkg.d, and ensure that that directory
> > is created during installation.
> > This is for packages. After a package installation a user should
> > copy the script from /usr/pkg/share/examples/rc.d/ to /etc/rc.pkg.d
> > to enable the startup.
>
Our pkg system has never defined the difference between "services are
installed" and "services are configured for this system". This is, in
and of itself, a problem.
The proposed change doesn't fix it, but it also doesn't make it worse.
- Nathan
ito...@iijlab.net
> > This is a lose. Once the user installs a package, he shouldn't have
> > to copy stuff around to make it go. I think this is going to be a serious
> > negative for our pkg system.
Please don't try to start daemons automatically, some of pkgsrc needs
careful configuration to be secure/work properly.
> I agree with what you are saying, but we have conflicting requirements.
> What are the choices?
> 3) copy/ln -s from /etc/rc.d to /usr/pkg/etc/rc.d
> PRO: configure info is in /etc.
> clients have entire package
> CON: users have to do something
>
> I prefer #3. Perhaps the link from /etc/rc.d to /usr/pkg/etc/rc.d
>should occur automatically on "make install" for pkgsrc. Then, on the client
>(if there is one) the link has to be made if desired. This is a no-op for
>machines with a private /usr/pkg. Maybe we should have "pkg_enable foo"
>to do this for us, and perhaps create any accounts, etc. (ssh host key...) that
>is required.
I vote for 3, without automatic symbolic links (user needs to
something). pkg_enable sounds good to me.
itojun
Greywolf
#
# > > This is a lose. Once the user installs a package, he shouldn't have
# > > to copy stuff around to make it go. I think this is going to be a serious
# > > negative for our pkg system.
#
# Please don't try to start daemons automatically, some of pkgsrc needs
# careful configuration to be secure/work properly.
Agreed.
# > 3) copy/ln -s from /etc/rc.d to /usr/pkg/etc/rc.d
Don't do that.
We find ourselves at something of an impasse: We've already shot
ourselves in the foot with /usr/local/etc/rc.d. It should be in
/etc/rc.local.d (what if there's something that we want up prior to
our filesystems being mounted? Not likely, but it _could_ happen...).
But, as with all of us, that's an opinion based upon a strategy that
"makes sense".
What of those of us who have done away with /usr/pkg in favour of
/usr/local (someone, please give me a sanity check and tell me that I'm
not the only one who did this!)? Maybe we'd like the option
(configuration, please, not a symlink) to put pkg/rc.d stuff directly into
$LOCAL_RC_DIR, and we'd still like to keep all the local/pkg stuff
separate from the system stuff.
--*greywolf;
--
BSD: more is more.
Greywolf
are mounted.]
I recant! I recant! I must have been slipped a stupid pill this morning.
Please accept my apology for that insane idea.
--*greywolf;
--
NetBSD: we put the Net in BSD.
Aidan Cully
>
> > > This is a lose. Once the user installs a package, he shouldn't have
>
Shouldn't happen anyway, the user will need variables in rc.local.conf
to start up anything run from rc.d, I think.
--aidan
Aidan Cully
> Don't do that.
The copy works. The ln -s doesn't.
> We find ourselves at something of an impasse: We've already shot
> ourselves in the foot with /usr/local/etc/rc.d. It should be in
> /etc/rc.local.d (what if there's something that we want up prior to
> our filesystems being mounted? Not likely, but it _could_ happen...).
rcorder is currently run just once at boot time, and if the scripts
aren't available at this time, they don't get run. A possibility is
scripts like:
#!/bin/sh
#
# PROVIDE: foo
# REQUIRE: mount
exec /usr/pkg/etc/rc.d/me
so that the PROVIDE/REQUIRE info is available to rcorder, but the
script is still in pkg.
> What of those of us who have done away with /usr/pkg in favour of
> /usr/local (someone, please give me a sanity check and tell me that I'm
> not the only one who did this!)?
Nope, I've also done so.
--aidan
Andrew Brown
>> >scripts, he'll want to have an easy way to identify which scripts are
>> >his own, and which came with the system (or pkgsrc, or whatever). It
>> >should only help if NetBSD provided an easy way to do that.
>>
>
>Besides being able to tell which are mine, I don't like new invented system
>files overwriting my local extensions with the same name by pure chance (or
>bad naming conventions).
then you can call yours /etc/rc.d/*.local, but you'll still ultimately
lose.
imho, this is a game you can't win. when updating /etc, you either
decide to allow the new changes in and lose your local changes (no
matter what granularity you try to arrange for changes) or you decide
not to upgrade and lose whatever new features the new /etc would give
you.
yes, you can have files that are marked THISISMINE, but a newer
version of /etc might have something named the same. yes, you can
name your files with the .local extension (and perhaps even arrange
for the default files to run yours instead if they exist), but then
you need to deal with the new files coming in that overrule yours or
provide new options or simply exactly what you want.
i had dhcpd and xntpd running before there were netbsd mechanisms in
place, and i had to (in the interests of easier future upgrades)
retrofit my stuff onto the new rc* features.
it seems to me that as much as you provide options and open places to
plug things, things will grow to fill those holes. the rc.conf.local
thing is another place where i just feel it's better to be "hands on".
i'll keep a copy of rc.conf called rc.conf.orig and modify the
original in preference to losing track of what the things are that
rc.conf actually does. it makes upgrades easier and leaves me feeling
more secure about what's actually going on. i'd hate to have a new
feature enabled by default simply because my rc.conf.local didn't turn
it off. and having rc.conf turn everything off by default wouldn't
help much.
again....imho.
Todd Whitesel
> /usr/local (someone, please give me a sanity check and tell me that I'm
> not the only one who did this!)?
No offense, but I _hope_ you're the only who does this.
Providing a clean, consistent system is already hard enough. I think
it is a mistake to add additional overhead that supports customized
restructurings when it would not otherwise be required.
The primary flaw with most SysV-isms, and bogus config systems in general,
is that machines need very predictable data structures, but anything
built out of scripts or .INI files, or whatever, stops being predictable
the minute somebody goofs in the editor, or when application programs are
forced to invent their own (broken) algorithms to configure something that
isn't already provided for. A great example of this latter point is WinBlows
drivers that want to be the last line of AUTOEXEC, and keep appending lines
to it on every reboot.
The single great strength of the old-style monolithic rc system is that
virtually every change forces a person to approve it, and people generally
are going to get it right (or realize their mistake when they don't).
Machines have no such judgement built-in, and have to be taught it line by
line. Thus keeping the config system as brain-damagedly simple as possible
is the easiest way to keep the rest of the software from screwing it up.
Todd Whitesel
toddpw @ best.com
der Mouse
> that virtually every change forces a person to approve it, and people
> generally are going to get it right (or realize their mistake when
> they don't).
> Machines have no such judgement built-in, and have to be taught it
> line by line. Thus keeping the config system as brain-damagedly
> simple as possible is the easiest way to keep the rest of the
> software from screwing it up.
Eh, no, the simplest way of keeping software from botching it is surely
to make sure that software doesn't even try.
And as you point out, that's something the monolithic style of startup
script does very well.
Tim Rightnour
On 12-Mar-00 Jason R Thorpe wrote:
> This is a lose. Once the user installs a package, he shouldn't have
> to copy stuff around to make it go. I think this is going to be a serious
> negative for our pkg system.
I agree. How about having the pkg system do something like this:
Have an rc.pkg.conf and an /etc/rc.pkg.d directory. All packages auto-install
start/stop scripts (when needed/available) into the rc.pkg.d directory, and add
a line to the rc.pkg.conf script saying:
PKGNAME= NO
On deinstall, the pkg would grep itself out of your config file, and delete the
entry. This way.. all the user has to do is follow the usual netbsd method of
turning the item on via rc*.conf.
---
Tim Rightnour <ro...@garbled.net>
NetBSD: Free multi-architecture OS http://www.netbsd.org/
NetBSD Mailing lists on the web: http://mail-index.netbsd.org/
Luke Mewburn
> On Mon, Mar 13, 2000 at 09:08:32AM +1100, Luke Mewburn wrote:
> > is created during installation.
> > This is for packages. After a package installation a user should
> > copy the script from /usr/pkg/share/examples/rc.d/ to /etc/rc.pkg.d
> > to enable the startup.
>
> to copy stuff around to make it go. I think this is going to be a serious
> negative for our pkg system.
>
> documented in our packages documentation.
Jason,
the new rc.d stuff has NOT changed the requirement for users to
manually setup the startup for a pkg daemon. You've always had to do
that.
Now, whilst that's not the most optimal behaviour, it is what existed
before, and because it's a bit of a thorny issue I decided not to try
and solve that in the new rc.d stuff in the initial implementation.
Luke.
Jaromir Dolecek
> The people who suggested /etc/rc.local.d and /etc/rc.pkg.d are trying
> to solve this namespace problem by creating two new namespaces. I
> would prefer to solve it by separating out the namespace within
> /etc/rc.d.
>
> Declaring '.' or '-' as a separator, and then having
> "/etc/rc.d/foo.pkg" or "/etc/rc.d/bar.local" seems reasonable.
Hmm, this seems to be better than the /etc/rc.{local|pkg}.d :)
One more possible solution (I'm not sure if mentioned before)
is adding /etc/rc.d/{local|pkg} and putting the respective startup
scripts there.
Simon J. Gerraty
>We find ourselves at something of an impasse: We've already shot
>ourselves in the foot with /usr/local/etc/rc.d. It should be in
Oh? I've only seen that on FreeBSD systems - and though "what a pitty
they botched a nice idea" - for the very reasons you cite.
Ah, is that because they use /usr/local instead of /usr/pkg ?
I use both btw, I consider /usr/pkg stuff part of NetBSD so best left as
shipped, _really_ local stuff goes in /usr/local.
/etc/rc.local.d and /etc/rc.pkg.d make sense. So does /etc/init.d (or call
it what you like) as a holding area for rc scripts - use name space rules
to avoid conflicts foo, foo.local foo.pkg if you like or bsd.foo, pkg.foo
and anything else is local, and then links into /etc/rc*.d to do what you want.
Then it is easy to have the start/stop script available without having it
enabled.
Oh and yes rc*.conf should die.
Having a file that needs to be edited tosses so much of the benefit of
individual rc scripts is not funny.
Did I ever mention that the _biggest_ advantage of individual rc scripts has
nothing to do with boot/shutdown managment? Its being able to tell the
night watchman at the end of the line to "type '/etc/init.d/ntpd restart'"
or whatever, rather than explain how to run ps, kill etc etc.
Once you have the scripts for that purpose, using them for boot just
"makes sense". Your /etc/rc could be noting more than a manually edited
list like:
/etc/init.d/fu
/etc/init.d/bar
...
no lack of control there for those that don't trust anything but themselves.
Obviously not everyone likes everything Luke and Matt have done, but it
is a definite step in the right direction.
--sjg
Simon J. Gerraty
>Oh and yes rc*.conf should die.
>Having a file that needs to be edited tosses so much of the benefit of
>individual rc scripts is not funny.
I should qualify that. rc*.conf is ok for providing default args etc
but should not need to be edited to enable a service once you have
the start script in rc*.d
--sjg
der Mouse
> Oh and yes rc*.conf should die.
I don't recall any conclusion to the debate on SysV-style startup
scripts...but this discussion sounds ominous. Does it mean that NetBSD
is shortly going to screw over sites for whom a monolithic startup
script is the right way? (Approximately, sites for which human
manipulation of the startup sequence is more important than mechanical
manipulation thereof.)
I saw one remark about "rcorder /etc/rc.d/*", which sounds even worse:
broken-out startup scripts run from a single startup script combine the
worst features of both. You lose the human and speed benefits of
all-in-one-place but at the same time you don't gain the mechanical
benefits of being able to count on "editing" the startup "script" by
frobbing files in a directory, because you have no way of telling what
may have been done to the driving script.
Bill Sommerfeld
> something). pkg_enable sounds good to me.
one more vote for pkg_enable, especially if it will permit support for
shared (read-only?) /usr/pkg. pkg_enable should probably verify that
all the relevant files are installed.
- Bill
Michael Richardson
>>>>> "Tim" == Tim Rightnour <ro...@garbled.net> writes:
Tim> On 12-Mar-00 Jason R Thorpe wrote:
>> This is a lose. Once the user installs a package, he shouldn't have
>> to copy stuff around to make it go. I think this is going to be a serious
>> negative for our pkg system.
Tim> I agree. How about having the pkg system do something like this:
Tim> Have an rc.pkg.conf and an /etc/rc.pkg.d directory. All packages auto-install
Tim> start/stop scripts (when needed/available) into the rc.pkg.d directory, and add
Tim> a line to the rc.pkg.conf script saying:
Tim> PKGNAME= NO
okay, but how do I share /usr/pkg between machines? There are things that
I may want all of my cluster to run.
Bill Sommerfeld
> I may want all of my cluster to run.
and similarly, i may want to share /usr/pkg but not run exactly the
same set of services on each machine..
- Bill
Hubert Feyrer
pkg_enable could do a lot more things than just throw in some symlink/file
somewhere. Frob inetd.conf, add users, etc. I'd prefer these to be
considered by anyone going that direction.
Tim Rightnour
I think we are inviting doom by attempting to come up with a works for everyone
solution. Consider the alternatives:
a) We don't do this, and install them in examples or whatever, meaning all
users, have to copy them manually to enable them.
b) we do do this, and you only have to copy the files manually on the NFS
clients that want to run the service. The win with b is that *most* users
don't play NFS games, and will benefit from this. Those that do, are no worse
off than if we picked A in the first place.
Greg A. Woods
> Subject: Re: rc, rc.shutdown proposed change
>
> On Sun, 12 Mar 2000, Martin Husemann wrote:
>
> > > >"What he said." I think that if an admin wants to create his own rc.d
> > > >scripts, he'll want to have an easy way to identify which scripts are
> > > >his own, and which came with the system (or pkgsrc, or whatever). It
> > > >should only help if NetBSD provided an easy way to do that.
> > >
> > > grep -l THISISMINE /etc/rc.d/*
> >
> > Besides being able to tell which are mine, I don't like new invented system
> > files overwriting my local extensions with the same name by pure chance (or
> > bad naming conventions).
>
FYI I have been puting packages into /usr, very successfully (i.e. no
conflicts so far in the ~140 odd packages I've acutally found useful and
have installed).
The /var/db/pkg stuff is how you tell which files belong to which
components. A system re-build is as simple as a base install from
scratch and then installation of all the previously installed packages,
and finally a restore of /etc.
Truly locally installed stuff still goes in /local (or /usr/local).
Now if only the system *and* packages always all kept virgin copies of
all user-modifiable files in a secure place, along with of course a map
of where the "installed" locations of such files are, then system
upgrades would be easier too since just before doing the upgrade one
could create a patch file of localisations and then instead of restoring
/etc one would apply the patch (and of course resolve any conflicts).
Obviously one can do much of this patch creation by manually maintaining
RCS files in /etc and its sub-directories, at least for all those
configuration items which involve only the changing of file contents,
but it would be nice to have built-in support in the base system for
doing this kind of thing too.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwo...@acm.org> <robohack!woods>
Planix, Inc. <wo...@planix.com>; Secrets of the Weird <wo...@weird.com>
Havard...@runit.sintef.no
> are installed" and "services are configured for this system". This
> is, in and of itself, a problem.
"Me too."
I'm not sure what's the best way to solve that, though; we'd
probably need a separate program to enable and disable packages
which require their own entries in the startup sequence.
- Håvard
Manuel Bouyer
> okay, but how do I share /usr/pkg between machines? There are things that
> I may want all of my cluster to run.
If you have a cluster of similar machines I would recommend setting up
rdist :) This is usefull for all system config files (and you have only
one place to backup).
--
Manuel Bouyer <bou...@antioche.eu.org>
--
Manuel Bouyer
> > What of those of us who have done away with /usr/pkg in favour of
> > /usr/local (someone, please give me a sanity check and tell me that I'm
> > not the only one who did this!)?
>
> No offense, but I _hope_ you're the only who does this.
No, he's not :)
I'd prefer to keep /usr/pkg but my users don't want to add another
dir to their path :(
Also, for new users /usr/local is more intuitive, I don't have to tweak
their path.
Manuel Bouyer
>
> is created during installation.
> This is for local scripts.
>
> c) Add support for /etc/rc.pkg.d, and ensure that that directory
> is created during installation.
> This is for packages. After a package installation a user should
> copy the script from /usr/pkg/share/examples/rc.d/ to /etc/rc.pkg.d
> to enable the startup.
I prefer the proposal of /etc/rc.d/foo.local and /etc/rc.d/bar.pkg
Minimize the number or directories please :)
Note that one thing doesn't prevent the other as long as don't install the
startup script themselve and we make sure system startup stripts will not
end by .local or .pkg.
John Nemeth
}
} Oh and yes rc*.conf should die.
I totally disagree. I like rc.conf. It keeps as much information
in one place as possible, which makes administration really easy and
pain free. It's also more in tune with the BSD way of doing things.
} Did I ever mention that the _biggest_ advantage of individual rc scripts has
} nothing to do with boot/shutdown managment? Its being able to tell the
} night watchman at the end of the line to "type '/etc/init.d/ntpd restart'"
} or whatever, rather than explain how to run ps, kill etc etc.
I do not consider this to be an advantage, since there is no way
that person should get anywhere near a root prompt. If the system is
so critical that it can't wait for a qualified person to come on site,
then the company better be prepared to do whatever is needed to get
that qualified person remote access or pay for qualified people to be
on site 24x7. Otherwise, they are just asking for trouble and are
likely to have bigger problems.
} Obviously not everyone likes everything Luke and Matt have done, but it
} is a definite step in the right direction.
This is a matter of opinion... For the moment, I'm reserving
judgement until I see the final results. However, if NetBSD turns into
yet another SysV derivative, then I'm outta here.
}-- End of excerpt from "Simon J. Gerraty"
Kevin P. Neal
> On Jun 29, 10:53am, "Simon J. Gerraty" wrote:
> } Did I ever mention that the _biggest_ advantage of individual rc scripts has
> } nothing to do with boot/shutdown managment? Its being able to tell the
> } night watchman at the end of the line to "type '/etc/init.d/ntpd restart'"
> } or whatever, rather than explain how to run ps, kill etc etc.
>
> I do not consider this to be an advantage, since there is no way
> that person should get anywhere near a root prompt. If the system is
> so critical that it can't wait for a qualified person to come on site,
> then the company better be prepared to do whatever is needed to get
> that qualified person remote access or pay for qualified people to be
> on site 24x7. Otherwise, they are just asking for trouble and are
> likely to have bigger problems.
Uh, no. What bigger problem do you refer to?
Say a problem happens at, oh, 5am. Wouldn't it be smart to
have a 2xMinimumWage person watching for a blinking red light, and
then typing one command that will get the system through the rest of
the night? This way the "qualified person" (who gets paid much more
than 2xMW) won't have to be called, woken up, pissed off, and then
compensated?
After all, what's the qualified person going to do in the middle of the
night? Type the same command in to get the system limping along, and
then go back to sleep. The real problem can be fixed during normal
business hours (at least typically, in my experience).
You can even use sudo/ru/similar to keep the night watchman from
executing any commands other than /etc/init.d/* to minimize the
damage that said person can do while still allowing for a big
cost savings from not calling the skilled person.
--
Kevin P. Neal http://www.pobox.com/~kpn/
"You're a slacker if you only give 90% 'cause you are afraid of the \
other 10%." -- Ross Smith Apr 22 1999 2:29am
Erik Bertelsen
the behaviour of rc_configured unset is somewhat funny: all rc.d scripts
seem to want to tell me that fact instead of having rc telling me once and
then stop rc processing (like original behaviour).
- Erik
Jason R Thorpe
> On Jun 29, 10:53am, "Simon J. Gerraty" wrote:
> }
> } Oh and yes rc*.conf should die.
>
> I totally disagree. I like rc.conf. It keeps as much information
> in one place as possible, which makes administration really easy and
> pain free. It's also more in tune with the BSD way of doing things.
It's also a giant PITA for package management, etc.
I'm a little annoyed that the current rc.d stuff went in. It's almost like
Luke simply chose to ignore all feedback he received on it.
A quick rundown of what we used to have:
- monolithic script where ordering of thing was really obvious
and guaranteed.
- a single way of doing things
- have to edit rc.conf
What we have now:
- a bunch of scripts with undocumented and not-always-obvious
dependencies, ordering is not obvious or guaranteed
- additional complexity, magick shell functions and variables
- multiple, incompatible ways of doing things (making the drop-in
package problem even harder to solve)
- still have to edit rc.conf
To me, this is a big, stinking LOSE.
However, I don't really feel inclined to provide suggestions at this point,
considering that all of the feedback I provided before was simply ignored,
as was the feedback provided by many others. Someone just wanted to steam
right ahead with their pet project, with pressure to get it in the tree
before 1.5 was ready to branch. Folks, that's NOT the way you do good
engineering.
...and before you argue that the feedback was conflicting with how the
proposed rc.d system was going to work, well then that should have said
something right there... "The proposal is fundamentally broken!"
Don't get me wrong... I *WANT* rc.d, init.d, etc. But what we have now
is actually WORSE than what we had before.
And, I VERY STRONGLY feel that the situation is bad enough to delay 1.5.
If we ship a release with this, and then change it all over again for the
next one, we're not exactly providing any semblence of consistency.
--
-- Jason R. Thorpe <tho...@zembu.com>
Hubert Feyrer
> Don't get me wrong... I *WANT* rc.d, init.d, etc. But what we have now
> is actually WORSE than what we had before.
>
> And, I VERY STRONGLY feel that the situation is bad enough to delay 1.5.
> If we ship a release with this, and then change it all over again for the
> next one, we're not exactly providing any semblence of consistency.
100% seconded.
BTW, wasn't there some poll at what people wanted/preferred? Can someone
remind me where the results were published?
der Mouse
>> I totally disagree. I like rc.conf. It keeps as much information
> It's also a giant PITA for package management, etc.
Which indicates that we really need something that allows the admin to
pick which way the system should go - for some, automated ease will be
more important than human ease; for others, the other way around.
> I'm a little annoyed that the current rc.d stuff went in. It's
> almost like Luke simply chose to ignore all feedback he received on
> it.
I'm pretty annoyed too. I saw no clear consensus either way on it,
which says very clearly to me that it is not sufficiently thought out
yet to be a Right Thing. (What we have, er, had, might not be a Right
Thing either, but given a choice between two wrong things with no clear
reason to choose otherwise, I'd say stick with what we have. Then at
least we don't compound wrong-thing-ness with gratuitous change.)
Not to mention that rc.d will seriously screw me, as a sysadmin. For
my style of sysadmin, single-script is the way to go. A system that
doesn't support that is, for me, basically just plain broken.
Manuel Bouyer
> > Don't get me wrong... I *WANT* rc.d, init.d, etc. But what we have now
> > is actually WORSE than what we had before.
> >
> > And, I VERY STRONGLY feel that the situation is bad enough to delay 1.5.
> > If we ship a release with this, and then change it all over again for the
> > next one, we're not exactly providing any semblence of consistency.
>
> 100% seconded.
And another "Me too".
Michael Richardson
>>>>> "Manuel" == Manuel Bouyer <bou...@antioche.lip6.fr> writes:
Manuel> On Mon, Mar 13, 2000 at 11:51:01AM -0500, Michael Richardson wrote:
>> okay, but how do I share /usr/pkg between machines? There are things that
>> I may want all of my cluster to run.
Manuel> If you have a cluster of similar machines I would recommend setting up
Manuel> rdist :) This is usefull for all system config files (and you have only
Manuel> one place to backup).
rdist works fine for files in /etc, but starts to fail if the machines are
only slightly similiar --- i.e. the local user still gets to install stuff,
which is why they have a /usr/local.
When I say I want all of my cluster to run things, I really mean that I
want them to have access to the same set of tools :-)
] Out and about in Ottawa. hmmm... beer. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
Michael Richardson
>>>>> "John" == John Nemeth <jne...@victoria.tc.ca> writes:
John> On Jun 29, 10:53am, "Simon J. Gerraty" wrote:
John> }
John> } Oh and yes rc*.conf should die.
John> I totally disagree. I like rc.conf. It keeps as much information
John> in one place as possible, which makes administration really easy and
John> pain free. It's also more in tune with the BSD way of doing things.
A lot of converts from that Penguin place really, really like rc.conf.
Lucio De Re
>
> I'm a little annoyed that the current rc.d stuff went in. It's almost like
> Luke simply chose to ignore all feedback he received on it.
>
programs/scripts/shell-functions, even, labelled "start", "stop", "reset",
"restart" and possibly more, all drawing from a common configuration file
for their eventual operation. We alreay have named.restart, it would be
nicer in the form "restart named", to be paralleled by "restart sendmail".
Any good reason not to investigate this further?
++L
Greywolf
# You can even use sudo/ru/similar to keep the night watchman from
# executing any commands other than /etc/init.d/* to minimize the
# damage that said person can do while still allowing for a big
# cost savings from not calling the skilled person.
...and you can also write a wrapper script which would do what you need.
If you have sudo/ru/whatever in place, you're a fool not to have scripts
in place which perform specific tasks.
--*greywolf;
--
BSD: Servers' choice!
Simon J. Gerraty
># executing any commands other than /etc/init.d/* to minimize the
># damage that said person can do while still allowing for a big
># cost savings from not calling the skilled person.
>..and you can also write a wrapper script which would do what you need.
>If you have sudo/ru/whatever in place, you're a fool not to have scripts
>in place which perform specific tasks.
Exactly - they are called start/stop scripts and conventionally live
in /etc/*.d :-)
--sjg
Manuel Bouyer
>
> rdist works fine for files in /etc, but starts to fail if the machines are
> only slightly similiar --- i.e. the local user still gets to install stuff,
> which is why they have a /usr/local.
> When I say I want all of my cluster to run things, I really mean that I
> want them to have access to the same set of tools :-)
Ok, I see what you mean. My users are not root on their machines so
I only rdist the root-owned parts and they can play with the rest.
Greywolf
# ># You can even use sudo/ru/similar to keep the night watchman from
# ># executing any commands other than /etc/init.d/* to minimize the
# ># damage that said person can do while still allowing for a big
# ># cost savings from not calling the skilled person.
#
# >..and you can also write a wrapper script which would do what you need.
# >If you have sudo/ru/whatever in place, you're a fool not to have scripts
# >in place which perform specific tasks.
#
# Exactly - they are called start/stop scripts and conventionally live
# in /etc/*.d :-)
No. Write what you need.
I still think that the ability to choose one's startup interface
would be preferable.
I half-regret, half-don't that I deleted two raging flames regarding this
whole thing. To sum up, I think /etc/rc.d is NOT (necessarily) a move
forward, nor did it take into account the bent of the NetBSD user community.
Why do we care about converts from other systems? What is SO DAMNED BAD
about having a monolithic rc? Could we not have a stock rc with things
that could get manipulated by ed, if necessary (backing up rc{,.conf})?
I mean, there are better ways than admitting defeat and switching to
some "solution" which is worse than the problem!
I can live with an rc.d for local/pkg stuff, but I'd like to continue
to stay monolithic for the system. Is this possible, or are the imple-
mentors of this scheme basically telling me "f*ck you and your ideas,
because we don't care anymore"?
--*greywolf;
--
BSD: Where are going tomorrow?
der Mouse
> to stay monolithic for the system. Is this possible, or are the
> ideas, because we don't care anymore"?
Well, as I've said before, I certainly feel the latter message
underlying it all.
abs wrote that Luke's work includes an option to generate a monolithic
rc file. I don't find it on a casual perusal.
Someone else asked what a traditional monolithic file gives that
cat `rcorder /etc/rc.d/*` > /etc/rc
doesn't. I've now looked at /etc/rc.d/*, and I can answer that in one
word: comprehensibility. The only way in which such an rc file is
better than the split-up scheme is that I don't have to grep around to
figure out which script something is started from. It's still full of
all the other problems, like sourcing rc.subr and rc.conf a dozen times
each, like having to grok a complicated set of shell functions in order
to have a clue what's going on (and in particular what I need to do to
get some desired effect). The resulting script is almost as much of a
maintenance nightmare as the original split-up files were.
If this, or anything like it, is the "support" for people who want/need
a monolithic rc, then yeah, that's basically saying "we don't care
about your needs, or at least not enough to bother supporting them any
longer".
Greg A. Woods
> Subject: Re: more work in rc.d [was Re: rc, rc.shutdown proposed change]
>
> I half-regret, half-don't that I deleted two raging flames regarding this
> whole thing. To sum up, I think /etc/rc.d is NOT (necessarily) a move
> forward, nor did it take into account the bent of the NetBSD user community.
That's probably a *good* thing! ;-)
Greg A. Woods
> Subject: Re: more work in rc.d [was Re: rc, rc.shutdown proposed change]
>
> about having a monolithic rc? Could we not have a stock rc with things
> that could get manipulated by ed, if necessary (backing up rc{,.conf})?
IMO this isn't at all about helping other people accustomed to other
systems -- this is entirely about making a better system that's more
flexible, more reliable, easier to manage, and more maintainable. In
all of those senses it is a step forward (and a big leap forward on some
fronts!).
Greg A. Woods
> Subject: Re: more work in rc.d [was Re: rc, rc.shutdown proposed change]
>
>
> cat `rcorder /etc/rc.d/*` > /etc/rc
>
> doesn't. I've now looked at /etc/rc.d/*, and I can answer that in one
> word: comprehensibility. The only way in which such an rc file is
> better than the split-up scheme is that I don't have to grep around to
> figure out which script something is started from.
As a side comment I'll note that most of the script naming seems quite
logical to me now except for the "empty" place-holder scripts that
simply help determine dependencies and act as additional state nodes.
I'd like to see a recognisable naming convention be used for them so
that I can see by their names that they don't actually do anything
themselves.
> It's still full of
> all the other problems, like sourcing rc.subr and rc.conf a dozen times
> each
OK, then throw in a tiny filter to eliminate all the extra reads....
> like having to grok a complicated set of shell functions in order
> to have a clue what's going on (and in particular what I need to do to
> get some desired effect).
If you're talking about what's in /etc/rc.subr, well first off I don't
find it all that complicated, and it's well documented internally to
boot.
I think that once the overall API is well enough documented in more
obvious and traditional places there'll be no need to even peek at the
underlying framework -- the higher-level functions are already quite
simple to understand in my mind and I'm sure the finer details will come
clear soon enough. Obviously all the lower level details are repetitive
anyway so why do you want to see them in full all of the time?
> The resulting script is almost as much of a
> maintenance nightmare as the original split-up files were.
Well of course! So, if you treat the result as an opaque blob much as
if it was a binary executable then you'll not be tempted to try and
maintain it as a single entity. Edit the components as source and
"compile" the monolithic script if that's what you feel you have to
do....
der Mouse
> more reliable, easier to manage, and more maintainable. In all of
> those senses it is a step forward (and a big leap forward on some
> fronts!).
More opinion being stated as fact. I think I've been careful to keep
my opinions marked as opinions; please do me the courtesy of doing
likewise. (If I've slipped up on this, please call me on it.)
It most certainly is not a step forward in any of those areas for me,
with the possible exception of more flexible, on which point I reserve
judgement until I've actually had time to sit down and look at it in
detail. Having used split-up OSes in the past, I doubt the additional
flexibility, if any, is anywhere near worth the cost.
More reliable? It's new code, therefore almost axiomatically buggier.
There's more of it -> almost axiomatically buggier. It involves more
steps -> more pieces that can break -> almost axiomatically buggier.
Easier to manage? This is entirely a judgement call by the individual
sysadmin. As I said, I've used monolithic systems and I've used
split-up systems, and on the latter I constantly find myself feeling
I'm fighting the system, rather than working with it. (One could argue
that it's not the split-up nature of the scripts but the particular
implementation thereof. In theory this could turn out to be
correct...and in theory, I could inherit six million dollars tomorrow.)
More maintainable? Certainly not by me. Even on the reasonably
objective merit of sheer size, "wc /etc/rc" on my monolithic (pre-rc.d)
system is 473 lines. "wc rc.d/*" in src/etc in my supped-to-current
tree reports 2086 lines. 337 of those are in rc.d/network, it's true -
but pre-rc.d netstart is only 181 lines. That you can sit there and
with a straight face try to claim that over two thousand lines spread
over 74 files is more maintainable than 654 lines in two files is
utterly astonishing to me. (There is an rc.subr in the pre-rc.d
system. It's all of 15 lines long. If you want to count it in, things
get even worse: 669 lines in three files, versus 2569 lines in 75.)
>> like having to grok a complicated set of shell functions in order to
>> have a clue what's going on (and in particular what I need to do to
>> get some desired effect).
> If you're talking about what's in /etc/rc.subr, well first off I
> don't find it all that complicated, and it's well documented
> internally to boot.
Sanity check time. As I said above, my monolithic rc file is 473
lines. rc.subr *alone* is 483.
In short, however (un)complicated you may find it, it's a hell of a lot
more complicated than what we had before.
> I think that once the overall API is well enough documented in more
> obvious and traditional places there'll be no need to even peek at
> the underlying framework
Ah yes, once again "you don't need to care about that, it just works,
trust us". I'll thank you to stop trying to tell me what I do and
don't need to know about my systems!
> Obviously all the lower level details are repetitive anyway so why do
> you want to see them in full all of the time?
There didn't used to *be* any repetitive details - or at least no more
than any repeated if clause is repetitive, and if that's repetitive, so
is much of what is even now present in rc.d/*, like dotting rc.subr and
rc.conf, assigning to command and name, etc.
>> The resulting script is almost as much of a maintenance nightmare as
>> the original split-up files were.
> Well of course! So, if you treat the result as an opaque blob much
> as if it was a binary executable then you'll not be tempted to try
> and maintain it as a single entity. Edit the components as source
> and "compile" the monolithic script if that's what you feel you have
> to do....
You have managed to so completely miss the point of my wanting a
monolithic script that I wonder if it's even worth attempting to
explain it again.
Editing rc.d/* and "compiling" them into a monolithic rc file has all
the problems that I see in split-up rc files to start with, plus some
additional ones of its own. (I once mentioned that the only benefit of
catting everything together is no need to grep around to see where
something is started. If you have to edit the individual file rather
than the catted-together file, even that benefit is largely lost.)
Being in a single file, per se, is not what I like about a monolithic
rc script. What I like is the comprehensibility and maintainability
benefits that result. A few of them are because everything is in a
single file; many more of them are because everything is simple and
straightforward (at least as compared to the split-up way).
And besides all that, this is debating the proposal on purely its own
merits, and as I've remarked in other messagse, much of my outrage
derives not from what was done but from how it was done. (Not all; I
still don't like rc.d regardless.)
Todd Whitesel
> lines. rc.subr *alone* is 483.
>
> In short, however (un)complicated you may find it, it's a hell of a lot
> more complicated than what we had before.
It also *does* more. A lot more. So it is not unreasonable for it to
be bigger, or more complicated.
I suppose you could make a case that it is now *bloated*. That's something
I can't speak to (I stopped tracking -current to do 1.4.2 release builds).
> You have managed to so completely miss the point of my wanting a
> monolithic script that I wonder if it's even worth attempting to
> explain it again.
This wasn't aimed at me, but it makes me think: Mouse, has it ever occurred
to you that _you_ are also being pretty damn stubborn here?? Other people
obviously want the new functionality, but you don't seem to be giving it
any credit at all. If you're assuming no one needs the new features just
because you don't need them, then that's a local assumption and it instantly
turns much of what you say here into opinions not marked as such.
> Being in a single file, per se, is not what I like about a monolithic
> rc script. What I like is the comprehensibility and maintainability
> benefits that result. A few of them are because everything is in a
> single file; many more of them are because everything is simple and
> straightforward (at least as compared to the split-up way).
The reason that it is simple and straightforward is because it only does
one thing: start everything. It does not restart, it does not stop. It
does not manage dependencies nor does it provide for correct insertion
of 3rd party services.
I think rcorder needs official diagnostic options so we can get it to tell
us what the heck it plans to do. It should be possible to get rcorder
to generate a "flat" script that properly represents a classic rc file,
but it would also be able to do this for shutdown as well as startup.
Better, the rc.d stuff should be capable of acting as the build system
for /etc/rc. This would especially be handy for debugging purposes.
At the very least, it sounds like two modes, new-style and monolithic+pkgsrc,
would be needed to satisfy everyone who's piped up so far. Shouldn't be too
hard to get sysinst to set them both up, but of course we'd better document
how to do this (after the section where we tell them how to run MAKEDEV...
now where was that in the manual?).
Todd Whitesel
toddpw @ best.com
der Mouse
> This wasn't aimed at me, but it makes me think: Mouse, has it ever
> occurred to you that _you_ are also being pretty damn stubborn here??
Heh. Not in so many words, but close.
> Other people obviously want the new functionality, but you don't seem
> to be giving it any credit at all. If you're assuming no one needs
> the new features just because you don't need them, [...]
I don't think I'm assuming that.
But in most areas, when someone proposes a new feature, one of the
first things I ever see is some form of "make sure it doesn't break
anything". That seems to have fallen by the wayside here. Lots of
features have waited - or been waiting - in the wings, in one form or
another, for a long time, pending someone figuring out how to do them
right enough that everyone was at least mollified, if not entirely
content. This time around was entirely different; I never even saw any
indication that it was more than another strawman proposal being
presented with a fait accompli - once again, method rather than
substance is a large part of the issue, not that I like the substance
any more than I ever did.
Robert Elz
From: der Mouse <mo...@Rodents.Montreal.QC.CA>
Message-ID: <2000031710...@Twig.Rodents.Montreal.QC.CA>
| But in most areas, when someone proposes a new feature, one of the
| first things I ever see is some form of "make sure it doesn't break
| anything". That seems to have fallen by the wayside here.
How? What has been broken? Certainly if anything is actually broken
that needs to be fixed (and would have been better fixed before being
installed). But I haven't actually heard of anything being more broken
than "it doesn't suit my way of doing things" - which is going to be
an outcome from any change at all.
So can you point to something in the system which no longer functions,
and used to function before?
kre
Greywolf
# > Sanity check time. As I said above, my monolithic rc file is 473
# > lines. rc.subr *alone* is 483.
# >
# > In short, however (un)complicated you may find it, it's a hell of a lot
# > more complicated than what we had before.
#
# It also *does* more. A lot more. So it is not unreasonable for it to
# be bigger, or more complicated.
The point I think der Mouse is making is that it does more, sure, but
for whom? For him (and several others I've seen, such as myself),
/etc/rc.d, at least for the stock system startup, actually gets in the
way and makes more work.
# I suppose you could make a case that it is now *bloated*. That's something
# I can't speak to (I stopped tracking -current to do 1.4.2 release builds).
There's a good argument right there. It's become probably unnecessarily
bloated. Isn't this something that NetBSD has historically avoided?
# > You have managed to so completely miss the point of my wanting a
# > monolithic script that I wonder if it's even worth attempting to
# > explain it again.
#
# This wasn't aimed at me, but it makes me think: Mouse, has it ever occurred
# to you that _you_ are also being pretty damn stubborn here?? Other people
# obviously want the new functionality, but you don't seem to be giving it
# any credit at all. If you're assuming no one needs the new features just
# because you don't need them, then that's a local assumption and it instantly
# turns much of what you say here into opinions not marked as such.
...and, again, other people _don't_ want it. We never truly reached
an acceptable solution, yet something was built and shoehorned in amid
MUCH objection.
I didn't think NetBSD was like that. We're technical people, here,
not just some knee-jerk user group. I don't think the objections
would have arisen if not for some technical problems.
# The reason that it is simple and straightforward is because it only does
# one thing: start everything. It does not restart, it does not stop. It
# does not manage dependencies nor does it provide for correct insertion
# of 3rd party services.
But it _could_ provide for that. Tagged RC lines come to mind.
A script to insert stuff just-after-X or just-before-Y could be designed.
# I think rcorder needs official diagnostic options so we can get it to tell
# us what the heck it plans to do. It should be possible to get rcorder
# to generate a "flat" script that properly represents a classic rc file,
# but it would also be able to do this for shutdown as well as startup.
i.e. generate rc and rc.shutdown. Great. Can it regenerate the 669
lines used, or is it going to generate a 3K-line startup script and a 3K-line
shutdown script.
# Better, the rc.d stuff should be capable of acting as the build system
# for /etc/rc. This would especially be handy for debugging purposes.
This is not the point. The point is that /etc/rc should not have been
will-ye-nill-ye replaced as was done (nor with the attitude put forth!
"Monolithic rc is going away. Deal.").
# At the very least, it sounds like two modes, new-style and monolithic+pkgsrc,
# would be needed to satisfy everyone who's piped up so far. Shouldn't be too
# hard to get sysinst to set them both up, but of course we'd better document
# how to do this (after the section where we tell them how to run MAKEDEV...
# now where was that in the manual?).
in /etc/rc:
if [ -d /etc/rc.d ]; then
status=do-whatever-you-need-to-do-with-rc.d
exit $status
fi
Hey, wow, look, a four-line fix (modulo the do-whatever-you-need-to-do-
with-rc.d script/function).
--*greywolf;
--
"Windows/NT - From the people who brought you EDLIN".
Greg A. Woods
> Subject: Re: more work in rc.d [was Re: rc, rc.shutdown proposed change]
>
> > more reliable, easier to manage, and more maintainable. In all of
> > those senses it is a step forward (and a big leap forward on some
> > fronts!).
>
> More opinion being stated as fact. I think I've been careful to keep
> my opinions marked as opinions; please do me the courtesy of doing
> likewise. (If I've slipped up on this, please call me on it.)
Pardon my so-called opinions, *but* I think there's been a lot of at
least semi-expert testimonial appear over the past few debates on this
topic to speak to the fact that my opinions are at least well founded
opinions if indeed not exactly facts on their own, yet. So far all I've
really heard in terms of concrete claims by those such as yourself who
oppose the new scheme is that they don't like change and they especially
don't like changes that are forced on them by surprise. Change is the
only constant and this change was discussed in at least those forums
where any discussion on it would be worth anything.
Certainly there are people who get to like doing things in one
particular way and are very uncomfortable with change. I'm not trying
to say that their opinions are not important but I am saying that no
matter what one does to improve something they care about, the change
itself is all they're going to see and it is not going to be met with
much enthusiasm regardless of how solid the proof is that real benefit
results. Some people would indeed rather chop their own wood and grind
their own flour no matter how much extra work it takes to do things that
way.
It is also important to remember that all other "ground shaking" changes
in -current are usually only mentioned after they've been committed in
current-users anyway. Certainly if this kind of change had been slipped
last-minute into a release (eg. 1.4.2) there'd be reason to complain but
I can't see any reason whatsoever in complaining about the "surprise" of
such a change in -current. If you really don't like it then obviously
you can complain -- just don't complain that it was forced down your
throat. As an "outside developer" I can't say I'm entirely happy about
this approach either, but it is a long established tradition by now.
> More reliable? It's new code, therefore almost axiomatically buggier.
> There's more of it -> almost axiomatically buggier. It involves more
> steps -> more pieces that can break -> almost axiomatically buggier.
Yes, indeed there are bugs in the first incarnations of this system.
However by design they will be more reliable in the longer run. They
can hardly be anything but, especially given the fact that they are
broken apart into separate components that isolate the effects of
failure in one from the others. I'm sure the inevitable "newness" bugs
will be squashed and most of the wrinkles will be at least smoothed over
(if not ironed right out) long before this stuff gets to the public in
the form of an official release.
That said of course it would be nice if the current failure handling
mechanism was slightly enhanced so that a service could be marked as
critical and that total system failure would only occur when a critical
step fails, but boot to multiuser could continue if a non-critical one
fails.
> Easier to manage? This is entirely a judgement call by the individual
> sysadmin. As I said, I've used monolithic systems and I've used
> split-up systems, and on the latter I constantly find myself feeling
> I'm fighting the system, rather than working with it. (One could argue
> that it's not the split-up nature of the scripts but the particular
> implementation thereof. In theory this could turn out to be
> correct...and in theory, I could inherit six million dollars tomorrow.)
You've agreed several times now to the fact that automated management is
now at least possible and clearly that makes the overall management
of the system much easier too (at least if you buy the premise that once
you've automated some part of a larger task then the entire task becomes
that much easier to perform).
Several people have also pointed out that it's easier to give more naive
people one-step instructions for doing various tasks. Regardless of
whether that's true or not I know that it's better to have a single
consistent and easy-to-remember way of doing common things to often
disparate programs and subsystems. I can also assure you from long
experience that it's much easier to tell people to do something like
"/etc/rc.d/inetd reload" than it is to tell them to read the manual page
to learn what signal triggers a reload and to send that signal to the
running "inetd" process; and it's still easier than telling them to do
something more mechanical such as "kill -1 `ps -a | grep inetd | awk
'{print $1}'`"; and I think it's even easier and more productive than
telling them to do "kill -1 $(cat /var/run/inetd.pid)".
If you feel like you're fighting this system then you probably are, but
what's important is to ask the question "why?". If the only answer you
can come up with is "because it's different from what I'm accustomed to"
then I think you can guess what I'd suggest. Any other answer will no
doubt be better applied to refining the new system than to being used as
an argument to kick it out again.
> More maintainable? Certainly not by me. Even on the reasonably
> objective merit of sheer size, "wc /etc/rc" on my monolithic (pre-rc.d)
> system is 473 lines. "wc rc.d/*" in src/etc in my supped-to-current
> tree reports 2086 lines. 337 of those are in rc.d/network, it's true -
> but pre-rc.d netstart is only 181 lines. That you can sit there and
> with a straight face try to claim that over two thousand lines spread
> over 74 files is more maintainable than 654 lines in two files is
> utterly astonishing to me. (There is an rc.subr in the pre-rc.d
> system. It's all of 15 lines long. If you want to count it in, things
> get even worse: 669 lines in three files, versus 2569 lines in 75.)
There's a heck of a lot more to maintainability than just counting lines
of code. The new system is, in my *opinion* thats based on many years
of experience, much easier to understand, especially from the point of
view of someone who only needs to add, change, or delete one particular
component. Obviously there needs to be better documentation developed
for the new system but that's supposed to be an opportunity not a
road-block.
Indeed given the additional functionality that's presented by the new
system I would have to say that it's rather elegant and one could in
fact be pleasantly surprised at the relatively small increase in lines
of code! You can argue all you want that the additional functionality
wasn't necessary for your purposes and that as a result the additional
code is bloat and thus a maintenance headache for you, and you may very
well be right for your specific circumstances, but I don't think very
many other people will agree with you for the general case.
The other issue with maintainability here is the fact that monolithic
blobs of code are impossible to localise on a microsopic internal basis
(shell scripts or not) without destroying the possibility that they can
be automatically upgraded. Now at least localisations can be isolated
to much smaller components and far less impact will be felt on upgrades
as a result. (Having just gone through a one-year leap forward in a
"production" -current system that happened to include conversion to the
new rc.d system I can assure you that courtesy of the retention of the
rc.conf style of control the new rc.d system is the least of your
worries in merging your localisations into a new /etc. It is a tiny
fraction of the total effort required for any significant general
purpose machine and it is in fact entirely and easily automatable!)
> Ah yes, once again "you don't need to care about that, it just works,
> trust us". I'll thank you to stop trying to tell me what I do and
> don't need to know about my systems!
It never fails to make me wonder why people will get all up in arms
about silly sys-admin details and yet take for granted the thousands of
obscure lines of code that make some of the most intricate and important
internals of the system function the way they do.... Certainly you can
see and feel the sys-admin things much more closely, and if your job is
to maintain systems then such things might affect you far more than the
rewrite of a filesystem or the VM system but I still don't see the
difference. In each case there's a damn good chance that any such
change will have been very closely considered by persons who've taken
into account as wide a set of requirements and ways of doing things as
they can without getting totally stuck on inevitable conflicts and other
road-blocks.
Being "*BSD-like" is not, IMO, about the sys-admin crud on top of the
system -- it's about the innards and the APIs! The *BSD crowd, when I
was not de facto a member, always seemed to be so caught up in the
innards of their systems that they never paid enough attention to making
the system administration tasks "production quality". Now before anyone
tries to claim that "production" and "research" systems are not
compatible in their goals let me remind you that much of what's done on
a research system has nothing at all to do with the sys-admin details in
the first place and indeed the more attention that is paid to good
production-quality sys-admin the more reliable and productive the entire
system can be even when it's only used as an OS research platform. Also
please remember that research into what it takes to build a high-quality
production system is just about as important as research into networking
protocols or filesystems.
> There didn't used to *be* any repetitive details - or at least no more
> than any repeated if clause is repetitive, and if that's repetitive, so
> is much of what is even now present in rc.d/*, like dotting rc.subr and
> rc.conf, assigning to command and name, etc.
Please don't try to count sourcing files containing shared components as
"repetitive" in that sense. That's mis-direction of the worst kind.
Perhaps you're also forgetting the repetitive manual tasks that were
implied by the old system too....
Given the trade-off between what's now possible in terms of additional
functionality (status/stop/reload/etc) and of course the far more
flexible dependency controls I think the extremely small amount of new
code is well worth having.
der Mouse
> changes in -current are usually only mentioned after they've been
> committed in current-users anyway.
This might be a valid argument, EXCEPT that this particular change
(from monolithic to split-up rc) has been discussed multiple times, and
ever time, including the most recent, it has generated a very noted
lack of consensus.
>> Easier to manage? [...]
> You've agreed several times now to the fact that automated management
> is now at least possible
Well...more possible.
> and clearly that makes the overall management of the system much
> easier too
No, it is not "clearly".
The improved ease of mechanical management comes at a price in ease of
human management. To me - and this is where the judgement call comes
in - the price is greater, much greater, than the benefit.
> (at least if you buy the premise that once you've automated some part
> of a larger task then the entire task becomes that much easier to
> perform).
Other things being equal, yes...but that's not the case here.
> If you feel like you're fighting this system then you probably are,
> but what's important is to ask the question "why?".
Because the vendor-provided way is never satisfactory out of the box.
(Not once have I found a system, including any of the free ones, that
was satisfactory out of the box. I suspect that on *this* point I am
very far from alone.)
That means that it needs modification, anywhere from tweaking to
massive overhaul.
Doing that, maintaining it, rolling it forward to new OS revs, all of
those involve understanding what's there.
Split-up rc files are a twisty maze of shell functions and script
files. When I want to find out where something happens (necessary to
figure out enough about how it happens to know how to determine and
apply the called-for change), I have to grep through dozens of files,
filter out the false positives, sometimes search through auxiliary
shell functions, read through scripts that try to do everything for
everyone and as a result are longer than entire monolithic startup
files, never mind just the relevant pieces thereof.
And because of the vendor attitude of "it's just the interface that
matters" (which as I just explained is not true), this all has to be
done de novo with the next release.
> Any other answer will no doubt be better applied to refining the new
> system than to being used as an argument to kick it out again.
If you can bring it down to no more than, say, twice the size of the
old way, in file and line count, I might buy that.
>> More maintainable? Certainly not by me. Even on the reasonably
>> objective merit of sheer size, [...669&3 vs 2569&75...]
> There's a heck of a lot more to maintainability than just counting
> lines of code. The new system is, in my *opinion* thats based on
> many years of experience, much easier to understand,
And in mine, based on many years of experience, harder. As I said,
widely divided opinions.
> especially from the point of view of someone who only needs to add,
> change, or delete one particular component.
Add or delete...maybe. Change, I especially disagree; the amount of
code you have to understand to change one component is more than the
amount in the whole thing under the old way.
> Indeed given the additional functionality that's presented by the new
> system I would have to say that it's rather elegant and one could in
> fact be pleasantly surprised at the relatively small increase in
> lines of code!
*Only* a factor of 3.84 (lines) or 25 (files) larger? When it's doing
only some two-plus times as much (startup, shutdown, and
restart=shutdown+startup)? Perhaps that's your idea of relatively
small. It's not mine.
Oh, and I just noticed I forgot to include rcorder's source code.
> The other issue with maintainability here is the fact that monolithic
> blobs of code are impossible to localise on a microsopic internal
> basis (shell scripts or not) without destroying the possibility that
> they can be automatically upgraded.
Right. This is one of the things that makes me feel most secure about
the old way: because it can't be mecahnically "upgraded", nobody tries,
which means that I don't have to worry about making sure installing
something new hasn't nuked a localization somewhere in the rat's-nest
of shell functions and dotted files.
> Being "*BSD-like" is not, IMO, about the sys-admin crud on top of the
> system -- it's about the innards and the APIs!
If all you are is a systems hacker, perhaps.
I'm a sysadmin too. It's as a sysadmin that I find this "not BSD".
> The *BSD crowd, when I was not de facto a member, always seemed to be
> so caught up in the innards of their systems that they never paid
> enough attention to making the system administration tasks
> "production quality".
Of course not. They were doing a research system, and while as you
point out research and production are not entirely incompatible, this
is one point where you can't have it both ways, so of course they
picked the one that was better for humans who go grubbing around in
anything and everything.
>> There didn't used to *be* any repetitive details - or at least no
>> more than any repeated if clause is repetitive, and if that's
>> repetitive, so is much of what is even now present in rc.d/*, like
>> dotting rc.subr and rc.conf, assigning to command and name, etc.
> Please don't try to count sourcing files containing shared components
> as "repetitive" in that sense. That's mis-direction of the worst
> kind.
I'm not claiming that the reptition is of the code in rc.subr or
rc.conf. I'm comparing "if [ -x ...]; then ... fi" with ".
/etc/rc.subr; . /etc/rc.conf", pointing out that if the former is
considered repetitive then the latter must also be.
> [...] and of course the far more flexible dependency controls [...]
...= far more complex, and therefore more likely to bite you in the ass
at a bad time. As in, you add something new and rcorder happens to
juggle the scripts differently, and all of a sudden your startup breaks
subtly because there's a dependency someone didn't notice and hence
didn't declare. And you go nuts trying to find and fix it.
No thanks.
Greywolf
Greg-> [ On Friday, March 17, 2000 at 03:44:09 (-0500), der Mouse wrote: ]
Mouse: Ah yes, once again "you don't need to care about that, it just works,
Mouse: trust us". I'll thank you to stop trying to tell me what I do and
Mouse: don't need to know about my systems!
#
Greg-> It never fails to make me wonder why people will get all up in arms
Greg-> about silly sys-admin details and yet take for granted the thousands of
Greg-> obscure lines of code that make some of the most intricate and important
Greg-> internals of the system function the way they do.... Certainly you can
Greg-> see and feel the sys-admin things much more closely, and if your job is
Greg-> to maintain systems then such things might affect you far more than the
Greg-> rewrite of a filesystem or the VM system but I still don't see the
Greg-> difference.
You just answered your own question! We, as systems administrators,
SEE AND FEEL the difference. For all our sysV boxes, I implemented a
profile which, when run, would do the right thing with a control-D from
single-user mode as well as from a login shell. You've heard that one
from me before.
When I worked with Autodesk, we were switching over to Solaris. I hated
it. The performance was abysmal, the shells crashed, and everything felt
suddenly quite alien. EVERYthing. From the way ps worked, to the way the
startup was handled, to where the host config was split across six or
eight files, to the fact that su didn't work right, to the STUPID GODDAMN
DEVICE STRINGS (the compat devices didn't work right, for some reason).
It was a blight on the face of UNIX (either that or BSD was a bit of
sandpaper on UNIX's face, which is a blessing in itself :-), and it was a
slap in the face of every sysadmin who'd ever touched a Berkeley or Sun
system.
Greg-> In each case there's a damn good chance that any such
Greg-> change will have been very closely considered by persons who've taken
Greg-> into account as wide a set of requirements and ways of doing things as
Greg-> they can without getting totally stuck on inevitable conflicts and other
Greg-> road-blocks.
Sorry, I think they missed the boat on this one. Mind you, to give Luke
some credit, I think he put in quite a bit of work on this, and I credit
him for trying to take that "step forward". Mandating it, though, was
not the right move.
Greg-> Being "*BSD-like" is not, IMO, about the sys-admin crud on top of the
Greg-> system -- it's about the innards and the APIs!
I beg to differ in a _very_ large way. The thing that first tells me
I'm on a Berkeley system is the way the system responds to my commands;
ps ax doesn't give me an error message. /dev/sd0a is there and not a (soft)
link to some long convolved path name. MAKEDEV is there. rc is there
and I can look to see how it's configured via whichever mechanism. /usr
isn't required at boot time just to get into single-user mode.
The UI is a BIG part of what BSD is. Yes, the innards and the APIs are
_equally_ important. You can't just chuck what's been a consistent UI
and do a radical change like this, and then turn around and say, "oh,
the UI is not important". That's the biggest double-speak I think I
have heard in AGES.
If you're expected to learn to admin a system, much less use one,
what's the FIRST thing you're gonna see...?
And I concur with der Mouse: To be told that the details of administrating
a system are unimportant is an insult to my career as a systems and network
administrator.
We in the business are here because we are good at what we do. We like to
be able to see what the hell the box is doing when it comes up (does anyone
else type 'sh /etc/rc' from a single-user prompt to do debugging?), or
at least we like to be able to see what the box is SUPPOSED to be doing
on its way up.
Greg-> ...The *BSD crowd, when I
Greg-> was not de facto a member, always seemed to be so caught up in the
Greg-> innards of their systems that they never paid enough attention to making
Greg-> the system administration tasks "production quality".
Define "production quality". What's _really_ wrong with what we had?
"Couldn't be automated." Bull[#@$(]. It could be. Just takes some
more thought, is all.
Greg-> Now before anyone
Greg-> tries to claim that "production" and "research" systems are not
Greg-> compatible in their goals let me remind you that much of what's done on
Greg-> a research system has nothing at all to do with the sys-admin details in
Greg-> the first place and indeed the more attention that is paid to good
Greg-> production-quality sys-admin the more reliable and productive the entire
Greg-> system can be even when it's only used as an OS research platform. Also
Greg-> please remember that research into what it takes to build a high-quality
Greg-> production system is just about as important as research into networking
Greg-> protocols or filesystems.
Production-quality sysadmin tools != dumbing down the tools.
Your first production-quality sysadmin tool had better be your systems
administrator!
Greg-> Given the trade-off between what's now possible in terms of additional
Greg-> functionality (status/stop/reload/etc) and of course the far more
Greg-> flexible dependency controls I think the extremely small amount of new
Greg-> code is well worth having.
I will agree that my idea (I proto'd it and it got zorched ("The disk ate
my homework") :-(...) jumped thru a few hoops, and I'm not sure how much
more or less code it had to it, but upon reading rc.subr, the functions
looked somewhat similar. I just handled it a different way, but there
was functionality to start/stop/reload/status each daemon.
If I can get it rewritten, I'll post it. If I can define a grammar for
add-daemon and remove-daemon properly, I'll post that too.
--*greywolf;
--
BSD: We Come In Peace. We're leaving in pieces.
Aidan Cully
> > It is also important to remember that all other "ground shaking"
> > changes in -current are usually only mentioned after they've been
> > committed in current-users anyway.
>
> This might be a valid argument, EXCEPT that this particular change
> (from monolithic to split-up rc) has been discussed multiple times, and
> ever time, including the most recent, it has generated a very noted
> lack of consensus.
FWIW, I agree with Mouse here. I like the new rc.d, and I'm glad to
see it in tree, but I never got the impression from previous discussion
on the subject that it was coming. In this case, at least some warning
should have been given.
> The improved ease of mechanical management comes at a price in ease of
> human management. To me - and this is where the judgement call comes
> in - the price is greater, much greater, than the benefit.
I don't believe the difficulty of human management has increased
enough to warrant that statement.
> > If you feel like you're fighting this system then you probably are,
> > but what's important is to ask the question "why?".
>
> Because the vendor-provided way is never satisfactory out of the box.
> (Not once have I found a system, including any of the free ones, that
> was satisfactory out of the box. I suspect that on *this* point I am
> very far from alone.)
It's not appropriate for the vendor-provided way to do absolutely
everything a particular sysadmin would want done on hir box. What's
important is that it have the hooks in place so that it only needs
to be modified in the places it's supposed to be modified. I've
never found myself needing to modify /etc/rc, or /etc/netstart.
> That means that it needs modification, anywhere from tweaking to
> massive overhaul.
>
> Doing that, maintaining it, rolling it forward to new OS revs, all of
> those involve understanding what's there.
I don't acknowledge that the mechanics of /etc/rc.d/*, or even
/etc/rc.subr are all *that* difficult to understand. Or, at least,
it isn't that difficult to work out the execution path of a
particular init script. I'll acknowledge that the dependancy tree
might be a little tricky to figure out, but that's an easily
solvable problem with another tool that parses PROVIDE: REQUIRE:
lines, and can display the tree in a human-readable format.
> When I want to find out where something happens (necessary to
> figure out enough about how it happens to know how to determine and
> apply the called-for change), I have to grep through dozens of files,
All the files are in the same place, and the order is determined by
rcorder. 'grep some_command `rcorder /etc/rc.d/*`' is almost
functionally equivalent to 'grep some_command /etc/rc'.
> filter out the false positives, sometimes search through auxiliary
> shell functions, read through scripts that try to do everything for
> everyone and as a result are longer than entire monolithic startup
> files, never mind just the relevant pieces thereof.
They _need_ to provide for everything, or 3rd parties that need
everything would need to maintain their _own_ _unique_ everythings
for their scripts. At least by providing everything, you only need
to figure out how it works once, rather than once for every 3rd
party service you install.
> And because of the vendor attitude of "it's just the interface that
> matters" (which as I just explained is not true), this all has to be
> done de novo with the next release.
I don't know what you mean, here...
> > Any other answer will no doubt be better applied to refining the new
> > system than to being used as an argument to kick it out again.
>
> If you can bring it down to no more than, say, twice the size of the
> old way, in file and line count, I might buy that.
File count? That completely removes the possibility of rc.d. And
line count basically makes it much more difficult (maybe impossible)
for /etc/rc.d scripts to provide start/stop/restart, &c. If you
lose both of these, there's no point to rc.d.
> > especially from the point of view of someone who only needs to add,
> > change, or delete one particular component.
>
> Add or delete...maybe. Change, I especially disagree; the amount of
> code you have to understand to change one component is more than the
> amount in the whole thing under the old way.
I disagree entirely. It all depends on the magnitude of the change.
Maybe all you need to understand is /etc/rc.conf, maybe all you need
to understand is the interface to run_rc_command, maybe all you need
to understand is 'whoops, this script runs "abcd" when we're running
"xyzd" instead'. That's like arguing you need to know the syscall
interface if you just want to call printf() from your code.
> *Only* a factor of 3.84 (lines) or 25 (files) larger?
If you remove the
#!/bin/sh
# PROVIDE:
# REQUIRE:
. /etc/rc.subr
. /etc/rc.conf
preamble, I doubt the 'lines' count will be that much greater. The
'files' count buys you granularity that was simply *impossible* to
get before.
> When it's doing
> only some two-plus times as much (startup, shutdown, and
> restart=shutdown+startup)?
It does startup, shutdown, and restart much more reliably, through
the check_pidfile/check_process functions. It also has status and
reload, neither of which are useful at bootup or shutdown, but
which can be very useful when the system is running.
> > The other issue with maintainability here is the fact that monolithic
> > blobs of code are impossible to localise on a microsopic internal
> > basis (shell scripts or not) without destroying the possibility that
> > they can be automatically upgraded.
>
> Right. This is one of the things that makes me feel most secure about
> the old way: because it can't be mecahnically "upgraded", nobody tries,
> which means that I don't have to worry about making sure installing
> something new hasn't nuked a localization somewhere in the rat's-nest
> of shell functions and dotted files.
So, that the *possibility* of mechanical upgrade exists is a drawback?
> >> There didn't used to *be* any repetitive details - or at least no
> >> more than any repeated if clause is repetitive, and if that's
> >> repetitive, so is much of what is even now present in rc.d/*, like
> >> dotting rc.subr and rc.conf, assigning to command and name, etc.
>
> > Please don't try to count sourcing files containing shared components
> > as "repetitive" in that sense. That's mis-direction of the worst
> > kind.
>
> I'm not claiming that the reptition is of the code in rc.subr or
> rc.conf. I'm comparing "if [ -x ...]; then ... fi" with ".
> /etc/rc.subr; . /etc/rc.conf", pointing out that if the former is
> considered repetitive then the latter must also be.
Then it's just as repetitive. Glad we agree. :-)
--aidan
Greg A. Woods
> Subject: Re: more work in rc.d [was Re: rc, rc.shutdown proposed change]
>
> (from monolithic to split-up rc) has been discussed multiple times, and
> ever time, including the most recent, it has generated a very noted
> lack of consensus.
I don't see how true consensus could ever be reached on these issues.
Compromises must be made on both sides. I think the currently
implemented rc.d scheme has already made several compromises (as can be
shown by looking at some of the criticisms it is already receiving from
advocates of a more SysV-style /etc/rc?.d and /etc/init.d.
> The improved ease of mechanical management comes at a price in ease of
> human management. To me - and this is where the judgement call comes
> in - the price is greater, much greater, than the benefit.
This human (i.e. me) finds it easier to manage both by hand and by
automation. I fail to see how even those who baulk against change can
argue that the price they pay is *much* greater when at others find it
easier on all fronts.
> Because the vendor-provided way is never satisfactory out of the box.
> (Not once have I found a system, including any of the free ones, that
> was satisfactory out of the box. I suspect that on *this* point I am
> very far from alone.)
>
> That means that it needs modification, anywhere from tweaking to
> massive overhaul.
That argument is totaly useless in this case. We're not faced with an
isolated and un-repsonsive vendor here -- from what I've seen the new
system is very much pliable within its design constraints and open to
suggestions for improvements.
> Doing that, maintaining it, rolling it forward to new OS revs, all of
> those involve understanding what's there.
This depends very much on how invasive your "overhaul" is. I suspect
that with the NetBSD rc.d system most people will only change one or two
percent of the various scripts and if even half of those changes are
incorporated into the official distribution there will only be a tiny
number of changes to merge on upgrades. Of those remaining merges they
will *all* be isolated into specific files and the entire framework
won't require hacking just to get an upgraded system hobbling along
again.
> Split-up rc files are a twisty maze of shell functions and script
> files. When I want to find out where something happens (necessary to
> figure out enough about how it happens to know how to determine and
> apply the called-for change), I have to grep through dozens of files,
> filter out the false positives, sometimes search through auxiliary
> shell functions, read through scripts that try to do everything for
> everyone and as a result are longer than entire monolithic startup
> files, never mind just the relevant pieces thereof.
I think you're still making a mountain out of a mole-hill.... Once
adequate documentation is available I doubt your concerns will hold
water.
> If you can bring it down to no more than, say, twice the size of the
> old way, in file and line count, I might buy that.
If you take out all of the additional functionality provided, along with
all of the additional comments and blank lines, I think you'll already
be down to less than twice the size of the original.... That's
conjecture of course, but not entirely pulled from thin air as I have
read through all the scripts....
> Add or delete...maybe. Change, I especially disagree; the amount of
> code you have to understand to change one component is more than the
> amount in the whole thing under the old way.
That's wrong -- all you need to understand is the programming interface
and that can be documented in a few simple paragraphs (and indeed it is
mostly documented now with internal comments in rc.subr). The scripts
themselves are black boxes that the average admin should never even read.
> > The other issue with maintainability here is the fact that monolithic
> > blobs of code are impossible to localise on a microsopic internal
> > basis (shell scripts or not) without destroying the possibility that
> > they can be automatically upgraded.
>
> Right. This is one of the things that makes me feel most secure about
> the old way: because it can't be mecahnically "upgraded", nobody tries,
> which means that I don't have to worry about making sure installing
> something new hasn't nuked a localization somewhere in the rat's-nest
> of shell functions and dotted files.
Some of us, many perhaps, really hate the drudgery of repetitive
sys-admin tasks, especially those involved in upgrading a system. The
more that these tasks can be simplified, and especially the more that
they can be automated, the better.
To that end it is very important to define system configuration items in
ways that allow them to be modified entirely by locally owned files (the
new rc.conf and rc.local.conf, badly named as they are, as well as the
separation of startup/shutdown actions into separate scripts for each
subsystem are examples of this while things like inetd.conf,
syslog.conf, etc. are *not*) the better.
No matter what you do an upgrade still requires careful comparison of
the old and new systems and if you've done your homework early you'll be
comparing not just the actual files but the three-way differences.
> > Being "*BSD-like" is not, IMO, about the sys-admin crud on top of the
> > system -- it's about the innards and the APIs!
>
> If all you are is a systems hacker, perhaps.
>
> I'm a sysadmin too. It's as a sysadmin that I find this "not BSD".
As a systems hacker who has worked on, and administered, *everything*
from V7 onwards I can assure you that the variances I see in the
administration are definitely not what I would use to define the
heritage of a system. Those who've had a somewhat narrower view of the
spectrum of unix-like systems over the years are no doubt prone to
defining these distinctions in different ways.
> ...= far more complex, and therefore more likely to bite you in the ass
> at a bad time. As in, you add something new and rcorder happens to
> juggle the scripts differently, and all of a sudden your startup breaks
> subtly because there's a dependency someone didn't notice and hence
> didn't declare. And you go nuts trying to find and fix it.
This is no different than trying to get all the lines in the right order
in a monolithic script, or indeed even of getting all the script names
to sort in the right order with a SysV SNN*/KNN* style system.
While it's true that controlling the "rcorder" tool requires looking in
each script and being able to understand state diagrams and dependencies
the additional power and flexibility are, in my considered opinion, a
fair trade-off.
For example there's been great debate over the proper way to make
critical filesystem mounting and network startup work to handle all
contingencies and the consensus usually seems to be that at least with a
monolithic script it is impossible to do without actually hacking the
script. Though I've not yet seen or attempted an analysis of the new
system with the abilities of "rcorder" I suspect it will allow a lot
more flexibility without requiring script hacking.
der Mouse
>> code you have to understand to change one component is more than the
>> amount in the whole thing under the old way.
> That's wrong -- all you need to understand is the programming
> interface and that can be documented in a few simple paragraphs (and
> indeed it is mostly documented now with internal comments in
> rc.subr). The scripts themselves are black boxes that the average
> admin should never even read.
The same old "you don't need to know how it works under the hood, don't
bother your little head with that".
It just ain't so.
If the change I want to make is one that is provided for, I need to
know enough about how it works to be confident the documentation - if
any - is correct, that it's not going to spring a surprise on me and
automatically enable or disable something else I don't want because
someone else thought, incorrectly, "oh, but you can't possibly want
this without that". Or that there aren't even any simple bugs lurking.
If the change I want to make is one that isn't provided for, matters
are even worse. Or are you under the impression that you have
anticipated everything anyone can possibly want?
der Mouse
> It's not appropriate for the vendor-provided way to do absolutely
> everything a particular sysadmin would want done on hir box.
Oh, certainly. I don't expect the system to be satisfactory straight
out of the box. That was introductory to my next paragraph.
> What's important is that it have the hooks in place so that it only
> needs to be modified in the places it's supposed to be modified.
> I've never found myself needing to modify /etc/rc, or /etc/netstart.
With NetBSD, neither have I, at least not since clear_tmp went into
rc.conf.
But if I "upgrade" to an rc.d system, I have 2600+ lines of boot script
I have to comprehend, instead of under 700, to determine whether all I
want can be done by whatever configuration mechanisms are provided.
Repeat for every new rev. (Granted, diff can help - but the same is
equally true of the single-file way.)
I don't need that. But NetBSD seems to think I do.
> I don't acknowledge that the mechanics of /etc/rc.d/*, or even
> /etc/rc.subr are all *that* difficult to understand.
They probably aren't. But I'm quite sure they're more difficult to
understand than the old scripts.
>>> especially from the point of view of someone who only needs to add,
>>> change, or delete one particular component.
>> Add or delete...maybe. Change, I especially disagree; the amount of
>> code you have to understand to change one component is more than the
>> amount in the whole thing under the old way.
> I disagree entirely. It all depends on the magnitude of the change.
I don't. If I want to make a change, I have to understand most of the
startup system to be sure the change isn't going to produce some other
effect I don't want, or interact badly with something else.
Perhaps *you* are content just frobbing one thing that looks promising
and hoping it does what you want and only what you want. *I*'m not.
>> Right. This is one of the things that makes me feel most secure
>> about the old way: because it can't be mecahnically "upgraded",
>> nobody tries, which means that I don't have to worry about [...]
> So, that the *possibility* of mechanical upgrade exists is a
> drawback?
Yes. Not a critical one, perhaps, but a drawback. I don't trust
programs that try to mess with my system's configuration; I've seen
them go wrong, very wrong, far too often.
Greywolf
If there are people interested in the monolithic rc scheme, perhaps
they could just keep it up to date and offer it as a replacement for
the rc.d scheme.
I mean, if the Project won't support it, and there are people who want it,
then the alternative is to have an up-to-date monolithic style rc scheme
somewhere, it doesn't matter where.
Does someone wish to own this project? I'd even go so far as to suggest
pkgizing it, but not everyone installs/uses pkgsrc, so...
I can take a stab at it, but:
/greywolf: Optimization changed from TIME to QUALITY
about seven years ago :-).
--*greywolf;
--
BSD: Tap The Power.
Robert Elz
From: der Mouse <mo...@Rodents.Montreal.QC.CA>
Message-ID: <2000031818...@Twig.Rodents.Montreal.QC.CA>
| I don't need that. But NetBSD seems to think I do.
No, I think you're missing the point. There's no question by that
some people are going to suffer from almost every change. You may
be one of the ones who suffer a bit from this one. That's one of the
prices of any change.
What is thought is that many people need the change (or a change) - not
that everyone does.
Further, it is (IMO) believed that the people who will suffer from the
change are the ones best able to cope - that is, if it is likely to
matter to you the way that the startup scripts are processed, then you're
most likely able to manage, perhaps with some extra effort. On the other
hand, all those people who never want to look at an rc file, ever,
and couldn't really handle it if they were required to, are the ones that
benefit most from the change - along with those who can cope easily enough,
but simply prefer not to have to.
I know that you don't think that NetBSD ought to pander to the incompetant,
but it isn't really a choice that anyone gets to make - more and more
people are at least trying NetBSD, the simpler it is for them, the less
work it is for the people who maintain the system - as they don't have
to spend as much time helping people cope with the simplest things, and
can spend more time doing more interesting development.
| They probably aren't. But I'm quite sure they're more difficult to
| understand than the old scripts.
Yes, they probably are. But they need to be understood by less people.
Overall, the people * understanding product has most likely gone down.
I think that NetBSD needs more of this kind of thing - that is, this
kind of approach to getting things improved. I have seen a bit too
much of "no, we won't take that, it isn't perfect". That kind of thing
just discourages people, and leads to nothing getting done for a long
time. It is OK to say "no, we won't take that, that breaks X Y & Z"
or "no, we won't take that, we already have X, which does it better".
But not "I could do better than that, even though I haven't yet".
Let's take the imperfect code, and then use the existance of that as
a motivation to the people who can do better to actually do so.
I am not meaning to suggest here that the rc.d stuff is imperfect
(though it might be) but that NetBSD ought be more willing to import
code without lots of advance discussion, debate, and argument. Then
people should also be taught to expect their code to be ripped out
again and replaced by something else - all this at least in -current
systems. If something looks only half done, and hasn't been fixed
at the time a release is due, then rip it out (or discuss ripping it
out) - it can be added back to -current again after the release if
people miss it enough.
kre
Kimmo Suominen
of this in the Linux world where various services are enabled on a stock
system, without the user really knowing about them (or needing them).
IMHO it would be better if daemons do not run automatically, but rather
require the system administrator to enable them.
I've been looking at the apache pkg (in hopes of upgrading to using the
pkg instead of a locally maintained copy) and these feelings have only
been made stronger. The apache pkg installs a default configuration on
the system (in /usr/pkg/etc/httpd/httpd.conf), which in combination with
the startup script would publish files openly.
I would feel better about just providing a sample configuration file that
the administrator can modigy and install next to the other host-specific
somewhere in /etc (e.g. in /etc/httpd) and the server should default to
that location for its configuration (so it would fail to start without
intentional configuration).
+ Kim
tho...@shagadelic.org (Jason R Thorpe) writes:
| On Mon, Mar 13, 2000 at 09:08:32AM +1100, Luke Mewburn wrote:
|
| > c) Add support for /etc/rc.pkg.d, and ensure that that directory
| > is created during installation.
| > This is for packages. After a package installation a user should
| > copy the script from /usr/pkg/share/examples/rc.d/ to /etc/rc.pkg.d
| > to enable the startup.
|
| This is a lose. Once the user installs a package, he shouldn't have
| to copy stuff around to make it go. I think this is going to be a serious
| negative for our pkg system.
|
| At the very least, this change should be VERY CEARLY AND LOUDLY
| documented in our packages documentation.
|
| --
| -- Jason R. Thorpe <tho...@shagadelic.org>
--
Kimmo Suominen
k...@tac.nyc.ny.us
Greg A. Woods
> Subject: Re: more work in rc.d [was Re: rc, rc.shutdown proposed change]
>
> SEE AND FEEL the difference.
Yes but my point was that it still doesn't make any real difference --
it is just an emotional issue. When it becomes an emotional issue the
supporters of each particular opposing feature will claim superiority
whether one's really better than the other or not.
> When I worked with Autodesk, we were switching over to Solaris. I hated
> it. The performance was abysmal, the shells crashed, and everything felt
> suddenly quite alien. EVERYthing. From the way ps worked, to the way the
> startup was handled, to where the host config was split across six or
> eight files, to the fact that su didn't work right, to the STUPID GODDAMN
> DEVICE STRINGS (the compat devices didn't work right, for some reason).
> It was a blight on the face of UNIX (either that or BSD was a bit of
> sandpaper on UNIX's face, which is a blessing in itself :-), and it was a
> slap in the face of every sysadmin who'd ever touched a Berkeley or Sun
> system.
I can promise you that if you'd started by learning V7 and 32V, then
suffered under several years of running Xenix and SysIII, and finally
been relieved a bit by the last releases of SysVr3, and on occasion had
suffered with fall backs to SunOS-3 and even SunOS-4, and all the time
working with at least a few systems that had to work reliably in
commercial production environments, you'd have a much different view and
be far more accepting of change in those systems regardless of whether
it's always for the better! :-)
> If you're expected to learn to admin a system, much less use one,
> what's the FIRST thing you're gonna see...?
The manual pages. *EVERY* "vendor's" system is different. Trying to
stuff systems into one of two categories is only going to get you into
trouble. Everyone stole something from everyone else and everyone made
their mark with something new and unique. Never ever trust that you can
guess where something is or how something works -- always check the
documentation and double check with hands-on tests.
> And I concur with der Mouse: To be told that the details of administrating
> a system are unimportant is an insult to my career as a systems and network
> administrator.
That's not waht I was saying. The point is that narrowing your view of
how to do things so that you're only competent in one environment is
limiting. Criticising differences just because they are different
doesn't help. Complaining that "the other" way of doing things is
harder without learning it openly and using "it" in the environments it
was designed for doesn't help either.
> Define "production quality". What's _really_ wrong with what we had?
> "Couldn't be automated." Bull[#@$(]. It could be. Just takes some
> more thought, is all.
Production quality has to do with things like reliability,
reproducibility, consistency, integrity, and automatability. An ideal
production system would run itself in a "lights-out" 7x24 environment,
upgrade itself, tune itself, and perform its own disaster recovery. All
the system administrator would have to do is the initial install, plug
in new hardware when it's required and authorise the addition and
deletion of user accounts, software, etc. Obviously no system yet meets
all of those goals 100%....
> Production-quality sysadmin tools != dumbing down the tools.
Of course not -- it means making them smarter, more reliable, and more
consistent, and more automated.
> Your first production-quality sysadmin tool had better be your systems
> administrator!
Well, hmm... from a systems programmer's P.O.V. I would have to
disagree! :-)
Todd Whitesel
> of this in the Linux world where various services are enabled on a stock
> system, without the user really knowing about them (or needing them).
> IMHO it would be better if daemons do not run automatically, but rather
> require the system administrator to enable them.
Yeah, that's a problem with a command line interface whose main operation
is "add".
A good feature request for pkgsrc would be to allow different install modes,
like "beginner" vs. "expert" ... I think we need both. End users (and me
when I'm experimenting on a scratch machine) really appreciate having a
mode that just makes a package work; but of course for any mission critical
machine, it is better to have the installer simply populate and leave the
actual enabling to us.
This is one place where an 'inactive' state for rc.d scripts would be ideal;
after installation, you'd do an ``ls -lrt'' in rc.d to see what new services
are available, and decide which ones to enable.
Greywolf
# Yes but my point was that it still doesn't make any real difference --
# it is just an emotional issue. When it becomes an emotional issue the
# supporters of each particular opposing feature will claim superiority
# whether one's really better than the other or not.
Then you have missed the real point. UI feel is important. I'm a
sysadmin. I do it for a living. UI feel is _real_ important to me.
# I can promise you that if you'd started by learning V7 and 32V, then
# suffered under several years of running Xenix and SysIII, and finally
# been relieved a bit by the last releases of SysVr3, and on occasion had
# suffered with fall backs to SunOS-3 and even SunOS-4, and all the time
# working with at least a few systems that had to work reliably in
# commercial production environments, you'd have a much different view and
# be far more accepting of change in those systems regardless of whether
# it's always for the better! :-)
1. You're a SysV veteran. I'm a BSD veteran. I expect our viewpoints
to be slightly askew each other's.
2. I didn't have your experiences: I was born and raised on four washers
and a fridge (VAX 11/750, three 80MB drives and a TapeStretch-11),
migrated to Sun-2 running SunOS 3, to Sun-3 running SunOS 3, to Sun-3
limping along on SunOS 4, to SPARC box running SunOS 4, to SPARC box
crawling on Solaris, with a few lurid interludes with SVR0, SVR2 and 3
(each with NFS, NIS and a Berkeley TCP/IP stack glued on), and A/UX
(which I did a (n admittedly miniscule) bit of work on all back between
the Sun3/SunOS3 and Sun3/SunOS4, as well as a few random encounters
with IRIX, HP-UX and AIX.
# > If you're expected to learn to admin a system, much less use one,
# > what's the FIRST thing you're gonna see...?
#
# The manual pages.
<dry>
Wow. A system that shows you the manual without intervention from the
minute you log in. Now that's intriguing.
</dry>
# *EVERY* "vendor's" system is different. Trying to
# stuff systems into one of two categories is only going to get you into
# trouble. Everyone stole something from everyone else and everyone made
# their mark with something new and unique. Never ever trust that you can
# guess where something is or how something works -- always check the
# documentation and double check with hands-on tests.
Ain't THAT the trough.
#
# > And I concur with der Mouse: To be told that the details of administrating
# > a system are unimportant is an insult to my career as a systems and network
# > administrator.
#
# That's not waht I was saying.
No, that's what we are being told. "It's all in the subroutines which
you should never need to look at."
Now, I have a bit more TRUST in NetBSD trying to do that, but it's magic
which is definitely on the darker side of gray.
# The point is that narrowing your view of
# how to do things so that you're only competent in one environment is
# limiting.
I will grant you that. You've a very valid point. To my defense,
I am not incompetent -- in fact, I'm reduced to doing even some NT
administration these days! -- but I am a hell of a lot more comfortable
in a BSD environment than not (ps, df, su, and LINES=34 are only a few
of the aggravations I can name).
# Criticising differences just because they are different
# doesn't help. Complaining that "the other" way of doing things is
# harder without learning it openly and using "it" in the environments it
# was designed for doesn't help either.
Nor does approaching it with the attitude of "F*ck you. We're doing it
this way and your opinion as a user doesn't matter. Deal."
It's a problem.
# > Define "production quality". What's _really_ wrong with what we had?
# > "Couldn't be automated." Bull[#@$(]. It could be. Just takes some
# > more thought, is all.
#
# Production quality has to do with things like reliability,
# reproducibility, consistency, integrity, and automatability.
Agreed with everything but the last one. Do you *really* trust any
automation to be done right by _every_ script? Do you really trust
the third parties to have their order in sync with your system?
I am certainly not so foolish.
Now, that aside, I must confess to having installed ssh, gone into
/etc/rc.local, s/pkg/local/g, and rewritten /usr/local/etc/rc.d/ssh
so that it took stop/start args...
# An ideal
# production system would run itself in a "lights-out" 7x24 environment,
# upgrade itself, tune itself, and perform its own disaster recovery.
# All the system administrator would have to do is the initial install, plug
# in new hardware when it's required and authorise the addition and
# deletion of user accounts, software, etc. Obviously no system yet meets
# all of those goals 100%....
Thank you SO much for working so hard to make my job obsolete.
# > Production-quality sysadmin tools != dumbing down the tools.
#
# Of course not -- it means making them smarter, more reliable, and more
# consistent, and more automated.
"Dumbing down the tools" : I meant just the transformation you described.
Hiring a monkey to do systems administration. Thankfully, sysadmin is
more than just that.
# > Your first production-quality sysadmin tool had better be your systems
# > administrator!
#
# Well, hmm... from a systems programmer's P.O.V. I would have to
# disagree! :-)
Of course. I'm a systems administrator (and I do my job very well,
thanks).
I'm a systems administrator because, admittedly, I can script and I
can program my own tools as necessary. I've never been put on a
programming project from start to finish (and I can't do that on
my own, really.).
# Greg A. Woods
#
# +1 416 218-0098 VE3TCP <gwo...@acm.org> <robohack!woods>
# Planix, Inc. <wo...@planix.com>; Secrets of the Weird <wo...@weird.com>
#
--*greywolf;
--
BSD: The Power of Code.
der Mouse
> all those people who never want to look at an rc file, ever, and
> couldn't really handle it if they were required to, are the ones that
> benefit most from the change
Yup. Support as many people as possible. Numbers are good, minorities
can go hang.
I see NetBSD as turning into - or trying to turn into - yet another OS
catering to the point-and-drool crowd. *Just* yet another such, even.
That is incompatible with satisfying me or the niche I see myself as
belonging to.
> I know that you don't think that NetBSD ought to pander to the
> incompetant, but it isn't really a choice that anyone gets to make -
Sure it is. There's no reason core couldn't decide that anyone who
*needed* (as opposed to wanted) sysinst was not part of their target
"market", same as they now don't consider people who want to run
MSWindows programs part of their target market and thus don't fault
their OS for not satisfying them.
> more and more people are at least trying NetBSD, the simpler it is
> for them, the less work it is for the people who maintain the system
> - as they don't have to spend as much time helping people cope with
> the simplest things, and can spend more time doing more interesting
> development.
Underlying this is the assumption that NetBSD has to support (either
with software or with handholding) everyone who tries to use it,
regardless of who those "everyone" are. I don't think that's as
necessarily true as you seem to be assuming it is. I see nothing
conceptually wrong with responding to someone who can't grasp the
notion of a disk partition about the way we currently would to someone
who complaints that Microsoft Word won't run: "you aren't part of our
target market; you're better served by some other OS". (What is inside
and what is outside the "target market" envelope is something that few
if any of the free OSes even try to state, so it's not surprising that
it could shift, here, without anyone catching it happening - indeed,
most people probably aren't even aware of the shift.)
If indeed it's a shift; that may have been core's direction from day
one. It's not what I perceived when I first got involved with NetBSD.
Havard...@runit.sintef.no
> > already examples of this in the Linux world where various
> > services are enabled on a stock system, without the user
> > really knowing about them (or needing them). IMHO it would
> > be better if daemons do not run automatically, but rather
> > require the system administrator to enable them.
>
> Yeah, that's a problem with a command line interface whose main
> operation is "add".
Right. IMHO, we need a per-machine separate "enable" step for
deamons and stuff requiring similar treatment.
- Håvard
Greg A. Woods
> Subject: Re: more work in rc.d [was Re: rc, rc.shutdown proposed change]
>
> sysadmin. I do it for a living. UI feel is _real_ important to me.
Yeah, but I'm telling you that if you want your career to have a future
you have to be prepared to take on challenges like this every day. I've
been there and done that for about 15 years now, a good half of the
whole life of all of Unix. I'm probably not a better sys-admin than
anyone in particular and indeed mayb not even as good as most -- I am
just saying that I learned to complain less loudly and under my breath
about the *stupid* and unnecessary differences between various unixes
and to appreciate the different ways of doing things where there weren't
so may stupidities (at least some of the "stupid" things in Unix were
often driven by the various intellectual property issues AT&T forced to
the table and the need for every new vendor to dream up a new name and a
uniquness for their "unix-like" systems).
> # > And I concur with der Mouse: To be told that the details of administrating
> # > a system are unimportant is an insult to my career as a systems and network
> # > administrator.
> #
> # That's not waht I was saying.
>
> No, that's what we are being told. "It's all in the subroutines which
> you should never need to look at."
>
> Now, I have a bit more TRUST in NetBSD trying to do that, but it's magic
> which is definitely on the darker side of gray.
I don't think it was meant quite that way either. My point mostly is
that not everyone who uses Unix, nor even everyone who uses NetBSD, are
system administrators and certainly it's not possible to have a systems
administrator for every machine out there being used productively.
That's the way it is today and it's not a matter of "dumbing down" the
system to make for a wider market share but simply a matter of making
the system more reliable and easier to use for the existing users.
I can guarantee to you that not all of the users using NetBSD want to be
system administrators and more importantly not all of them should have
to be restricted to working in environments where system administrators
are available to support them.
Even if I were to use NetBSD only as a general purpose programming
platform I'd still end up automating and making easier the system
management tasks that I would be forced to perform. Surely you're not
going to tell all the other users of NetBSD that they are not allowed to
benefit from the tools and automation that I and others like me develop
for our own use!
Now if you *want* to look into the details of how rc.subr and rcorder
and all the rest work then please do so!
Indeed if you don't want to use some component of NetBSD then you don't
have to do that either (unless you go to work on someone else's system
that hasn't been subjected to your own personal decisions).
> Agreed with everything but the last one. Do you *really* trust any
> automation to be done right by _every_ script? Do you really trust
> the third parties to have their order in sync with your system?
Automation is incredibly critically important in anything much bigger
than a one-man, one-machine shop. Trust in the tools that automate
systems management comes through verification, validation, testing, and
indeed certification. (Or single-vendor sources, but I don't think many
people, at least in these circles, want that any more!)
> Thank you SO much for working so hard to make my job obsolete.
Don't worry -- the number of systems is growing far faster than
automation can currently reduce the need for skilled system managers.
Personally I hate doing anything mundane more than once especially when
I can see perfectly well a way to automate it.... :-)
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwo...@acm.org> <robohack!woods>
Chris G. Demetriou
> I see NetBSD as turning into - or trying to turn into - yet another OS
> catering to the point-and-drool crowd. *Just* yet another such, even.
> That is incompatible with satisfying me or the niche I see myself as
> belonging to.
> Sure it is. There's no reason core couldn't decide that anyone who
> *needed* (as opposed to wanted) sysinst was not part of their target
> "market", same as they now don't consider people who want to run
> MSWindows programs part of their target market and thus don't fault
> their OS for not satisfying them.
> Underlying this is the assumption that NetBSD has to support (either
> with software or with handholding) everyone who tries to use it,
I can do installs by hand. I can compile just about every package out
there by hand, hacking it to make it work if need be. I can hack rc
scripts and install hooks by hand. I've got the clue, I can devote
brain cells to it.
However, I don't _want_ to. I suspect many others are in the boat.
If you want to be in a niche where you spend a whole lot of time
maintaining systems, and less doing real work or enjoying other parts
of life because of it, great, you can do everythin by hand and hell
you can rewrite rc or whatever you want.
But that doesn't mean that, for instance, it's wrong for others to not
want to do it.
If i can have packages install themselves for me, that's more time i
can spend doing something else. SIGN ME UP. In the bad old days,
installing the software I wanted and needed too way too much of my
time.
If i can have software set up rc scripts for itself, asking me only to
supply configuration information, wonderful!
If i can type a few numbers into sysinst and not have to remember the
right magic, i'll definitely keep other stuff in my head.
Yes, sure, changes like these may help new users, or may help the
system gain popularity with people much UNIX experience.
That doesn't mean that's the only way to interpret their motivations
or results.
And, on the other side of this, there are the people who aren't the
low-level systems hackers:
If NetBSD is actually a great and useful and stable and secure, etc.,
system -- i.e. a worthwhile system to use -- people should _want_ to
use it, to help them get them done with their work, whatever it may
be. data processing, computation, visualization, networking,
whatever. There are a lot of things that are better done on UNIX.
You might want them to have to learn to be Great UNIX Gurus to use it.
But why should they spend their valuable time, err, i should say
_waste_ their valuable time, doing something absolutely useless and
unrelated to what they want to be doing? There is no necessary
inherent cost in using NetBSD over another system; it's just software,
and difficulties with it can be fixed if there's a will.
Why should your will and the will of a few others keep the system from
progressing in ways that, in a nutshell, make peoples' lives better?
cgd
--
Chris Demetriou - c...@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.
John Nemeth
} On Mon, Mar 13, 2000 at 10:52:03PM -0800, John Nemeth wrote:
} > On Jun 29, 10:53am, "Simon J. Gerraty" wrote:
} > } Did I ever mention that the _biggest_ advantage of individual rc scripts has
} > } nothing to do with boot/shutdown managment? Its being able to tell the
} > } night watchman at the end of the line to "type '/etc/init.d/ntpd restart'"
} > } or whatever, rather than explain how to run ps, kill etc etc.
} >
} > I do not consider this to be an advantage, since there is no way
} > that person should get anywhere near a root prompt. If the system is
} > so critical that it can't wait for a qualified person to come on site,
} > then the company better be prepared to do whatever is needed to get
} > that qualified person remote access or pay for qualified people to be
} > on site 24x7. Otherwise, they are just asking for trouble and are
} > likely to have bigger problems.
}
} Uh, no. What bigger problem do you refer to?
}
} Say a problem happens at, oh, 5am. Wouldn't it be smart to
} have a 2xMinimumWage person watching for a blinking red light, and
} then typing one command that will get the system through the rest of
} the night? This way the "qualified person" (who gets paid much more
} than 2xMW) won't have to be called, woken up, pissed off, and then
} compensated?
You're missing several aspects of the real world here. First,
night watchmen rarely have computer access at all, and if they do, then
it is limited to one program or a menu with just a few programs. They
most certainly wouldn't have access to a shell. Second, blinking red
lights rarely happen, and when they do it usually indicate a serious
problem. So, it would almost always take a "qualified person" to
diagnose the problem. If the night watchmen were capable of doing it,
they'd be after your job. Also, the example of '/etc/init.d/ntpd
restart' is rather silly. Something that is that easy almost never
happens (unless the sysadmin is incompetant) and there is still the
issue of diagnosis. Finally, if the "qualified person" gets pissed off
at being woken up, then they are in the wrong job / industry.
} After all, what's the qualified person going to do in the middle of the
} night? Type the same command in to get the system limping along, and
} then go back to sleep. The real problem can be fixed during normal
} business hours (at least typically, in my experience).
I don't know what your experience is, but I would say that you are
missing real world experience. I have spent many hours in machines
rooms in the middle of the night, usually because of hardware problems
(systems that I run rarely go down for any other reason), or because
I'm doing off-hours upgrade/maintenance. If the machine is important
enough that the qualified person has to come in during the middle of
the night to get it going, then it is important enough that it be fixed
completely. This is either because the machine is 24x7 mission
critical, or because it would cost major money for the machine to be
down during normal business hours (think of lost wages due to many idle
hands and/or lost sales; these items are why you see really high costs
attributed to downtime, it's not the costs of repairing the system and
bringing it back up).
} You can even use sudo/ru/similar to keep the night watchman from
} executing any commands other than /etc/init.d/* to minimize the
} damage that said person can do while still allowing for a big
} cost savings from not calling the skilled person.
You can do a h*ll of a lot of damage with just that, especially
since most of those scripts aren't written in a secure manner. And,
there is still the issue of diagnosing the problem. If the person is
capable of diagnosing the problem and choosing appropriate corrective
actions then they might as well be the sysadmin.
}-- End of excerpt from "Kevin P. Neal"
Greywolf
# On Aug 3, 9:08pm, "Kevin P. Neal" wrote:
#
# } After all, what's the qualified person going to do in the middle of the
# } night? Type the same command in to get the system limping along, and
# } then go back to sleep. The real problem can be fixed during normal
# } business hours (at least typically, in my experience).
#
# I don't know what your experience is, but I would say that you are
# missing real world experience. I have spent many hours in machines
# rooms in the middle of the night, usually because of hardware problems
# (systems that I run rarely go down for any other reason), or because
# I'm doing off-hours upgrade/maintenance. If the machine is important
# enough that the qualified person has to come in during the middle of
# the night to get it going, then it is important enough that it be fixed
# completely. This is either because the machine is 24x7 mission
# critical, or because it would cost major money for the machine to be
# down during normal business hours (think of lost wages due to many idle
# hands and/or lost sales; these items are why you see really high costs
# attributed to downtime, it's not the costs of repairing the system and
# bringing it back up).
As a member of a 24x7 operation who has spent several nights about 180
degrees out of phase with a normal sleep schedule lately, I can vouch
for this. "Limping along until normal business hours" (at which point
downtime is more costly) is not an acceptable mode of operation.
The reason for the init.d stuff has already been made clear: It is mostly
for automation of scripts, as well as to flatten the learning curve a bit.
<sarcasm>
Face it, it's "easier" to type
# sh /etc/init.d/foobard restart
than it is to type
# ps axc | grep foobard | awk '{print $1}' | xargs kill
isn't it?
And this is what we are doing. We are making it so that a systems
administrator doesn't have to take the time to learn the real tools of
the trade. Such a noble end, don't you think?
</sarcasm>
#
# } You can even use sudo/ru/similar to keep the night watchman from
# } executing any commands other than /etc/init.d/* to minimize the
# } damage that said person can do while still allowing for a big
# } cost savings from not calling the skilled person.
#
# You can do a h*ll of a lot of damage with just that, especially
# since most of those scripts aren't written in a secure manner. And,
# there is still the issue of diagnosing the problem. If the person is
# capable of diagnosing the problem and choosing appropriate corrective
# actions then they might as well be the sysadmin.
This (and some other omitted stuff) seems to reaffirm the following:
+ Your number one quality grade systems administration tool had
best be your systems administrator.
+ A UI is pretty damned important from the point of view of anyone
who has to maintain the machine.
--*greywolf;
--
BSD: Use the ENTIRE computer!
Simon J. Gerraty
>Face it, it's "easier" to type
> # sh /etc/init.d/foobard restart
>than it is to type
> # ps axc | grep foobard | awk '{print $1}' | xargs kill
>isn't it?
Exactly, especially in the dark.
No need for sarcasm. I stopped being excited about
working 24hrs many years ago. If when the poor junior bunny stuck
with that role rings up out of hours, I'd _much_ prefer to be able
to give him a one line answer than a tutorial. He can learn it
on his own time.
Not talking about yourself, but several folk in this thread
have thrown around claims of what is and is not real life sysadmin.
Commercial reality is that too many sites have fewer and fewer
properly qualified sysadmins and the "bums on seats" mentality
is here. Declaim it all you like (collective you not anyone in
particular), it won't go away. Some suggest that M$ have something
to do with this - when the only solution to any problem is re-install
from CD, you don't need anyone with much skill.
So yes, I find reducing or eliminating the complexity of mundane tasks
a worthy goal. I spent most of the 90's doing that (among other things)
for a company with far more users and computers than competent sysadmins.
--sjg
Michael Richardson
>>>>> "Simon" == Simon J Gerraty <s...@quick.com.au> writes:
Simon> No need for sarcasm. I stopped being excited about working 24hrs
Simon> many years ago. If when the poor junior bunny stuck with that
Simon> role rings up out of hours, I'd _much_ prefer to be able to give
Simon> him a one line answer than a tutorial. He can learn it on his own
Simon> time.
I agree.
And when *I* have to be there at 4 in the morning, *I'm* much more likely
not to screw up due to lack of caffeine.
One can still produce monolithic rc from the startups.. I like this a lot.
I think the proposal on the table is the best of all worlds.
] Out and about in Ottawa. hmmm... beer. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
John Nemeth
}
} I can guarantee to you that not all of the users using NetBSD want to be
} system administrators and more importantly not all of them should have
} to be restricted to working in environments where system administrators
} are available to support them.
All servers, regardless of the OS, should be installed and
maintained by qualified system administrators. To do so otherwise with
production servers is extremely foolish and could be far more costly in
the long run in terms of downtime. I will grant you that there are
many sites that are too small to have full-time sysadmins; but, that is
why there are contractors. A qualified sysadmin should install,
configure, and perform all high level administration tasks (low level
tasks such as changing tapes, creating and deleting accounts, etc.
could be performed by somebody on-site).
}-- End of excerpt from Greg A. Woods
Greg A. Woods
> Subject: Re: more work in rc.d [was Re: rc, rc.shutdown proposed change]
>
> }
> } I can guarantee to you that not all of the users using NetBSD want to be
> } system administrators and more importantly not all of them should have
> } to be restricted to working in environments where system administrators
> } are available to support them.
>
> All servers, regardless of the OS, should be installed and
> maintained by qualified system administrators.
I agree 100%. However the key word in there is "should". Remember too
that not all machines running NetBSD are servers.
> To do so otherwise with
> production servers is extremely foolish and could be far more costly in
> the long run in terms of downtime.
Yup, but that doesn't stop people from thinking they're either immune to
the inevitable problems, or that they're smarter than the average
non-sysadmin, etc. Often up-front costs are deferred because they can
be and the fact that future disaster might strike is irrelevant because
it is only a future possibility.
> I will grant you that there are
> many sites that are too small to have full-time sysadmins; but, that is
> why there are contractors.
As one of those contractors I can assure you that we do indeed end up
doing costly fire-fighting as a result of lack of attention to various
sysadmin details which almost always could have been handled with less
cost up-front in the first place. I.e. regardless of the availability
of sysadmins, either in-house or contracted, real-world people often
fail to take advantage of them despite the also availiable evidence that
future problems will cost more to fix as a result.
I think the issue is one much larger than just whether or not a shop
decides to hire a qualified sysadmin vs. ``coercing'' an existing
employee who is, if not also less qualified, focused on their primary
duties. I read an interesting article in CACM recently ("The Myths and
Realities of Information Technology Insourcing", Feb 2000) about various
techniques at trying to show senior management that IT/MIS departments
are not just cost centres even though their returns are often less
tangible than a black number on the bottom line of the balance sheet and
that insourcing can be cheaper than outsourcing. The most important
thing I got out of the article though was that senior management is
reluctant to fund IT/MIS departments regardless of whether the work is
done inside or outside and these quotes sum it up pretty well: "The
Board coud care less about IT. They treated it like they treated heat
or electricity [services]." and "They are always telling us our
processing for payroll is too damn expensive. Then when you say `Well
have you looked outside?' [they reply] `Oh yes, we beat the heck out of
them.' so our costs are too high but they can't get it any cheaper."
While this article focused on multi-billion-dollar companies the issues
with convincing senior management about the "value" of IT remain in many
companies of much smaller size too (and contrary to the big companies
often small companies simply cannot afford anything "extra" for IT).
John Nemeth
} >>>>> "Simon" == Simon J Gerraty <s...@quick.com.au> writes:
} Simon> No need for sarcasm. I stopped being excited about working 24hrs
} Simon> many years ago. If when the poor junior bunny stuck with that
} Simon> role rings up out of hours, I'd _much_ prefer to be able to give
} Simon> him a one line answer than a tutorial. He can learn it on his own
} Simon> time.
}
} I agree.
} And when *I* have to be there at 4 in the morning, *I'm* much more likely
} not to screw up due to lack of caffeine.
I'm a night-owl (look at the Date: on this message) so being there
at 4am does bother me. Although, I usually try to do my work after
business hours and before midnight. On the otherhand, being there at
9am does bother me :-) Also, I don't drink coffee or smoke, etc. (i.e.
I'm not dependent on drugs to get me going).
}-- End of excerpt from Michael Richardson