Install Linux binaries in `/opt` instead of `/usr/local`, with `-bin_root_dir`, to support Fedora Silverblue

[strugee]

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 #896 (comment)

[strugee]

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.)

[strugee]

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.

[directionless]

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.

[strugee]

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.

[strugee]

@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.

[directionless]

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.

[coyotte508]

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

[federicotdn]

I managed to get the kolide-ele project working on Fedora Kinoite 43 via some small changes: https://github.com/federicotdn/kolide-ele (I may open a pull request, but I have only tested this once, locally)