Product SiteDocumentation Site

2. Changes in Fedora for System Administrators

2.1. Kernel

Fedora 18 features the 3.6.0 kernel.

2.2. Installation

2.2.1. Dual booting with Windows 8

Windows 8 Fast Restart

Using the fast restart feature of Windows 8 and rebooting into Fedora may lead to data loss. Files written to the Windows partition by Fedora may be deleted when rebooting into Windows 8. This may be avoided by disabling the fast restart feature in Windows 8.
The ntfs-3g driver used by Fedora 18 for NTFS filesystems will attempt to detect the dangerous situation and prevent mounting to avoid data loss. This is less true of previous Fedora releases, and fast restart should still be disabled to ensure proper function and prevent data loss.

2.2.2. New Installer User Interface

The anaconda installer has been totally redesigned for Fedora 18. Users will now have more flexibility in how they configure their installation. Some tasks will run in the background to speed the installation process. Consult the Fedora 18 Installation Guide at https://docs.fedoraproject.org for more information.

Advanced Features

System configuration with anaconda is more powerful and flexible through the use of kickstart files. Kickstart files automate installation and accommodate advanced requirements not presented in the GUI, such as multiple desktop environments, atypical storage, and more. Learn more about kickstart options in the Installation Guide.
2.2.2.1. Installing grub
Fedora has used GRUB2 for several releases. A great improvement over legacy GRUB, GRUB2 supports more filesystems, virtual block devices such as mdadm and LVM, automatically scans for and configures available operating systems, and presents visual improvements. This added functionality makes the lives of Fedora users much easier, but comes at the cost of size. GRUB2 fits in the Master Boot Record of a drive, but many filesystems do not leave room on a partition for GRUB2 without special configuration.
Anaconda now follows the recommendation of upstream GRUB developers and does not install GRUB2 to partitions. Users with multiboot systems are encouraged to make use of GRUB's OS detection:
	   # grub2-mkconfig -o /boot/grub2/grub.cfg 
Users can also choose to skip bootloader installation with anaconda. GRUB can be manually installed to a partition with the force option, at the risk of filesystem damage, or another bootloader can be used.

2.2.3. Changed package group names

For those doing kickstart installs, many package group names have changed in Fedora 18. In particular, the Base group has been renamed to Standard. In order to install this group, it must be explicitly specified in the kickstart file.

2.2.4. --nobase

The --nobase flag used to supress the installation of the Base package group has been deprecated.

2.2.5. Upgrade with fedUP

2.2.5.1. What is fedUP ?
Fedup is a new tool for upgrading Fedora installations that is replacing preupgrade and the DVD methods of upgrading that have been used in previous Fedora releases. It utilizes systemd for much of the upgrade functionality and will eventually be able to source packages from a DVD and use the standard repository instead of an upgrade specific side repo.
2.2.5.2.  Upgrade Sources
FedUP can use several sources to perform an upgrade. The Fedora mirrors are used by default. It can also use an installation image with the --iso argument, or use the --device to use a device or mountpoint as a source. Options are also available to enable or disable network repositories.
2.2.5.3. Doing an Upgrade
This is the current process for doing an upgrade from F17 to F18 using fedup. This documentation will change over time as the process evolves.
It is possible to install fedup on an Fedora 17 system using yum:
su -c "yum install fedup"
2.2.5.4. Using FedUP
Using the fedup-cli command, prepare the upgrade using the following command:
su -c "fedup-cli --network 18 --debuglog fedupdebug.log"
At this point, the Fedora 17 system is ready for upgrade.
2.2.5.5. Running the Upgrade
Once you reboot, there will be a 'System Upgrade' boot option at the grub prompt. The system will boot into a special environment to perform the upgrade. The screen will show a graphical progress screen during upgrade.

Go get some coffee

The upgrade process usually takes a while (anywhere from 45-90 minutes, depending on the system), be patient and wait for it to finish. The system will boot into the new version of Fedora when the upgrade is complete.
2.2.5.6. Enabling the Upgrade Shell
In order to enable the Upgrade debug shell, select the System Upgrade boot option, and append rd.upgrade.debugshell to the end of the kernel boot arguments.

Advanced logging during upgrade

