Meeting started at 2026-08-05 17:00:04 UTC

The Meeting name is 'fedora-server '

!hi

Jocelyn Gould (UTC-4): Jocelyn Gould (korora) - she / her / hers

!hi

!group members server-wg

Members of server-wg: Alexander Bokovoy, Adam Williamson, Paul Maconi, Brett Weir, Emmanuel Seyman, Rowan Puttergill, jwhimpel, Kevin Fenzi, korora (@korora:fedora.im, @korora1981:matrix.org), mowest, ngompa (@conan_kudo:matrix.org, @ngompa:fedora.im, @pharaoh_atem:opensuse.org, @ngompa:kde.org, @ngompa:almalinux.im), Peter Boy, Stephen Gallagher

Ro: Rowan Puttergill (goroboro) - he / him / his

Welcome to our weekly Server WG meeting.

Let's still wait 2-3 mins.

!hi

Brett: Brett Weir (brettweir) - he / him / his

OK, let's start.

We shortly discussed the details on Monday.

Even though we’ve discussed this at length, any comment ?

Let's start

meetings overview:

Regarding the action, see the list in our

https://docs.fedoraproject.org/en-US/server-working-group/wg-minutes-2026/

Did I forget something?

That looks good, I guess another ongoing activity is there seems to be a lot of people trying out Vale, so we've been looking at integration for the docs.

I think, Vale is a topic for nest meeting. It would be too much today.

No worries

In regards to this I'm will working on my writeup of how to acutally get it working. The goal is to bring it inline wiht the docs article on Vale.

Announcements:

I updated our FAS group (server-wg) and also the forge group is updated.

Congratulation and a big welcome.

Currently, we have 5 positive votes each, no abstentions, no votes against. So we have already reached the quorum. Nevertheless, further votes are welcome. The voting period ends on July 31 (next Friday).

Since Friday we havew 2 new memberes, Brett and Rowan.

So now there are two new threats to our repos to manage 😏😀

Glad to be here. 🙂

Has someone something to announce?

Oh yes!

They created a Forge runner for server.

https://forge.fedoraproject.org/forge/forge/issues/701

So we can start trying it out. It is for small capacity jobs, so we can't run everything on it.

But we can use it for linting and stuff like that.

sneaking in vale discussion here :D

ssshhhh

Let me know what you want to do, I just did the same for FreeIPA's use. We can use it to spawn any job in Testing Farm.

I just had something fun to say, discussion over. 🤣

I will pick your brain about testing farm after, I haven't quite figured out what it is.

OK, I think can proceed.

Tracking issue: https://forge.fedoraproject.org/server/tickets/issues/203

We finally made a lot of progress.

https://forge.fedoraproject.org/server/tickets/projects/615

Now that I am a group member I can move tickets... so that's good. Also I now have a bare-metal box to do future testing.

I have to put my findings into the test summaries. Will do this later

Did you mention that there was a new build already? Is there somewhere we can track when these become available?

The bare metal box is helpful. I lost my test box to my wife needing a computer here at home.

I wasn't happy giving up hardware for testing... but I can do it for a period until I need the compute at home

Conan Kudo 😌: Just a friendly reminder: You took over the task to fix the wrong partition type in VM image and ARM sbc image. That's the problem, why the VM test failed. Could you do it before branching, please?

I'll try

it's on my list

I need to pull the vm images and put htem through the ringer. I am going ot work on that this week, Health and family obligations have been occuping my time

Emmanuel Seyman put together a list of possible problematic changes. We should start to discuss that when he is back from holiday. In the meantime, please everyopne shouild take a look!!!

Some Some of the recent releases have caught us off guard in this respect. We need to pay more attention to this.of the back releases

Some of the recent releases have caught us off guard in this respect. We need to pay more attention to this.

Are there particular things we should look for? References to versioning? Changes to configuration etc?

Well, the most important is, of some of it tackle e.g. our default configuration.

Or do things, we want to avoid.

