The latest Fedora release had to wait more than two months before it was officially released to compete for users’ favor. That Fedora 18 proved to be “extremely buggy” or “completely useless” according to the assessments after the first tests hardly helped improve the situation. However, this criticism relates primarily to desktop use, and in particular to errors in the new Gnome version 3.6.2 and the massively revised Anaconda installer. Under the surface lies a whole series of innovations of interest to ambitious users and administrators.

A Choice of Desktops

From the perspective of admins and developers, Fedora 18 provides interesting prospects, particularly with regard to its use as a server or virtualization and cloud management platform. The rightly criticized deficits for desktop use (the Anaconda installer and Gnome) are less relevant for admins because, on the one hand, Fedora 18 provides enough stable alternatives with KDE SC 4.92, Cinnamon 1.6.7, Xfce 4.10, and MATE, and on the other hand, most server admins can probably do without a graphical interface completely.

Moreover, Fedora 18 is available not only in the standard version as an installable Live CD with the Gnome desktop, but also, as used for this test, in a directly installable DVD variation and in the form of spins for KDE and Xfce. Alternatively, just like KDE and Xfce, the Gnome 3 fork Cinnamon and the Gnome 2 fork MATE can simply be installed from a standard Fedora system with Gnome 3.6.2.

Taming Anaconda

In spite of all the installer’s deficiencies, any admin should be able to install Fedora 18 in the desired manner (partitioning) with the new installer, even though available updates cannot be installed during the installation. These features from the old Anaconda could not be integrated in Fedora 18 because of time constraints, but they should be back in Fedora 19.

Criticism of the visually revised Anaconda is primarily directed toward manual partitioning of the hard disk space. Thanks to smart default settings and automatic partitioning, it more quickly provides a usable system with minimum user interaction. The installer already begins copying files in the background while the user is still configuring missing or optional settings, such as the time zone, the locale, or the root password.

For manual partitioning, you click on Installation destination on the Anaconda main installation menu and then select the desired device in the list marked Local Standard Disks. Optionally, the Full disk summary and options link delivers more information about the highlighted device. A click on Continue first leads to the Installation Options, and, in my test, Anaconda pointed out there that there was enough free space on the freshly created virtual SCSI disk for automatic partitioning.

If you want to partition manually, you must first unfold the Partition scheme configuration line and then select the partition type: Standard Partition, LVM, or Btrfs. Using an inconspicuous checkbox, you can also encrypt the partition.

Current criticism of the partitioning module also refers to usability, which is more cumbersome than in the old Anaconda version, at least from the user perspective. More serious, however, are some bugs in the new Anaconda. For example, the program crashed reproducibly during a test when Btrfs was the selected partitioning scheme, because the disk was apparently too small. The limit, according to the Fedora wiki, is 8GB. In the second attempt, the installation with a larger Btrfs partition executed properly, and Btrfs proved to be as stable in operation (Figure 1).

Figure 1: Fedora 18 supports the new Btrfs filesystem in the boot partition – as long as it is at least 8GB.

The new System Storage Manager (SSM) tool for disk management had no problems dealing with Btrfs.

After installation, the bootloader and kernel, which are digitally signed for the first time, ensure that Linux will boot, even on machines secured by UEFI Secure Boot (see the box “Boot Blockade”).

DNF Package Manager

Fedora 18 includes DNF, a new package management tool that is based on the code of Yum 3.4 and is intended to replace Yum fully in one of the next Fedora versions. Like openSUSE, DNF now uses the libsolv library for more reliable resolution of dependencies (Figure 2).

Figure 2: Fedora 18 includes DNF, a new Debian packaging utility.

Furthermore, in Fedora 18, DNF and Yum are based on RPM version 4.10, which is supposed to be more stable and faster than its predecessor. Additionally, many RPM packages now contain information to help the user or a debugger more quickly determine which part of the code harbors the problem. Although the full set of debugging information is still included in the debuginfo packages, the packages are smaller, thanks to improved DWARF compression.

systemd 195

To initialize system start, Fedora 18 uses systemd version 195, which brings several new command-line tools to system configuration. For example, timedatectl serves to configure time zones and system time, localectl is dedicated to the system language and keyboard layout, and hostnamectl is used for configuring the system name. In the previous version, configuration files in /etc/sysconfig were used for some of these settings. Their number has thus been reduced in Fedora 18. New to systemd 195, the admin can now specify which display manager will serve as the graphical login screen.

Firewalld

A new iptables daemon, controllable via D-Bus, and firewalld now take care of the firewall rules. Among other things, firewalld supports various security zones, such as public WLAN, home, or corporate networks, and then automatically uses corresponding rules. The service can be configured with the graphical tool firewall-config (Figure 3) or the command-line tool firewall-cmd.

Figure 3: Fedora 18 includes a new firewall daemon with a graphical interface for configuration.

More Innovations

Fedora 18 also contains the current Samba 4, which implements an Active Directory domain controller in a Windows domain. Also, Fedora 18 includes the DragonEgg GCC plugin that enables GCC to use the LLVM compiler infrastructure, which can, for example, be useful for cross-platform development and optimization.

Beyond that, Fedora 18 also includes Riak, the fault-tolerant and scalable NoSQL database. MariaDB is scheduled to replace MySQL as the database no later than Fedora 19.

Fedora 18 is one of the first distributions to include the NFSometer tool, a framework for measuring performance, with reporting for all current versions of the NFS protocol. NFSometer supports all important NFS options and takes into account the peculiarities of NFS client implementations under Linux. NFSometer was originally developed at NetApp as a procedure for automated performance testing services under Linux. Now, however, it has many features in addition to the reporting interface and is available under the GPLv2 license. Fedora 18 also contains the tracing tool SystemTap version 2, as well as the Linux Trace Toolkit – next generation (LTTng).

