Setting up a Fedora Nextcloud server, needing help

Ask Fedora
, ,
1

Hey people!

I want to setup a Nextcloud server and decided for Fedora Server, after hearing that Nextcloud can depend on a lot of system packages for some tools, making CoreOS a pain (?)

I dont fully understand it, are Docker containers completely isolated, running their own libraries, dependencies and apps? How can they depend on for example RPM Libreoffice, clamAV or others?

1. Problem with Anaconda & Partitions

I want to use a custom partition layout

  • 1GB /boot
  • 16GB swap
  • 50GB /
  • The Rest /var

I think that should be the option to have Docker, Nextcloud and all seperated from the system, right?

I want to encrypt as many partitions as possible, but cant do it. I chose “BTRFS” instead of LVM, as this is needed for using BTRFS partitions it seems.

(The Anaconda installer is also nearly nonresponsive, really weird. Is my old Laptop total trash?)

When I choose “standard-format” and the partition scheme uses xfs by default, I can encrypt the partition. But this doesnt seem to work for BTRFS.

I am currently trying the “advanced extended installer”, which just seems like a regular partition manager (why is that not default???) , but still the same problem.

What should I create? LVM Group, “BTRFs” or seperate Partitions?

I just went with only creating Partitions, / and /var are encrypted with the same password, but I had to enter it twice and worry this will be a problem.

2. Server tools?

Is everything as manual as on Destkop? Or are there easy autoupdates, automatic reboots?

Is there a way to do these reboots while not needing to enter the LUKS password?

I also made a little project collecting ways to auto-shutdown the laptop once power connection is disabled, for security and data integrity.

3. Experience

I added my user to the docker group and set its directory as /var/home/server (as I know from my Kinoite Desktop), so its on the same “data” partition.

Booting only requires a single password, which is already looking good.

2

Partitions are seen as devices and each must be unlocked separately when encrypted separately.

Servers would be disastrous to manage and have consistency if there is any form of automatic updates or reboots involved. The idea of a server is stability and that it just runs silently and unchanging unless the admin makes a change and/or reboots.

An encrypted file system must be unlocked each time the system boots to access it. That is for security purposes.

If one wants the convenience of not needing to perform the unlock step then what good is the encryption? An automatic unlock would be effectively the same as never having the file system encrypted.

The trade off is security of encryption with the cost of manually unlocking the device.

1 Like
3

As someone who is involved in the Fedora CoreOS working group and who runs Fedora CoreOS I disagree. We enable automatic updates by default. Systems update every two weeks. If something breaks, roll back and report an issue.

Now, depending on who you are, you might not like automatic updates. That’s fine. It’s just an option, but one that I encourage because over time your systems will be more up to date (with hopefully security fixes applied) if it doesn’t require someone manually triggering the update.

This is true, but there are other options like network bound disk encryption. it all depends on your threat model what is acceptable and what isn’t.

2 Likes
4

Does this mean that the server automatically updates and reboots every two weeks?

That seems contrary to most standards in that the reboots may (and probably do) impact a large number of users who depend upon 24/7/365 access for whom reboots must be scheduled in advance to avoid customer dissatisfaction.

Smaller servers that do not serve large numbers of clients or those larger environments with HA backup configuration may not require the continuous operation of every system but many do.

Then again, we are discussing fedora which is constantly changing and not the strictly stable environment like RHEL servers.

1 Like
5

If you want encrypted partitions, you need an LVM (using LUKS for encryption) and you can have physical volumes (PV) for /,/var, swap with whatever file system you want (xfs, ext4, btrfs). Native btrfs encryption is disabled in Fedora, I’d stay away from it.

You can use dnf-automatic and configure it to only notify, or download, or download and install system updates. You can also configure a reboots after updates.

Podman is the new docker.
see: Docker and Fedora 37: Migrating to Podman - Fedora Magazine and You searched for podman - Fedora Magazine

Opinion:

If this was my system, I’d go with xfs filesystem and deploy nextcloud in a container using podman. That way you only have to backup the nextcloud “volumes” (nextcloud-db, nextcloud-data, …) and you would be able to very quickly redeploy the server on the same machine or any other machine.

1 Like
6

Hm, at least security updates should go automatic I think. But these are often backported, so not existent in Fedora right?

I would like to have some way to reboot from the live system, without needing to enter the password. But only for this reboot, and only possible to initiate while logged in.

7

Thanks! I will use Podman in that case. Used encrypted LVM and btrfs, but that should be fine.

8

I guess I will enable daily updates at night, and only reboot manually for kernel updates.

Thinking about that, coreOS with LUKS must be a pain for servers!

Would there be a better option, in danger or stolen hardware, could you have a regular system with just login and encrypt files only for Nextcloud or something? Not talking of Cryptomator for the Clients, as this breaks collaboration.

9

Yes. The servers reboot every two weeks, but you can configure the servers to only reboot for the update during a maintenance window or have it be controlled via an external locking mechanism.

In larger environments users may be using an orchestration platform on top (think Kubernetes) and drain workloads from updating nodes before they reboot for the update.