tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Moving rc.d scripts to base.tgz



On Sat, Apr 16, 2011 at 09:26:21PM -0400, der Mouse wrote:
 > >> So, admins that find NetBSD's maintenance scripts unsuitable for
 > >> their purposes must provide their own, rather than modify the
 > >> existing ones?
 > > If what you're doing is patching the system, patch the system.  [...]
 > 
 > >> [...]
 > > You're merely being difficult here.
 > 
 > Not trying to be.

Well, you're harping on what "valid" means instead of making any
constructive points about what a sysadmin might be trying to
accomplish by editing the scripts.

If a sysadmin wants to make custom changes to a program in /usr/bin,
they realistically need to either patch the source or install a custom
replacement in /usr/local/bin. For example, on a number of machines I
have a local change to w(1) that prevents long hostnames from eating
the entire screen width.

I don't see why the nightly maintenance program (or any of the others)
is or should be any different from other programs -- the mere fact
that it's editable because it's a shell script is not a particularly
good reason, nor is the fact that because of ancient history it
appears in /etc instead of /usr/libexec. Once upon a time you had to
edit it because it wasn't configurable; originally AFAIK it was there
to serve as an example or starting point for maintenance scripts that
sysadmins otherwise got to write from scratch. But neither of those
things is true any more

Just as we don't make provisions to handle custom sysadmin in-place
edits of /usr/bin/w, I don't see any reason we need to make provisions
to handle custom sysadmin in-place edits of the nightly maintenance
script. There are facilities for extending it, and if you want to
rewrite it extensively the right place to do that is the system source
tree.

Robert Elz has posted a list of reasons that one might edit or rewrite
the scripts; however, most of those reasons look like bugs that should
be fixed. Go see the response I'm about to write if you're interested
in the specifics.

 > I find myself wondering how an admin is supposed to tell whether a
 > proposed change is "patching the system" under NetBSD or a
 > reasonable end-system admin adjustment.

It's very easy: if something you edit will be overwritten by the next
installworld, then you probably wanted to edit the source rather than
making modifications in place.

Things in /etc are supposed to be configuration and are therefore not
supposed to be (and are not) overwritten by install. This is why these
scripts should be moved out of /etc.

The question you're really asking, which is how one determines which
things are supposed to be administrator-configurable without patching
the system source, is a matter of design and taste, largely. It's also
about expectations as much as anything else: do we expect a sysadmin
to need to edit the periodic scripts to have a usefully functioning
system? I'd say we don't; we'd like NetBSD to be generally usable by
sysadmins who are not experts at shell scripting, since that describes
the majority of even the fairly clueful population. Therefore, the
scripts should be configurable enough to do whatever is reasonably
needed, or be turned off if they're in the way; that means in turn
that there should also be no need for the people who *can* edit them
to have to actually do so.

I don't see that it's unreasonable to ask the small number of people
who routinely make substantial modifications to the system to do so as
source patches; in fact, as a general rule it's much easier to manage
such modifications that way than as custom edits that have to be
redone (often slightly differently) on every newly installed machine.

-- 
David A. Holland
dholland%netbsd.org@localhost


Home | Main Index | Thread Index | Old Index