RFC: Atomic Updates configuration handling proposal by Thorsten Kukuk for CoreOS

[Neal Gompa]

Hey all,

When I was at SUSECON a couple of months ago, one of the things that
came up then was a discussion with Thorsten Kukuk (one of the major
folks leading openSUSE MicroOS/Kubic stuff and is CC'd to this email)
about how to handle config files in an atomically updated system (or
even a regular one!) in a smarter way.

Thorsten here came up some proposals[0] which are very solid and also
lines up well with some of the other things I'm working toward, as
some of you may know from what I've discussed in the IRC channel.

At the openSUSE Conference, he gave an excellent talk about it[1][2]
and we had some great discussions with the DNF team about how to
further support this.

I have one main quibble currently with it: I think /usr/share/defaults
is not descriptive of what it is _and_ does. I much prefer
/usr/share/sysconfig (though I might be persuaded to
/usr/share/baseconfig or /usr/share/defconfig). There is, of course,
the /usr/etc idea, but I *really* don't like the idea of keeping dumb
names from the 70s if we don't have to. "etc" doesn't describe that
it's for configuration _at all_. And if we're introducing a new
location, let's make it more descriptive than that. :)

Also, in general, it seems we really don't have a good way to handle
users and groups. I know that there was a proposal from Stephen and
Harald[3] that was intended to try to improve this for adding and
removing them, but it doesn't really address the problem of giving
people a way to have coherent files to look at the whole state.

My thought here was that we could have an SSSD plugin that combines
the partial passwd(5), shadow(5), and group(5) files in
/usr/share/sysconfig and /etc and spits out "full" transient ones in
/run that people can look at. This makes it easier to support
stateless systems that are also a mix of local and remote users
managed through systems like IdM.

I think there's still quite a bit of value in the proposal, and
perhaps this is something we can work on together to agree on how this
should look for RH/Fedora CoreOS and openSUSE MicroOS. And actually, I
think this would benefit regular Fedora/openSUSE too, because having
the ability to unbreak a system by simply deleting a file in /etc to
roll back is pretty good. This speaks to the general "let's make it
easy to fix stupid" thing I was talking quite a bit about.

I know that this is a bit of an FHS-ish discussion, but I'd like to
see us get firmer agreements on what we'd like to do between RH/Fedora
CoreOS and openSUSE MicroOS before we go and propose something to be
included in the FHS.

We already have the pending /usr/lib/sysimage thing, and I'd like to
get a location in place for configuration data too.

Anyway, I'd appreciate it if you took a look into it yourself and let
us know what you think!

[0]: https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md
[1]: https://youtu.be/ony0ajC0PWA
[2]: https://github.com/thkukuk/atomic-updates_and_etc/raw/master/Slides/Atomic-U...
[3]: https://pagure.io/packaging-committee/issue/850

--
真実はいつも一つ！/ Always, there's only one truth!

[Thorsten Kukuk]

Hi,

On Mon, Jun 03, Neal Gompa wrote:
> I have one main quibble currently with it: I think /usr/share/defaults
> is not descriptive of what it is _and_ does. I much prefer
> /usr/share/sysconfig (though I might be persuaded to
> /usr/share/baseconfig or /usr/share/defconfig).

My problem currently is more /usr/share at all. It should only contain
architecture independent data, so that you can share it between all
machines (but I really doubt that anybody is still doing so today).
But there are some configuration files, which are not architecture
independent, not even host independent. E.g. passwd, shadow, ...

But the feedback was also, that /usr/lib is already overcrowded and
chaotic and nobody finds there anything anymore...

Thorsten

[Dusty Mabe]

On 6/3/19 8:27 AM, Neal Gompa wrote:
> Hey all,

Hey Neal,
> When I was at SUSECON a couple of months ago, one of the things that
> came up then was a discussion with Thorsten Kukuk (one of the major
> folks leading openSUSE MicroOS/Kubic stuff and is CC'd to this email)
> about how to handle config files in an atomically updated system (or
> even a regular one!) in a smarter way.
>
> Thorsten here came up some proposals[0] which are very solid and also
> lines up well with some of the other things I'm working toward, as
> some of you may know from what I've discussed in the IRC channel.
>
> At the openSUSE Conference, he gave an excellent talk about it[1][2]
> and we had some great discussions with the DNF team about how to
> further support this.

I like it a lot. I think what systemd has done spoiled us when it comes
to default configuration and overriding configuration. We want it everywhere!
> I have one main quibble currently with it: I think /usr/share/defaults
> is not descriptive of what it is _and_ does. I much prefer
> /usr/share/sysconfig (though I might be persuaded to
> /usr/share/baseconfig or /usr/share/defconfig). There is, of course,
> the /usr/etc idea, but I *really* don't like the idea of keeping dumb
> names from the 70s if we don't have to. "etc" doesn't describe that
> it's for configuration _at all_. And if we're introducing a new
> location, let's make it more descriptive than that. :)
>
> Also, in general, it seems we really don't have a good way to handle
> users and groups. I know that there was a proposal from Stephen and
> Harald[3] that was intended to try to improve this for adding and
> removing them, but it doesn't really address the problem of giving
> people a way to have coherent files to look at the whole state.
>
> My thought here was that we could have an SSSD plugin that combines
> the partial passwd(5), shadow(5), and group(5) files in
> /usr/share/sysconfig and /etc and spits out "full" transient ones in
> /run that people can look at. This makes it easier to support
> stateless systems that are also a mix of local and remote users
> managed through systems like IdM.

I know Jonathan and Colin have mentioned something called systemd-sysusers
a lot when problems around users/groups have come up in Atomic Host/Silverblue/CoreOS 
Maybe that is the answer. Someone more familiar would have to comment. See:

https://github.com/projectatomic/rpm-ostree/issues/49
> I think there's still quite a bit of value in the proposal, and
> perhaps this is something we can work on together to agree on how this
> should look for RH/Fedora CoreOS and openSUSE MicroOS. And actually, I
> think this would benefit regular Fedora/openSUSE too, because having
> the ability to unbreak a system by simply deleting a file in /etc to
> roll back is pretty good. This speaks to the general "let's make it
> easy to fix stupid" thing I was talking quite a bit about.
>
> I know that this is a bit of an FHS-ish discussion, but I'd like to
> see us get firmer agreements on what we'd like to do between RH/Fedora
> CoreOS and openSUSE MicroOS before we go and propose something to be
> included in the FHS.
>
> We already have the pending /usr/lib/sysimage thing, and I'd like to
> get a location in place for configuration data too.
>
> Anyway, I'd appreciate it if you took a look into it yourself and let
> us know what you think!

I'd be interested in other FCOS community member thoughts here. I'd also
be interested to know what you think are good next steps for this initiative?
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> _______________________________________________
> CoreOS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]