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 <> 
>    Date:        Sat, 16 Apr 2011 20:33:43 +0000
>    From:        David Holland <>
>    Message-ID:  <>
>  | /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