Server Linux Distro

Sorry for the repeat question (I asked this on the PG Matrix room, but am looking for more opinions). I am looking for a Linux distro to use on a self hosted server. I currently use Arch Linux on my server, but it is a bit too much manual work unfortunately and I don’t have the relevant expertise to micromanage a server and ensure it is secure on all fronts.

What I need From A Distro:

  1. Secure out of the box (that means good default apparmor or SELinux configuration and decently hardened setup)
  2. Free (and open source, but presumably that is a given since the Linux kernel is under GPLv2)
  3. (Relatively) Easy to learn with good documentation
  4. Easy to set up RAID

Distros Recommended Thus Far

  • Rocky Linux
  • OpenSUSE
  • Ubuntu

If you’re familiar with Arch, even on a server use case, the closest one would be openSUSE Tumbleweed. It passes all your needs from a distro.

But I have no idea with either AppArmor or SELinux. openSUSE TW uses AppArmor, by the way. Since it’s a corporate distro, I would assume their security model isn’t too bad.

Other than openSUSE TW, I would recommend Ubuntu. It’s a no-brainer on my servers. I even plan to move to Ubuntu on my main desktop soon.


For me, Arch is best to be used in a container, as you already skipped all the hassle of setting it up on bare metal. It’s like I wouldn’t put Arch on bare metal, the same with I wouldn’t put openSUSE in a container :joy:

2 Likes

I’d recommend Fedora Server, that’s what I usually use. It checks all 3 of your boxes, so should be a good fit. I also love Cockpit and other features it has. Overall, good experience.

2 Likes

I’d strongly suggest you add OpenSUSE MicroOS to your shortlist of of distros to consider, especially if this will be a container server. This will likely be my next server OS. Like you, I prioritize about “easy to learn, good docs”, and unfortunately MicroOS falls short in this regard, but while the community is small, they are quite helpful and active.

My “(not so) shortlist” of server distros I consider for my own purposes:

Ubuntu Server – A very reasonable default choice in many contexts. Reasonably good security ootb, versatile, widely used, large community, huge body of resources and documentation, decent sized professional team behind it, and because almost everyone has used a Debian based distro (usually Ubuntu based) at some point in their linux journey, it is familiar to most people, and easy to find support. Ubuntu Core is also worth considering for some use-cases. As far as server OSes go, moderately beginner friendly.

CentOS Stream – (or RHEL/Alma/Rocky) along with Ubuntu and Debian, RH server distros are among the most popular and possibly best documented server distros around. Reasons to consider this family over Ubuntu or Debian: a preference for selinux, a preference for Red Hat (for example, if you plan to use podman containers, there may be some value in using a distro developed by the same organization backing podman).

Debian – Good old dependable Debian.

Alpine Linux – Ultralight and Minimal

