Introducing dfbeadm(8), Ready for Testing

[Michael Voight]

Hello everyone,
I've been working on this project primarily during my lunch breaks over the past few months, and have reached a point where I feel it's viable for more wide-spread testing than just my laptop.
The build I'm calling "v0.1.0-BETA" is available in a mostly frozen branch here: https://github.com/newnix/dfbeadm/tree/v0.1.0-BETA
If you're feeling adventurous, you can switch to "master" but I can't recommend that unless you have an install you're not particularly attached to.

A quick overview is that this is a C implementation of beadm(8) on FreeBSD/Illumos, but specifically for DragonFly BSD and HAMMER2. The utility creates snapshots of every mounted HAMMER2 filesystem
using the name given on the command line as an identifier, so for example, if you run `sudo dfbeadm -c testing`, a HAMMER2 filesystem `nvme0s1d at ROOT` gets a new snapshot called `nvme0s1d at ROOT:testing`.
It'll create a backup copy of your fstab in `/etc/fstab.bak` before installing the new fstab for the boot environment. At this time, you'll still need to update your `loader.conf(5)` to set the correct
`vfs.root.mountfrom`, this should just require adding on the new boot environment (or updating it in the case of having several). Rollback on failed creation of a boot environment is planned, but not functional in this version.

I wanted to start getting feedback, as it's been a long time without any real progress report aside from mentioning it periodically in IRC.

In my own testing, there's a few considerations and limitations that have come up:

* Due to how snapshots are generated, the new fstab is created before the snapshots, so in the unlikely event that a boot environment is unable to be created, you'll have to manually revert the fstab via `sudo mv /etc/fstab.bak /etc/fstab`
* Due to what's being done, significant portions of the code need to be run as root, I'd like to do some privilege separation at some point, but it'll require some reworking to pass the boot environment structs around properly
* For some reason I've not had the time to hunt down properly, if you, like me, have a somewhat complex filesystem layout where your $HOME is its own HAMMER2 PFS, the snapshot will be mounted with permissions `root:wheel 0000` and needs to be corrected.
I'm considering possibly having a privileged daemon run separately to handle the privileged functions after receiving a message from a properly authenticated user, but also allow listing without needing root privileges.
* Currently, the `-l` option is the only supported flag other than `-c`, and has no way to be certain that it's properly listing boot environments. As is, it'll list all "managed" snapshots, which are assumed to be part of a boot environment
* While I have not tested it, if your `/boot` is HAMMER2, you'll effectively be able to run several versions of DragonFly BSD on the same PFSes, simply by changing your boot environment
* Currently, boot environments are not tracked, this is a planned addition to future versions, likely through a SQLite3 database
* Currently, there's no way to omit a PFS from the snapshots, so if you're running X, vim, or some other program with temporary files under $HOME, they'll be captured in the boot environment. This may cause some mild annoyances depending on workflow.

My workflow is based on fossil repos that are mirrored to github, but I'll get notifications if you feel like opening an issue or sending pull requests to address anything you may run into, it just may take me a bit to
integrate them. I make no claims to be a C expert, but I thought this would be a useful tool, giving DragonFly BSD devs one more way to stage their work, having the ability to revert your filesystem to a previous version, so long as you have a compatible ABI with the kernel being used.
Please feel free to mail me back or ping me @newnix on IRC, I'll try to get around to addressing any questions or concerns, kinda new to this. Hope y'all find it as useful as I have!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20190821/2184dfce/attachment-0002.htm>