home server spin-off: preinstalled applications

jonashub commented

2026-04-08 16:48:12 +00:00

We should start collecting a discussing the baseline of preinstalled applications

Goal / scope

Define "good defaults" for an intermediate user.
Keep this focused on core services and management UX (e.g. Cockpit + useful plugins), not becoming curated distro or project like Freedombox or ZimaOS.
Prefer well-supported, maintained components available in Fedora

This is tracking/discussion ticket, that means that it's not a final list.

Initial candidates (from current discussion)

File sharing
- Samba (and possibly NFS)
Mail storage
- local mail -- default
- Mailcow (optional)
Cockpit (+ plugins - podman, storage, networking, SELinux, software updates) -- default
DLNA streaming server
- Universal media server
- Jellyfin
- Gerbera
Calendar and todo server
- Radicale
- Vikunja
- Planka
Epub library
- Calibre server or Calibre-Web
Ansible control hub
Monitoring
- smartmontools
Backup
- UrBackup
- restic, borgbackup (optional)
Remote access
- SSH
- Wireguard (optional)

We should start collecting a discussing the baseline of preinstalled applications **Goal / scope** - Define "good defaults" for an intermediate user. - Keep this focused on core services and management UX (e.g. Cockpit + useful plugins), not becoming curated distro or project like Freedombox or ZimaOS. - Prefer well-supported, maintained components available in Fedora **This is tracking/discussion ticket, that means that it's not a final list.** **Initial candidates (from current discussion)** - File sharing - Samba (and possibly NFS) - Mail storage - local mail -- default - Mailcow (optional) - Cockpit (+ plugins - podman, storage, networking, SELinux, software updates) -- default - DLNA streaming server - Universal media server - Jellyfin - Gerbera - Calendar and todo server - Radicale - Vikunja - Planka - Epub library - Calibre server or Calibre-Web - Ansible control hub - Monitoring - smartmontools - Backup - UrBackup - restic, borgbackup (optional) - Remote access - SSH - Wireguard (optional)

jonashub added this to the home server spin-off project

2026-04-08 16:48:12 +00:00

korora commented

2026-04-09 13:48:52 +00:00

Member

Are you looking at the linuxserver.io images for Calibre/Calibre-Web? if so we will need to spin up a reverse proxy that can handle SSL as the image for calibre now requires SSL and it won't work without a cert of some kind

sgallagh commented

2026-04-09 14:44:07 +00:00

Owner

@korora wrote in #192 (comment):

Are you looking at the linuxserver.io images for Calibre/Calibre-Web? if so we will need to spin up a reverse proxy that can handle SSL as the image for calibre now requires SSL and it won't work without a cert of some kind

Can you reuse the Cockpit certificate for this? That might be the easiest option.

@korora wrote in https://forge.fedoraproject.org/server/tickets/issues/192#issuecomment-611679: > Are you looking at the linuxserver.io images for Calibre/Calibre-Web? if so we will need to spin up a reverse proxy that can handle SSL as the image for calibre now requires SSL and it won't work without a cert of some kind Can you reuse the Cockpit certificate for this? That might be the easiest option.

korora commented

2026-04-09 14:50:43 +00:00

Member

@sgallagh wrote in #192 (comment):

Can you reuse the Cockpit certificate for this? That might be the easiest option.

Unsure. I've not tried, although that does sound like it would be a plausible answer. I would have to find the time to research how to do this.

@sgallagh wrote in https://forge.fedoraproject.org/server/tickets/issues/192#issuecomment-611696: > Can you reuse the Cockpit certificate for this? That might be the easiest option. Unsure. I've not tried, although that does sound like it would be a plausible answer. I would have to find the time to research how to do this.

sgallagh commented

2026-04-09 15:17:35 +00:00

Owner

On a freshly-installed system (without manually-installed certificates), The cockpit-ws package uses sscg to create:

/etc/cockpit/ws-certs.d/0-self-signed-ca.pem
/etc/cockpit/ws-certs.d/0-self-signed.cert
/etc/cockpit/ws-certs.d/0-self-signed.key

