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.

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 regular install repos instead of needing a specially created side repo.
2.2.5.2. 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.

sudo or root

The commands listed below use sudo but could also be run as root
It is possible to install fedup on an Fedora 17 system using yum:
yum install fedup
2.2.5.3. Using fedUP
Using the fedup-cli command, prepare the upgrade using the following command:

Using the correct URL

To use the public Fedora resources to upgrade to Fedora 18 Beta, replace [insert-arch-here] below with the arch that you're upgrading - either x86_64 or i386. The final release should not require --instrepo to be explicitly declared.
sudo fedup-cli --network 18 --debuglog fedupdebug.log --instrepo=http://dl.fedoraproject.org/pub/fedora/linux/releases/test/18-Beta/Fedora/[insert-arch-here]/os/
At this point, the Fedora 17 system is ready for upgrade.
2.2.5.4. Running the Upgrade
Once you reboot, there will be a 'System Upgrade' boot option at the grub prompt. Note that it is not the default and will need to be selected manually in order for the upgrade process to continue. Adding plymouth.splash=fedup to boot arguments for the Beta will show a graphical progress screen during upgrade. This will be the default for the final release. If all goes as it should, you might see a few boot messages but will eventually see the fedup plymouth theme.

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.5. 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.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 depricated

A number of files in /etc/sysconfig have been depricated. 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 informatino 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 seperate 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 tempfs. 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

Fedora 17 included the packages required to support a minimal installation of the oVirt virtualization management platform. This initial offering has been significantly expanded in Fedora 18. In addition to the existing functionality, it is now possible to use a Fedora installation as a fully fledged oVirt "Engine" - providing a graphical management console for your virtualized environments.
Project homepage: http://ovirt.org.
2.6.3.1. oVirt Engine Installation
The oVirt Engine provides a browser accessible management console for creating, provisioning, and using virtual machines. It also provides facilities for managing the networking and storage needs of the virtualized environment. For users who want to experience the management console but do not have a spare machine to act as a virtualization host an 'all in one' plugin is provided. The 'all in one' plugin allows a system to act as both the oVirt Engine and as a virtualization host.
To install the oVirt Engine:
  1. Log in to the Fedora system on which you wish to host oVirt Engine as the root user.
  2. Install the ovirt-engine package with yum install ovirt-engine.
  3. Run the engine-setup script and follow the prompts to complete installation of oVirt Engine.
  4. Once the Engine has been installed successfully the script will provide instructions for accessing the web Administration Portal.
2.6.3.2. Virtualization Host Installation
For each system you wish to use as a virtualization host:
  1. Install Fedora 18. A minimal installation is sufficient. Ensure that you set password for the root user and that SSH is enabled.
  2. Log in to your oVirt Engine installation using your web browser.
  3. Select Add from the Hosts tab.
  4. Enter a name for the Fedora host.
  5. Provide the hostname or IP address and root password for the Fedora host
  6. Click OK.
There will be a short delay as your host downloads and installs required packages. Your Fedora host will then be added to the environment.
2.6.3.3. Additional Information
A Quick Start Guide for oVirt 3.1 is available 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 peformance 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.8.4. OwnCloud

owncloud provides a server and client to synchronize files across multiple devices, including mobile. This allows users to run their own file synchronization service.

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.