Flock 2026 Fedora Server talk CfP #181

Open
opened 2026-02-08 16:58:29 +00:00 by pboy · 6 comments
Owner

We need to provide a CfP for Flock 2026. Here a draft proposal.

Fedora Server – What you can expect from the next two releases

Last year, we conducted a user survey that gave us many insights into the use of Fedora Server Edition. The task now is to incorporate the wishes and requirements into further development.

The data show a high level of satisfaction, particularly with regard to reliability and compatibility, even between different releases. The focus of the next two release cycles will be on improving the user experience, reducing administrative overhead, and enhancing operational security.

There are three areas in particular that are to be addressed

  • In response to the high number of home server usages, we will finally create a dedicated home server spin-off. The goal is to combine a high level of environmental friendliness with an easy and comfortable usability similiar to commercial NAS boxes while offering a more powerful configurability. The challenge is to achieve this using standard Fedora tools such as Cockpit and Ansible. We will use Participatory Software Development (PD) methodology to actively involve users in the development process.
  • Backup & restore are work-intensive processes, especially for standalone servers without integration into a centralized backup management. And it becomes even more complicated if they are located in a remote data center without even access to a console or USB port. In these cases in particular, it is important to establish an easy-to-use and automated procedure. Using the specific features of the Fedora Server storage concept, LVM and usage-specific logical volumes, should allow for a fast, parallelizable operation. Special attention should be paid to dnf updates, where the backup can be discarded if successful. In the long term, a special dnf plug-in is being pursued.
  • Fedora Server in standalone mode currently uses only a simple name/password authentication by default. More elaborate procedures must be installed and configured by the system administrator. It is a complex process and usually not even feasible for standalone servers. The recently available Local Authentication Hub (LocalKDC) provides local Kerberos keys, exclusively locally via Unix domain sockets and executed on demand by socket activation. It significantly expands the functionality for file services such as Samba and can also become bases for the login function of NFS v4.

Comments (not part of the public text):

  • A large number of our users utilize Fedora Server as a home server, often in addition to professional use. We have decided to develop a dedicated home server spin-off. We intend to use a participatory development model in which current and potential future users are involved in the design and, optionally, in the development and testing of the final product. The goal is to develop an environmentally friendly spin-off that is as easy to use but at the same time more powerful to configure than commercial NAS boxes. The standard Fedora tools such as Cockpit and Ansible can achieve this.

  • One task that is often neglected is the systematic backup of the server, especially before routine updates. The critical point is that many Fedora servers are operated in a – usually remote – data center with limited access to the console. The LVM used by the server provides a basis for creating backups elegantly and restoring them in an emergency with snapshots. Ultimately, we need a way to coordinate the backup with the Fedora DNF update process and a rescue system with network access for emergencies.

  • Furthermore, it is necessary to integrate more elaborate measures for secure identity and access management into the default configuration of Fedora Server Edition. As a first step, localkdc should be integrated, as it offers extended options for standalone servers.

We need to provide a CfP for Flock 2026. Here a draft proposal. # Fedora Server – What you can expect from the next two releases Last year, we conducted a user survey that gave us many insights into the use of Fedora Server Edition. The task now is to incorporate the wishes and requirements into further development. The data show a high level of satisfaction, particularly with regard to reliability and compatibility, even between different releases. The focus of the next two release cycles will be on improving the user experience, reducing administrative overhead, and enhancing operational security. There are three areas in particular that are to be addressed - In response to the high number of home server usages, we will finally create a dedicated **home server spin-off**. The goal is to combine a high level of **environmental friendliness** with an easy and comfortable **usability** similiar to commercial NAS boxes while offering a more powerful **configurability**. The challenge is to achieve this using standard Fedora tools such as **Cockpit** and **Ansible**. We will use Participatory Software Development (PD) methodology to actively involve users in the development process. - **Backup & restore** are work-intensive processes, especially for **standalone servers** without integration into a centralized backup management. And it becomes even more complicated if they are located in a **remote data center** without even access to a console or USB port. In these cases in particular, it is important to establish an **easy-to-use and automated** procedure. Using the specific features of the Fedora Server storage concept, LVM and usage-specific logical volumes, should allow for a fast, parallelizable operation. Special attention should be paid to **dnf updates**, where the backup can be discarded if successful. In the long term, a special **dnf plug-in** is being pursued. - Fedora Server in standalone mode currently uses only a simple **name/password authentication** by default. More elaborate procedures must be installed and configured by the system administrator. It is a complex process and usually not even feasible for standalone servers. The recently available **Local Authentication Hub (LocalKDC)** provides local Kerberos keys, exclusively locally via Unix domain sockets and executed on demand by socket activation. It significantly expands the functionality for file services such as Samba and can also become bases for the login function of NFS v4. ### Comments (not part of the public text): - A large number of our users utilize Fedora Server as a home server, often in addition to professional use. We have decided to develop a dedicated home server spin-off. We intend to use a participatory development model in which current and potential future users are involved in the design and, optionally, in the development and testing of the final product. The goal is to develop an environmentally friendly spin-off that is as easy to use but at the same time more powerful to configure than commercial NAS boxes. The standard Fedora tools such as Cockpit and Ansible can achieve this. - One task that is often neglected is the systematic backup of the server, especially before routine updates. The critical point is that many Fedora servers are operated in a – usually remote – data center with limited access to the console. The LVM used by the server provides a basis for creating backups elegantly and restoring them in an emergency with snapshots. Ultimately, we need a way to coordinate the backup with the Fedora DNF update process and a rescue system with network access for emergencies. - Furthermore, it is necessary to integrate more elaborate measures for secure identity and access management into the default configuration of Fedora Server Edition. As a first step, localkdc should be integrated, as it offers extended options for standalone servers.
pboy self-assigned this 2026-02-08 16:58:52 +00:00
Member