In addition to the debug shell, these kernel boot parameters can be useful for debugging :
rd.debug systemd.log_target=console systemd.jounald.forward_to_console=1 systemd.log_level=debug console=tty0 console=ttyS0,115200n8
You can access the debug shell by switching to VT2 (ctl-alt-F2). Note that you won't be able to access the debug shell until after the upgrade process has started, so you'll want to wait a minute or two before switching.
Once you've switched to VT2, you should see the dracut prompt:
dracut#
In order to get into the actual upgrade debug shell, you may need to exit the currently running shell (another will start up right afterwards) so that you can access all the binaries present in the initramfs.
exit
To view the upgrade progress, use:
cat /sysroot/var/log/upgrade.out
If you want to see the system logs, use journalctl
journalctl -a -o cat
2.2.5.7. Third party modules
The initramfs created by FedUP may need to be rebuilt in some cases where drivers are provided by a third party repository. If you experience issues with third party drivers after the upgrade, boot into a single or multi-user target and issue the following command:
        # dracut /boot/initramfs-$(uname -r).img $(uname -r)

2.3. Boot

2.3.1. Offline System Updates

PackageKit and systemd join forces to provide a stable offline environment for applying critical system updates. By booting into a special target, these updates can be applied without causing conflicts in a running system.

2.3.2. Some /etc/sysconfig files have been deprecated

A number of files in /etc/sysconfig have been deprecated. These changes should be transparent to most applications.
2.3.2.1. /etc/sysconfig/clock replaced by /etc/localtime
The time zone is now configured by creating an appropriate /etc/localtime symlink to the relevant timezone.
To list available timezone run the following command:
timedatectl list-timezone
To set timezone run the following command:
timedatectl set-timezone Atlantic/Reykjavik
Systemd uses UTC for the hardware clock by default, but some systems are configured for local time. Users can verify that setting in their BIOS. To set the system clock directly run this command, using the current time and date:
set-time "2012-10-27 01:02:03"
To set the clock to use local time instead of UTC, use the command
timedatectl set-local-rtc 1
For more information on how systemd deals with time, see man timedatectl and man localtime.
2.3.2.2. /etc/sysconfig/i18n has been replaced by /etc/locale.conf
Environment variables and configuration directives now belong in /etc/locale.conf. The locale settings configured here are system wide and inherited by every service or user, unless overridden or unset by individual programs or users. For more information, see man locale.conf
2.3.2.3. /etc/sysconfig/keyboard has been change to /etc/vconsole.conf
The virtual console configuration is now in /etc/vconsole.conf
2.3.2.4. Hostname configuration moved from /etc/sysconfig/network to /etc/hostname
There are now three separate classes of hostnames in use on a given system. The pretty hostname is the high level hostname often presented to users by their desktop environment or shell. The static hostname is used by the kernel at boot, and is usually the system's fully qualified domain name. A system may also have a transient hostname assigned by a dhcp server. hostnamectl is provided for administering these hostnames:
CommandFunction
hostnamectl set-hostname fedorasystem --prettySet pretty hostname.
hostnamectl set-hostname fedorasystem.example.org --staticSet static hostname.
hostnamectl set-hostname fedora-dhcp-client.example.org --transient Set transient hostname.
hostnamectl set-hostname fedorasystem.example.orgWithout arguments, hostnamectl will apply to all hostname types.
hostnamectl statusShow current hostname settings
For more information on hostnames, see man hostname and man hostnamectl

2.4. Security

2.4.1. Active Directory made easy

Fedora can be used on an Active Directory domain (or other Kerberos realms, such as IPA) out of the box. It should be easy to configure domain logins on a Fedora machine, and then it should be intuitive and uneventful to login with those credentials.
These improvements will also increase reliability and ease usage for any Kerberos realm, not just Active Directory. Improvement has been made in much of the login and authentication stack, which now includes realmd and adcli.
The GNOME User Accounts Settings GUI features support for enterprise logins.
With Fedora 18 it is possible to create a trust relationship between an IPA and an Active Directory domain which would allow users from one domain to access resources of the other domain. The FreeIPA project has documented the feature at http://freeipa.org/page/IPAv3_testing_AD_trust.

2.4.2. Secure Boot

UEFI Secure Boot will be supported in Fedora 18. This will allow Fedora to boot on systems that have Secure Boot enabled. Tools are available for administrators to create custom certificates to sign local changes to GRUB or the kernel.

2.4.3. rngd

Random number generation is improved by enabling rngd by default.

2.4.4. Secure Containers

Using SELinux and virt-sandbox, services can be run in secure sandboxes, even as root. The virt-sandbox-service package will create mount points and a libvirt container.

2.4.5. SELinux boolean renaming

In order to clarify the purpose of SELinux booleans, all settings that begin with allow will be renamed to reflect their domain. Existing policy booleans will continue to be supported.

2.4.6. SELinux Systemd Access Control

Support has been added to systemd to check unit files against SELinux settings before allowing a process to start or stop the service.

2.4.7. System calls restricted

The libseccomp library is now available, which provides applications with an easy way to reduce the potential damage of exploits by using kernel syscall filters. Virtual machines benefit from this as QEMU/KVM now uses libseccomp.

2.4.8. usermode

usermode, a wrapper to provide superuser privileges to unprivileged users, is being phased out in favor of polkit.

2.4.9. Kerberos credentials moved and improved

Fedora 18 changes the standard location of Kerberos credential caches to /run/user/$UID in order to increase security and simplify locating the caches for NFSv4. Fedora's Kerberos support will now allow users to maintain credentials for multiple identities and for the GSSAPI client code to automatically select credentials based on the target service and hostname.

2.4.10. halt, poweroff, and reboot Configuration Moved

The ability to use halt(8), poweroff(8) and reboot(8) commands by unprivileged users is now controlled using polkit. See the actions in /usr/share/polkit-1/actions/org.freedesktop.login1.policy. The PAM configuration files in /etc/pam.d/{halt,poweroff,reboot} are no longer used and their content, if any, is ignored.

2.5. File Systems

2.5.1. FedFS

Fedora 18 adds FedFS, a mechanism to provide a coherent namespace across multiple file servers.
The code provided in this package is a technology preview. The intent is to provide a full and supported Linux FedFS client and server implementation based on this code. Programming and user interfaces may change significantly for the next few releases.
The components in this package are used for managing file system referrals in order to create a global network file system namespace. Installable components include:
  • An automounter program map to manage the FedFS domain namespace on FedFS enabled clients.
  • A mount command to mount parts of a FedFS domain namespace.
  • A plug-in library that allows programs outside of FedFS to resolve junctions on local file systems.
  • An ONC RPC service daemon that runs on file servers enabling the management by remote FedFS ADMIN clients of FedFS junctions.
  • A tool called nfsref to manage local junctions without requiring fedfsd.
  • A set of command-line clients that can access fedfsd instances on remote file servers.
  • A set of command-line clients that can manage FedFS entries on an LDAP server acting as a FedFS NSDB.
  • A tool to manage NSDB connection parameters on the local host.
  • An LDIF format schema to enable an LDAP server to support FedFS objects.
For more information refer to the FedFS project page and the FedFS Documentation page.

2.5.2. /tmp on tmpfs

By default, /tmp on Fedora 18 will be on a tmpfs. Storage of large temporary files should be done in /var/tmp. This will reduce the I/O generated on disks, increase SSD lifetime, save power, and improve performance of the /tmp filesystem.

2.6. Virtualization

2.6.1. Live Snapshotting of Virtual Machines

The virtualization stack in Fedora has provided the ability to take "snapshots" of a virtual machine for many releases. These functions have however always required that the virtual machine be paused or stopped while the storage snapshot was created. Recent updates included in Fedora 17 allowed for qemu and libvirt to create snapshots of a virtual machine without requiring any downtime.
Live snapshot creation now works even for virtual machines using disk images stored in RAW format. In these cases libvirt creates snapshots using external QCOW2 files - transparently switching the virtual machine to run on the new external image(s) once created.

2.6.2. KVM supports hibernating and suspending guests

Suspend and hibernate now works from within KVM virtual machines. These can also be invoked on virtual machines from the host using virsh.

2.6.3. Manage Virtualized Environments with oVirt 3.1

The oVirt virtualization management platform has been significantly expanded in Fedora 18 with the upgrade to version 3.1. For more information, consult the oVirt 3.1 Release Notes at http://www.ovirt.org/OVirt_3.1_release_notes and the oVirt Quick Start Guide at http://wiki.ovirt.org/wiki/Quick_Start_Guide.

2.7. Web Servers

2.7.1. httpd

The Apache httpd package has been upgraded to version 2.4.3-1, which contains numerous security and performance fixes.

2.7.2. lighttpd

The lighttpd package has been upgraded to version 1.4.32-2.

2.8. Cloud

2.8.1. Eucalpytus

eucalyptus allows the creation of private Infrastructure-as-a-Service (IaaS) clouds that are compatible with Amazon Web Services.

2.8.2. OpenShift Origin

OpenShift Origin brings Platform-as-a-Service (PaaS) support to Fedora 18.

2.8.3. OpenStack

Fedora 18 includes the latest version of the OpenStack IaaS cloud service, codenamed Folsom.
2.8.3.1. Heat
Heat was added to provide an AWS CloudFormation API for OpenStack. Heat provides a standardized method for OpenStack users to launch multiple applications in an OpenStack cloud from a template file describing the cloud application. Administrators are encouraged to read the project's getting started guide or the browse their Wiki.

2.9. Database Servers