Specific tools for specific jobs:

  • OpenSUSE MicroOS – Immutable/Atomic distro, design philosophy of “do one thing well” (in this case, the ‘one thing’ is being a somewhat minimal container server (podman/docker host). Reliable, predictable, easy to rollback.
  • Proxmox – A hypervisor based on Debian, useful base OS for hosting VMs and Containers.
  • TrueNAS – A popular distro for DIY NAS builds, very beginner friendly from what I’ve heard, and makes docker accessible to less experienced people (supposedly). I don’t recall whether this is based on Linux or BSD.
  • OpenMediaVault – Another distro geared towards NAS use-cases. This OMV is based on Debian. Like Truenas one ofthe distinguishing features is relative beginner-friendliness and allowing many/most things to be configured through the WebUI.
  • Ubuntu Core – This distro is designed for embedded systems or IoT. It is build from the ground up around snap, and security, resilience, and low/no maintenance are some of its design goals.
4 Likes

I have been looking at MicroOS for a while now. But it does not support Snap, which could filter out some official software that would otherwise be usable on it. Unless one is willing to compile software on their server, which could destroy the ease of use of the server, thus potentially running on much outdated software if not managed properly stack their software on the OS base, which would destroy the benefit of using an immutable OS.

Other than that, if secure internet connection is required on the server, it’s not easy to install VPN in a container, especially, in an unprivileged container. If privileged container is required, the only thing one would get from this kind of OS is complication with little to no security benefit compared to mutable OS. AFAIK, among the reputable VPN providers, only IVPN is available on Snap, which works on the immutable OS IF the OS in question supports Snap. Unfortunately, MicroOS doesn’t.

At this time, I see zero benefit of running MicroOS. I can pretty much do the same on TW, i.e. only use apps via container, Flatpak, and even on Snap if I have to.

Ubuntu core will only run Snap, which would filter out many of the official apps. This is another attack surface. See: a fake Exodus wallet app had entered Snap store, the app scammed 9 BTC out of an investor. This kind of OS can’t protect the users in this regard. It only benefits a carefully planned use case. It’s not for everyday users (yet).

I’m a bit new to this, why would you need a VPN on a server, wouldn’t that mean connecting to it wouldn’t be possible?

1 Like

You can connect to your server just fine even with VPN connection, as you can allow local connection/split tunneling. But this again, the last time I checked, IVPN Snap version doesn’t support split tunneling :joy:

Using immutable OS on your server without carefully planned/fixed use case, is nothing but troubles after troubles, some would even lead you to attack surface. I would recommend against the idea.

If I wanted a host OS for snap packages, I’d strongly preference Ubuntu, and in particular I’d consider Ubuntu Core. One of the OG immutable linux distros, but doesn’t get a lot of attention, probably in part due to snap, and in part because it made its splash before most linux users had interest in immutable distros.

It has a lot of design goals in common with MicroOS / Fedora IoT / CoreOS, but whereas MicroOS is really focused on being a container host for Podman containers, Ubuntu Core is designed with snap in mind.

This kind of OS can’t protect the users in this regard. It only benefits a carefully planned use case. It’s not for everyday users

Yes, that is an important thing to understand about both MicroOS and Ubuntu Core. They are not general purpose distros, they are designed for a specific use-case, they are designed to do that one thing well, but they are not designed as general purpose distros for all use cases.

edit: you’ve said some things (mentions of flatpak for instance) and referring to apps throughout your comment, that makes me think that you may be thinking about this in the context of a Desktop OS not a Server OS the considerations will be different for these different use-cases

4 Likes

It doesn’t have to be carefully planned, so long as you are using it for what it is designed for: being a low/no maintenance, reliable, container host that you modify as little as possible.

If you are trying to do exotic things with it, or do desktop-y things, you are most likely using the wrong tool for the job.

edit: and I do agree with what you said in general, that with immutable distros (particularly on desktop) you are better off if you think through your use-case, and make sure the software you need is not going to to complicate things too much. VPN clients in particular can complicate things, but this seems like more of a desktop issue not so relevant to servers.

2 Likes

I don’t know about Fedora IoT or CoreOS, but Ubuntu Core has a valid reason to be Snap only, as it doesn’t even support .deb packages. While MicroOS still supports .rpm packages through transactional update, along with Flatpak, etc. but just doesn’t want to support Snap. In this regard, I think Ubuntu Core and MicroOS are quite different, i.e. I don’t think it’s questionable for Ubuntu Core to not support Flatpak, but it’s questionable (in terms of users benefit) for MicroOS to not support Snap.

Yes, it’s true :joy: But some desktop apps are also usable/preferable on the server, as I mentioned VPN apps, of which also have CLI as a proof of the server use case. Sure, you can also use WireGuard or OpenVPN config files, but that limited the functionality you would get by using the apps’ CLI.

Edit: If your server is connecting to the internet at all, presumably you would want to have your server connection to be private from your ISP, the same way you want to be private from ISP on desktop, mobile, etc. For example, you can use headless Transmission on your server, which would required VPN with port forwarding to work reliably. This would depend on your usage.

1 Like

Id recommend a distro that has the latest bugs security from the below url. At least thats what im doing. I really dont want to run a server with old software, exposed vulnerabilities.
openssh packaging badges - Repology

1 Like

I think you may be misunderstanding either the use-case for MicroOS or the use-case for Flatpak. Flatpak is specifically intended for primarily GUI applications on a Desktop computer. MicroOS is designed to be a server OS, specifically a container server.

From the Flatpak FAQ:

Flatpak is designed to run inside a desktop session and relies on certain session services, such as a D-Bus session bus and, optionally, a systemd --user instance. This makes Flatpak not a good match for a server.

Flatpak and Snap is just outside of the scope of what MicroOS is intended to be. And criticizing it for not supporting these things is somewhat akin to critizing a screwdriver for not being a hammer. MicroOS is a specific tool for a specific job.


If your server is connecting to the internet at all, presumably you would want to have your server connection to be private from your ISP,

You may want to do this in some contexts, But a GUI desktop app is not a typical or common way to do this on a server. There are various other ways to accomplish this that don’t rely on a commercial VPN’s desktop app.

you can also use WireGuard or OpenVPN config files, but that limited the functionality you would get by using the apps’ CLI.

I don’t believe these options are necessarily more limited, at least not in the context of features that’d matter on a server, it is just more complex/steeper learning curve. Commercial VPN clients are often just simplifying (from a desktop end-user perspective), the configuration of various pieces of software already present in Linux, which can be great in terms of simplicity/ease of use for a desktop user, but doesn’t really introduce fundamentally new capabilities. At least that is my experience.

I am pretty clear as daylight about my critique to MicroOS as a server OS, as we’re talking about the server use case here. By not supporting Snap, it can only mean that the server users would lose their benefit one way or another, since, unlike Flatpak, Snap also focus around server use. In fact, unlike Flatpak, you can safely say that Snap was designed to be the server first packaging format that just happened to be useful on the desktop.

As you suggested MicroOS for server use, you probably are the one who either misunderstand the OS use-case, or Snap use-case. Between Snap and Flatpak, MicroOS should support Snap if it positions itself as a server centric OS. But due to political or whatever reasons, it doesn’t.

I am not sure if your statement regarding Flatpak aligns well with what MicroOS actually is, as Flatpak is the most preferable way to install apps on MicroOS, according to its developer: Portal:Aeon - openSUSE Wiki

What’s preventing you to use CLI instead of GUI providing the app offers it? Also, you can RDP to your server, and there’s nothing wrong with it. Most people would probably prefer to RDP to their headless self-host or VPS server.

There’s nothing wrong if you prefer to do it the hard way. But you can’t define/limit that everyone else should work on their server the hard way. It has never been limited this way. Otherwise, there would be no tool to VNC/RDP to your headless server.

Probably wouldn’t list this. The only real reason for using this is when you need binary compatibility with RHEL for some reason.

There is also Fedora Server which is a reasonable option.

So would your recommendation be Fedora server over Rocky Linux and co? Why is Fedora better in your eyes than the alternatives? Sorry for all the questions, I’m just trying to learn more.

Fedora is upstream of Rocky Linux. Gets patches first, then Rocky and co have to apply it to their downstream forks, which WILL take more time.

you probably are the one who either misunderstand the OS use-case

I am not sure if your statement regarding Flatpak aligns well with what MicroOS actually is, as Flatpak is the most preferable way to install apps on MicroOS, according to its developer: Portal:Aeon

You are talking about (and have linked to) A Desktop Operating System (OpenSUSE Aeon). That is not what is being discussed here.

Flatpak is the right tool for the job in the case of the distro you linked to (Aeon) but the distro you linked to is not MicroOS noris it a server distro. Aeon is a desktop operating system so it makes sense to use a desktop focused package format in that context.

  • MicroOS is an immutable server distro, designed to be a minimal container host.
  • Aeon is an immutable desktop distro with Gnome.

But you can’t define/limit that everyone else should work on their server the hard way.

I am not defining or limiting anything. I am simply trying to explain to you the logic of why the developers have made the choices they have made. It is up to those developing a voluntary, free and open source project, what they want the scope and goals of that project to be. You can try to use or modify it however you see fit as a user, but developers are absolutely in their right to define a set of goals or a specific use-case they want to focus on.

It seems like you are looking for an ‘everything and the kitchen sink’ type general purpose distro compatible with the widest range of software formats and use-cases including even desktop stuff, and that just isn’t what MicroOS is designed to be, in fact that is almost the exact opposite of what MicroOS is intended to be. MicroOS is meant to be a minimal, and minimally modified, low maintenance, container host.

There are lots of other distros that would be a much better fit for what you are looking for that would be a more suitable fit for you. Diversity is the beauty of Linux, different tools for different jobs, we don’t want every tool to be a hammer or every tool to be a screwdriver, we don’t even want every tool to be a multi-tool.

2 Likes

Incorrect. Rocky Linux is a 1 to 1 clone of RHEL. Fedora does not feed into Rocky or RHEL in any way as they both serve different purposes.

Source?

There’s no single word about “server” use on its official page. And the fact is that, you need to download MicroOS base ISO in order to install Aeon (formerly MicroOS). I don’t think it defines itself as clear as you’re trying to convince here that it’s specifically designed for server use case, which is not true.

The same way that Tumbleweed is categorized on the official download page as both a desktop OS and a server OS.


But the point of the discussion is not about whether it’s a server OS. Since you suggested it to be used on the server, even though it lacks some aspects as a tool that’s meant to be used on the server, e.g. Snap, containerized workflow that would add complexity with little to no benefit (VPN use case), etc. You keep telling me that I critique it for desktop use, but I didn’t. You keep telling VPN apps are only for desktop use, even though the devs/providers specifically add CLI into their clients.

Except for the fact that there’s no MicroOS dev that define the OS as a server OS. It has always been around the containerized workflow. That’s all. The server part is what you define it yourself, not the dev.

Would you define Tumbleweed to be a desktop OS too, when openSUSE itself says otherwise?

Source?

Sorry, but… openSUSE in general has always been (or at least, trying to be) a multi-tool :joy:

I don’t have a dog in this race but just because something has a CLI interface doesn’t mean it’s designed for server usage; CLI interface more implies automation and scripting than specifically server

Also to bring it back around to the actual topic instead of semantics arg #348574635876, I’d just go with Ubuntu and take advantage of the Ubuntu Pro live patching for server use unless you have more specific needs (like what @dngray said about Rocky and RHEL binary compat, for example)

2 Likes