Looks good. Your might mention that through the local authentication hub we also aim to remove less secure authentication options such as NTLM.

Looks good. Your might mention that through the local authentication hub we also aim to remove less secure authentication options such as NTLM.
Member

@pboy wrote in #181 (comment):

  • Backup & restore are work-intensive processes, especially for standalone servers without integration into a centralized backup management. And it becomes even more complicated if they are located in a remote data center without even access to a console or USB port. In these cases in particular, it is important to establish an easy-to-use and automated procedure. Using the specific features of the Fedora Server storage concept, LVM and usage-specific logical volumes, should allow for a fast, parallelizable operation. Special attention should be paid to dnf updates, where the backup can be discarded if successful. In the long term, a special dnf plug-in is being pursued.

Snapshots are not backups by themselves. You need some kind of off-site archival mechanism to make them backups. Of the storage technologies available in Fedora, only Btrfs provides a trivial way to extend snapshots into backups with its built-in replication mechanism.

That said, it would be very cool if Fedora Server had the ability to be a backup host. If open source solutions like UrBackup were packaged and available in Fedora itself, that would make it useful as a central host for backups. You could have Fedora workstations and servers backing up automatically to a Fedora Server backup host. Restores could be supported by pulling backups over the wire back to the target machines using some kind of recovery media.

@pboy wrote in https://forge.fedoraproject.org/server/tickets/issues/181#issue-68340: > * **Backup & restore** are work-intensive processes, especially for **standalone servers** without integration into a centralized backup management. And it becomes even more complicated if they are located in a **remote data center** without even access to a console or USB port. In these cases in particular, it is important to establish an **easy-to-use and automated** procedure. Using the specific features of the Fedora Server storage concept, LVM and usage-specific logical volumes, should allow for a fast, parallelizable operation. Special attention should be paid to **dnf updates**, where the backup can be discarded if successful. In the long term, a special **dnf plug-in** is being pursued. Snapshots are not backups by themselves. You need some kind of off-site archival mechanism to make them backups. Of the storage technologies available in Fedora, only Btrfs provides a trivial way to extend snapshots into backups with its built-in replication mechanism. That said, it would be very cool if Fedora Server had the ability to be a backup host. If open source solutions like [UrBackup](https://www.urbackup.org/) were packaged and available in Fedora itself, that would make it useful as a central host for backups. You could have Fedora workstations and servers backing up automatically to a Fedora Server backup host. Restores could be supported by pulling backups over the wire back to the target machines using some kind of recovery media.
Author
Owner

Snapshots are not backups by themselves

Yes, I know. But you get quickly a frozen state, which you can then transfer using tar of whatever or can drop it if you wanted a fall back solution and the update went finde. That's the idea.

That said, it would be very cool if Fedora Server had the ability to be a backup host. If open source solutions like UrBackup were packaged and available in Fedora itself

Splendid idea! That's probably a separate project, but in the same context. And is seems to be an active project. I suppose it's written in python, do you know details?

> Snapshots are not backups by themselves Yes, I know. But you get quickly a frozen state, which you can then transfer using tar of whatever or can drop it if you wanted a fall back solution and the update went finde. That's the idea. > That said, it would be very cool if Fedora Server had the ability to be a backup host. If open source solutions like UrBackup were packaged and available in Fedora itself Splendid idea! That's probably a separate project, but in the same context. And is seems to be an active project. I suppose it's written in python, do you know details?
Author
Owner

we also aim to remove less secure authentication options such as NTLM.

Done. Thanks

> we also aim to remove less secure authentication options such as NTLM. Done. Thanks
Author
Owner
You can read the [current version without logging in here](https://cfp.fedoraproject.org/flock-to-fedora-2026/talk/review/MLEYFUVJRRZ3UDEPCZUBQHB9Y7NQDEZ7).
Member

@pboy wrote in #181 (comment):

Snapshots are not backups by themselves

Yes, I know. But you get quickly a frozen state, which you can then transfer using tar of whatever or can drop it if you wanted a fall back solution and the update went finde. That's the idea.

To handle that strategy effectively, you'll need some kind of control mechanism to make sure you don't fill up due to snapshots.

That said, it would be very cool if Fedora Server had the ability to be a backup host. If open source solutions like UrBackup were packaged and available in Fedora itself

Splendid idea! That's probably a separate project, but in the same context. And is seems to be an active project. I suppose it's written in python, do you know details?

I believe it's actually a mix of C and C++.

The sources are available for download from the website.

@pboy wrote in https://forge.fedoraproject.org/server/tickets/issues/181#issuecomment-376557: > > Snapshots are not backups by themselves > > Yes, I know. But you get quickly a frozen state, which you can then transfer using tar of whatever or can drop it if you wanted a fall back solution and the update went finde. That's the idea. > To handle that strategy effectively, you'll need some kind of control mechanism to make sure you don't fill up due to snapshots. > > That said, it would be very cool if Fedora Server had the ability to be a backup host. If open source solutions like UrBackup were packaged and available in Fedora itself > > Splendid idea! That's probably a separate project, but in the same context. And is seems to be an active project. I suppose it's written in python, do you know details? I believe it's actually a mix of C and C++. The sources are available for download from [the website](https://www.urbackup.org/download.html).
Sign in to join this conversation.
No milestone
No project
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
server/tickets#181
No description provided.