Riak, a scalable and reliable noSQL data store written in Erlang, is available in Fedora 18.

2.10. File Servers

2.10.1. vsftpd

Fedora 18 includes the newest vsftpd release, version 3.0, which includes the following changes:
  • A new highly restrictive seccomp filter sandbox.
  • A fix for passive mode connections under high loads.
  • A few timeout fixes, particularly with SSL.
  • Make listen mode the default.

2.10.2. NFSometer

NFSometer is a performance measurement framework for running workloads and reporting results across NFS protocol versions, NFS options and Linux NFS client implementations. More detailed information can be found at http://wiki.linux-nfs.org/wiki/index.php/NFSometer

2.10.3. StorageManagement

Fedora 18 provides a number of libraries enabling users to programmatically manage their storage, namely libstoragemgmt and targetd. Documentation is included in the packaged manpages and READMEs.

2.10.4. ssm: System Storage Manager

Fedora 18 includes ssm, a tool to ease common storage management tasks by providing a unified command line experience. man ssm describes the new functionality provided by the utility.

2.11. Samba

Fedora 18 includes Samba4, which provides improved cross-platform file server support. The release supports the new SMB2.2 and SMB3 protocols and includes an LSA Service Daemon for FreeIPA trust relationship support. Administrators leaning on python will be pleased with the new Samba4 scripting interface, which allows Python programs access to Samba internals.

2.12. System Daemons

2.12.1. SysVinit to systemd

Additional SystemV init scripts are migrated to systemd unit files to improve readability and boot times.

2.12.2. Expanding the admin toolkit with procps-ng

Fedora 18 brings the migration of legacy procps tools to procps-ng. This provides better maintainability, expanded functionality, and better compatibility with scripts run on other distributions. Users should consult the documentation in /usr/share/doc/procps-* for more information.

2.13. Server Configuration Tools

2.13.1. dnf greets Fedora

dnf is a fork of the venerable yum package manager. It is build on hawkey, a library allowing clients to query and resolve dependencies of RPM packages based on the current state of RPMDB and yum repositories.
dnf in Fedora 18 is a technical preview, and is installed alongside yum. It should not yet be used on critical production machines, but early adopters are promised a more efficient, faster package management utility.

2.13.2. systemctl assumes it works with services

systemctl, the utility used to administer services and other systemd targets, will now assume that it is working with a service. Administrators will no longer have to append .service to the name of the daemon they are administering. For example, systemctl restart dhcpd will now just work, but previous releases required systemctl restart dhcpd.service.

2.13.3. Terminals get more colorful

Fedora now features supporting terminal emulators using 256 colors by default. With new environment variables, applications such as gnome-terminal, konsole, and screen will automatically be enabled with 256 color support. Other applications can display 256 colors but must be configured. While still disabled by default, users can enable color terminals for connecting remote systems with the environment variable SEND_256_COLORS_TO_REMOTE. These configurations can be found in /etc/profile.d/256color.sh.

2.13.4. Remote management gets better with Agent-Free Systems Management

On systems that contain IPMI compliant Service Processors, it is now possible to have closer integration of OS and Service Processor without the need for 3rd party software. This will enable better management of the system remotely.

2.13.5. CIM management tools improved

Administrators managing large numbers of systems get a running start with Fedora 18's improvements on WEBM and CIM offerings.
Users can build applications using new and enhanced CPMI providers to monitor and administer network interfaces, storage objects, services, power state, users, and software packages. They can also monitor system load, usage, and more. The toolkit also includes yawn, a web based browser for navigating and working within the CIM object model.
These features ease the task of managing large numbers of systems, laying the foundation for robust management infrastructure. Experienced users and system administrators are invited to review the sample python scripts and documentation provided with the sblim-cmpi-* or openlmi-* packages.

2.14. Xorg

2.14.1. Server Kernel Mode Setting (KMS) Drivers

Many servers ship with only basic GPU hardware. Despite the basic nature of such hardware a fully fledged X.org driver has historically still been required to manage it. Fedora 18 introduces Kernel Mode Setting (KMS) drivers which provide enhanced support for the GPUs commonly found in servers. Users of these GPUs are now able to utilize the additional features provided by KMS drivers, including enhanced graphics in virtual consoles. Chipsets supported by these new KMS drivers include AST and MGA based ServerEngines.

2.14.2. GPU Hot Plug Support

The X.org server has been rewritten to support 'hot' plugging and unplugging of GPUs. Specifically, this allows Fedora to provide better support for USB connected graphics devices exposed by many modern systems and laptop docking stations. The user is no longer required to restart the X.org server for such devices to be recognised.