E.g. Cockpit again includes spice into the vm module which puts in a lot of package we don't need and we don't want to have. (That's since a while ago).

We should consider whether Cockpit is now causing more potential harm than good.

I recall seeing somethign about kmsmon becoming the default fb in F45, but I don't see any testing stuff abuout it. (I looked into it and it didn't look like anything changed from our prespective)

Jocelyn Gould (UTC-4): Yes, that's another example.

I'm an extensive user of Cockpit. While it has it's flaws, it is also very useful)

hmmm I like Cockpit personally, but I don't really know how heavily people use it

Are you asking about removing it from the testing config? Or from the distribution?

Feel like we could work with the upstream to cull the default package list. Cockpit always feels like a value-add of using Fedora and I feel like we should try to keep it.

As something we advertise, I mean

I'm basically in favour of Cockpit, even as a admin who is familiar with the keyboard.

For me, it depends on how 'dirty' I am willing to get my hands for simple stuff...

Can we do package cockpit vm without the spice stuff?

We need to adjust the declared dependencies in the upstream.

Brett: Agreed! Therefore I'll start a discussion with them again. We already had a lot in the past.

Ro: Mabe, but that's a hube workload. Do we have the capacity?

Right... I see what you mean. Small team... maintaining patched sources is a beast.

Ro: Mabe, but that's a huge workload. Do we have the capacity?

Yeah, I'm generally against maintaining forks if I can avoid it.

Syncing two code bases is my idea of hell

I just know that RHEL disable all the btrfs stuff in cockpit... so at Oracle we maintained a patched version of that to re-enable it... but I wasn't responsible for that directly other than discovering what was missing and providing a proof of concept build

proposed: !action pboy will contact the Cockpit team regarding the packages in the VM module that are unnecessary for servers

who even uses spice any more?!! I have never found a properly functional client

I see no objection?????? regarding the proposal. Last chance it someone has

I don't remember if Cockpit has a console viewer built into it, but if it does, Cockpit could be who is using SPICE

I know it has a terminal, but not sure about VM console, I mean

No... the cockpit console viewer uses vnc and then if you ask for spice it asks to open your spice client

Feels like a good opportunity then to remove it.

Let's switch to the next topic.

Tracking issue: https://forge.fedoraproject.org/server/tickets/issues/230

Oooh... I was looking at this and saw a ticket for a dnsmasq role

since I have been digging around in that so much lately... I would be interested in looking to see if I can get something to work

I don't want to tread on toes though

I will probably use AI to assist, because I am lazy writing ansible... but everything will be reviewed and tested

I guess, we should postpone the dnsmasq role for now. And first decide about the foundation and the concentrate on the model project: post install tasks

I guess, we should postpone the dnsmasq role for now. And first decide about the foundation and then concentrate on the model project: post install tasks

okay... I am happy to help out here... even if it is testing the post install role and tasks

I have checked out the repo

if more work needs to be done here, I would be happy to have a play at adding things

Ro: Well, e’ve been treading water with Ansible for so long now, constantly starting afresh in different areas.

doing small tasks in ansible is easy enough, and I think this is a pretty neat project to get someone started with configuration. It would be nice to get some basics in place, and it will also help us to easily set up environments to test docs.

One recommendation I have is to keep individual roles small and focused and use playbooks to assemble complete systems.

We should really focus on 1 or 2 things and see them through to the end...

We should really focus on 1 or 2 things and see them through to the end. Even easy and small ones

We don't have runner capacity for this, but if we get capacity, I can set up an Ansible molecule harness.

That would allow us to test playbooks in CI

But those jobs are a bit hungrier so we'd need to figure out self-hosted runners for it.

I don't think you guys want all the jobs running at my house. 😅

Starting to see where my hardware might end up going...

I have the capacity for selfhosting performance intensive task on public servers.

Oh, oh? I put together a playbook for runner hosting yesterday if anyone wanted to try it out:

https://codeberg.org/brettweir/ansible/src/branch/main/roles/forgejo_runner/tasks/main.yml

