Meeting started at 2026-07-08 17:00:11 UTC

The Meeting name is 'fedora-server '

!group members server-wg

Members of server-wg: Alexander Bokovoy, Adam Williamson, Paul Maconi, Emmanuel Seyman, 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

!hi

!hi

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

Welcome to our weekly Server WG meeting.

I'll post the agenda in 2-3 minutes.

As usual, let's wait a moment for everybody to show up.

mmmm zodbot doesn't like me :D

!hi

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

yay

I like you!

I like you too, Ro

Hi likes you! (zodbot)

and me as well

this is such a welcoming community

!hi

mowest: Steve Daley (mowest)

Welcome. Let’s get started. On the second Wednesday of the month, we’re usually a small group.

I propose the agenda based on some discussion on Matrix. Unfortunately, I'm a bit under the weather.

So I don't know if I everything got right.

Some additions? Or deletions?

Looks like plenty for us this afternoon.

Yeah, so let's start.

Regarding the action, see the list in our

meetings overview:

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

Regarding actions:

5.

2.

DONE Brett, Jocelyn and MatH will put together a proposal for the initial small set of apps for home server spin-off from the current ideas and proposals

3.

ONGOING eseyman writes an Ansible playbook that applies the official post-installation tasks.

4.

OMGOING Conan Kudo will fix Kiwi to set the right partition type of Linux LVM for the system partition on KVM guest and arm image.

ONGOING MatH will compose the existing ideas and proposals into a TOC proposal, perhaps already for next meeting

ONGOING pboy will implement the Fedocal workarount for providing meeting location address

1.

6.

DONE: korora resolves both the tickets #175 & #176 appropriately as discussed.

Did I forget something?

That looks correct to me

OK.

No announcement from me today.

Someone something to announce?

Nothing here, just finally made it back for a meeting.

PR for PXE stuff... but that is coming up soon

Yeah

OK, let's proceed

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

We decided to use a project board. How do we want to to that?

It's a splendid idea, but I'm unsure how to organize that.

I was thinking that we could use it to track tests that we know we need to do, or if there are regressions once we hit the later stages

Yes, do we create a ticket for each test per test release?

Couldn't we use "Projects" under forge.fedoraproject.org

We can set up a "Testing Project" as a Kanban Board.

mowest: Yes, we can. But we have to fill in tickets.

Probably the best way to do it, then we can track per build

Where do you want the tickets to live? Just in our WG space on the forge or someplace else.

mowest: At the moment we have all tickets in one place, the tickets repo.

This is new to me... I need to find out what I can do to get involved in testing. I am happy to test stuff in VMs running on my machine.

Maybe we would flood that repo?

I just need to learn what needs to be done and how we track...

Ro: The tests we have to do are listed in the ticket, mentioned above.

And at the linked places there are further links to test description.

I haven't used "Projects" in forgeo, but if it is a typical KanBan board, you could have a column for "Waiting"; "Failed"; "Passed" and a new "card" could be created for every test that we desire to do.

All testing would be contained in one place.

Or if something is brougth to us that we need to take a look at

Yes, we already have several of those projects

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

There we have a project maintenance

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

To use it, we have to create a ticket for each test. And probably per test build

I don't know how many test builds we habe to expect. One every 2 weeks?

Every two weeks sounds right

maybe we should just use the bords once we hit the RC's

Oh, I get it, that is slick, you create a project, and every "card" in the Kanban Board is an "Issue" so you see them in both the Projects tab and the Issues tab with tags.

With RC it gets more complicated. Sometimes there are 3 a day

It sounds like some automation is needed to generate tickets and assign them to projects for each build. Possibly with options to limit which tickets are generated per build.

Would a better organization be, "issue" per "test", updates of issues can include the build number.

mowest: Yeah, but then would be no progress on the kanban, right? Everything would be "In progress"

If there is a "regression" you can always move the "issue" or "card" to the failed column and not which build failed. Move it to the "passed" when a build later is successful.

Or with the next build we would replace it in ToDo

Are the columns set? Or can you rename them so it is more relevant to "testing a release"

right... presumably if a new build is out... then switching all issues back to ToDo makes sense because a problem in a test on a previous build might be resolved

This would be a good sorurce for tagging things. (Tag per build?) then we can track what we need to look at)?

OK, maybe we create 4 columns: "To Do" "in Progress". "passed". "failed". ?

if failed you have to test in the latest build and if resolved you move it into passed?

R

Ro: yeah, could be one way.

"To Do" would be every test we desire to do; "In Progress" indicates a team member is actively testing it or has promised in the next few days to test it; "Passed"; "Failed" would occur as testing is done with regressions being caught by having someone test all of the "Passed" one with a new build.

how do you know that something in passed isn't going to fail in a future build? or do we assume that all passes are kind of future-proof in terms of builds?

