Fedora Server Installation Guide
A good and sustaining server installation benefits from some plannings ahead. As the saying goes, planning ahead will substitute for many a mishap. This section provides basic guidance. Having done various decisions and some preparations, the installation itself is an easy step-by-step procedure, selecting one of various available methods.
Fedora Server Edition uses the Fedora installation program, Anaconda, as several other editions and spins.
While Fedora Server Edition uses the same rpm package repository as all Fedora editions, the composition of the packages and especially the defaults of the runtime environment are different and more tailored to a server install. Among others, the most important of these defaults are outlined in the following sections, and can, of course, be overridden.
The installation planning depends on the details of the target environment. The installation program, Anaconda, can install on 'bare metal' directly on server hardware as well as in a virtual environment on a virtual machine (VM). While both targets are similar in many ways, they also differ in key technical details. As an example, on both targets, the storage organization is a very important planning item, but on a virtual machine the system administrator does not need to worry about a RAID system.
This chapter and its subchapters cover general planning principles and focus on a bare metal installation. The implementation of the principles for a virtual machine covers the chapter Virtualization.
The question of the minimum requirements is always raised, even though it is obvious to anybody that it depends entirely on the deployment plan.
Nevertheless, technically, you can run a default Fedora Server on a storage space of about 5 GiB. The installed system occupies about 2.5 GiB. Of course, such a server would hardly be useful for anything. The smallest disc currently available for purchase is 64 GiB. With that, you could satisfactorily run a small to medium server for web and mail services. For virtual machines, we currently use 40 GiB as default.
Again, from a purely technical point of view, a standard Fedora server would get by with about 1 GiB of memory. Again, without doing anything useful. The smallest memory chip currently available for purchase is 4 GiB. In a at least dual channel server system you need 2, so you have a minimum of 8 GiB RAM. This is also perfectly sufficient for a small to medium server for web and mail services.
So, with today’s smallest possible purchasable hardware, a Fedora server can be run perfectly for a small to medium deployment.
Technically, a specific storage organization on a server itself will result in a specific partitioning of the hard disk and, beyond that, to the provision of external resources such as a SAN. However, this is about server installation and therefore only about partitioning the internal hard disk.
If you ask 3 system administrators about the best practice for hard disk partitioning, you will get at least 5 different answers. There is no clear, best way to partition your disks. A discussion of the details is beyond the scope of this article. Talk to your friends, read up on the subject, search for articles, and make your own judgment.
The Fedora Server Edition working group has also discussed the topic and agreed on a recommended default configuration, which is explained in the following sections. It puts for servers the highest possible reliability and fault tolerance as well as the lowest possible service interruption in the top priority, and accepts a higher effort for system administration, for example.
A new Fedora installation creates a (modern) GPT partition table by default.
On a BIOSboot machine, Anaconda creates at first a small (1 MiB)
system partition on the first drive. It stores the second stage bootloader which is required by GNU/Grub. Subsequently, it creates
/boot` partition of 1 GiB. It contains all the files necessary for booting Linux, especially the kernel. The remaining area is completely filled with a third partition containing one large volume group (LVM VG) named
fedora by default. You end up with 3 primary partitions on the hard disk that use all the available space.
Fedora can still use the (legacy) MBR partition scheme, provided that the disc is not larger than 2 TB. It then omits the
`BIOSboot partition and uses only the other two partitions.
In the case of a UEFI boot system, Anaconda creates first the required 'EFI System' partition and then adds the aforementioned
partition and one large LVM partition and Volume Group (VG) as described above. You will end up with 3 partitions on the hard disk that completely occupy the available space.
In each of these alternatives, Anaconda creates one logical volume of approximately 15 GiB (the exact value depends on the disk capacity of your system) named
root for the operating system and its software. The remaining available space is at the disposal of the system administrator for free use to store user data.
The rationale behind this is a separation of system and user data, which eases system administration, increases security, and decreases the likelihood of errors and data loss. The system area (i.e. the operating system including installed software) must be maintainable completely independently of the storage of user data. System maintenance must not jeopardize user data under any circumstances. If necessary, it must be possible to unmount user data.
Following this principle, the system administrator would later set up additional logical volumes for storing an application’s data and mount them at an appropriate location in the directory tree. In case of a PostgreSQL database, for example, a system administrator would create a logical volume of appropriate size, assign a descriptive name, such as
pgdata, and mount it in the directory tree at
/var/lib/pgsql, where Fedora PostgreSQL expects the data to reside.
In this way, any error that may occur in the file system should have as little impact as possible and jeopardize as little valuable data as at all possible. For this, the additional effort in system administration is purposely accepted.
If you are a more experienced administrator, you may wish to further the rationale above with increased separation.
You will select
Custom and create the
/boot partitions as required and a small partition and VG dedicated to the operating system. A good size for this VG (eg.
) is, approximately, 30 GiB. Occupying the remaining space, you will create a dedicated partition and Volume group (eg.
) for user data. You will end up with 4 partitions on the hard disk (boot, sysvg, usrvg with Bios boot machines and hard disks up to 2 TB) rsp. 4 partitions (BIOSboot/efi, boot, sysvg, usrvg for all other machines) that use all the available space.
Create a LV (e.g.
) of about 15 GiB for the operating system and maybe additional LVs for the runtime environment, e.g. a LV
of about 5 GB. Mount it at
to prevent log files from flooding and blocking the system and, vice versa, prevent that any other space issue on the root partition block your logs and complicate error analysis. The remaining free space is left for distribution as needed over time. Similar to the default partitioning, all user data is created as LVs in
and mounted in the corresponding directories of the system. This is the maximum possible separation of system and user data with only one hard disk available. And with today’s typical hard drive size of 2 TB and more, those dedicated 30 GBs don’t interfere with the effective use of disk space anymore.
If there is more than one disk available, the default partitioning creates, on each of the other disks, one big partition with a Physical Volume (PV) and adds it to the VG.
On a server, this is usually not optimal. Rather, several disks should store data redundantly in order to maintain operation in the event of a hardware failure. Configuring a RAID system is one such solution.
Anaconda analyzes the hardware and generates at least a basic configuration file for each network interface found, regardless of whether a carrier is present. If a DHCP service is detected, anaconda creates a corresponding complete configuration.
Some system administrators prefer a static configuration even if there is DHCP available, suspicious as they are of any possible source of failure. The network configuration is nevertheless a customization option during the installation.
Fedora Server comes with its own special installation ISO image, either as a full local installation or as a network installation. If at all possible, use one of the two Fedora Server Edition alternatives ("Standard" or "Netinstall") and avoid booting from another image. Anaconda, the installation program and the GUI look alike for any edition or spin, but are tailored differently under the hood, e.g. with different configuration defaults.
That’s why you don’t get a "Fedora Server Edition" as a result with the "Everything" installation medium, even if you select "Fedora Server" as a software package. This can lead to various problems during operation and is not supported.
Wether on hardware or on a virtual machine, an installation requires the download and the verification of an appropriate installation media. On your Workstation open a terminal window and navigate to the directory where you want to keep the files. We assume your home directory here. Then issue the following commands line by line.
[…]$ mkdir -p ~/tmp && cd ~/tmp
[…]$ wget https://download.fedoraproject.org/pub/fedora/linux/releases/38/Server/x86_64/iso/Fedora-Server-dvd-x86_64-38-1.6.iso
[…]$ wget https://download.fedoraproject.org/pub/fedora/linux/releases/38/Server/x86_64/iso/Fedora-Server-38-1.6-x86_64-CHECKSUM
[…]$ wget https://fedoraproject.org/fedora.gpg
[…]$ gpgv --keyring ./fedora.gpg *-CHECKSUM
[…]# sha256sum --ignore-missing -c *-CHECKSUM
sha256sum: WARNING: 17 lines are improperly formatted
You can safely ignore the warning of the last command about not correctly formated lines.
A installation on bare metal requires to transfer the installation file to a bootable media, mostly an USB memory stick. There are several option:
As a (typically comfy) server sysadmin to be, you may use the Fedora project provided graphical utility, "Media Writer" to fullfill that task. See Creating and using a live installation image - Using Fedora Media Writer for guidance how to use it.
As a (hard core) server sysadmin to be, you might prefer a quick and efficiont CLI utilitiy, the
ddcommand. Being already in a terminal windoe, connect the USB stick and issue the following command to get a list of attached devices.
Determine the USB device, e.g.
Just in case, umount the device and transfer the downloaded installation file to the device in one go. On the above example use
[…]$ sudo umount /dev/sdc* […]$ dd if=Fedora-Server-dvd-x86_64-38-1.6.iso of=/dev/sdc bs=8M status=progress
Of course, adjust file and device accordingly! You may receive an error message about parameter
status=progressnot supported. Then you still have an older dd version and have to leave that option off.
And as a (typically busy) server sysadmin to be, you might appreciate a tool provided by the Open Source ventoy project. A small utility on a USB stick of any size takes over the presentation of the device to the hardware as bootable, and reads itself the ISO file, which is stored on a data partition of the stick. Depending on it’s size, it can accomodate multiple ISO files. The server sysadmin can choose between them at boot time in a selection menu. With a new version simply copy the ISO file as it is on the stick and ready to go. No more dd and no Media Writer.
With everything done proceed with one of the available installation procedures.
Want to help? Learn how to contribute to Fedora Docs ›