RFC: Support /etc/ostree/config.d/ and use it to support user-configured top-level symlinks
#2681
Conversation
The sysroot handling of libostree supports multiple knobs specified in the system repo keyfile. E.g. `sysroot.bootloader`, `sysroot.readonly`, etc... One issue is that all the knobs so far have been "vendor-oriented". I.e. they're not necessarily something we expect users to directly modify. I'd like to add more sysroot configurable knobs which we *do* expect users to modify, but I don't want them to modify the main config directly and mix with knobs they really shouldn't touch. It's also not convenient to modify in a provisioning flow. Add a new concept of a "user config" which is a config obtained by merging all the configs in `/etc/ostree/config.d`. Now, there's no official API for merging `GKeyFile` objects, but the parser has the right semantics if we simply concatenate all the configs and parse the resulting final config: keys are merged into the same group and later keys override earlier keys. Appending to a string list is not supported, but we can design our knobs so that this is not an issue. We don't want user configs to be able to override e.g. `core.mode`. We only want to support specific keys in those configs (but for consistency, also in the primary config). So keep it as a separate `user_config` object.
A semi-common topic that comes up with libostree is the lack of support for top-level entries. The main reason for this is that OSTree cycles deployments all the time and so we don't want users to store data there. But we do want to be nice to e.g. applications which expect a specific top-level path to exist or users who are used to mounting things at the root. Add support for user-configurable symlinks provided via the new user configs. The configuration looks like this: ``` [toplevel-links] foobar=/var/foobar ``` OSTree will create the symlinks everytime a new deployment is created. Add a hidden `ostree admin create-toplevel-user-links` command which can be used by provisioning code to create the symlinks on first boot so that it takes effect on the pre-existing deployment. I initially also supported configuring empty immutable directories (which would only be useful as mountpoints), but this becomes much harder to support in a provisioning flow via Ignition. We can still support it in libostree if wanted, and just not expose it in Ignition-based downstreams. The nice thing with symlinks is that it matches all the other default symlinks pointing into `/var` to reinforce that all user data must remain there. Closes: coreos/rpm-ostree#337
|
Skipping CI for Draft Pull Request. |
With this, users can specify an Ignition config like
```yaml
variant: fcos
version: 1.4.0
storage:
files:
- path: /etc/ostree/config.d/01-foobar.conf
contents:
inline: |
[toplevel-links]
foobar=/var/foobar
```
and on first boot, a `/foobar` symlink will be created.
Requires: ostreedev/ostree#2681
With this, users can specify an Ignition config like
```yaml
variant: fcos
version: 1.4.0
storage:
files:
- path: /etc/ostree/config.d/01-foobar.conf
contents:
inline: |
[toplevel-links]
foobar=/var/foobar
```
and on first boot, a `/foobar` symlink will be created.
Requires: ostreedev/ostree#2681
Related: coreos/rpm-ostree#337
|
I encountered https://gitlab.gnome.org/GNOME/libglnx/-/merge_requests/41 while hacking on this, which took me some time to figure out! |
|
Today, the ostree-ext container logic discards everything not in FROM quay.io/coreos-assembler/fcos:testing-devel
RUN mkdir /nix |
|
(hmm also really need to fix |
Sure, I think this could make sense to support in the container flow. Do you think it obviates native support for it in libostree? The UX described in the demo above is quite streamlined in comparison. (There's also the question of whether other downstreams not planning to ship their OS as a container would be interested in this.) |
I'd say there's clearly room for both.
I find this a bit more debatable 😄
True! Basically I'm roughly 👍 if you want to drive this in. |
|
|
||
| self->user_config = g_key_file_new (); | ||
|
|
||
| /* we want g_key_file_load_from_fd() but that's private */ |
There was a problem hiding this comment.
Mmm...I think I would say it's simpler to read the configs into e.g. a GString or a GMemoryOutputStream.
Heh fair. The
OK cool! In that case, I'll enhance it to support directories too. It'd be good to support anyway, but also I think I've ironed out a not-too-hacky way to support it on first boot via Ignition. |
|
I know I wrote this somewhere else but I can't find it right now: Another approach that would work both client and server side is to support e.g. Then the UX flow (instead of frobbing a config file) for making a toplevel dir is just: (OK and...hm, we'd need a command to re-reconcile this, might as well support it live; don't want to wait to do an upgrade to process it) A key idea here is that the description of the root directory is captured in |
|
I'm still increasingly thinking we should relax the "content in /usr" restriction in ostree and just allow people to put at least empty directories wherever (except That said, today one can do this via a systemd unit with Then one can have a regular mount unit mount it that's ordered |
|
@jlebon: The following tests failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
Closing in favour of the derivation approach. |
The first commit adds support for users to drop configs in
/etc/ostree/config.d. The second commit makes use of it to support users configuring top-level symbolic links. See individual commit messages for details.Example using Fedora CoreOS: