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.
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.
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
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.
systemctl restart sshd to reload the
sshd_config and host keys and finish the sshd setup.
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
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
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
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.
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).
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.
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.