Fedora Server
It’s that time of the year again – spring.
Where normal people clean their home, and nerds clean out their IT-infrastructure.
My unfortunate victim this year is my old Nextcloud server. A dual-core machine running Ubuntu 20.04.
Even though everything works fine with just two cores, running on eight gives the web UI a much more snappy feel and makes use much less frustrating! So I decided to go for the upgrade.
But because I also recently switched from Ubuntu as my daily driver to Fedora, I think I’m going with Fedora as the OS for my server as well.
Install
The installation is pretty straightforward. You download the Fedora Server ISO from here, attach it to your machine, and set the machine to boot from it. If you have a VPS you upload it to your hosting provider, or if you have physical access to the machine, you burn it to a pen drive and attach that. So far nothing unusual …
The graphical anaconda installer is easy to navigate, and I won’t go into detail what settings you could or should apply, but there’s official documentation available.
Connect via SSH
The system should come with OpenSSH Server running by default, so we just ssh-copy-id fynn@cloud our credentials over (I have a corresponding entry for cloud in my ~/.ssh/config), and then ssh fynn@cloud into the machine.
Ideally, you already know the fingerprint of the host key (you can find out with ssh-keygen -l -f /path/to/key
on the server after the installation), so that you can now compare it against the host key ssh
was presented by the remote machine.
If you do not check this, you will be vulnerable to MITM attacks.
From this point on, pretty much everything needs root, so we can just go ahead and sudo -i
, but be careful what you type from now on.
We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility.
You probably know the drill …
Once logged in, we dnf install vim
(or just use nano
if you’re a s), so we can edit documents more easily, and then configure sshd
with vim /etc/ssh/sshd_config
.
I like to put in something along the lines of:
HostKey /etc/ssh/ssh_host_ed25519_key PermitRootLogin no LogLevel INFO MaxAuthTries 2 PubkeyAuthentication yes PasswordAuthentication no KbdInteractiveAuthentication no Subsystem sftp /usr/libexec/openssh/sftp-server AllowUsers fynn
Another nice thing to do, is to regenerate the host keys, or rather the ed25519 one, and scrap the rest.
You can achieve that with rm /etc/ssh/ssh_host_* and ssh-keygen -t ed25519 -N '' -f /etc/ssh/ssh_host_ed25519_key
. Take note of the key fingerprint, so you can compare on subsequent logins, e.g. mine looks like this: SHA256:h+CQfgJ7mLHafGZCHBCsr3oBNKMGAeXPcX/c4O0icrk root@cloud
. Sharing these fingerprints is unproblematic and helps verify, that we’re dealing with the right machine, and not an impostor.
Now run systemctl restart sshd
to reload the sshd_config
and host keys and finish the sshd setup.
Setting up DNF-Automatic
Install the tool with dnf install dnf-automatic
.
We can edit the file /etc/dnf/automatic.conf
, set the ‘apply_updates’ option, and enable the systemd timer for dnf-automatic, or alternatively we just enable the ‘install’ timer with systemctl enable --now dnf-automatic-install.timer
One not so great thing, especially coming from apt as my package manager, is that there is no good way for dnf-automatic to automatically reboot if updates necessitate it. So I decided to just add a cronjob to reboot every week on Wednesday 3AM, because then I’m usually not using it.
For that, we have to first dnf install cronie
and then crontab -e
, after which we add a line like so 0 3 * * 3 /usr/sbin/reboot
. If you want to time it differently, maybe check out this helpful webpage
Extend Root Partition
For some reason (probably me being incapable of using the anaconda installer properly) I get a root partition, that is only about 15G in size. You can check if you are also affected by this for yourself with lsblk
.
Because of that, I manually resize the LVM partition to take up all available space with lvextend --size +100%FREE /dev/mapper/fedora_fedora-root
. And then I expand the filesystem to make use of the added space, by running xfs_growfs /dev/mapper/fedora_fedora-root
.
These commands are specific to my issue and might not have any relevance for you, so don’t just run them and expect your system to survive that.
Disable Grub Menu Timeout
Since this is a headless server, that only runs one OS, I’d rather have the system skip the grub menu, instead of showing me boot options, that will always stay at their default, so I set the menu timeout to zero.
You can find the Fedora specific documentation here, but this should work for other distributions too.
Basically, you edit /etc/default/grub
and overwrite the old config with grub2-mkconfig
. The exact commands for my use case are sed -i.bak 's/GRUB_TIMEOUT=[0-9]*/GRUB_TIMEOUT=0/' /etc/default/grub
and grub2-mkconfig -o /boot/grub2/grub.cfg
, but take note, that the specific path of the grub.cfg file can change depending on the system (specifically depending on wether it’s an EFI or a BIOS system).
Firewall Rules
Because the hosted Nextcloud instance should be accessible over the internet, we need to open a few ports on the host.
Depending on your approach, you might want to do that later, after setting up Nextcloud.
First we reconfigure firewalld
to use the public zone by executing sed -i.bak 's/DefaultZone=.*/DefaultZone=public/' /etc/firewalld/firewalld.conf
, then add all needed services with firewall-cmd --permanent --zone=public --add-service=cockpit --add-service=dhcpv6-client --add-service=http --add-service=https --add-service=ssh
, and finally systemctl restart firewalld
to make the changes appear.
Setting up Nextcloud
Now we are ready to install Nextcloud!
I like to use the snap version, because it works well, is easy to set up and administer, comes with a few nice tweaks, and just generally makes dealing with Nextcloud a breeze.
Nextcloud is available in the Fedora repositories, if you want to, you can try your luck with those.
So to install this snap, we need to install snapd with dnf install snapd
and then we snap install nextcloud
.
Assuming, that the relevant ports are open, and you have set the DNS records pointing your domain name to your machine, you can now nextcloud.enable-https lets-encrypt
and either head to your domain to set up your admin account, or import the backup of your old snap instance with nextcloud.import -abcd backup_dir
(export with nextcloud.export -abcd
, should write the backup directory to /var/snap/nextcloud/common/backups/
), or maybe even just use nextcloud.manual-install
, which would be preferable to doing it via the browser, because imagine someone’s faster than you and sets up their own admin account.
Once we’re done with that we can snap connect nextcloud:network-observe
, to allow the System app to do better reporting for us, and to make sure, that the Office app runs smoothly later, we should also throw in a dnf install fontconfig
, so that the inbuilt office suite works.
I personally like to set snap set nextcloud nextcloud.cron-interval=5m
and snap set nextcloud http.compression=true
as well.
And finally, we set snap set nextcloud php.memory-limit=16G
. Total overkill, but flaunt it if you’ve got it.
That’s it. At this point, you should have a running Fedora server with a preconfigured Nextcloud instance running on it.