<@apiaseck:matrix.org>
16:30:04
!startmeeting fedora_coreos_meeting
<@meetbot:fedora.im>
16:30:07
Meeting started at 2024-07-10 16:30:04 UTC
<@meetbot:fedora.im>
16:30:07
The Meeting name is 'fedora_coreos_meeting'
<@apiaseck:matrix.org>
16:30:14
!topic roll call
<@jbtrystram:matrix.org>
16:30:16
!hi
<@zodbot:fedora.im>
16:30:18
Jean-Baptiste Trystram (jbtrystram) - he / him / his
<@marmijo:fedora.im>
16:30:51
!hi
<@zodbot:fedora.im>
16:30:52
Michael Armijo (marmijo)
<@ravanelli:matrix.org>
16:31:02
!hi ravanelli
<@zodbot:fedora.im>
16:31:03
Renata Ravanelli (ravanelli)
<@siosm:matrix.org>
16:31:07
!hi
<@zodbot:fedora.im>
16:31:09
Timothée Ravier (siosm) - he / him / his
<@jlebon:fedora.im>
16:31:18
!hi
<@zodbot:fedora.im>
16:31:19
None (jlebon)
<@hricky:fedora.im>
16:31:24
!hi
<@zodbot:fedora.im>
16:31:25
Hristo Marinov (hricky) - he / him / his
<@jlebon:fedora.im>
16:31:53
apiaseck: i just realized that i didn't do all the housekeeping steps for the previous meeting
<@apiaseck:matrix.org>
16:32:05
I can look into that later on.
<@jlebon:fedora.im>
16:32:32
it's ok. it's not worth posting the summary at this point i think
<@jlebon:fedora.im>
16:33:33
i was checking if any meeting issues should be untagged. there's just the change considerations one from last week, which i've dropped
<@apiaseck:matrix.org>
16:33:49
Since it's a nice bunch of us here, let's start already.
<@apiaseck:matrix.org>
16:34:02
!topic Action items from last meeting
<@jlebon:fedora.im>
16:34:04
marmijo: once you get around to updating that list, if there are any new ones, you can re-add the label
<@siosm:matrix.org>
16:34:05
Jonathan Lebon: anything we should tackle first?
<@marmijo:fedora.im>
16:34:21
Jonathan Lebon: sure thing. I'll update the list today
<@ydesouza:fedora.im>
16:34:24
!hi
<@jlebon:fedora.im>
16:34:25
travier: i think https://github.com/coreos/fedora-coreos-tracker/issues/1758 is the most pressing
<@zodbot:fedora.im>
16:34:25
Yasmin Valim de Souza (ydesouza)
<@jlebon:fedora.im>
16:34:55
and then https://github.com/coreos/fedora-coreos-tracker/issues/1745 would be good to discuss too
<@apiaseck:matrix.org>
16:35:38
I can't see any action items, so let's move on to the first proposed by Jonathan Lebon
<@apiaseck:matrix.org>
16:36:08
!topic No serial console login after update to 40.20240616.3.0
<@apiaseck:matrix.org>
16:36:15
!link https://github.com/coreos/fedora-coreos-tracker/issues/1758
<@apiaseck:matrix.org>
16:37:16
Jonathan Lebon, travier. Would any of you would like to introduce this one?
<@jlebon:fedora.im>
16:37:23
sure
<@apiaseck:matrix.org>
16:37:26
Jonathan Lebon, travier. Would any of you like to introduce this one?
<@dustymabe:matrix.org>
16:37:32
!hi
<@zodbot:fedora.im>
16:37:33
Dusty Mabe (dustymabe) - he / him / his
<@aaradhak:matrix.org>
16:37:57
!hi aaradhak
<@zodbot:fedora.im>
16:37:58
Aashish Radhakrishnan (aaradhak)
<@jlebon:fedora.im>
16:38:38
in a recent release we did, an selinux-policy update broke systemd-getty-generator, which means that the serial-getty@.service isn't instantiated for the available serial ports. concretely: users can't log into the serial console anymore
<@jbrooks:matrix.org>
16:39:02
!hi jasonbrooks
<@zodbot:fedora.im>
16:39:04
Jason Brooks (jasonbrooks) - he / him / his
<@jlebon:fedora.im>
16:39:15
now, first, it's pretty embarrassing this slipped by. we clearly need a test for this
<@jlebon:fedora.im>
16:39:27
so that's number 1
<@siosm:matrix.org>
16:40:06
No idea how difficult writing a test would be. If it's "just" checking the systemd unit status then that should be fairly easy
<@jlebon:fedora.im>
16:40:17
number 2 is how to handle this
<@jlebon:fedora.im>
16:40:17
currently, i've pinned selinux-policy to a working version in testing-devel so it'll be in the next testing and next
<@jlebon:fedora.im>
16:40:17
the bug is not fixed yet.
<@jlebon:fedora.im>
16:40:33
the question is whether to fast-track the pin to stable too
<@jlebon:fedora.im>
16:40:39
travier: i think we can just check the console output
<@jlebon:fedora.im>
16:40:49
we do this already for the auto-login test in kola testiso
<@siosm:matrix.org>
16:41:00
ah, indeed, but that would be in kola then?
<@jlebon:fedora.im>
16:41:36
yeah... it'd need some design if we want to try to make it an external test. but clearly possible
<@jlebon:fedora.im>
16:41:52
worth noting that there are multiple ways to work around this
<@jlebon:fedora.im>
16:42:22
one is to boot with `enforcing=0`, another is to manually override selinux-policy, another is to manually enable serial-getty@PORT.service
<@dustymabe:matrix.org>
16:42:35
Has this reached stable yet? Or is it just in testing
<@jlebon:fedora.im>
16:42:41
it has
<@siosm:matrix.org>
16:43:09
Made https://github.com/coreos/coreos-assembler/issues/3832
<@dustymabe:matrix.org>
16:43:34
Part of me wants it fixed sooner, but either way it will be fixed in a few weeks?
<@jlebon:fedora.im>
16:43:40
so one argument is to not risk it and not fast-track; people that need the serial console can use one of the workarounds
<@jlebon:fedora.im>
16:44:28
another argument is that serial console is pretty basic functionality, and it may be the only way a user has to get into the system (or may not have easy access to the GRUB menu to select the rollback/edit kargs)
<@siosm:matrix.org>
16:44:34
The thing is, usually, when you need console access is when the rest doesn't work so you can't really apply those workarounds
<@jbtrystram:matrix.org>
16:45:14
I feel we had a lot of issues with selinux-policy recently. Could we ask them to gate their releases on the kola tests ? They are in boghi already
<@jlebon:fedora.im>
16:45:46
overall, i lean towards fast-tracking. worth noting that the pinned version shipped in stable before
<@jbtrystram:matrix.org>
16:45:48
I feel we had a lot of issues with selinux-policy recently. Could we ask them to gate their releases on the kola tests ? They are in bodhi already
<@jlebon:fedora.im>
16:46:08
jbtrystram: that's the long-term goal, but it's part of a much larger effort
<@jbtrystram:matrix.org>
16:46:33
+1 to fast track and writing up some documentation for affected users
<@marmijo:fedora.im>
16:46:36
I'd agree with fast-tracking as well, especially if there could be situations where users cant apply the workaround
<@marmijo:fedora.im>
16:46:53
I'd agree with fast-tracking as well, especially if there could be situations where users cant apply the workarounds
<@apiaseck:matrix.org>
16:47:32
Let's propose, and have the voting on the above, shall we ?
<@jbtrystram:matrix.org>
16:47:42
Jonathan Lebon: I know but I'm just thinking it's worth reaching out and say "maybe please look closely at these tests because we've had a lot of issues?"
<@jbtrystram:matrix.org>
16:48:01
(^ about bodhi tests)
<@jlebon:fedora.im>
16:48:20
jbtrystram: ahhh gotcha. yeah, possibly.
<@apiaseck:matrix.org>
16:48:53
initial proposed: We will fast track and write up documentation for affected users regarding the `no serial console login`
<@jbtrystram:matrix.org>
16:49:29
Maybe they are not even aware they're there. I reached out to the kdump folks with the same message, maybe nothing will come out of it, but it is worth trying
<@siosm:matrix.org>
16:49:52
+1 for proposed
<@jbtrystram:matrix.org>
16:49:55
+1
<@ravanelli:matrix.org>
16:50:06
+1
<@aaradhak:matrix.org>
16:50:08
+1
<@marmijo:fedora.im>
16:50:15
+1
<@jlebon:fedora.im>
16:50:27
+1
<@jlebon:fedora.im>
16:50:27
"We will fast-track the selinux-policy rollback to stable and ..."
<@apiaseck:matrix.org>
16:51:13
proposed: We will fast-track the selinux-policy rollback to stable and write up documentation for affected users regarding the no serial console login
<@apiaseck:matrix.org>
16:51:35
!proposed: We will fast-track the selinux-policy rollback to stable and write up documentation for affected users regarding the no serial console login
<@siosm:matrix.org>
16:52:14
+1
<@jlebon:fedora.im>
16:52:23
i think we have enough for an agreed :)
<@apiaseck:matrix.org>
16:52:34
Not sure if there should be an `!` before proposed here, but I will amend that in the summary.
<@apiaseck:matrix.org>
16:53:05
agreed: We will fast-track the selinux-policy rollback to stable and write up documentation for affected users regarding the no serial console logi
<@apiaseck:matrix.org>
16:53:16
!agreed: We will fast-track the selinux-policy rollback to stable and write up documentation for affected users regarding the no serial console logi
<@jbtrystram:matrix.org>
16:53:53
remove the : :)
<@jbtrystram:matrix.org>
16:54:02
remove the `:` :)
<@apiaseck:matrix.org>
16:54:07
!agreed We will fast-track the selinux-policy rollback to stable and write up documentation for affected users regarding the no serial console logi
<@apiaseck:matrix.org>
16:54:17
++ jbtrystram
<@apiaseck:matrix.org>
16:54:32
jbtrystram ++
<@zodbot:fedora.im>
16:54:34
c4rt0 gave a cookie to jbtrystram. They now have 1 cookie, 1 of which was obtained in the Fedora 40 release cycle
<@apiaseck:matrix.org>
16:54:37
Can we move on to the second proposed topic: `Different partition layout` or is there anything else to discuss here?
<@jlebon:fedora.im>
16:54:59
i think since dustymabe and travier are finally both there, let's do the firewalld one
<@apiaseck:matrix.org>
16:55:43
I can't see any objections :)
<@apiaseck:matrix.org>
16:55:49
!topic New Package Request: firewalld
<@dustymabe:matrix.org>
16:55:50
😀 - might not be able to make the best argument. Currently holding a baby, but let’s proceed
<@apiaseck:matrix.org>
16:55:58
!link https://github.com/coreos/fedora-coreos-tracker/issues/1747
<@apiaseck:matrix.org>
16:56:52
Anyone feels like introducing this one?
<@jlebon:fedora.im>
16:57:14
i nominate travier :)
<@apiaseck:matrix.org>
16:57:50
travier: the floor is yours :)
<@siosm:matrix.org>
16:59:39
:)
<@siosm:matrix.org>
17:00:05
Some folks want to include firewalld by default in Fedora CoreOS
<@siosm:matrix.org>
17:00:47
The summary of the discussion is that it should work well as a container
<@siosm:matrix.org>
17:01:11
It also pulls in Python (which would be the first one to pull it)
<@hricky:fedora.im>
17:01:16
I tried the container and it works.
<@siosm:matrix.org>
17:02:02
The main advantage of adding firewalld would be that we would be "closer" to other editions
<@siosm:matrix.org>
17:02:12
but I don't know if server or cloud includes it by default
<@jbtrystram:matrix.org>
17:02:30
server does I think
<@siosm:matrix.org>
17:02:32
That's for the non personal points
<@dustymabe:matrix.org>
17:02:40
i'm pretty sure server does, not sure about cloud (the arguments for firewall in the cloud are a little weaker IMO)
<@dustymabe:matrix.org>
17:03:46
I think the main advantage of adding it would be that something that seems like basic functionality would be included by default. The way I look at it this is similar to using networkmanager to manage network versus ip commands - firewalld versus iptables/nftables seems similar to me.
<@siosm:matrix.org>
17:04:08
From my personal perspective, it's not worth it. It's easily layered, it works as a container, most people are not going to use it as they will use either podman/docker network native isolation or cloud firewalls.
<@siosm:matrix.org>
17:04:49
And it brings Python. Bringing python for udev rules and better cloud support, I can get behind. Not for firewalld.
<@siosm:matrix.org>
17:05:13
We would likely not enable it by default either as that would break users (and it's super slow)
<@jlebon:fedora.im>
17:05:20
I also don't personally think it's worth it out of the box for our intended use case.
<@dustymabe:matrix.org>
17:05:29
I think the point of us having the prior discussion (on python) was to exclude it from this discussion
<@siosm:matrix.org>
17:07:04
it's not a blocking point, but it's still a point to consider
<@jlebon:fedora.im>
17:08:15
dustymabe: minor nuance: the point for me of that discussion was to treat it like any other package. also of course it'll never be just python, it'll be python + libraries of whatever application we're considering
<@siosm:matrix.org>
17:08:57
From my personal usage, podman networking has completely removed the need for a firewall on my systems. I used to have very strict rules in place, with custom nftables scripts, etc.
<@dustymabe:matrix.org>
17:09:01
Another thing that makes me favor including it is our claim that our OS is secure.. I know we wouldn't want to enable firewalld by default (at least initially) but we may consider it in the future in some cases
<@siosm:matrix.org>
17:09:25
I no longer do, I just run containers with no ports exposed or with the ports needed published on a podman network
<@dustymabe:matrix.org>
17:09:37
travier: when you say `podman networking` what do you mean exactly?
<@siosm:matrix.org>
17:10:09
If you run a container with podman it runs it in a network that is not accessible from the internet
<@siosm:matrix.org>
17:10:22
you need to explicitly publish ports
<@siosm:matrix.org>
17:10:27
(same with docker)
<@dustymabe:matrix.org>
17:11:00
right, it's juts in a different network namespace (unless you use the host's)
<@siosm:matrix.org>
17:11:02
the super common use case of firewall rules is to say which ports are accessible from the network
<@siosm:matrix.org>
17:11:22
you get that "for free" with containers
<@siosm:matrix.org>
17:11:49
sure it's not the exact same thing, you can still run in the host namespace, run rootless containers and publish, etc.
<@dustymabe:matrix.org>
17:13:30
<@dustymabe:matrix.org>
17:13:30
that page could then go on to explain how to layer in firewalld and use it OR use it from a container
<@dustymabe:matrix.org>
17:13:30
ok so to counteract the argument I made before about the host being secure I think we should have a docs page that discusses all of this (i.e. exactly which ports our systems listen on by default (ssh being one) and why we think there really isn't the need for a firewall because of container networking works)
<@jlebon:fedora.im>
17:13:48
maybe it would help if we discussed the firewalld use cases. does did you have in mind dustymabe ?
<@jlebon:fedora.im>
17:13:55
maybe it would help if we discussed the firewalld use cases. what did you have in mind dustymabe ?
<@jlebon:fedora.im>
17:14:13
yeah, definitely worth documenting
<@dustymabe:matrix.org>
17:14:39
maybe from what travier said it covers most everything
<@jlebon:fedora.im>
17:14:51
one useful thing i can imagine is restricting ip ranges for sshd
<@dustymabe:matrix.org>
17:15:07
oh yeah. I acutally do that on my home router
<@jlebon:fedora.im>
17:15:10
we commonly do that in the cloud (but using the cloud tools of course)
<@jlebon:fedora.im>
17:16:00
sshd is really the only thing we have by default you may want to add firewall rules for
<@dustymabe:matrix.org>
17:16:22
<@dustymabe:matrix.org>
17:16:22
```
<@dustymabe:matrix.org>
17:16:22
```
<@dustymabe:matrix.org>
17:16:50
```
<@dustymabe:matrix.org>
17:16:50
```
<@dustymabe:matrix.org>
17:16:50
<@dustymabe:matrix.org>
17:16:50
rule family="ipv4" source address="x.x.x.x/32" service name="ssh" log prefix="dustymabecomssh " level="info" limit value="1/m" accept
<@dustymabe:matrix.org>
17:16:50
rich rules:
<@dustymabe:matrix.org>
17:17:10
limits by source address and also limits to 1 try per minute
<@dustymabe:matrix.org>
17:17:51
but I don't know if that's a compelling enough reason
<@siosm:matrix.org>
17:18:59
What I do now is I put my sshd daemon behind a wireguard interface, which has other trade offs (I can login from anywhere but I need the wireguard keys)
<@dustymabe:matrix.org>
17:18:59
TBH I'm suprised systemd hasn't baked this functionality in yet (systemd-firewalld) :)
<@jlebon:fedora.im>
17:19:39
dustymabe: now you're giving people ideas :)
<@dustymabe:matrix.org>
17:19:45
travier: yeah I do something similar with tailscale, but have this one path in as a fallback in case tailscale isn't working
<@jbtrystram:matrix.org>
17:20:02
dustymabe: i am curious how do you decide on the source address range ?
<@dustymabe:matrix.org>
17:20:21
jbtrystram: it's just a specific IP from another intstance I own
<@jlebon:fedora.im>
17:20:32
if possible, i'd like to bring up something from a discussion with Hristo Marinov before we close
<@jlebon:fedora.im>
17:21:30
proposed: currently, we are not considering adding firewalld by default. we will however add documention detailing every port open by default, and instructions on how to add firewalld to the host.
<@jlebon:fedora.im>
17:21:30
let me write up a proposed to accelerate things
<@siosm:matrix.org>
17:21:32
should we vote on firewalld before?
<@siosm:matrix.org>
17:21:45
=1
<@siosm:matrix.org>
17:21:46
+1
<@apiaseck:matrix.org>
17:21:49
+1
<@jbtrystram:matrix.org>
17:22:07
+1
<@marmijo:fedora.im>
17:22:07
+1
<@hricky:fedora.im>
17:22:07
I think you already said what is important.
<@dustymabe:matrix.org>
17:22:10
Jonathan Lebon: along with rationale on why we think running containers reduces the need for an active firewall
<@jlebon:fedora.im>
17:22:25
dustymabe: will amend in the agreed
<@dustymabe:matrix.org>
17:23:11
we should probably also include examples of basic iptables/nftables usage (i.e. butane configs that allow access to a specific port or something)
<@apiaseck:matrix.org>
17:23:50
Any other votes for proposed?
<@hricky:fedora.im>
17:24:00
+1
<@jlebon:fedora.im>
17:24:10
dustymabe: will amend the agreed :)
<@dustymabe:matrix.org>
17:24:14
+1
<@jlebon:fedora.im>
17:24:22
!agreed: currently, we are not considering adding firewalld by default. we will however add documention detailing the rationale for this, as well as every port open by default, example nftables configs, and instructions on how to add firewalld to the host.
<@jlebon:fedora.im>
17:25:20
with the bit of time left, can we discuss https://github.com/coreos/fedora-coreos-docs/issues/650 ?
<@siosm:matrix.org>
17:25:26
we have https://github.com/coreos/fedora-coreos-docs/issues/247 that we can re-purpose
<@apiaseck:matrix.org>
17:25:55
!topic Document ways to contribute to FCOS
<@apiaseck:matrix.org>
17:26:11
!link https://github.com/coreos/fedora-coreos-docs/issues/650
<@jlebon:fedora.im>
17:26:50
we've identified a need to better document how to contribute to FCOS
<@jlebon:fedora.im>
17:27:14
the current proposal is to add a new top-level "Contributing" page to the docs
<@jlebon:fedora.im>
17:28:19
though we should also start to think about developing a process for community members to contribute to the more privileged parts of maintenance, such as FCOS release rotation and general infra maintenance
<@jlebon:fedora.im>
17:28:38
see https://github.com/coreos/fedora-coreos-docs/issues/650#issuecomment-2220354989 and following
<@jlebon:fedora.im>
17:28:38
Hristo Marinov indicated some interest there
<@jlebon:fedora.im>
17:29:52
this is a large topic on its own, but wanted to see if there's agreement on the overall direction
<@dustymabe:matrix.org>
17:30:17
+1 to adding a new top level contributing page
<@siosm:matrix.org>
17:30:42
I think that apart from the release side of things, everything should be open to anyone for contributions. +1 for a dedicated page
<@siosm:matrix.org>
17:31:05
should "already" be opne
<@siosm:matrix.org>
17:31:10
should "already" be open
<@marmijo:fedora.im>
17:31:20
+1 from me as well
<@jlebon:fedora.im>
17:31:47
i found https://fedoraproject.org/wiki/Infrastructure_Apprentice interesting; the "read-only access" phase of the process
<@jlebon:fedora.im>
17:32:27
i think that'd require some rejigging in the ansible bits for our openshift projects if we wanted to do something analogous
<@siosm:matrix.org>
17:33:08
I'm warry of the amount of work needed to make our release pipeline safe or read only
<@siosm:matrix.org>
17:33:33
i.e. Jenkins has an awefull track record in terms of security
<@siosm:matrix.org>
17:33:49
i.e. Jenkins has an awful track record in terms of security
<@jlebon:fedora.im>
17:34:10
travier: i don't mean read-only by default. but allow some contributors to have read-only access to start
<@jlebon:fedora.im>
17:34:26
but anyway, maybe the simplest/most appropriate is to piggyback on the existing infrastructure processes
<@apiaseck:matrix.org>
17:34:41
side note: we are stretching allocated time.
<@jlebon:fedora.im>
17:35:22
yes, we can close this. sounds like there's overall agreement there to discuss further
<@siosm:matrix.org>
17:35:27
overall, I feel that there are bigger wins outside of the release part of things
<@siosm:matrix.org>
17:36:40
Cloud platform support is top one from my perspective
<@jlebon:fedora.im>
17:36:44
travier: i think it's more philosophically, this should be possible
<@siosm:matrix.org>
17:36:49
Cloud platform support is a top one from my perspective
<@apiaseck:matrix.org>
17:37:06
Should we write up the `agreed` here, or move this topic another meeting?
<@jlebon:fedora.im>
17:37:13
in my opinion, part of the "trust building" process would be to work on those issues
<@apiaseck:matrix.org>
17:37:21
I feel like there is so much more to discuss here...
<@siosm:matrix.org>
17:37:28
hopefully with Konflux, this becomes a non issue and anyone can setup their own pipeline
<@siosm:matrix.org>
17:37:38
but we're clearly not there yet
<@siosm:matrix.org>
17:38:39
I'll stop here so that we can close. I don't think we specifically need an agreed to add a page to the docs?
<@jlebon:fedora.im>
17:38:44
apiaseck: i think we can close :)
<@apiaseck:matrix.org>
17:39:10
Perfect, thank you all.
<@apiaseck:matrix.org>
17:39:11
!topic Open Floor
<@apiaseck:matrix.org>
17:39:44
Is there anything else pressing folks?
<@apiaseck:matrix.org>
17:40:42
If not, it's been a pleasure! Thank you for the discussion and see you on the next one!
<@apiaseck:matrix.org>
17:41:08
!endmeeting