kolide
Install Linux binaries in `/opt` instead of `/usr/local`, with `-bin_root_dir`, to support Fedora Silverblue
On Fedora Silverblue, a immutable, atomic desktop, /usr/local is a mutable area of the filesystem reserved for the local system administrator. Therefore, it is not present during package installation, resulting in a "No such file or directory" error when installing Kolide's RPMs.
Instead, Kolide should drop binaries in /opt. See hier(7).
See also https://github.com/kolide/launcher/issues/896#issuecomment-1459712655
FYI, I don't have the full command in front of me at the moment but I got this completely working last night by passing -bin_root_dir /opt to package-builder (though I hit some confusing bugginess around argument ordering for a long while).
So this should be trivial to fix. (/var/lib/kolide-k2 or whatever it was in the RPM package won't get created properly on ostree systems, including Silverblue, but this appears to not be a problem since the daemon apparently recreates this directory if it's missing. And RPM packages creating /var directories is evil anyway.)
Here's the command I used (you'll need to make package-builder first, and you'll also need to download the official RPM to ~/Download in order to extract the secret):
./build/package-builder make -identifier kolide-k2 -update_channel stable -transport jsonrpc -hostname k2device.kolide.com -enroll_secret $(rpm2archive ~/Downloads/kolide-launcher.rpm | gunzip | tar xO ./etc/kolide-k2/secret) -targets linux-systemd-rpm -output_dir pkgout -bin_root_dir /opt -i-am-a-kolide-customer true
The RPM package will be in ./pkgout.
For some background, launcher installs into /usr/local/kolide-k2 for historic reasons. I agree it would make more sense to install to /opt/kolide. However, moving it is trickier than it sounds. It's easy to build a new package, but we need to handle cases where people install newer and older packages, so there's an entire migration flow that we need to build to facilitate that.
Can't you offer the /opt package only for Fedora Atomic Desktop users? It clutters the package list on kolide.com, and means other Linux packages would still be "wrong", but saves a bunch of work.
@directionless are you sure there's a migration flow needed? AFAICT from looking at /opt/kolide-k2/bin, the only binaries that are affected by -bin_root_dir are launcher and osqueryd. Both of which are owned by the package. In theory that means that when someone upgrades from a pre-this-change package, the copies of those binaries in /usr/local will be removed, and newer copies will be installed in /opt/kolide-k2, no?
Is the problem /var/kolide-k2/k2device.kolide.com/launcher.db, which grep says contains the string /opt? Or the /usr/lib/.build-id stuff...?
Of note: none of the launcher state data has to move away from /var.
are you sure there's a migration flow needed
Probably. It's something we'd need to evaluate across our customers. There are a lot of odd deployments out there.
FYI there's this repo with patches: https://github.com/chainguard-dev/kolide-ele to be able to install kolide on fedora silverblue (bazzite/bluefin) - I am not related at all to that repo.
Would be nice if support for those distros was built-in, bluefin in particular is really nice for dev work
