CoreOS June 2019

coreos@lists.fedoraproject.org

8 participants
15 discussions

Fedora CoreOS Meeting Minutes 2019-06-05
by Benjamin Gilbert 05 Jun '19

05 Jun '19

Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-06-05/fedora_coreos… Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2019-06-05/fedora_coreos… Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-06-05/fedora_coreos… ======================================== #fedora-meeting-1: fedora_coreos_meeting ======================================== Meeting started by bgilbert at 16:30:10 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2019-06-05/fedora_coreos… . Meeting summary --------------- * roll call (bgilbert, 16:30:17) * Reminder that we're switching the meeting format back to only meeting tickets + open floor (bgilbert, 16:34:08) * LINK: https://lists.fedoraproject.org/archives/list/coreos@lists.fedoraproject.or… (bgilbert, 16:34:11) * Action items from last meeting (bgilbert, 16:34:26) * Signing for release artifacts (bgilbert, 16:34:52) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/187 (bgilbert, 16:34:55) * will be discussing this with infra tomorrow during their weekly meeting (dustymabe, 16:35:26) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/187#issuecomment-499… (dustymabe, 16:35:37) * Open Floor (bgilbert, 17:02:17) Meeting ended at 17:06:22 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * bgilbert (49) * dustymabe (19) * red_beard (18) * zodbot (17) * jlebon (6) * ajeddeloh (4) * kaeso[m] (3) * geoff- (2) * yzhang (1) * rfairley (1) * slowrie (1) * mnguyen_ (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

Re: RFC: Atomic Updates configuration handling proposal by Thorsten Kukuk for CoreOS
by Thorsten Kukuk 05 Jun '19

05 Jun '19

Hi, On Tue, Jun 04, Dusty Mabe wrote: > On 6/3/19 8:27 AM, Neal Gompa wrote: > > 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 We did evaluate systemd-sysusers already 3 years ago as solution, but there is one big problem: if files in the RPM are owned by the user, you need to create the user before you are able to install the RPM. But systemd-sysuser only runs at the next boot. So we would need a service, which is running afterwards, to "fix" the ownership of this files. In some cases, this can lead to a deadlock. So currently we are using systemd-sysusers config file for new users, but have a macro, which creates this accounts based on the sysusers file with help of useradd/groupadd (systemd has far too many dependencies and thus installed too late during an initial install). > > 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? From discussions with the openSUSE community: find a location below /usr for the configuration files. That's the most blocking issue and would allow immeaditly to move first configuration files. There should be one location everybody is using, so /usr/share is already bad, as this means shareable between different hosts, which is not true for all configuration data. /usr/lib is already overcrowed and with too many things (bug would be acceptable for me, if we decide on one subdirectory, where we move everything). /usr/etc is still a directory used most often today, not only on Linux systems. But quite some people don't like it. So we need something new, where I like from all proposals /usr/sysconfig best. Else, currently it looks like, as if openSUSE will do it if other distributions join. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg)

2 1

RFC: Atomic Updates configuration handling proposal by Thorsten Kukuk for CoreOS
by Neal Gompa 04 Jun '19

04 Jun '19

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-… [3]: https://pagure.io/packaging-committee/issue/850 -- 真実はいつも一つ！/ Always, there's only one truth!

3 2

[Fedocal] Reminder meeting : Fedora CoreOS Group Weekly Meeting
by dusty＠dustymabe.com 04 Jun '19

04 Jun '19

Dear all, You are kindly invited to the meeting: Fedora CoreOS Group Weekly Meeting on 2019-06-05 from 16:30:00 to 17:30:00 UTC At fedora-meeting-1(a)irc.freenode.net The meeting will be about: This is the meeting for the Fedora CoreOS Working Group. We typically go over previous meeting action items and then cover all tickets with the meeting keyword: https://github.com/coreos/fedora-coreos-tracker/labels/meeting. For how to run the meeting, see https://github.com/coreos/fedora-coreos-tracker#steps-to-run-the-meeting Source: https://apps.fedoraproject.org/calendar/meeting/9437/

1 0

Re: RFC: Atomic Updates configuration handling proposal by Thorsten Kukuk for CoreOS
by Thorsten Kukuk 04 Jun '19

04 Jun '19

Sorry, wrote from the wrong email account. ----- Forwarded message from Thorsten Kukuk <kukuk(a)suse.de> ----- Date: Mon, 3 Jun 2019 17:07:11 +0200 From: Thorsten Kukuk <kukuk(a)suse.de> To: Neal Gompa <ngompa13(a)gmail.com> Cc: coreos(a)lists.fedoraproject.org, Ben Breard <bbreard(a)redhat.com>, Dusty Mabe <dustymabe(a)redhat.com>, Daniel Mach <dmach(a)redhat.com> Subject: Re: RFC: Atomic Updates configuration handling proposal by Thorsten Kukuk for CoreOS 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 -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) ----- End forwarded message ----- -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg)

1 0

2024

2023

2022

2021

2020

2019

2018

CoreOS June 2019