But besides runners, what about the repo structure?

I would like to see it down to 1-2 detailed examples. And how we would like to look the distributed script collection,

My project here looks substantially like [Emmanuel Seyman](https://matrix.to/#/@eseyman:fedora.im)'s for that reason.

I thought we had discussed in a previous meeting and landed at Ansible kind of having a self-enforcing structure.

I still don’t know enough about ansible.

https://codeberg.org/brettweir/ansible

We have 10 mins left. So we should wrap up this topic.

I agree with that structure... it looks good to me

we might need more info in the README

and some examples of usage

proposed :info Brett will explore the use of runners for testing Ansible playbooks. All will further check the proposed structure for a more detailed discussion in 2 weeks (when eseyman is back)

I will have a play with what is currently in the repo and see if I can update the README a bit

!nfo Brett will explore the use of runners for testing Ansible playbooks. All will further check the proposed structure for a more detailed discussion in 2 weeks (when eseyman is back)

(Sorry, c&p can sometimes be a beast)

Tracking issue: https://forge.fedoraproject.org/server/tickets/issues/228

Part of this structure discussion and decision could be the idea, to create a "use cases" subdir moving tutorial and all current use-case into that.

I wrote an issue to track the runner portion as well: https://forge.fedoraproject.org/server/tickets/issues/232

I like this idea a lot.

I would like Post-installation tasks to become the "Configuration" section as depicted in the article.

I would like Post-installation tasks to become the "Configuration" section as depicted in the issue.

Is it about general configuration? Isn't it specific to things to do just after installation?

The use-case ticket: https://forge.fedoraproject.org/server/tickets/issues/224

Right, I guess this overlaps with the Ansible project quite nicely. Whatever we decide belongs in this space, should be task options in Ansible. This does look like general system configuration stuff.

Configuration makes sense. It’s post installation, and providing services/securing so it is all really configuring the base server install to be what the user needs it to be.

Right... but we need to make sure that scope doesn't creep beyond what you get in the base install

That's a good point, "Post-installation" could also be a workable title.

Instead of Configuration.

dnf-automatic might be outside of that because you're starting to install other packages...

but debatable

Since it's like all the junk you gotta do once the install is complete but not going off and building your empire.

dnf-automatic is a package, but it's a basic administration task that you pretty much always need to do

And I guess the criteria is "do you always need to do this?"

"Does every audience need to do this?"

Dnf automatic just keeps your system up tofate without requiring the admin remember to do it. (Might be something to include in the home server spin)

if the package needs to be installed on every install... it should be a package included in the spin

Is there anyone who doesn't want to use dnf-automatic?

I don't know... this was debated at Oracle a fair bit :D enterprise users suck though

hahaha

Yeah, I mean not everyone needs to change their hostname either, but it still doesn't feel like it fits anywhere else

right... I was looking at the DNF documentation - which currently lives and looks crappy in quick-docs... there is some wiki stuff as well (but of course the docs team has a project to obsolete pages in the wiki). I was wondering whether we should just have a general DNF doc like a software management guide... I did one at Oracle, and would be happy to work on something and propose it in a PR.

proposed !info WG will discuss the post-installation issue raised in ticket 228 and attempt to prepare a decision that can be agreed upon.

Folks, our time is up. So i propose to wrap this up as

That could cover stuff like dnf-automatic

I do like the configuration section plan though

and am not opposed to covering stuff like dnf-automatic there

Just keen to be clear on what falls into this space

maybe we call it Recommended Configuration Steps

Folks, we are 6 mins overdue!

we can chat in [\#server:fedoraproject.org](https://matrix.to/#/#server:fedoraproject.org)

Any objetion regarding the wrap up proposal? I'll put a summary of our discussion into the ticket tomoros

Just to be complete and not skip this again. 5 mins max!!

nothing from me... other than what we have discussed above...

Plenty to keep us busy until next week

OK, then I'll close and we continue in our Matrix room an in ticket 228