Re: Can't update /etc/sysconfig/docker-storage-setup from custom repo

[Dan Nicholson <nicholson endlessm com>]

On Thu, Mar 1, 2018 at 9:17 AM, Cristian Falcas <cristi falcas gmail com> wrote:
> What could keep it from updating the file in /etc? I even deleted the
> existing file before rebase, thinking that maybe it was not updated because
> it was not the original file from an rpm (and config files from rpms are not
> updated on upgrades). But it still didn't work.

ostree's handling of /etc is very basic. Essentially, if the file has
changed from the previous deployment, then it's not updated by the new
deployment. This is so that any local changes to /etc are not blown
away on a system update.

So, you essentially cannot deploy changes to /etc with ostree unless
you're absolutely certain that there have been no local modifications.
You have a couple options:

1. Manage files in /etc that need local modifications out of band.
This is not pretty but we do it at Endless when we need to. We
typically add a script and systemd service that only runs on update.
Here's an example -
https://github.com/endlessm/eos-boot-helper/blob/master/eos-ostree-remotes-config.service.
That doesn't modify something in /etc, but the concept is the same
since it's handling a file that we can't deploy changes to.

2. Move as much configuration as possible into /usr with only local
overrides in /etc. This is dependent on the software you're
configuring supporting it. For example, systemd does this well where
you can ship normal system units in /usr/lib/systemd/system and manage
local overrides in /etc/systemd/system.

I don't know exactly how container-storage-setup works, but I'm
guessing it only accepts configuration via /etc/sysconfig. In that
case, you'll probably have to write your own tool that merges changes
from /usr/etc/sysconfig/docker-storage-setup to
/etc/sysconfig/docker-storage-setup at boot time.

I realize this makes you a sad panda (it often makes me sad and lose
sleep that our users aren't receiving important changes because they
happen to have edited a file in /etc), but if you think about it for a
minute, ostree really doesn't have a better strategy to take. The
contents of the files are domain specific and encode local policy.
ostree would just be guessing on what's best to do and possibly get
things wrong in a detrimental way. Package managers are in the same
boat, too. Most of the time they just leave the existing file as is if
it's been changed from the previous version. Some package managers
provide interactive dialogs to let you manage these files, but that
would not be in line with what ostree is trying to accomplish.

What I've often thought about is providing /etc merge hooks in ostree
that run during the deployment. It would be pretty complex, though.
ostree already does something very similar for selinux relabeling and
it is not trivial.

--
Dan