Meeting started at 2025-08-27 17:02:08 UTC

The Meeting name is 'fedora-server '

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

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

!hello

Steve Daley (mowest)

!hello

Emmanuel Seyman (eseyman) - he / him / his

Hello, Peter Boy and mowest

So my main homelab server has one 1TB drive part of a 1.5TB lvm pool reporting a bad sector. I'm guessing I'm going to have to replace that drive, rebuild the lvm, and recover the data loose from a backup.

Yeah, welcome everybody!

Homelab woes when reusing 12 year old hard drives.

mowest: As long as you can still read the drive, you can make a copy (or try to make)

an 12 years are a lot:-)

And lucky one who has a backup

I reseated the sata cables, and plugged into a different sata port on the motherboard and restarted the server and the drive came back on line. We ran backups last night. I'm thinking of getting a bigger drive to replace the 1TB with a 2TB so I think I will have to recover data from the backups.

Well, that backup is fairly recent. what a luck (I'm quite lazy with backups. bad habit)

OK, I gues nirik is lurking as usual and jumps in when require. So let's start.

Anny addition?

I do want to talk about the httpd vhost stuff

No, I probably have to cut out early, like 40 minutes into meeting.

OK., lets insert a new topic httpd vhost itemsl

Sorry, I wasn't saying "No" to Emmanuel Seyman

OK, new agenda topic

Regarding the action, nothing new. See

Announcements

1.

The change regarding bios boot systems as discussed at last meeting is now active.

https://discussion.fedoraproject.org/t/160757/22

https://pagure.io/fesco/issue/3468

Did anyone else check the complete proposal? Regarding the RAID part it looks perfectly OK for me. There are some other parts, e.g. about graphics adapter, I don't oversee out of my head. But I think Kamal did the best he could for our requirements.

Any comment here?

No, I don't have enough understanding to spot problems.

Same

OK

2. There are new issues with Fedora providing Web services. see

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

This is not new

A default configured package, ajp protocoll, doesn't work out of the box but is blocked by SELinux. The packager refuses to fix this.

Emmanuel Seyman: not new? I didn't see bug report

This has been the case for years. We discussed it back when John was writing a Tomcat playbook (or just deployment instructions)

Maybe we should join in the chorus: "Disable SELinux and you'll be happy".

Maybe we should join in the chorus: "Disable SELinux and you'll be happy". 🫠

In looking at the bug report. It appears that you would make this configuration change after the install of httpd. So instead of the packager making a change in the installation of httpd wouldn't it be on the sysadmin to make the SELinux configuration change at the same time as the Tomcat configuration or am I missing something?

I suspect we "just" need a tomcat-selinux package that does the changes automatically

We really really do not want to advocate disabling SELinux

Admittedly, SELinux causes issues for homelab people too. When most are used to running Ubuntu in the homelab coming over the Fedora causes a number of SELinux warnings and issues.

And because we wanted to advocate SELinux, some years ago we tried hart to make it as easy to use as possible and to avoid any issues.

But maybe, we currently have too many users and too many contributors :-)

OK, we resolve it by documentation for now. And I'll ask the Tomcat maintainers, if they could provide a solution.

Something elso do add here?

OK

Emmanuel Seyman: your floor is open :-)

I really would like to see some movement here

Back in February, I reviewed your documentation and found the steps heavy-handed but they improved the default layout of httpd configuration files

I asked if it was possible to upstream this to fix the heavy-handiness and you've apparently had communication issues with Joe

So how do we move forward?

Well, I have to make some minor fixes in the links, not in the text. On my todo list this is on Saturday together with some other work on httpd (my project to package openmeetings for Server). So we could publish it or we could make a PR to httpd and wait 4 days before we publish anyway.

Until now I got no feedback at all to my bugzilla entry

A PR to httpd seems like a very good idea

And the we may add an additional release criteria to our current 3

it would give us a public place to both see evolutions to the suggested layout and a public place to discuss it

Emmanuel Seyman: I really agree, we must speed up things.

Yes, and we could write a Fedora Magazine article.

I

So I read this: we publish the article next week and start a public discussion about it?

Probably after a new proofreading#

Probably after a new proofreading?

Where is the issue? The project maintainers or httpd or the Fedora packagers of httpd?

Where is the issue? The project maintainers of httpd or the Fedora packagers of httpd?

an non-working and outdated httpd package and the non-feedback of the httpd packagers

Is this something to bring to FESCO, asking them to intervene, or reassign the packaging of httpd to someone else?

I don't think we should make a big deal out of this. The packagers may also be overloaded.

I'm guessing that our Fedora package has not adopted some of the new guidelines from the upstream project.

Indeed, since several releases

Peter Boy: I'm sure you are right that the packagers are overloaded. I'm amazed at how much gets packaged for Fedora and how quickly things are updated. I don't know who the community does it.

Peter Boy: I'm sure you are right that the packagers are overloaded. I'm amazed at how much gets packaged for Fedora and how quickly things are updated. I don't know how the community does it.

trust me, it's not easy

I know nothing about packaging but I would think that a PR that has the fix in it for the httpd package should help move it along since the packager would just have to merge the PR.\

OK, so we agree to publish next week and do an Fedora Magazine article that describes a solution that we have found.

I know nothing about packaging but I would think that a PR that has the fix in it for the httpd package should help move it along since the packager would just have to merge the PR.

I hav e alfready a draft.

yes, that sounds good

OK, then let's move on.

Heading out, have a great night. Thanks for all you do.

bye, Steve. See you next time

Well, Paul Maconi (Aggraxis) is not online today.

Yeah, by by

But we already discussed some of the tickets on Matrix.

Or should we postpone nest week, when Paul hopefully will participate?

That's probably best

When I was looking at the documentation for installing to an SBC, I did wonder what it takes for information to move from stg to main

Yeah, that's a bit of work. You can't merge, but have to cherrypick various commits.

What?

Or you just overwrite everything in main and don't care about the log.

cherrypick, instead of merging stg to main you select those commits, that were adding the content to stg.

That sounds even less appealing

You ae right!

I would prefer to just copy it over.

And we have to reconsider our strategy with stg. Probably, when we migrate to the new forge.

merging seems very much the way to go

ah, I had forgotten we will be moving to forgejo sooner or later

Yeah, but to my knowledge you merge always the complete branch, i.e. all the commits, which includes all the other aricles.

Yeah migrating to forgejo is the other topic we have to care about.

I hope we migrate sooner then later :-)

So, let's postpone the issues to next meeting.

Tracking issue: !link https://pagure.io/fedora-server/issue/164

I updated our issue with the latest test release.

I did some testing with Rock Pi 4. It didn't work for the server image (nor the Minimum image)

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

That's quite severe. Nothing works for Server.

I went to install Fedora-Server-Host-Generic-43-20250826.n.1.aarch64.raw.xz on a Banana Pi M64 and it failed because my SD card was too small

Turns out the raw image is 10G uncompressed

I will try again this weekend with a 16G card

OK, it's very interesting if you find the same issues as me.

see the bug report link

Fortunately, I didn't found any issue with x86:64 until now.

Indeed. I will post there if I see it is the same issue

A

And also, it not. I think, we than have to investigate that.

And, by the way, I also manged to install an aarch64 version using Anaconda. Worked flawless.

(in a VM on my Mac an on a Radxa Pi 5 with edk firmware)

OK, I think, at the moment we have nothing to add here?

So

no

so much to do, so little time...

Yeah, we should apply for a reform of the calendar :-)

Anyone lurking around with a question or a comment?

Obviously no one. So I'll close for now

3

2

1