buildFHSEnv and a self-updating service that wants to update in place

According to the documentation for buildFHSEnv (Nixpkgs 23.11 manual | Nix & NixOS), it can be used for self-updating binaries.

So in my case, I’m trying to bundle an application that seems particularly egregiously behaved. It’s CrowdStrike. There are other references to people running into trouble (for instance, Systemd config recommendations - Help - NixOS Discourse), but no complete solutions that I can see. Plus, I am having different problems.

So, here are the strange things that I’m sure the application is doing:

  • It expects all of its executables and libraries to live in /opt/CrowdStrike.
  • Creating a log file, /var/log/falconctl.log, which is a link to /dev/stdout. I’ve tried several different things to prevent this, including creating the file with systemd.tmpfiles, and touching the file in startup scripts for the falcon-sensor service.
  • Trying to write data to /opt/CrowdStrike
❯ exa -la /var/log/
.rw-rw----   38k root 21 Feb 12:46 btmp
.rw-------   44k root 26 Feb 11:24 falcon-sensor.log
lrwxrwxrwx     - root 26 Feb 11:24 falconctl.log -> /dev/stdout
.rw-------  2.8k root 26 Feb 11:24 falcond.log
drwx--x--x     - root 17 Mar  2022 gdm
drwxr-sr-x@    - root 16 Mar  2022 journal
.rw-rw-r--  292k root 21 Feb 12:46 lastlog
drwxr-xr-x     - root 21 Mar  2022 libvirt
drwx------     - root 16 Mar  2022 private
.rw-rw-r--  631k root 21 Feb 12:46 wtmp

So, I have no idea how to solve the problem with the log file, but at minimum, how do I make it possible for the application to write data to /opt/CrowdStrike?

So, how does the Steam derivation handle the Steam self-updating?

Yes, I know that the code is there. But it’s hundreds of lines of environmental code, and I can’t see which parts of it provide for the self-updating.

You have full control over the filesystem inside the FHS container, so any directory could be bind-mounted to /var/log/ or you could have a tmpfs mounted instead. All without needing to touch the system config at all.

I’d mount a tmpfs on /var/log, that seems like the simplest option to me.

That directory itself or a subdir thereof? If it’s a subdir, bind mount a sensible state directory onto it.

If it’s the dir itself, it’s going to be more complicated. One way of achieving it would be to treat the entire installation as state and bind-mount a state dir at /opt/CrowdStrike/. In the fhsenv startup script, you’d copy the pre-packaged binaries to that state dir if they don’t already exist. The app would then update itself correctly (presumably?).

Steam puts its real executables into a state directory inside the user home; that’s just how it works by default AFAIK.