Re: Moving rc.d scripts to base.tgz

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 16 Apr 2011 20:33:43 +0000
    From:        David Holland <dholland-tech%NetBSD.org@localhost>
    Message-ID:  <20110416203343.GA27594%netbsd.org@localhost>

  | /libexec. Which is also where /etc/{daily,weekly,monthly,security}
  | should be, as there hasn't AFAIK been any valid reason for sysadmins
  | to edit those in a long time.

That's clearly incorrect, all you need to do is look at them to see that.

The obvious first potential problem with all of them is the "umask 077"
which is likely to be OK for many people, but certainly is not necessarily
suitable for everyone (some might want umask 037 instead - or even 033).

That's in all of them.

There's not much else to say about /etc/monthly, as aside from running
monthly.local (which is obviously intended to be modified at the site)
it does nothing else.

But daily and weekly are full of things that might need to be added, eg:
daily looks for core files, but using its own idea of what a core file
name is, totally ignoring the sysctl variable kern.defcorename (and
kern.coredump.setid.path as well, of course).

Then it has a built in list of fstypes to ignore when doing the df that
checks file system space, the only config is whether it includes remote
filesystems or not - personally I see no need to include mounted cd's
(and dvds of course) in this output, as they're not writeable, and so
that they always appear 100% full isn't really very interesting.  The
standard list also omits procfs, which to me is no different from this
purpose than kernfs which is included - I suspect just because most
people use kernfs these days, but procfs is or was less useful (but the
need for it from many linux emulation binaries means that it is now
quite common, at least the /usr/pkg/emul/linux/proc version).  The
list also skips unionfs (that is, fails to exclude it) which also doesn't
seem consistent - just that unionfs isn't recommended to be used.
But you get the point, I'm sure.

Then if network checking is turned on, there's no way to avoid ruptime
and just look at the network connections.

And for process accounting, there's no way to alter the number of days
of past accounting files that are retained (it is just "4"), or for that
matter, whether any are kept, the only config (aside from whether to
do it at all or not, which should probably be deduced from whether or
not accounting is turned on in the kernel - it is a waste of time purging
accoounting if there is none, and close to a disaster not to do it if
accounting is on (especially since NetBSD seems to have lost the ability
to suspend writing accounting data if the filesystem concerned gets close
to full).

Then in /etc/weekly, there's no way to alter the niceness used to rebuild
the locate database (or that nice is used at all), there's no way to
keep the current locate database while a new one is being built, so the
locate command just silently fails to report sane results while the
rebuild is happening (and the same for the whatis database, but no-one
really cares...)

And, for both of those (daily and weekly) - and for monthly too, if
it did anything, there's no way (aside from editing the script, naturally)
to alter the order in which the various functions are carried out,
which is probably important only in terms of the order of the generated
report, but for that, it can be useful to have the parts that need most
attention from the local admin to come first.

This one ought to be handled by moving these scripts to a rc.d type
setup, and by "a" I do mean singular, not one each for daily weekly
and monthly - an /etc/periodic (or /whatever/periodic) which contains
rc.d/* type configs for the individual functions that need to be run,
with (overridable) keywords to set the frequency desired, and the
order in which to run them (which just like rc.d needs to be something
that can be altered by the site admin, that one - finally - seems now
to be getting the attention it needs).

Once we have that, the script can each get a bit more complex to
handle the issues above - no-one really wants a 500 line /etc/daily
just so every little feature can be configured, but 10 50 line scripts
would be manageable... (it isn't the overall volume that matters, but
the complexity for anyone who needs to look at (one of) the scripts).

We can also easily have annual, semi-annual, quarterly, bi-monthly,
bi-weekly, odd days, and all kinds of other periodic scripts, and not
just the three varieties that are currently provided.   This can also
deal with the problem of whether or not the daily script should run the
same day as the weekly and monthly scripts, and how to avoid them
running in parallel (which we currently achieve by offsetting the start
times and hoping...)

  | However, before you can do any of this you must address the two
  | reasons /etc/rc.d is still considered configuration:
  | 
  | 1. It is currently necessary to edit the rc scripts if you need to
  | fiddle with the ordering.

Yes, we need to fix this one, and always have.

  | 2. The recommended method for usin pkgsrc (and local) rc scripts is
  | still to copy them into /etc/rc.d.

And that should stay - having a whole bunch of different directories
for config scripts (of the same nature) just makes life harder.

And this brings up the point that has been avoided in much of this
discussion - while the rc.d/* scripts themselves might be "binaries"
(in the sense that ideally we should have no more need to alter them
than /bin/ls etc) but the directory /etc/rc.d itself isn't, it is
a configuration file, and is intended to be altered, in ways that /bin
(and /libexec etc) aren't.

kre