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 Sun, Apr 17, 2011 at 12:49 AM, Robert Elz <kre%munnari.oz.au@localhost>
wrote:
> 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).
Define a new configuration variable to tune the umask.
> 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).
Fix the script to look for the correct name. Sounds like 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. 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.
Add a variable to tune this behavior; hardcoded values are never good.
> Then if network checking is turned on, there's no way to avoid ruptime
> and just look at the network connections.
Add a yes/no variable.
... yadda yadda ...
The fact that these things are not configurable nicely, other than by
editing hardcoded values, is a result of these scripts trying to be
generic but not really being because people is supposed to edit them
in place. This is not the result of a nice design.
--
Julio Merino / @jmmv
Home |
Main Index |
Thread Index |
Old Index