Meeting started at 2026-08-19 17:00:12 UTC

The Meeting name is 'fedora-server '

!hi

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

!hi

!group members server-wg

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

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

Welcome to our weekly Server WG meeting.

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

!hi

Peter Boy (ServerWG, Docs): Peter Boy (pboy)

!hi

!hi

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

No Fedora Accounts users have the @pa_ubach:matrix.org Matrix Account defined

!hello

!hi

Emmanuel Seyman: Emmanuel Seyman (eseyman) - he / him / his

John Himpel: John Himpel (jwhimpel)

welcome back [Emmanuel Seyman](https://matrix.to/#/@eseyman:fedora.im)

We already meet our quorum. So let's start.

I introduce myself. I am a university professor and engineering researcher who wants to use Fedora Server for homelab use.

Peter Boy suggested me to use my experience to contribute documentation for the Fedora Server. We can comment at the end of the meeting if it suits you

Welcome back, Emmanuel SeymanHope the vacation was good!

Welcome [Pere-Andreu](https://matrix.to/#/@pa_ubach:matrix.org)

Welcome, Pere!

Welcome Pere-Andreu !!! I remember our most interesting discussion very well!

welcome welcome!

!hi

copperi: Jan Kuparinen (copperi)

Thanks! It was very relaxing (even if hot).

As of our Matrix discussion we came up with the following agenda

Any comment on this agenda?

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/

Did I forget something?

OK, no announcements from me.

I'm good

No announcements from me

OK, let's move on.

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

Tracking issue: https://forge.fedoraproject.org/server/tickets/issues/193 (image issue)

I did some testing with the branched version. No surprises yet

I will pull the qcow2 imsages and play with those. i'll report back any findings

I need to get started with testing... I will try to do something on Friday. Are we updating the tickets to reflect the new build dates?

Well, we have 2 topics to care about. The first one:

https://bugzilla.redhat.com/show_bug.cgi?id=2484542

Didn't do much during my vacation. I will be busy this weekend so I won't test until next week

Emmanuel Seyman: It's your 'domain of concern' as our 'master of the change list'

Looking into this a little further, it appears to only affect arm builds, but it might affect the qcow images too. It's something I'll be testing.

I sent a list of Changes that we should test to the mailing-list.!

I did not see any reply

As far as I got it, the kmscon is completely unnecessary for us. It requires graphics drivers, but we work in headless mode.

From what I can see in the boot messages, it starts up and then shuts itself down shortly afterwards.

Although, looking at the BZ, it looks like Jocelyn (the other one, not me) already uploaded a patch so it might be a moot point

From what I can see in the boot messages, it starts up and then shuts itself down shortly afterwards. That’s one of the things we’ve inherited from the desktop team without being asked, and it’s just lying around on the server.

Emmanuel Seyman: Do we have a link in the ticket system, too?

Not to my knowledge

I can take a peak at the 'modernize boot.iso' feature change

OK, I add the list in a comment.

I will continue to sit in on the QA/Beta Blocker meetings and report back as necessary

If each one of us could test 1 or 2 new features, that would be great

I suppose we should either ticket the new features as a single ticket... or tickets per feature

I don't know how far we go testing with things like new versions of stuff

like Podman 6... do we just install podman and confirm that it is at version 6... or do we test functionality and features listed

Ro: Could you organize that we have an organized discussion either with one ticket or wirth several?

I will start with a single ticket and we can add individual tickets if necessary

We need to test functionality and new features as much as possible

OK, I think we dismiss the changes for now and use the tickets first.

We’ll stick to eseyman’s list of selected changes.

OK, I think we dismiss the discussion of changes for now and use the tickets first.

Let's revisit the topic next week

OK, to wrap up:

Tracking project: https://forge.fedoraproject.org/server/tickets/projects/436

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

We should structure our disussion, and maybe start with the distribution. There seems to be still some discussion here.

!hello

mowest: Steve Daley (mowest)

Emmanuel Seyman: Would you take over the chair?

Let's go

So the discussion is still ongoing

Please give your input in the tickets if you have a strong opinion

It seems that [Brett](https://matrix.to/#/@brettweir:matrix.org) already flattened the repo. So we're now treating it as a single set of roles.

We probably need to restructure again as an Ansible collection to align with Fedora packaging guidelines

But probably not a huge amount of work

And we should aim to release on Galaxy because the Fedora packaging guidelines expect that the collection is also published on Galaxy (I think, only skimmed yesterday)

But still package as RPM

Because that is a cool distribution option

What is the feeling on breaking out some of the tasks into individual roles? or are we sticking with one post-install role?

And we should aim to *also release on Galaxy because the Fedora packaging guidelines expect that the collection is also published on Galaxy (I think, only skimmed yesterday)

I'm going to argue for one postinstall role

I think that Ansible Galaxy is the best place for our production product. It is hosted by RedHat. Ansible & Ansible Galaxy are RedHat products. I'm not against a single rpm containing our ansible production product in addition. Much in the same way the Fedora Infrastructure group has done with their Ansible content.

Emmanuel Seyman: +1

I like the idea of breaking things into smaller composable roles and making a postinstall playbook.

I'm kind of agnostic about it. I kind of agree with [Brett](https://matrix.to/#/@brettweir:matrix.org) but also am happy with one role with many tasks.

I'm kind of agnostic about it. I kind of agree with [Brett](https://matrix.to/#/@brettweir:matrix.org) but also am happy with one role with many tasks and vars to control which tasks are run.

The main motivation (for my part) is that I don't always want everything. I want some things, some times.

I think this is what the vars were for.

I still want to make a boolean for each task so that you can choose what you want to do

I like one role with several distinct tasks. Flow control provided via vars.

Cool... that sounds good.

Emmanuel Seyman: So would that involve doing the RPM install of one post install role, and then editing a config file before you would run the Ansible Playbook?

In related news, I filed https://github.com/ansible-middleware/wildfly/issues/394 on GH

I would prefer a rpm or Download from the Server repo as the primary path. And Galaxy additional. It is really highly server specific. And not useful for anything else.

Galaxy has to come (logically) first because the packaging guidelines expect a Galaxy namespace and we need to claim it.

This is not an either-or situation. We should allow users to choose how they want to do thigns

But it doesn't have to be advertised in any way if we don't prefer that route

The advertising is in our docs!

The ansible-middleware team seem willing to support Fedora.

We now need to test their wildfly role againt Fedora Server (preferably 44) to see if it works

And it is ineresting for Fedora Server admins only.

I don't know when I'll be able to do this

Well, I'm specifically interested in Wildfly. So I'll take that one.

I'm open to what this ends up looking like. It's probably six-of-one, half-a-dozen of the other

But the 'when' is an issue for me, too

Oh, what I mean is we don't have to broadcast that we release to Ansible Galaxy. We just need to make sure we claim the namespace.

But yeah, this too!

NOTE: We are 10 mins in our disussion and still at 1 of 5 items.!

Oh, I think they'd happen at roughly the same time, or there's no reason they couldn't, I should say.

I'll continue working on the postinstall role and the wildfly testing. Any help is welcome

Let's move on to the other topics

Happy to help with the gaps and the booleans.

I probably won't do much with the tasks themselves but I can help with packaging and CI/CD stuff.

At this time anyway.

OK. I take it that way: @eseyman will complete the post-install aansible things

Any objections about my wrap up?

None from me

Nope!

OK, then:

:info @eseyman will complete the post-install Ansible support work. It will at the same time server as a live demo how we can distribute our Ansible support code.

Let's continue with the next topic on agenda.

Tracking project: https://forge.fedoraproject.org/server/tickets/projects/490

We have at least 4 items to discuss here, Let's start with:

New structure for postinstall & navigation bar

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

https://forge.fedoraproject.org/server/tickets/issues/224

My proposal:

New subdirectory "post-installation customizations"

Contents:

- Basic steps

- Network consolidation

- Storage organisation

- Fail2ban and other security measures

- Various other brief topics

- DNF / Update

- Organisation of backups

New subdirectory "post-installation customizations"

Contents:(articles)

- Basic steps

- Network consolidation

- Storage organisation

- Fail2ban and other security measures

- Various other brief topics

- DNF / Update

- Organisation of backups

The new subdir may be the 4th after containerization.

I like where you're going with this. I'd like to propose some variations, mainly shorter titles:

First steps

Networking

Storage

Security hardening

# Various other brief topics, I'm assuming this isn't a specific page

Automatic updates

Backups

I like where you're going with this. I'd like to propose some variations, mainly shorter titles:

- First steps

- Networking

- Storage

- Security hardening

- Various other brief topics, I'm assuming this isn't a specific page

- Automatic updates

- Backups

lol that was unexpected

Shorter is better for how it appears in the sidebar.

Various brief topics may be various short articles / howto

Networking is a gerund... but I think it is unavoidable :D

Yeah, I think it's a noun in this context, lol

Because jargon

I think, at the moment the primary thing is the structure. The naming the the second. a compromise betwen descriptive and shortish

That structure looks great, and all sitting under "Postinstall"?

I like the structure!

I learned this week that Red Hat recommends "postinstall" and "postinstallation" for the correct spelling.

haha

I'm good with "postinstall" as the main topic

Yeah. There is a general dislike of hyphenation.

I don't think it needs to be a topic... just top level nav

Oh, I think that's what he meant.

I wonder if it's because hyphenated words get split across lines.

But yeah, this layout looks good, I like it

OK: proposed: !agreed The working group has agreed to split the current ‘post-installation’ article into several shorter and more specific articles in a separate subdirectory. Today’s proposal will be developed further in a ticket.

+1

+1

proposed: !action pboy will summarise the discussion in a ticket.

OK, no objection so far:

!action pboy will summarise the discussion in a ticket.

5 mins left. Lets swith to open floor and take some more time.

I have a DNF/Software Management guide PR as a WIP... I'm doing this partially to help close down the wiki topics... but also to consolidate information that really doesn't belong in Quick-Docs...

I will continue working on it for a bit... but will slow down to catch up with testing etc. If anyone has any objections or suggestions... I appreciate feedback

Pere-Andreu: are you still available or have we put you off?

I'm here

I'm still working on adding CI/CD for Ansible playbooks. I've got an ansible-lint job going. The Actions need to be enabled on the ansible-support repository, for whoever is admin on that repo. Here's the job I have:

https://forge.fedoraproject.org/server/ansible-support/pulls/181

I'd appreciate some tips on how to produce useful material for documentation, and also what steps are you most interest for me to document.

Pere-Andreu: We hat an interesting discussion about various topics. I guess, a good start would be to pick a topic you are interested on and are currentloy working with.

I am starting with a clean environment. A DELL Poweredge R730 that I want to use for several services, including HPC and AI

[Pere-Andreu](https://matrix.to/#/@pa_ubach:matrix.org) and if you have any questions about the repo or asciidoc etc... just yell in [\#server:fedoraproject.org](https://matrix.to/#/#server:fedoraproject.org)

Otherwise, we have some white spots in our documentation, e.g. podman container, systematic backup strategies to name a few.

There's some good notes here:

https://docs.fedoraproject.org/en-US/server-working-group/usr-docs-maintenance/local-authoring/

https://docs.fedoraproject.org/en-US/server-working-group/usr-docs-maintenance/gitcheatsheet-for-authors/

https://docs.fedoraproject.org/en-US/fedora-docs/contributing-docs/style-guide/

OK, then I will be reporting to the #Fedora Server group and will try to systematically document in asciidoc

Podman, definitely in my list of priorities, as well as systematic backup

HPC has been under-represented here so far, as have server clusters.

Or Server as domain controller

I don't think I have the knowledge to be exhaustive, but I will try my best

There's a lot of opportunity. I joined because I was building a Fedora Server homelab and wanted to contribute what I learned back upstream.

(still am lol)

Endless opportunity... so much work... so few people :D

Well, thanks for the warm welcoming!

Thanks for joining us... the more contribution the better.

We are 10 minutes over time and we shouldn’t overdo it.

Regarding the next meetings: I would suggest that the next meeting focuses solely on release testing and Ansible, and the meeting after that on release text and documentation.

+1

Regarding the next meetings: I would suggest that the next meeting focuses solely on release testing and Ansible, and the meeting after that on release test and documentation.

Let’s call it a day. It was another very productive meeting.