2. Changes in Fedora for System Administrators
2.2.1. Dual booting with Windows 8
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.
The --nobase
flag used to supress the installation of the Base
package group has been deprecated.
2.2.5. Upgrade with 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.
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
Using the fedup-cli command, prepare the upgrade using the following command:
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.
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.
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.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.
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.
Random number generation is improved by enabling rngd by default.
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.
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.
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.
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.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.
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
:
Log in to the Fedora system on which you wish to host oVirt Engine
as the root
user.
Install the ovirt-engine package with yum install ovirt-engine
.
Run the engine-setup
script and follow the prompts to complete installation of oVirt Engine
.
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:
Install Fedora 18. A minimal installation is sufficient. Ensure that you set password for the root
user and that SSH is enabled.
Log in to your oVirt Engine
installation using your web browser.
Select Add from the Hosts tab.
Enter a name for the Fedora host.
Provide the hostname or IP address and root password for the Fedora host
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
eucalyptus allows the creation of private Infrastructure-as-a-Service (IaaS)
clouds that are compatible with Amazon Web Services.
OpenShift Origin brings Platform-as-a-Service (PaaS)
support to Fedora 18.
Fedora 18 includes the latest version of the OpenStack IaaS cloud service, codenamed Folsom.
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.
owncloud provides a server and client to synchronize files across multiple devices, including mobile. This allows users to run their own file synchronization service.
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.
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.
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.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.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.