ah... I think [mowest](https://matrix.to/#/@mowest:fedora.im) answered that

someone tests all the passes in the new build

so Passed and Failed are always ToDo on each new build

Proposal: We create one ticket per test, with the build date in the title. A ticket starts as ‘To Do’ and ends as ‘Failed’ or ‘Passed’. A new build is then reflected in the title, and everything starts again as ‘To Do’.

We could try that and decide after some time if it works for us

It might be hard to check which Passed and which Failed have already been done for a given build

+1 to pboy's proposal

Ro: Yes, we have no history that way. But we gain an overview, what we had done and where are the gaps.

I think, that maybe not the optimal, but it is progress

sounds good to me

I need to learn how to get involved in testing, but being at this point in the creation of a new process helps

OK.

Then:

:agreed For release testing, we create one ticket per test with the build date in the title. A test starts in ‘To Do’, and ends in either ‘Failed’ or ‘Passed’. A new build is then added to the title, and everything starts again in ‘To Do’.

I really glad we made this progress.

Do we have a mechanism to automate the creation of tickets?

Testing in the past was always a kind of Floundering in the dark

And update the titles for builds?

No, we don't at the moment. If we are content with it, we should try to automate it.

Everythin would be manual for now.

definitely. Also, having tickets that people can pick up easily for each testing task, will help... and will make it easier to try to get more community involvement for testing#

Ok, so let's try it.

For the next build, probably someone else could edit the build date. 😏

Or create a runner for that job

please share the project in channel when you have some of the tickets created... so we can see how this evolves

Yes, I'll do that on Friday. So we can include it in our Friday planing Matrix discussion.

Let's proceed.

No tracking topic yet

There was some discussion on Matrix, but I lost track

What do we have to do or decide?

Right... so I have two PRs for this - one is just a general update for dnsmasq - commands in codeblocks to use sudo etc

I have nothing to add since these are technologies that I haven't used or know.

that one... possibly needs some clean up... since there is general resistance to my HEREDOC method of generating files... but this just mean changing those blocks to use an editor instead...

I’d just like to point out that I consider these points to be important. I need this for a project I’m proposing as a successor to nhome server: Fedora Workplace

I would go with $EDITOR, but sudo vi/nano seem fine to me... or just state in the paras: Edit the file at blah to look like the following...

the other PR is just for dnsmasq and pxeboot

Call out nano in the text? If somene is familair wiht vi/vim/emacs, htey will just use that instead of nano, methinks

I just think to say Edit the file at /path/to/file, is sufficient.

With nano, we’re making a mockery of ourselves in the professional sector.

Possibly with Edit the file using sudo and your preferred editor

I think we can avoid mentioning the editor :)

don

don't mention the wars

okay... that one is easy... I will update that PR tomorrow

OK, so I guess: we can wrap this up as "We'll have some progress and expansion of the DNSmasq docs"

the other PR is validated for PXE using dnsmasq for UEFI clients. I can't get the Fedora 44 install initrd image to load the network on legacy BIOS

or PXE as well?

That PR provides a full setup for dnsmasq to do PXE install...

It works fine with a UEFI client

the UEFI client is using an identical initrd and kernel... so I really can't work out why the BIOS thing is failing

it works up until the initrd loads, but that drops back into dracut shell and the network is down and doesn't do a DHCP request... even if that is in the kernel cmdline at boot

So proposed wrap up :info We will have made some progress and expanded our documentation on DNSmasq and PXE for UEFI after the ongoing PRs

That works for me

yep.... I want to get some review on these reasonably soon

OK.

Let's move on

No tracking issue yet

We decided for individual development environments. How will wew start?

I think. we need a guide how to set up the dev env

I have no idea how to proceed here... LOL

There was some one in user discussed who managed to use kiwi for a rebuild of workstation.

MAybe we should try to contact them?

Who is good at making contact here?

I don't even know what kiwi is :D busy trying to find out

Kiwi is a boot image generating tool

Kiwi is a boot disk image generating tool

ah... just looking at it... neat

OK, so noone has an idea for now. So let's proceed.

We should at least some minutes th spend here.

Anyone with anything??

Now that my laptop has been replaced and I'm functioning again, i'm going to start to dig into the NFS stuff a little deeper.

Yeah, it's one of our long ongoing topics.

Um... one thing... how do I get my OpenSSH stuff merged to main?

I can carry on adding to it... but I kind of wanted the initially migrated content merged so that it is easy to see diffs

Oh, you would to create a local authoring environmant, create that file there, and then push.

It is a new article, isn't it?=

yes... well new inside the server docs

I'm really not seeing a value in NFS or Samba when you are looking at homelab, I can understand NFS for remote storage for images and such, but I use syncthing to keep all of my important files on the computers that I need them, and git with yadm front end for all of my config files. I suppose if I used media across the network NFS and Samba is more worthwhile, I hadn't thought of that use case before just now.

I have the PR already and we agreed on it in a previous meeting

I make extensive use of NFS inside my lab

Ro: OK, so let's talk in our Server room about it. Because we should clear this room now.

I use NFS all the time at home... all of my systems connect to an NFS server on the network

Jocelyn Gould (UTC-4): That's interesting, what solution does it provide in your homelabs? Do you use it for media, or image storage or VM storage...

Regarding NFS / SAmba: I thin it is important to use our experience to design home server. At he same time we should reflect common use cases. I think every home server offers Samba, but maybe not NFS.

My homelab is mostly a single server, serving up webapps so all of the storage and compute is on the same machine. I don't have a file server per say because the main server just syncs all document files and then runs a backup script to send the backup to a remote site and to a local USB drive enclosure.

I use Samba for additional storage I don't want to carry around with my laptop. E.g. private files.

mowest: what app do you use for syncing?

Peter Boy (ServerWG, Docs): That would make sense as well, keep all of your private docs in a NFS or Samba share (if Windows desktops need to access it. Okay I'm seeing some awesome reasons to use it.

Syncthing, been using it for years and I love it. Just flawless.

In the Fedora Repos

OK, syngthing is bidirectional, isn't it?

It is like your own personal Google Drive or One Drive.

Yes it is bidirectional.

OK, but folks, we have to clear this space!!!!!!!!!!! We are 10 mins overdue.

3

2

1