Recommended location for custom scripts and binaries (and systemd units)?

Hello,

For those with custom images, where on the filesystem do you typically put custom scripts and binaries that you’re including into the image?

/usr/local is a symlink to /var/usrlocal (at least on uCore), so is not an option.

I could use /usr/bin - but that feels too “official” for my junk scripts to go into.

Is there some other location that folks suggest?

On a similar topic where do you typically put systemd unit files you include into the image? I’m just putting them into /etc/systemd but I wonder if there’s a case to be made for using /usr/lib/systemd/system.

Thoughts and recommendations?

1 Like

@pauldoo Why are you eliminating /usr/local as a valid option? Both it and /usr/local/sbin are in the PATH by default. /usr/local would be my first preference even though the intention for that dir is typically reserved for server specific items (hence the use of the term local).

For your systemd use case I would probably make a choice on a case by case basis leveraging the documented lookup paths at systemd.unit - man systemd.unit

For both use cases, I would lean into picking a location that allows for:

  • easily discovering diffs between your custom stuff and stuff from your upstream image
  • fits organically with the architectural decisions made upstream
  • remains as agnostic to HW / DE details as possible - will allow you to switch upstream base images a little easier

Not a concrete answer, I know. But solution architecture is always about balancing trade-offs. I hope my reply helps you think through things a little.

/usr/local is linked to a mutable state full directory under /var on the host. Putting files in that location within my image simply won’t work.

I’m asking what is the appropriate location to use within a custom image.

When you say “custom image” you mean one you have forked and are building?

My custom image derives from one of the uCore ones. But I think question applies when deriving from any of the universal blue family of images (bluefin, bazzite, aurora, uCore), no?

I maintain my own set of images in an org called Winblues (GitHub - winblues/blue95: A desktop for your childhood home's computer room, GitHub - winblues/vauxite: A modern and lightweight desktop experience based on Fedora Atomic Xfce, etc). For custom scripts or other misc files, I tend to drop them in a few places:

  • If it’s an executable that is not meant to be invoked directly, I’ll place it in /usr/libexec and typically prefix the script name with winblues-.
  • If it’s meant to be directly invoked by the user, I’ll place it in in /usr/binand prefix it with winblues-
    • This case is rare as I generally instead try to add recipes to ujustinstead of creating scripts for /usr/bin
  • If it’s not an executable, I’ll place it in/usr/share/winblues

Systemd units are placed in /usr/lib/systemd/ as that is where vendor units should go. As someone creating a custom image, you are the vendor.

2 Likes

Thanks for the reply and advice!

After you put your systemd units under /usr/lib/systemd are you doing anything special during the image build to enable those? A simple systemctl enable foobar.service during image build will put the “wants” symlinks under /etc/systemd/system, but you presumably want the symlinks under /usr/lib/systemd instead?

I generally create a few preset files in `/usr/lib/systemd/system-preset and /usr/lib/systemd/user-preset. These preset files indicate whether the unit should be enabled or disabled by default. In the build, I add systemctl preset–all at the end to enable or disable units based on the presets.

From what I can tell, this is the preferred way for the vendor to specify which units should be on or off by default.

Interesting, thanks! Are you aware of documentation for the best practice usage of systemd from a vendor perspective? How did you figure this out?

I also wonder when the “want” symlinks under /usr/lib/systemd/system are created. I’ll go investigate… :thinking:

For general custom image notes, I find that blue-build’s documentation is very good: Thinking like a distribution | BlueBuild .

Specifically for systemd, I honestly just spent a lot of time reading the man pages to try to understand how everything fits together. That’s probably not the best way to get a handle on it, but it worked decently for me.

1 Like