What is the problem with using Fedora for servers?

Solution 1:

There's nothing that dictates that Fedora is unsuited for use on servers, nor is there anything that dictates that "server distros" is the only choice for servers. It depends on your particular needs.

What you may gain from using the "server distros" is:

• long term support
• stable API's (little to no version-upgrades of libraries and applications)
• backported securityfixes and bugfixes
• paid support

My main "complaint" for the server-distros is that software/libraries tend to to be somewhat old, and the range of supported packages is much smaller than community driven efforts.

I.e. the long term support and the non-changing API's is something that commercial software vendors love, they won't have to rebuild their application for the newest libraries because the API suddenly changed. They can develop for Vendor Y Release X and know that this platform will be around for several years to come.

Solution 2:

I thought I didn't have anything to add to this, but after having run Fedora in production for nearly two years - for my very important Zabbix monitoring system! - it seems I do have a couple of things to say.

First, it was not my first choice. Typically for anything even vaguely important I will choose CentOS/RHEL for the long-term stability benefits that these distributions provide. However, for this particular deployment I absolutely required features in Zabbix 2.0, while the EPEL repo only provided 1.8. (EPEL now has Zabbix 2.0 and 2.2 packages in addition to 1.8, though it did not at the time. If it had, I would never have tried this.)

So the tradeoff here is: Fedora has the latest software, but its releases are on a very short 13-month lifecycle, with new releases made about every six months. This means I had to plan for a maintenance window to upgrade Fedora twice a year, in addition to the usual periodic installation of updates.

For a monitoring system which is supposed to be keeping track of everything else, it's vital that such maintenance periods be as infrequent and as short as possible. With the requirement to upgrade so frequently, this would usually rule out such a distribution, but remember that I had more pressing concerns; it would be useless without the features I needed. So this is a tradeoff I made with (nearly) full knowledge of the consequences.

Not long ago, I did the Fedora 18-19 upgrade on this server, using Fedora's new fedup upgrade tool. I planned for a two-hour outage, with another two hours to possibly deal with any of the monitored services that might have died and that fact missed since Zabbix was down.

The actual service downtime was 11 minutes. That's from the time Zabbix stopped before reboot to the time it was back up and monitoring services after the completed upgrade. I did not realize that the downtime would be so short! I was expecting much more trouble, even though I know from experience that significant upgrade problems are uncommon with Fedora. (And it's been improved further: When I did the Fedora 19-20 upgrade, the complete downtime was an amazing six minutes. The same time for 20-21.)

This service will almost certainly be moved onto RHEL 7 when it becomes available. After this experience I'm much more confident in Fedora as a server and now intend to keep it, even with a major upgrade every six months. Moving off to RHEL would be much more disruptive, and might limit me in the future, because of the following:

It's unfortunate that Red Hat has such a long time between major releases; a similar delay between EL5 and EL6 led me to actually put an Ubuntu installation into production, something I am still kicking myself over to this day. (For that system, I considered Fedora, but strangely it did not have the software I needed packaged at all at the time, despite an older version being in EPEL.)

One "problem" no one mentioned about running Fedora is that you will see many new things, both large software projects and tiny enhancements, well in advance of their inclusion in RHEL. So when you go to manage your RHEL/CentOS systems you will miss them. For example, Fedora has a large number of bash completions which aren't yet in RHEL by default; one notable one is tab completion for package names in the yum command line.

So, it's certainly possible to use Fedora in production, so long as you can accept the tradeoffs:

• There are no support contracts. You must have in-house expertise sufficient to manage the server and its services and deal with any issues that may arise; only community support is available, and there are no guarantees there. RHEL experience helps, as they are quite similar.
• You must have a maintenance window to upgrade at least annually. Though every six months is better; if you upgrade annually you will have to upgrade two releases at once, which doubles the number of potential issues you will have to deal with at 3 am.
• Updates may bring new versions of software, which you will have to deal with; however these will be point releases and not major versions. In rare cases significant new functionality might be added (e.g. BZ#319901). Typically, though, software remains on the same version number throughout the life of the release, with fixes backported; only some packages (such as PHP) track upstream point releases.
• While there's no significant difference in the pace of security updates, they may not always be isolated from bugfix updates (again, such as PHP). Whether this is a problem depends on the service you are planning to run.

All things considered, Fedora is still not my first choice for a server platform, and probably never will be. (Though I've been a happy Fedora desktop user for its entire existence.) In the case where you absolutely need more current versions of software not available in a more "enterprisey" distribution, and you can accept the tradeoffs, then there is nothing wrong with using Fedora.

Finally, since you asked specifically about security, a few words on that.

As previously noted, there's no real difference in the pace of security updates between Fedora and any other distribution. Fedora packagers make special efforts to stay close to upstream and get these sorts of updates out as quickly as possible, sometimes even before the upstream project does.

Like its enterprisey big brother, Fedora also ships with a fairly locked down security configuration: services (except ssh) ship off by default; the default-deny firewall is enabled by default for both IPv4 and IPv6; SELinux is enforcing by default. In addition, Fedora is hardened in a number of other ways.

On the other hand, you get to see new security technology very early; one example is the recent introduction of FirewallD, which still isn't quite ready for prime time, though switching back to the previous firewall is easy.

Solution 3:

It's more about stability and rate of change than security, per se. Fedora is a platform for Red Hat to roll out new features and applications to validate their relevance, provide a platform to experiment, and work out integration issues.

That is usually not what you want a server to do -- you generally want a server to perform a function in the most stable way possible.

Depending on what you are doing, Fedora may be just fine. If you're developing Linux desktop apps, working with the bleeding edge may be desirable. Likewise, if you're working on a semester-long school project or some other limited duration project where the high tempo of changes isn't a concern, Fedora is fine as well.