Re: Moving rc.d scripts to base.tgz

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sun, Apr 17, 2011 at 06:49:06AM +0700, Robert Elz wrote:
 >   | /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.

Well, I'm not sure about that. It's been a long time since I felt I
needed to patch one of them for local purposes; and in fact, most of
the things you describe are bugs.

 > 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.

Does it have any significant effect? The permissions of output files
generated by these scripts ought to be getting set explicitly, and
granting read access to temporary files and such seems pointless and
possibly a liability.

It looks as if the permissions of the saved accounting files are not
preserved; that's a bug. (Especially given that it explicitly tracks
and preserves whether they're compressed or not.)

 > 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).

That's a bug.

 > 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.

That seems like a bug too; maybe there should be a knob, or maybe it
should always exclude read-only full volumes, or the list of fstypes
to skip should include all the ones where we don't have read-write
support.

 > The
 > standard list also omits procfs, which to me is no different from this
 > purpose than kernfs which is included

That's definitely a bug, but it looks like it's been fixed in current.

 > 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.

There's certainly no point in reporting df output on unionfs, so
that's a bug too.

Maybe it's worth listing all unionfs mounts found as a warning though :-)
but if so that should be separate.

 > But you get the point, I'm sure.

Yes, it needs fixing.

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

ruptime? I've never seen it run ruptime... hmmm:

        t=/var/rwho/*
        if [ "$t" != '/var/rwho/*' ]; then
                ruptime
        fi

I guess the assumption is that if you run rwho at all you want to see
the status. That doesn't seem entirely unreasonable, but it's
certainly easy enough to improve it.

 > 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

That's a bug, that should definitely be configurable. (And I've always
wondered why it's not handled via newsyslog, too. It seems like the
best fix is to make that work, and then it's not just configurable but
also configurable the same way as everything else.)

 >  (especially since NetBSD seems to have lost the ability
 > to suspend writing accounting data if the filesystem concerned gets close
 > to full).

I just fixed that a couple weeks ago. Or I think I did. See PR
43413. I haven't filed pullups yet because I haven't had time to
actually test that the fix works -- if you have a machine that's
naturally prone to this (I used to but don't any more) give the patch
a try.

 > 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), 

Bug.

 > 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

That's definitely a bug. (Keeping it should be the default behavior,
too, or perhaps the default unless disk space is very low.)

 > (and the same for the whatis database, but no-one
 > really cares...)

still a bug.

 > 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.

That is a valid point, and furthermore editing the script to do this
is bad because it puts you squarely in merge hell. But it's not so
easy to arrange. If each operation is written as a shell function then
you can do something like:

   OPS=$(echo "$operation_order" | tr ' \t' '\n\n' | sed 's/^/op_/')
   for OP in $OPS; do $OP; done

but this needs additional checking for robustness and it leaves the
sysadmin with a maintenance hassle whenever new operations are added.
Some kind of before/after ordering constraint system akin to the one
used for rc scripts would be better, but it's not entirely trivial;
you can feed the ordering constraints and the list of available
operations to tsort easily enough but then you get arbitrary ordering
(that might change next time something's added) for things you haven't
nailed down and that's not desirable either.

 > 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).

I'm not sure this is desirable either; one of the things I really
dislike about Linux is the proliferation of /etc/foo.d directories
full of tons of little files whose names and name ordering might or
might not be significant.

Then again, it's having to cope with these things as configuration
that bugs me. If the scripts are kept in /usr/libexec/periodic, or
/usr/libexec/maintenance, and the controls are elsewhere, it's
probably ok.

hrm. Probably the best comprehensive solution is to do that and just
list them in root's default crontab. This would require teaching cron
to handle combined jobs or combined report mails in some fashion,
which might or might not be realistically tractable. But assuming it
is, it's probably better to just be doing crontab -e than adding and
working with an additional layer of daily/weekly/monthly
configuration.

 >   | 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.

Right.

 >   | 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.

I'm not convinced; after all, there's a reason we have a whole bunch
of different directories for bins. The only reason we can't have
/usr/pkgsrc/etc/rc.d and /usr/local/etc/rc.d and have it all work is
that rcorder has no ability to do a partial run and resume later after
mountcritlocal (or whatever)... but this is fixable.

 > 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.

Right.

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