CoreOS Layering: User files in var

Is it possible to use Container-native image layering to create user-files?

For example, in my Containerfile, I want to copy a systemd-generator’s podman-quadlet to the core user’s path:

...
COPY app.container /home/core/.config/containers/systemd/app.container
RUN ostree container commit

However, the commit provides this error:

error: Found content in var

What is the best solution for this issue?

  • I would prefer not to move this file to Ignition, since I wanted the flexibility to modify its properties without re-provisioning
  • I suspect I could run the container as a root user and place this file under /etc, but I would much prefer to use core user

I think you’ll want to use butane and/or cloud-init for this:

https://cloudinit.readthedocs.io/en/latest/reference/examples.html#writing-out-arbitrary-files

1 Like

If you want to run a container via systemd using systemd generator you can look at Running Containers :: Fedora Docs.

Thanks for feedback.

The boxes I am using are bare-metal, and re-provisioning bare-metal isnt as quick as cloud deployments. I was using butane for this, but i’m hoping to move application-centric configurations out of Butane and into Containerfile-layers so it is easier to manage via a Container-registry.

Got it, thanks

This is what I was eluding to in my 2nd bullet about using root user with /etc, but, I would prefer to do it with a non-root user like core.

Unless I am misunderstanding something…? Do you happen to know if there a way to instruct core user to reference quadlets in /etc?

coreos-layering has the goal of supporting arbitrary inputs. Maybe opening an issue there would be helpful. The centos-bootc project includes making these layered images bootable and installable on bare metal.

Being able to do everything currently possible with kickstart and ansible (puppet, cfengine, etc.) but using layering techniques out of the container work has potential. Good job with your current work and keep it going.

As I continue investigation of bootc I learned that “Injecting configuration into a custom image But a new super-power with bootc is that you can also easily create a derived container that injects your desired configuration, alongside any additional executable code (binaries, packages, scripts, etc). The expectation is that most operating systems will be designed such that user state i.e. /root and /home will be on a separate, persistent data store. For example, in the default ostree model, /root is /var/roothome and /home is /var/home. Content in /var cannot be shipped in the image - it is per machine state.” Some additional method will be needed to adjust content there either before or after first boot.

As stated in podman-systemd.unit — Podman documentation

For rootless containers, when administrators place Quadlet files in the /etc/containers/systemd/users directory, all users’ sessions execute the Quadlet when the login session begins. If the administrator places a Quadlet file in the /etc/containers/systemd/users/${UID}/ directory, then only the user with the matching UID execute the Quadlet when the login session gets started. For unit files placed in subdirectories within /etc/containers/systemd/user/${UID}/ and the other user unit search paths, Quadlet will recursively search and run the unit files present in these subdirectories.

Regarding layering, you can take a look at Changes/OstreeNativeContainerStable - Fedora Project Wiki

/home is /var/home on Fedora CoreOS and thus you can not place files there (yet, may change later, this is work in progress).

As @hricky said, you can place your unit in /etc, even for users.

Note that the container format is currently experimental for Fedora CoreOS and not recommended.

@hricky @siosm Y’all are rockstars! That’s the context I was missing! Thanks for the assist