The 0-self-signed-ca.pem can also be loaded into a client to trust this service. (It's designed in such a way that it can't be reused to trust anything but the 0-self-signed.cert.

On a freshly-installed system (without manually-installed certificates), The `cockpit-ws` package uses `sscg` to create: * `/etc/cockpit/ws-certs.d/0-self-signed-ca.pem` * `/etc/cockpit/ws-certs.d/0-self-signed.cert` * `/etc/cockpit/ws-certs.d/0-self-signed.key` The `0-self-signed-ca.pem` can also be loaded into a client to trust this service. (It's designed in such a way that it can't be reused to trust anything but the `0-self-signed.cert`.

jonashub commented

2026-04-11 10:03:57 +00:00

Author

I wasn’t aware of the TLS requirement here. This makes sense. If Calibre/Calibre‑Web requires TLS for, reusing Cockpit’s generated certs from /etc/cockpit/ws-certs.d/ sounds like a reasonable “good defaults” approach for a LAN setup (and users who want a publicly trusted cert can still put it behind a reverse proxy later).

pboy added the

project

home server spin-off

label

2026-05-13 06:30:56 +00:00

rafaelmcruz commented

2026-05-21 22:28:09 +00:00

Hey guys, 👋

Don’t know if this is still open to suggestions, but I would like to propose adding an automated, lightweight Alerting & Notification system to the "Monitoring" section (which currently focus mainly on hardware with smartmontools).

The core philosophy of a Home Server is often "set and forget", I think users want to deploy their services and not worry about constant manual checking. To achieve this without waiting for a catastrophic failure to happen, to realize that something is wrong, we need a proactive approach.

I haven't personally deployed this specific stack yet, but I've been researching open-source solutions that would fit this idea perfectly, such as integrating Uptime Kuma or utilizing the Apprise library.

This setup would provide:

Proactive Monitoring: Sending alerts based on thresholds (eg, when a partition hits 85% storage or a container stops responding).
Easy Configuration: Users could easily bind a local webhook or link a communication channel they already use daily (like a Telegram bot, Signal, or Discord webhook).
Zero-Cost Maintenance: It doesn't require any paying external SMS gateway, keeping the entire stack 100% open-source, private, and lightweight.

I'm open to researching this further, testing implementations, if needed, or helping with documentation if the team feels this makes sense for the Home Lab scope!

If I’m late and this is not the intended purpose, i’m very sorry!

Hey guys, 👋 Don’t know if this is still open to suggestions, but I would like to propose adding an automated, lightweight Alerting & Notification system to the "Monitoring" section (which currently focus mainly on hardware with smartmontools). The core philosophy of a Home Server is often "set and forget", I think users want to deploy their services and not worry about constant manual checking. To achieve this without waiting for a catastrophic failure to happen, to realize that something is wrong, we need a proactive approach. I haven't personally deployed this specific stack yet, but I've been researching open-source solutions that would fit this idea perfectly, such as integrating Uptime Kuma or utilizing the Apprise library. This setup would provide: 1. Proactive Monitoring: Sending alerts based on thresholds (eg, when a partition hits 85% storage or a container stops responding). 2. Easy Configuration: Users could easily bind a local webhook or link a communication channel they already use daily (like a Telegram bot, Signal, or Discord webhook). 3. Zero-Cost Maintenance: It doesn't require any paying external SMS gateway, keeping the entire stack 100% open-source, private, and lightweight. I'm open to researching this further, testing implementations, if needed, or helping with documentation if the team feels this makes sense for the Home Lab scope! If I’m late and this is not the intended purpose, i’m very sorry!

jpcarvalhinho commented

2026-06-15 15:14:46 +00:00

Lets bee realistic:
So Being a fedora server user at my home server (2011 Imac) what I needed:
1- A Graphical interface like GNOME. Yes. Don't underestimate it. (it was the only way I got to "kill" the screen, keeping the computer working (But I am not a specialist, there is probably a better way, but heck I used it daily so a GUI makes sense)...
2- PLEX server (maybe jellyfin will work, but no clients for TV is a deal breaker)
3- QBit for torrenting
4- Cockpit with https (It scares the crap out of me to get to the URL and get a warning)
5- SMB
6- An easy way to ddns.
7- an improved way to work with containers: On cockpit you configure and start a container, and if you want to change one of the properties you need to insert all the properties again. it sux because let's face it, nobody gets it right at first try.

I think these were the main requirements for my case, just food for thought.

Some more notes:
"Fedora Server Home Server" is redundant. Just call it Fedora Home Server.
also If it is "home server" it will not fit SMBusinesses. They will discard it right away and opt for the other Fedora Server, so why bother with those users on this project?

Lets bee realistic: So Being a fedora server user at my home server (2011 Imac) what I needed: 1- A Graphical interface like GNOME. Yes. Don't underestimate it. (it was the only way I got to "kill" the screen, keeping the computer working (But I am not a specialist, there is probably a better way, but heck I used it daily so a GUI makes sense)... 2- PLEX server (maybe jellyfin will work, but no clients for TV is a deal breaker) 3- QBit for torrenting 4- Cockpit with https (It scares the crap out of me to get to the URL and get a warning) 5- SMB 6- An easy way to ddns. 7- an improved way to work with containers: On cockpit you configure and start a container, and if you want to change one of the properties you need to insert all the properties again. it sux because let's face it, nobody gets it right at first try. I think these were the main requirements for my case, just food for thought. Some more notes: "Fedora Server Home Server" is redundant. Just call it Fedora Home Server. also If it is "home server" it will not fit SMBusinesses. They will discard it right away and opt for the other Fedora Server, so why bother with those users on this project?

jonashub commented

2026-06-17 09:44:22 +00:00

Author

@jpcarvalhinho wrote in #192 (comment):

Lets bee realistic: So Being a fedora server user at my home server (2011 Imac) what I needed: 1- A Graphical interface like GNOME. Yes. Don't underestimate it. (it was the only way I got to "kill" the screen, keeping the computer working (But I am not a specialist, there is probably a better way, but heck I used it daily so a GUI makes sense)... 2- PLEX server (maybe jellyfin will work, but no clients for TV is a deal breaker) 3- QBit for torrenting 4- Cockpit with https (It scares the crap out of me to get to the URL and get a warning) 5- SMB 6- An easy way to ddns. 7- an improved way to work with containers: On cockpit you configure and start a container, and if you want to change one of the properties you need to insert all the properties again. it sux because let's face it, nobody gets it right at first try.

I think these were the main requirements for my case, just food for thought.

Some more notes: "Fedora Server Home Server" is redundant. Just call it Fedora Home Server. also If it is "home server" it will not fit SMBusinesses. They will discard it right away and opt for the other Fedora Server, so why bother with those users on this project?

Thanks for the feedback!

1 - GNOME on a Fedora home server is unnecessary IMO. Server Edition is meant to be managed headless through Cockpit (which you already use in point 4), and a full desktop just eats RAM and CPU that should go to your workloads. The goal should be making Cockpit good enough that you never need a desktop. Anyone who really wants one has Workstation or a spin.

2 - Since April 2025 Plex put remote access behind a paywall. You need either a Plex Pass on the server side, or a Remote Watch Pass on the client side. Jellyfin keeps remote streaming free and open source, the main tradeoff being that its TV clients are less polished (though Android TV, web, Findroid and Swiftfin all work).

3 - QBit is a good optional package, but not a main initial candidate.

4 - The https warning is just Cockpit's default self-signed certificate. That is normal for a local server and only needs to be accepted once. If we want to get rid of it properly, a reverse proxy like Caddy can pull a real Let's Encrypt cert automatically, which ties in nicely with the DDNS hostname from point 6.

5 - SMB is already in the issue.

6 - For DDNS, ddclient is already packaged in Fedora and supports most providers (DuckDNS, Cloudflare, No-IP). To make it actually easy we could ship a small Ansible role (fits the Server Ansible initiative) or a Cockpit module, where you just drop in a provider and token. A more modern alternative is Tailscale or Cloudflare Tunnel, which skip DDNS, port forwarding and certs entirely. The catch is they are harder to set up on a dumb TV.

7 - This is solvable with Quadlet. Instead of recreating a container every time you change one property, the whole config lives in a systemd unit file (.container) as plain text. You edit one line, daemon-reload, restart, done. It is also versionable in git. The missing piece is editing quadlets directly in Cockpit, which would be a great feature request for cockpit-podman.

@jpcarvalhinho wrote in https://forge.fedoraproject.org/server/tickets/issues/192#issuecomment-822089: > Lets bee realistic: So Being a fedora server user at my home server (2011 Imac) what I needed: 1- A Graphical interface like GNOME. Yes. Don't underestimate it. (it was the only way I got to "kill" the screen, keeping the computer working (But I am not a specialist, there is probably a better way, but heck I used it daily so a GUI makes sense)... 2- PLEX server (maybe jellyfin will work, but no clients for TV is a deal breaker) 3- QBit for torrenting 4- Cockpit with https (It scares the crap out of me to get to the URL and get a warning) 5- SMB 6- An easy way to ddns. 7- an improved way to work with containers: On cockpit you configure and start a container, and if you want to change one of the properties you need to insert all the properties again. it sux because let's face it, nobody gets it right at first try. > > I think these were the main requirements for my case, just food for thought. > > Some more notes: "Fedora Server Home Server" is redundant. Just call it Fedora Home Server. also If it is "home server" it will not fit SMBusinesses. They will discard it right away and opt for the other Fedora Server, so why bother with those users on this project? Thanks for the feedback! 1 - GNOME on a Fedora home server is unnecessary IMO. Server Edition is meant to be managed headless through Cockpit (which you already use in point 4), and a full desktop just eats RAM and CPU that should go to your workloads. The goal should be making Cockpit good enough that you never need a desktop. Anyone who really wants one has Workstation or a spin. 2 - Since April 2025 Plex put remote access behind a paywall. You need either a Plex Pass on the server side, or a Remote Watch Pass on the client side. Jellyfin keeps remote streaming free and open source, the main tradeoff being that its TV clients are less polished (though Android TV, web, Findroid and Swiftfin all work). 3 - QBit is a good optional package, but not a main initial candidate. 4 - The https warning is just Cockpit's default self-signed certificate. That is normal for a local server and only needs to be accepted once. If we want to get rid of it properly, a reverse proxy like Caddy can pull a real Let's Encrypt cert automatically, which ties in nicely with the DDNS hostname from point 6. 5 - SMB is already in the issue. 6 - For DDNS, ddclient is already packaged in Fedora and supports most providers (DuckDNS, Cloudflare, No-IP). To make it actually easy we could ship a small Ansible role (fits the Server Ansible initiative) or a Cockpit module, where you just drop in a provider and token. A more modern alternative is Tailscale or Cloudflare Tunnel, which skip DDNS, port forwarding and certs entirely. The catch is they are harder to set up on a dumb TV. 7 - This is solvable with Quadlet. Instead of recreating a container every time you change one property, the whole config lives in a systemd unit file (.container) as plain text. You edit one line, daemon-reload, restart, done. It is also versionable in git. The missing piece is editing quadlets directly in Cockpit, which would be a great feature request for cockpit-podman.

eseyman commented

2026-06-18 20:57:11 +00:00

Member

1 - I suspect installing a GUI is better left as a post-install task
4 - We have discussed TLS certificates a number of times and consensus is that you should accept untrusted ones or replace them with trusted certs.

1 - I suspect installing a GUI is better left as a post-install task 4 - We have discussed TLS certificates a number of times and consensus is that you should accept untrusted ones or replace them with trusted certs.

Rows
Columns

home server spin-off: preinstalled applications #192