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

["Taylor R Campbell via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR bin/59990; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Valery Ushakov <uwe%stderr.spb.ru@localhost>
Cc: gnats-bugs%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: bin/59990: /etc/security: first run mails megabytes of output
Date: Sun, 15 Feb 2026 19:17:22 +0000

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