Author a "Beginners Guide to Fedora Home Lab" 1 of 2 in Server Series #190
Labels
No labels
Ansible
basic support
Ansible
NFS server
Ansible/pxe
Ansible/Wildfly
distribution
bug
distribution
release test
distribution
rfe
documentation
improvement
documentation
new
documentation
review request
documentation
update
meeting
need info
project
backup&restore
project
home server spin-off
project
LocalKDC
project
strengthening updates
status
in progress
status
on hold
status
pending activity
No milestone
No project
No assignees
10 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
server/tickets#190
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
@korora and myself @theprogram have expressed an interest in writing a "Beginners Guide to Fedora Server"
This comes off the back of @cstrauf and myself writing a "Beginners Guide to Fedora" docs/tickets#8 which is almost complete.
Please add to the ticket here items you think should be covered, user needs, necessary software.
As it is a beginners guide, we don't need to be comprehensive, but we need to get people to a secure place where that can have basic services up and running.
If you would like to assist with more than making suggestions, let me or @korora know and we'll send you the shared workspace.
@theprogram and I are going to work on this for F44, with an 'on time' release for F45. We will be bringing this up in the meetings as well for any input from members of the WG
Suggestions:
Generic fileserver (for hosting your media library, backups, etc.). Setting up NFS on the server, automounting the NFS share(s) on other devices, setting up automated backups using e.g. Borg & Vorta.
Plex server.
Torrent box. (For torrenting linux ISOs, of course.)
@pbokoc wrote in #190 (comment):
Propose adding Jellyfin/Emby to this as well.
Probably a basic section on Podman as well. (containers are life)
The following apps are very useful homelab software:
I'd throw in Home Assistant, which has a substantial community and therefore could be useful to many. I'm running it in a VM in Fedora 44: needs to be a VM rather than a container, to be able to use all the features of Home Assistant.
I am coming up with a working theme about how to present this.
My idea is to give people command line projects that will enable them to learn more about broader concepts.
Say learn how to install a game server, but really you learn about opening firewall ports.
So what we want is a list of projects that are both useful in themselves, but structured in a way that introduces key concepts of server management and deployment in each one.
Wea re going to write some more extensive ideas in AsciiDoc at https://cryptpad.fr/code/#/2/code/edit/gpZ4MNy4ikWUBBcNP37CpjCn/
Author a "Beginners Guide to Fedora Server"to Author a "Beginners Guide to Fedora Home Lab" 1 of 2 in Server SeriesPeter has some initial thoughts at https://hackmd.io/9FjTMT67Q_Cut0MgW91aZg
One thing that has been talked about a lot in the Server Matrix room is setting up network installation of Server instances.
This would require setting up dnsmasq (or dhcp/tftpd), reposync and http/https/ftp/nfs.
Once this is done, the next logical step is identity management (freeipa or ldap).
@eseyman wrote in #190 (comment):
Server instances or general PXE boot for other options than just Server I think a section on dnsmasq would be good
Hi all, I'd like to highlight a few points that could be useful to folk that are not hugely technical (like me) and are trying to tinker with a server installation. I apologise in advance if I'm stating the obvious.
OS partitions: the installer defines automatically a partition table where '/' (root) and '/var' are in the same partition. This could eventually lead to a 'disk full' issue and the system being unuseable, as containers and VM in '/var' keep growing in size over time. Setups with small storage are particularly at risk (I had this problem with a 128 GB drive). Solutions could be either for the installer to separate '/' and '/var' (ideally), or the user to be guided to create a custom partion configuration.
SSL certificates: a homelab would likely need SSL certificates to avoid 'not safe' warnings from the web browser. This can be done in variuos ways, for example with a self-signed certificates or with Let's Encrypt, but the former seems not effective for mobile access and therefore many use the latter. SSL certificates can be managed very easily with Nginx Proxy Manager in its GUI (which is what I do), but there are many other applications for this. For the domain part there are services like duckdns.org or dynu.com that offer free dynamic DNS services that are pretty straightforward to setup. They give you a free subdomain for your server or you can link your own domain. These services are vital so that you don't expose your home IP publicly.
External access: some services of a homelab would likely need access from outside the home LAN (files in Nextcloud for example). To avoid exposing the home IP address there are free services like Tailscale and Twingate that offer a very simple way to setup a secure connection between systems, including mobile.
System updates: the importance of keeping the OS updated is probably more critical on a server, as you don't get KDE or Gnome to remind you visually that there are updates to be done (I like how KDE shows me a red warning in my taskbar for important updates). There is a warning icon in Cockpit, but perhaps there should be a more forceful or 'push' warning for critical updates like email, system message, etc.
@andrefed wrote in #190 (comment):
I try not to get involved with installation issues but my understanding is that you are supposed to create partitions for each service (i.e.: /var/lib/mysql, /var/lib/pgsql, ...). See our post-installation checklist for more information.
We've discussed this subject several times over the years but there are simply too many options for us to handle them all
We recommend using dnf5-plugin-automatic to automate updates installation.
@andrefed In addition to the link eseyman provided you may take a look at
In essence, we generally distinguish (for professional usage) between three options:
And within that, create logical volumes for services, users, etc. as explained in topic 2 – this is for administrators who are extremely cautious and wish to store system and user data as independently and unaffected by one another as is possible on a hard drive.
We may have to simplify this for home server, e.g. by using btrfs, but stick to the principles.
Here are my thoughts about this so far:
Supply chain: The demonstration is more impressive for Fedora the less users have to reach outside of the Fedora ecosystem to solve their problems. This needs to be balanced by using the tools people actually want to use, of course. Jellyfin is not in the Fedora repository, nextcloud is, Immich is not, forgejo is.
Deployment model: Are we targeting devs that are new to Fedora? Users new to Linux and ops entirely? Fedora packages enough to get Kubernetes going, which can then be managed with OpenTofu, but that means a lot of abstraction. The model I've been exploring focuses on systemd and podman, which has a simpler mental model. systemd units have a surprisingly large surface area of configuration, but you kill two birds with one stone by teaching about systemd and setting up the homelab at the same time. That leaves Ansible as the option for deployment, which leds into:
Automation: I recommend either choosing an automation solution upfront, or not choosing one at all. I've seen a lot of tutorials that explain how to set up everything manually and then tack on a discussion of opentofu or ansible at the end, and it's like "it's too late!" We either need to make a decision for them about workflow, or not mention it in the tutorial.
Ingress/certificates: We could probably cover a lot of use cases by assuming certbot for certificate generation and going over an HTTP and DNS challenge setup. If we don't talk about it, we're leaving people to fend for themselves in an area that's really messy and will lead to people dropping off the tutorial. I like to prescribe a happy path in situations like this. certbot is in the Fedora repository.
External access: For a data point, I've been using Cloudflare Access to expose a public endpoint that hides my home IP and puts a login in front. It likely wouldn't cost anything for this use case but you'd need to own your own domain and set up Cloudflare. Maybe external access is a topic for a future tutorial since it introduces a lot more risk than just running behind the firewall.
Dashboard: A lot of people I know are not familiar with Cockpit and don't know that it exists. This is a really cool thing that's unique to Fedora, and it's worth highlighting and specifically telling people to install it. It's an easy and fast way to get a dashboard going.
Installation: If we target a single node setup, it's probably better to walk people through the installation rather than walking through a kickstart or something like that. Can take screenshots of the installation in QEMU/KVM or use HDMI capture on a real system.
Backups: Anyone who wants to use their homelab for anything more than a toy is going to be really anxious about backups. restic seems like a good solution here and it's in the Fedora repository.
Drive encryption: Whole drive encryption is important and confusing. You can do a TPM-backed setup that is encrypted but can reboot unattended, but it's not obvious at all how to achieve. I don't know how far we want to scope this for "serious" homelab users or just for people playing around with the idea.
Secrets management: Similar to drive encryption, systemd supports TPM-backed secret management with systemd-creds. It'd probably be worthwhile to touch on this instead of telling people to write credentials to text files.
@brettweir
I really like the wasy you are thinking systemically here. This will make for a readable and structured guide.
I really like keeping to Fedora Repos as much as possible. Maybe we can do that, and then go on in another section about containers?
I do think we need external access, but I'mm not hot on Cloudflare for reasons that I wont go into here.
Drive encryption is important. Its not really difficult with the right instructions.
@brettweir wrote in #190 (comment):
A TPM-backed solution is interesting, but it's 1) extremely difficult to set up and 2) not really all that good of a security measure if someone steals the whole machine (such as an older laptop converted into a homeserver).
What if we pushed people towards a network-bound disk encryption (NBDE) setup instead? This is how I do things at my home. I have a Raspberry Pi 4 running Fedora whose only purpose is to run the
tangserver. It sits in a locked cabinet in my basement and as long as my desktop and laptop are on my home network, they have an unattended boot. If I take my laptop elsewhere or my RPi is unreachable for some reason, I can fall back on the LUKS password I used when the system was initially set up.What I'm envisioning for Server/HomeServer is the ability to easily "cluster" them so that if you add a new Server to your network, we can have a little registration app that you can point at an existing Server on the network. It then enrolls the new Server as a clevis client of the existing server and (optionally) as a clang server for the existing server as well. The net result would be that as long as the other machine was available on the network (at a known static IP), the other one can boot unattended. In the event of a site-wide power outage, you'd just need to bring the first one up with the LUKS password manually.
There are some technical details to work out when the number of servers gets to be more than just a handful (100 servers, each checking up to 99 others at boot gets messy so we'd probably want to come up with some cluster topology ideas), but what do you think about the general idea?
Something I've also been meaning to do for a while now (but never seem to find the cycles) is put together a minimal bootc disk image for RPi/IoT-like devices that we could also distribute, so if people wanted to buy a cheap device and lock it in a drawer for this, they could do that too. Cockpit already has native support for enrolling a LUKS partition with a tang server.
(Clevis also supports NBDE operation where "at least X tang servers out of these Y possible ones must respond", for the more security-sensitive users.)
And now as I finish writing this missive, I realize I should probably turn it into a separate ticket to be considered. So I'll do that too.
NBDE is a super interesting idea. For this Beginners Guide, I would like to go with something simpler, if less secure.
We could introduce NBDE in a future guide, or as a Server Doc that we link to.
Hey everyone! As requested in our Matrix chat, here is the centralized link to the initial technical documentation draft for the pre-installed Uptime Kuma monitoring service and Telegram alert pipeline integration:
https://hackmd.io/@rafaelmcruz/Hkvyzullfe
Feel free to review it. As a next step, I plan to experiment with a non-containerized setup to evaluate the service running directly on the host. I will keep adjusting the user-specific tasks as we move forward into the server image testing phase!