pkgbasify: Add to the base system

[emaste]

Summary

Our supported 14->15 update path will be either (1) pkgbasify on 14.x followed by pkg-based update to 15.0 or (2) freebsd-update to 15.0 followed by pkgbasify.

[ivy]

does pkgbasify correctly handle configuration files? pkgbase itself does not, which means e.g. root ends up with an empty password after switching to pkgbase. this is fine for testing but would not be acceptable on a production system.

[ivy]

libexec/pkgbasify/pkgbasify.lua

159

this should not be necessary, the postinstall script should already run pwd_mkdb, cap_mkdb or anything else that's needed.

[emaste]

libexec/pkgbasify/pkgbasify.lua

159

My intent is that if/when we go ahead with this review the one in src will be canonical, but until then we can make individual changes to the copy in https://github.com/FreeBSDFoundation/pkgbasify/

[ivy]

libexec/pkgbasify/pkgbasify.lua

159

understood. i need to spend time on other things prior to code slush so i don't have time to investigate that (and i don't mind if we run pwd_mkdb unnecessarily) but please note my other command about /etc/master.passwd: we cannot have an upgrade path that reset's root password, this needs to be fixed somehow.

[ifreund_freebsdfoundation.org]

libexec/pkgbasify/pkgbasify.lua

159

@ivy it is in fact necessary to run pwd_mkdb and cap_mkdb here since pkgbasify *does* handle configuration files, see the merge_pkgsaves() function. It performs a 3-way merge against the .pkgsave files using the current etcupdate database as the parent.

I'm not 100% sure what you mean by "correctly handle configuration files" though, perhaps you have something else in mind?

[emaste]

Add man page based on https://github.com/FreeBSDFoundation/pkgbasify/blob/main/README.md

[emaste]

For now I've placed it in /libexec with an assumption that we might use freebsd-update as a wrapper to call it -- based on discussions on continuing to use freebsd-update as a wrapper for upgrades managing the kernel-first-then-userland approach. It could be /usr/sbin/pkgbasify though.

[ivy]

libexec/pkgbasify/pkgbasify.lua

159

currently, updating from non-pkgbase to pkgbase overwrites /etc/master.passwd with the default copy of master.passwd, which means all local users are deleted and root's password is set to an empty string.

if pkgbasify already handles this and correctly installs the user's existing copy of master.passwd then that's fine, i just wanted to mention this as it's a fairly serious issue in the current pkgbase infrastructure.

[emaste]

libexec/pkgbasify/pkgbasify.lua

159

Yes pkgbasify handles this. I've now brought content from @ifreund_freebsdfoundation.org's README.md to a man page which describes pkgbasify's operation.

[ifreund_freebsdfoundation.org]

libexec/pkgbasify/pkgbasify.lua

159

currently, updating from non-pkgbase to pkgbase overwrites /etc/master.passwd with the default copy of master.passwd, which means all local users are deleted and root's password is set to an empty string.

Yes, and in this case pkg makes a backup of the file as /etc/master.passwd.pkgsave before overwriting it. After the overwriting pkg install completes, pkgbasify then merges that backup with the version installed by the pkgbase package, effectively restoring the backup.

However, there's a good argument to be made for special-casing critical configuration files like /etc/master.passwd and /etc/sshd/sshd_config rather than handling them generically like any other configuration file due to the catastrophic failure modes.

I've already seen one user run into an issue caused by making /etc/sshd/sshd_config a symlink. In this case, pkg does not backup the file to foo.pkgsave before overwriting it and pkgbasify then has no backup to restore from.

I'm not sure there's a way to completely avoid a window in time where /etc/master.passwd has the wrong data without adding some kind of new feature to pkg.

[grahamperrin]

Will there be a distinct FreeBSD-pkgbasify package in the FreeBSD-base repo?

If not,

In D51594#1178444, @emaste wrote:

For now I've placed it in /libexec … could be /usr/sbin/pkgbasify though.

– which existing package will provide pkgbasify?

---

For use cases where FreeBSD-base is not already present alongside FreeBSD-ports (or, more vaguely, FreeBSD):

• addition to the ports collection – sysutils/pkgbasify – will help.

If in FreeBSD-base but not FreeBSD-ports, then pkgbasify may be added without adding a repo configuration. A future example might be:

pkg add https://pkg.freebsd.org/FreeBSD:14:amd64/base_release_4/FreeBSD-pkgbasify-14.4.pkg

Use of pkg-add(8) is discouraged (see, for example, https://github.com/freebsd/pkg/issues/1946#issuecomment-2909099386), but still, useful when working without a repo config.

[bcr]

libexec/pkgbasify/pkgbasify.8

80

s/pkgbasify/.Nm/
Or if you don't want to start a sentence with a lowercase word, start with: The .Nm utility ...

[ziaee]

In D51594#1178444, @emaste wrote:

For now I've placed it in /libexec with an assumption that we might use freebsd-update as a wrapper to call it -- based on discussions on continuing to use freebsd-update as a wrapper for upgrades managing the kernel-first-then-userland approach. It could be /usr/sbin/pkgbasify though.

I think libexec is the right approach since only some systems will ever need to call this only once. Bin directories clutter the path.

[kib]

If /usr/sbin is fine, but libexec is decided, then it should be /usr/libexec and not /libexec. /libexec is for something that is needed when booting the system.

[emaste]

it should be /usr/libexec and not /libexec

Yes, it should pick up the default from libexec/Makefile.inc BINDIR?= /usr/libexec