Meeting started at 2024-12-18 18:00:18 UTC

The Meeting name is 'fedora-server'

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

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

!hello

Emmanuel Seyman (eseyman) - he / him / his

Hello, folks

!hello

Paul Maconi (aggraxis) - he / him / his

Hi Emmanuel

Hi Paul! HJappy to meet you. I still owe you an email answer. Sorry. I'm so swamped

You are fine my friend :) I'm just happy to be able to attend this week.

it's that time of the year where you have to finish every project in sight

Yes, and write all the applications for extensions and new projects.

And the (public) university's operation depends on funding.

OK, I think wé start. I adjust the order of topics, because mowest will attend later.

I think, we should start immediately

topic 1. Follow-up actions & announcements

Nothing new here. See:

Anything to announce here?

OK, then

Well, we have an issue how to organize the user id's, as far as I read the mails.

Yep. Classic problem, typically resolved through centralized authentication.

The best thing would be, to make Cerberos easyly availabler, maybe

Even an LDAP server and sssd would suffice

I'm not sure why John thinks LDAP is not a reasonable solution

I think that most people who have a home NAS that does NFS are doing most of their stuff as root instead of the individual account users, and that's why it seems to 'just work' for them. We saw the same thing here in the enterprise when we went back to revamp how some of this is done with our NetApp filers.

I took note of the freeipa ansible role mentioned in the e-mail thread, and it made me think about how, really, the centralized AAA piece is essentially a prerequisite to standing up end services like NFS and SMB.

samba basically comes with its own LDAP server these days but, yes, you're right

I can understand how it could be seen as 'too much', but you aren't going to get around the uid/gid mismatch any other way

The key would b e, to make is easily managable.

idmapd does sound like the solution to the problem

!hello

Steve Daley (mowest)

Hi mowest!

I read some documentation for nfs4 in FreeBSD that talked about idmapd only handling part of the issue, not all of it, and that ultimately using something like krb5 was 'the answer'

We have pulled forward another topic

FTR, I've started writing an ansible role to install and configure OpenLDAP

I read somewhere that NFS 4 only works with Kerberos, nothing else. But that was a while ago.

It sounds like if we could combine the ansible role for OpenLDAP with the role for NFS, then we could help users set up a workable file server with as little effort as possible, baking in some of the configuration.

I'm pretty sure I'm using NFSv4 and there's certainly no Kerberos in sight

Emmanuel Seyman: That would be great! Kerberos is quite a beast, if I remember correctly

Yes, very much so

Yep. gotta have a commonly trusted CA, time sync, overlapping crypto policies on both ends, etc.

How sure are we that NFS 4 also works with ldap?

It's not so much that NFS4 would work with ldap, but that each system would tie into one ldap to look up users. In essence, you wouldn't be using local users with locally generated UIDs GIDs. The system would retrieve them from ldap.

So in a nutshell you're moving where in the process you're trying to tackle the issue. And, of course, if the LDAP server goes down you could have an interesting time trying to log into that account on the remote system.

Sounds nice :-)

OK, so we would still use the UID and not the NFS 4 password capability?

Yes

you will still be doing sec=sys for NFS4 in this case, not krb5

OK.

And can we install an LDAP by default? And how do we get that synchronized with the standard logins?

That sounds messy for a homelab situation. Could we develop an Ansible role that would work for a homelab situation, and then a different one for a more enterprise role?

yes, we could do that

Your only other option for a homelab role is to ensure that you build the users with the same uids and gids on each machine

exactly what I was about to say

it's up to you, the builder, to manually map all of that out

but yes, it can be done.

basically, you have the simple solution and the complex one. Your job is to choose between the two

I have used syncthing in the home lab to do all of my syncing to the file server, then I use borg to backup the synced data from one server to a backup server, this sounds like I should stick to that for the homelab. It doesn't sound like I would gain anything to have NFS in the mix.

I used Vorta to configure Borg to stuff things in my Synology NAS. IIRC, this required me to install a package or two on the NAS and establish an account on that device. I'm pretty sure it's connecting via SSH using an SSH key, so NFS isn't invovled at all.

The only thing NFS serves is the VM datastore to the Proxmox nodes, and they all talk as 'root'.

By the way; And we still have another area to work on. I received a security warning from our federal agency that our test server on port 111 / portmapping is completely open. We should narrow this down to permissible IP ranges in the firewall. We also have to organize this, at least for publicly accessible servers.

we've already spent half the meeting on the subject and mowest is now with us. Perhaps we can move on to the survey

Our terstserver: sisyhos.resdigita.eu

