From nobody Thu Aug 01 15:56:38 2024 X-Original-To: questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WZYVr0XNjz5SyKt for ; Thu, 01 Aug 2024 15:56:52 +0000 (UTC) (envelope-from sr@genyosha.net) Received: from ns1.genyosha.net (ns1.genyosha.net [50.39.243.221]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "float.home.genyosha.net", Issuer "float.home.genyosha.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WZYVp6H7Xz4Z8X for ; Thu, 1 Aug 2024 15:56:50 +0000 (UTC) (envelope-from sr@genyosha.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sr@genyosha.net designates 50.39.243.221 as permitted sender) smtp.mailfrom=sr@genyosha.net Received: from dragon.home.genyosha.net (ops0.genyosha.net [50.39.243.219]) by ns1.genyosha.net (8.18.1/8.18.1) with ESMTPS id 471FuheR019642 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 1 Aug 2024 08:56:43 -0700 (PDT) (envelope-from sr@genyosha.net) Received: from dragon.home.genyosha.net (localhost [127.0.0.1]) by dragon.home.genyosha.net (8.14.7/8.14.7) with ESMTP id 471FucMS026434 for ; Thu, 1 Aug 2024 08:56:38 -0700 Received: (from sr@localhost) by dragon.home.genyosha.net (8.14.7/8.14.7/Submit) id 471FucXg026433 for questions@freebsd.org; Thu, 1 Aug 2024 08:56:38 -0700 Date: Thu, 1 Aug 2024 08:56:38 -0700 From: Steve Rikli To: questions@freebsd.org Subject: Re: periodic(8) pkg_* tasks not in /etc/defaults/periodic.conf ? Message-ID: References: <54896639-d782-4bb5-a712-e41471840913@FreeBSD.org> List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-questions@freebsd.org Sender: owner-freebsd-questions@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54896639-d782-4bb5-a712-e41471840913@FreeBSD.org> X-Greylist: inspected by milter-greylist-4.6.4 (ns1.genyosha.net [50.39.243.221]); Thu, 01 Aug 2024 08:56:43 -0700 (PDT) for IP:'50.39.243.219' DOMAIN:'ops0.genyosha.net' HELO:'dragon.home.genyosha.net' FROM:'sr@genyosha.net' RCPT:'' X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (ns1.genyosha.net [50.39.243.221]); Thu, 01 Aug 2024 08:56:43 -0700 (PDT) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.25 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.95)[-0.952]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_MATCH_FROMTLD(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:20055, ipnet:50.39.128.0/17, country:US]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[questions@freebsd.org]; DMARC_NA(0.00)[genyosha.net]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[questions@freebsd.org]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4WZYVp6H7Xz4Z8X 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.