Re: periodic(8) pkg_* tasks not in /etc/defaults/periodic.conf ?

On Thu, Aug 01, 2024 at 08:39:50AM +0100, Matthew Seaman wrote:
> On 31/07/2024 17:32, Steve Rikli wrote:
> > I usually start with /etc/defaults/periodic.conf for candidates I might
> > want for customizing periodic(8) behavior.  I also check the various
> > periodic man pages, and scripts themselves occasionally.
> > 
> > Recently I checked periodic.conf(5) and found there are some documented
> > variables which do not also appear in /etc/defaults/periodic.conf e.g.:
> > 
> >      weekly_status_pkg_enable
> > 
> > as well as pkg_version and pkg_version_index, possibly others.
> > 
> > It seems like most of the man page variables have default settings in
> > /etc/defaults/periodic.conf so maybe the missing pkg_* variable(s)
> > entries are a simple omission?
> > 
> > Adding weekly_status_pkg_enable="YES" to /etc/periodic.conf[.local]
> > works as expected, it just seems atypical there's no default for it.
> > 
> > Happy to file a bug if that's appropriate.
> 
> /etc/defaults/periodic.conf documents the variables used by the periodic
> scripts shipped with the base OS.  However, installing pkg(8) adds some
> periodic scripts that aren't part of the base.  There isn't really a
> mechanism to gather the defaults for (effectively) 3rd party periodic
> scripts into one place -- which might be a nice enhancement if someone can
> come up with a clean way of doing it.
> 
> Basically the same thing applies to rc scripts installed from ports.

That makes sense, though one could argue pkg(8) itself is (nearly) part
of base.  It somewhat straddles the line, and I recognize it's possible
to have a system without bootstrapping pkg(8) or installing additional
pkgs (or ports).

One difference I see between pkg(8) periodic defaults and periodics
from other pkgs/ports is

  pkg(8) has periodic defaults documented in a base man page
  (i.e. periodic.conf(5)), whereas other ports and pkgs do not

That's generally a good thing -- more docs usually is :-).  But it seems
like having info in a base man page means (implies?) that base defaults
entries for it should also be present. The man page info alone is much
better than having neither, of course.


Wrt a possible enhancement solution, something which attempts to handle
periodic defaults for pkg/ports: perhaps including another dir in
$periodic_conf_files, e.g.

  ${_localbase}/etc/defaults/periodic.conf

or similarly, adding another dir to $local_periodic, if possible, e.g.

  ${_localbase}/etc/defaults

either is basically mirroring /etc/ structure; though that new dir
(e.g. /usr/local/etc/defaults/) doesn't exist today, so it's kind
of a big change for a potentially small addition of functionality.

This one is already listed in the $periodic_conf_files variable:

  ${_localbase}/etc/periodic.conf

which also doesn't exist by default, I believe. Is that a reasonable
place for the documented pkg_* periodic variables to be listed by a
FreeBSD install, and potentially for ports/pkgs to have their settings?

On that point, it seems like there ought to be a separation between
defaults which shouldn't be modified, vs. overrides and settings which
are expected to be changed as needed. Just as there is today:

  /etc/defaults/periodic.conf    (not intended to be changed)
and
  /etc/periodic.conf[.local]    (changed as needed)

there could be something similar for ${_localbase} programs, as well as
for the pkg (and ports?) tools themselves if they aren't going to be in
base.

I think if ${_localbase}/etc/defaults/ was already created by a new
FreeBSD install, I'd say also install a periodic.conf there for default
settings, maybe including the pkg_* variables documented in
periodic.conf(5), and then use ${_localbase}/etc/periodic.conf for
overrides and ports/pkgs settings as can be done today.

Fwiw, with my sysadmin hat on, I tend to put new periodic settings and
overrides in the same file -- /etc/periodic.conf.local -- whether they
come from base, or from pkgs/ports.  Arguably I should be defining e.g.
$daily_status_smart_devices et al in ${_localbase}/etc/periodic.conf but
it hasn't worked out that way. ;-)  So some of these ideas may just be
overthinking and could end up unused anyway.

Hypothetically, if/when pkgbase becomes the/a norm, would that change
any thinking about pkg_ variables in /etc/defaults/periodic.conf? I
confess I don't know the answer, as I haven't tried it yet. :)

Sorry for the long reply, I don't know how much of this is actual food
for thought vs. rambling pontification.  :-)

Cheers,
sr.