Is that the RPCbind service? That is something we typically close off.

Yes, I thing so. And I thought with NFS4 we get rid of it.

Well, how will we proceed? What should be the solution?

(regarding the UID issue)

1. Let Emmanuel Seyman work on the LDAP role, and 2. Establish documentation for the manual way of coordinating the UID's.

OK, die we agree on that?

sounds fair

proposed !agreed Regarding NFS we will start with LDAP ansible playbook and in parallel establish documentation for the manual way in smaller networks.

I see no objection.

+1

!agreed Regarding NFS we will start with LDAP ansible playbook and in parallel establish documentation for the manual way in smaller networks.

Let's move on before we get out of time

https://fedoraproject.limequery.com/fedora-server-f41 I believe this address gives us a live poll that is ready to receive entries.

I believe we are just needing to let people know about. it.

OK, So let's consider when we want to publish the Magazine article (and officially start), In first week of January or next week?

I suppose, it s too late for this year.

An article would go unheeded.

Or mnaybe not, because everyone has free time :-)

I think any time is a good time. Probably will not get a lot of attention in the next few weeks. It would be nice to get all the publicity out on the same day if possible.

Yes, that is true that people will have free time so they might take a look at it over the break from work.

Fedora is a free time project for many, so getting it out as soon as possible might fit with their free time.

OK, the earliest way might be Monday Dec 23, maybe Friday Dec 20

Emmanuel, Paul what are you thinking?

I can look at the edits that you made to the article today, and give it my okay for publishing in Fedora Magizine. Are you able to get it through the pipeline to publish, I have never published an article for Fedora Magizine before.

I don't have much of an opinion on when we start the survey, only that it should last at least 60 days

mowest: I can di the publishing work, I did that several times.

I agree that we should keep it open till the end of February even if we get information out to people before 1/1/25

Yes, we agreed upon end of February.

And we can extend that, just in case we need more participation.

mowest: You decide about the time. What should I aim at?

This Friday if you think it is possible.

Otherwise Monday 12/23/25

12/23/24

OK, I'll go for that!

Or Monday 12/23/24

Any comment to my text additions? I think an Magazine article must not be too short.

I have the hackmd doc open, and will do my edits immediately after the meeting.

At first look, I have reservations about mentioning the img for RPi's.

I have done some testing on a RPi 3+ and has some conversations in Fedora ARM, and it seems as if targeting the RPi platform or holding out hope for that to work well with Fedora (any of the flavors) is not the best use of our time.

I don't think I want at this time offer that up as a possibility because it might bring people to Fedora Server with the wrong expectations.

Well, it is not specifically for RPI. That's just the marketing name because it is well known. I have expernces with other SBC, which work much faster and are fine.

And I think, we should try to create a new, additional installation medium.

But of course, it is is too slow, it is not useful.

And we can leave it off for now, and reconsider it later ir we have some experiences with our solution.

I would feel better about not mentioning RPi after my experiences. In Fedora ARM they suggested other ARM boards, but the price on those was significantly higher and not really what most people are going to be using in their homelab if we were hoping to target that img at the homelab audiance.

I would target RPi5 specifically if we want to target RPi at all

In the 4th paragraph I would like to do some editing to rework the sentences that start with "Or" because in English that isn't the best grammer.

mowest: On our documentation there are some other boards that are even cheaper as RPI and at the same time much more powerful.

mowest: please, correct my German English :-)

Peter Boy: Hum... I might consider taking a look at that. I have a little under $100 that I could use to give ARM another try.

Yes, the RPI is much more powerful

RPI -Y RPI 5

Emmanuel Seyman: Do you know the current state of Fedora on RPi5? I was under the impression that it wasn't bootable yet.

Actually, that gets us off topic and we are at time.

Emmanuel Seyman: Paul Maconi (Aggraxis) Any comments about the hackmd text? Or do we have permission to do it that way?

I have not tried it but understood that it was mostly functional

As far as I know RPI 5 boots with Server because we have no graphics.

No opinion. Please do as you see fit

OK

I don't think "arm-image-installer" lists it as a target yet.

IOndeed it doesn't. but alle the otherf powerful SBC in our documentation list.

Ok, sound good for the Fedora Mag. Article. Peter Boy I will ping you in Fedora Server channel when my edits are done.

OK.

I think we are done now. Hapy Christmas and a fine new year. And back in good health next year

Merry Christmas to all of you as well, enjoy your families and loved ones over the break from work.

Happy holidays, folks. See you in 2025!

Yes, see you in 2025

Bye Bye!