Support snippet configuration file(s) stored in /usr/...

[evelikov]

Is your feature request related to a problem? Please describe.

Currently rauc only supports a configuration file in /etc/rauc/. Which can be problematic if you consider:

• stateless systems
• systems aiming to preserve end-user changes in /etc, while ensuring rauc isn't broken, upon updates
• would like to override individual option without having to copy (and potentially process) the whole file

Describe the solution you'd like

Would be great if rauc supports the following two:

• support config file(s) in /usr/... as the root configuration place - identically named files in /etc will take precedence allowing for local sysadmin overrides
• support separate snippet handling, allowing fine-grained config control instead of having to copy the whole file only to change a single option

The above two are closely related, although feel free to split/tackle separately if it makes sense.

With the above two in place then distribution/vendor can use /usr/lib/rauc/00-section-{foo,bar}.conf as part of their rauc package, with additional standalone overrides via /usr/lib/rauc/01-section-foo-change-baz.conf.

The linked blog post and the CONFIGURATION DIRECTORIES AND PRECEDENCE section of man sysctl.d (among others) provides good additional details on the Whys and Hows.

Thanks in advance

[jluebbe]

Are you aware of an implementation for GKeyFile which already handles this? It seems a bit wasteful to reimplement this in each application. :)

[evelikov]

Based on a quick read at the glib/gkeyfile docs and checking with one of the glib devs - there is no API to automatically handle this. Doesn't seem like there are (m)any apps that use glib and do this either.

[jluebbe]

I've been wondering about why this has not come up before and I think it's because the system.conf describes aspects of the system which are very static (as it was designed to do ;). One aspect that is a bit more dynamic is the set of trusted certificates and this supports drop-ins via [keyring]/directory=foo (just a single directory, though).

This means that the case for changing parts of the system.conf on a specific system doesn't come up in most RAUC deployments. Which end-user changes to the system.conf are you thinking about?

So, given that there is no support for merging drop-ins in GKeyFile and the need for it doesn't seem to be widespread, I wouldn't want to implement/maintain it in RAUC itself. If there was support for that in glib though, it would be a completely different situation. :)

What I'd find useful (even without drop-ins) would be a search order for the system.conf, following the common precedence of /etc over /run over /usr/lib. That should already solve some aspects of stateless systems without increased complexity in RAUC.

[evelikov]

Having the /etc <> /run <> /usr/lib will be great thanks.

I agree and can sympathise on the GKeyFile/maintenance side wrt the fragments and don't want to force it onto anyone.

For illustration sake, here are some use-case(s):

• we currently use casync and we're considering switching to desync
• we could potentially look at using verity style bundles by default where using the snippet approach would be beneficial

In both cases, having that as fragment allows for easy migration - be that up or downgrades, and reversion. Even a semi-tech savvy user can do it locally themselves.

[Bastian-Krause]

Note: We had a similar discussion and a draft PR using libeconf in rauc/rauc-hawkbit-updater#84.

[jluebbe]

As a summary, we think that a search order for the system.conf, following the common precedence of /etc over /run over /usr/lib, would be a good enhancement for RAUC.