Fedora Server Installation Guide
Beta 1 Please comment on server mailing list!
Fedora Server Edition uses the same installation procedure as most of the other editions and spins. Basic installation is covered by Fedora’s overall Installation Guides.
However, there are some peculiarities and differences for Fedora Server Edition that should be noted in deviation or in addition to the explanations over there. These are outlined in the following sections.
And of course, the installation planning depends in many details on the target environment. As an example, a virtual machine installation requires a different approach to storage than a bare metal installation. Thus, in the former case, one does not need to worry about a RAID system.
These instructions and notes primarily concern a bare metal 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 and avoid booting from another image, for example 'Everything' and then selecting Fedora Server as the installation target, or changing the installation source to 'Fedora Server' afterwards. Anaconda, the installation program and the GUI look alike for any edition or spin, but are tailored differently under the skin, e.g. with different configuration defaults.
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 regarding partitioning. It depends on different goals and weightings.
By default, Anaconda as tailored for Fedora Server Edition creates in case of a bios boot machine a small /boot partition on the first drive, used by Grub2 bootloader. The remaining area is filled with another partition and one volume group (VG) created therein. In case of a disk larger then 2 TB it uses a GPT partition table and adds a BIOSboot partition to the described scheme, otherwise the traditional DOS partition table.
Therein, a logical volume of approx. 15 GB (the exact value depends on the disk capacity) is created for the operating system and its software. The other available space remains free for the creation of logical volumes (LVs) for user data, which are to be mounted at the appropriate positions in the directory tree of the system area.
The rationale behind this is a separation of system and user data. This should ease system administration, increase security, and decrease error-proneness. The system area, i.e. the operating system including installed utility programs and software must be maintainable completely independently of the storage of user data. System maintenance must not jeopardise user data under any circumstances. If necessary, it must be possible to unmount user data.
You may reinforce that rationale even further and create another small partition and VG dedicated to the operating system (in addition to the partition for /boot). A good size for this volume group, eg. sysvg, is approx. 30 GiB. Create an LV, e.g. 'sys_root' of 15 GiB for the operating system and maybe additional LVs for the runtime environment, e.g. a LV 'sys_log' of about 5 GiB. Mount it at /var/log to prevent log files to flood and block the system and vice versa prevent that any other space issue on root partition blocks your log files. The remaining free space is left for disposal as needed for whatever maintenance work. The remaining area of the hard disk is filled by a large partition and VG for user data, e.g. usrvg. Similar to the default partitioning, all user data is created as LVs in usrvg and mounted in corresponding directories of the system area. This is the maximum possible separation of system and user data if only one hard disk is available. And with today’s typical hard drive size of 2 TB and more, those dedicated 30 GiB don’t interfere with 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 volume group.
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. Manual partitioning is necessary for this. Select "Installation Destination" in the Summary Screen, the options "Custom" and "Advanced Custom (Blivet-GUI)" both enable manual partitioning.
On Bios boot machines and hard disks with a maximum of 2 TB, select the comfortable "Custom" option.
If exist, delete any partition (use the '-' sign at the bottom of the left box).
Add a Partition, select mount point /boot, type changes from default LVM to standard, select size 1 Gib.
After creation modify the partition type to RAID.
Anaconda later detects the raid configuration of /boot and installs the mbr on each included disks. If the first disk fails it can boot using the other one.
Add additional raid partitions as needed.
Hard disks larger than 2 TB require a GPT disk label and an additional BIOSboot partition. The Custom option can’t handle this in a RAID configuration. You have to choose the 'Advanced custom' option.
By default the installation program creates a DHCP configuration for each network interface. In case of an active connection it is automatically started during boot.
In case of servers it is often preferrable to configure a static IP address. This ensures a valid network connection at system start even if the DHCP server is defective. Select the network interface, activate the IPv4 rsp. IPv6 tab. Switch from DHCP to manual and add an IP spezification.
Note: Post F32 NetworkManager stores the configuration in /etc/NetworkManager/connected_systems/*.network!
As a minimum, you must set a password for the ROOT account. Select 'Root Password' below 'USER SETTINGS' and enter an appropriate password. For security reasons, ssh login as root is only allowed with key-file, but the account is not locked. It is not advisable to modify these security settings! This way, secure root access via ssh key file is still an option and, in an emergency, also with a password via an attached console or Cockpit login.
If there is no direkt terminal access available create a fall back user (e.g. hostmin) with password authentication active and administration privilege (group wheel & sudo su). In such a case, this is the only way to get access to the server after the reboot! And even later, it is the only way to get administrative access if for some reason the private key file is not available.
For the operation of a server, a crucial condition is to ensure the correct time setting. As a very simple example, you need to find a specific event in the log files. Therefore, the correct settings for date and time are of utmost importance.
On the "Installation Summary" page select "Time & Date" and check time, time zone and activation of time synchronization.