Re: bin/59990: /etc/security: first run mails megabytes of output

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Sun, 15 Feb 2026 18:49:11 +0300
> From: Valery Ushakov <uwe%stderr.spb.ru@localhost>
> 
> On Sun, Feb 15, 2026 at 14:34:21 +0000, Taylor R Campbell wrote:
> 
> > And we'd have to model the listing of devices and suid/sgid files via
> > mtree(8) -- and find some way to model the disklabels and MBRs too
> > (and GPTs if we did that).
> 
> It doesn't have to be perfect.  Just pre-creating the baseline
> "backups" for the /etc and /root dot-files is already an
> improvement... and saves time on the first boot for slower machines
> (spare a thought for a diskless Jornada with NFS root over 10MB PCMCIA
> card, or slower SD cards in arm gizmos).

There's another complication: we would need to either toolify RCS (or
at least ci(1)), or hackily generate the initial ,v file another way.

> > So perhaps a simpler approach -- and what I'm trying right now for the
> > present purpose -- is an rc script that just does:
> > 
> > 	# Make sure /etc/security has saved a backup of everything.
> > 	if ! [ -s /var/backups/etc/master.passwd.current ]; then
> > 		/etc/security >/dev/null
> > 	fi
> > 
> > (master.passwd is the one file that is unconditionally always backed
> > up, hard-coded in /etc/security.)
> 
> I guess that's not _too_ bad, as long as it doesn't take a week on
> sun2... :) Pre-creating the "backups" that we can precreate will
> probably speed it up too.

Well, if it takes a week, the daily insecurity report will be in
trouble too!

Do we even have any mechanism for preventing a long-running /etc/daily
or /etc/security from overlapping with the next run?  I don't see any
obvious lock files or collision detection.