If you install Fedora 18 as a guest system, KVM now also supports suspend-to-RAM, as well as suspend-to-disk, even with active virtio drivers. The ability to create snapshots with running guest systems is also supposed to be possible. Fedora provides both Eucalyptus 3.2 as well as OpenStack “Folsom” for setting up clouds; Red Hat has been involved with the OpenStack Foundation for some time.

oVirt Framework

Fedora 18 is also delivered with the oVirt framework in the current 3.1 version. With the help of the oVirt engine, a complex cloud management environment can be created independent of the manufacturer. ADMIN magazine presented the oVirt framework in detail in a previous article [1]. oVirt version 3.1 in Fedora 18 now supports live snapshots, shared disks, external disks, CPU pinning, jumbo frames, “prestarted” virtual machine pools, and quotas, as well as cloning virtual machines from a snapshot.

oVirt 3.1 also supports hot plugging with disk and network interfaces, as well as Posix filesystem storage. Also, the oVirt framework can connect with Red Hat Directory Server or IBM’s Tivoli Directory Server and use remote databases. All-in-one operation makes it possible to run the engine hypervisor on the same machine.

VirtSandbox

The VirtSandbox server tool makes it possible to embed secure container environments in which a service is sealed off from the rest of the system. VirtSandbox allows the admin to confine individual applications in a secure sandbox with the help of KVM (optionally, LXC) as in other sandbox solutions, such as the SELinux sandbox, which has been included in Fedora and Red Hat since 2009.

VirtSandbox is based on virtual machines. The trick is that it is not necessary to set up an operating system in the VM explicitly, because the VM kernel can read parts of the host filesystem directly using the Plan9fs (Plan 9 filesystem). That makes the overhead of the solution very small, so that the time and effort needed to start a confined application using VirtSandbox is of hardly any consequence – Red Hat speaks of a maximum of three seconds compared with a native start of the same application.

In the KVM variation, VirtSandbox starts the kernel together with initramfs in a VM, which in turn calls up the actual application after the boot. According to Red Hat, access to the CPU in VirtSandbox goes largely without a sacrifice in performance, and access to devices lies at about 90 percent of normal speed. The admin sets up the sandbox with the virt-sandbox tool and, for example, specifies which network resources will be available in the sandbox. Many uses are conceivable, such as confining the entire web browser in the virtual sandbox for secure online banking.

System Storage Manager

The new System Storage Manager (SSM) is also very interesting. With it, admins can complete many storage media configuration tasks in a uniform syntax, instead of having to combine tools like fdisk, btrfs, cryptsetup, lvm2, mdadm, or resize2fs. The Fedora admin can, for example, create ext3, ext4, XFS, and Btrfs volumes with the create option or check them with check.

The snapshot option makes a snapshot if the storage medium supports it. SSM can create, expand, or delete LVM, RAID, or Btrfs storage pools, and it can list devices, volumes, or LVM/RAID/Btrfs pools. The resize option enlarges or reduces the size of SSM volumes (Figure 4) or filesystems, and remove deletes them on request.

Figure 4: The new System Storage Manager simplifies reducing the size of logical volumes tremendously.

The commands are largely self-explanatory. More information can be found in the man page.

For example, in the classical approach, the fdisk, mkfs, pvcreate, vgcreate, vgdisplay, lvcreate, and lvdisplay commands are all required for the admin to create logical volumes in an LVM volume group; only a single command is needed in SSM. Using ssm list provides a list of all available devices, including any LVM groups or RAID arrays.

In the example, Anaconda automatically creates the LVM group for the Fedora partition during the partitioning, and the same goes for the 500MB boot partition that doesn’t belong to the LVM group. Creating a new logical LVM volume can then be achieved with

ssm create -s 4G --fstype ext4 /dev/sdb

This command specifies a logical volume of 4GB and formats it as ext4. The command also automatically creates the /dev/lvm_pool volume group required for this, which can easily be verified with the graphical Logical Volume Manager included in Fedora, provided the system-config-lvm package has been installed.

The tool makes it much easier to complete many scenarios because it does so many things automatically, such as creating a volume group on creation of logical volumes or creating the physical volumes when expanding a volume group. However, the opposite, such as just creating an LVM volume group without automatically creating volumes, is not possible, although you can do this using the classical tools. Restoring LVM snapshots is also not yet possible with SSM. Unfortunately, SSM does not reveal which of the underlying tools it uses itself.

Conclusions

From an administrative perspective, Fedora 18, as always, includes a cornucopia of new open source technology and new features. The oVirt framework definitely has much potential. Fedora now supports two private cloud architectures with Eucalyptus and OpenStack, revealing that planners either intend to afford admins and users maximum freedom or are not sure where the journey is headed. In the open source community, OpenStack currently has more adherents than Eucalyptus and OpenNebula.

I also particularly enjoyed the new System Storage Manager tool, which will make work a lot easier for many admins. The teething problems of Fedora 18, particularly on the user side, will hardly be of concern for system administrators. As usual, the remaining bugs will be fixed because Fedora 18 is the basis for the upcoming version 7 of Red Hat Enterprise Linux.

Info

[1] “Managing Virtual Infrastructures with oVirt 3.1” by Thomas Drilling, ADMIN Issue 11, pg. 26
[2] Fedora Secure Boot
[3] UEFI Secure Boot Guide
[4] Josh Boyer’s blog