Product SiteDocumentation Site

2. Changes in Fedora for System Administrators

2.1. Installation

2.1.1. Unversioned docdirs

Per package documentation is now installed into unversioned /usr/share/doc/packagename directories. Previously the directory name contained the package's version in addition to the package's name.

2.2. Security

2.2.1. FreeIPA gains transitive trust support

FreeIPA 3.3.2 adds support for complex Active Directory forests containing multiple domains. Users from multiple AD domains can access resources in FreeIPA. FreeIPA administrators can selectively block access per each AD domain.

2.2.2.  SSSD adds ID mapping for CIFS shares

The Fedora 20 System Security Services Daemon has gained support for mapping between Windows SIDs and POSIX IDs. Administrators using SSSD on their networks can establish access control using two new utilities, setcifsacl and getcifsacl.
More information can be found in the upstream design document at https://fedorahosted.org/sssd/wiki/DesignDocs/IntegrateSSSDWithCIFSClient and the manpages for setcifsacl, getcifsacl, and other related SSSD packages.

2.2.3. Shared System Certificate Tools

Fedora's Shared System Certificate feature is being enhanced this release with the addition of the p11-kit-trust application. This package allows modification to trust anchors and blacklist keys and certificates. With a single command, administrators can make changes to their system's certificate database instead of adding a file to a special directory and running a special command. This new tool continues the development of the Shared System Certificate feature.

2.3. File Systems

2.3.1. SSD caching for block devices

Fedora 20 offers experimental support for adding solid state drives (SSDs) as fast, transparent caches to traditional rotating storage (HDDs). Filesystems on the SSD cached block devices offer both the speed of SSDs and volume of HDDs. Both traditional and LVM partitioning schemes can benefit from this functionality.

Make backups!

Always back up your data before making low level changes, such as migrating to a bcache device. Until tools like blocks are packaged for Fedora, users are advised to implement bcache by creating clean bcache devices and populating their filesystems from a recent backup.

2.4. Virtualization

2.4.1. ARM emulation on x86 Hosts

Changes have been made to have smoother emulation of ARM guest virtual machines running on x86 hosts using standard libvirt tools, including virsh, virt-manager and virt-install. qemu has an ARM emulator that works well and is actively used in the Fedora ARM effort. However libvirt and virt-manager currently have issues launching qemu-system-arm VMs, mostly by encoding x86 assumptions in the generated command line that cause qemu-system-arm to fail to start. Changes have been made to fix this issue. More information can be found at https://fedoraproject.org/wiki/Changes/Virt_ARM_on_x86

2.4.2. Libvirt Client Access Control

The libvirt client allows for the setting of permission rules which can be applied to all managed objects and API operations, thus allowing for all client connections to be limited to a minimal set of rules and privileges. There are three levels of access which can be assigned.
Unauthenticated access is initially used for all connections. This state allows all API operations that are required to complete authentication. Following a successful authentication, two more levels can be assigned: Unrestricted, which gives full access to all API operations, and Restricted, which allows read only access.
System administrators can set permission rules for authenticated connections. Every API call in libvirt has a set of permissions that are validated against the object that is being used. For example, User A wants to change a parameter in the domain object. When the user tries to save the change, virDomainSetSchedulerParametersFlags method will check whether the client has write permissions on the domain object. Additional checks and permission settings can be processed as well. Filtering can also be done to see which clients have permissions on which objects to allow for smother administration of permissions. Documentation for polkit access control can be found at http://libvirt.org/aclpolkit.html.
The libvirtd.conf configuration file is responsible for setting the access permissions. It uses the access_drivers parameter to enable this operation. Note that if more than one access driver is requested, all must succeed in order for permission to be granted.

2.4.3. Virt-manager snapshots

Virtual Machine Manager, or virt-manager, allows for easy management and monitoring of virtual machine snapshots of KVM guests. Note that virt-manager will pause the guest virtual machine for a few seconds while taking the snapshot. More information is available here:
http://fedoraproject.org/wiki/Changes/Virt_Manager_Snapshots
http://fedoraproject.org/wiki/Features/Virt_Live_Snapshots
http://libvirt.org/formatsnapshot.html
Snapshot section of man 1 virsh
http://fedoraproject.org/wiki/QA:Testcase_Virt_Snapshot_UI

2.5. Database Servers

2.5.1. MongoDB

MongoDB has been updated to version 2.4 adding full text search, support for a wider array of geospatial indexes, and security enhancements. For more information about this new version read the release notes at http://docs.mongodb.org/manual/release-notes/2.4/.

2.5.2. Hadoop

Fedora 20 offers the core of the thriving Hadoop platform and many related packages. For a detailed review of Hadoop in Fedora, refer to https://fedoraproject.org/wiki/Changes/Hadoop.
The packaging of the Hadoop platform is the latest work of the Fedora Big Data SIG. Find this Special Interest Group at https://fedoraproject.org/wiki/SIGs/bigdata, your gateway to using and participating in the effort.

2.6. Mail Servers

2.6.1. No default sendmail

Fedora 20 no longer includes a mail transfer by default. Previous releases of Fedora included sendmail, but it has limited usefulness without manual configuration.

2.7. Samba

2.7.1.  SSSD adds ID mapping for CIFS shares

Information on this feature can be found in the Security section.

2.8. System Daemons

2.8.1. Syslog removed from default installation

syslog is no longer included in default installations. journald logging serves most use cases as well as, or better than, syslogd.
Users accustomed to checking /var/log/messages for system logs should instead use journalctl.
journalctl command examples
new journalctlold messages
journalctl less /var/log/messages
journalctl -f tail -f /var/log/messages
journalctl --unit named.service grep named /var/log/messages
journalctl -b Shows logs from current boot, no simple equivalent.

2.8.2. systemd

2.8.2.1. New unit types: Scope
Systemd now has two new unit types, scope and slice.
scope units are automatically created by systemd out of existing processes. By grouping a process and its children together, a scope unit can be used to organize processes, apply resource units, or kill a group of processes. User sessions are one example of processes contained in a scope unit.
slice units are used to group units that manage processes into a hierarchy that allows control of resources allocated to the slice. The default slices are machine.slice, for virtual machines and containers; system.slice, for system services; and user.slice, for user sessions. These default slices are automatically populated.
Instance units, such as getty@.service, are spawned on demand using the template defined in their configuration file. Each type of template is given a subslice of the system slice, and instances are contained within that slice.
Scope and service units assigned to a slice are descendants of that slice's node in the control group tree. A slice's name describes its position relative to the root slice. The output below demonstrates how user-1000.slice is a child of user.slice, which is in turn a child of ., the root slice. Each session is further confined in a scope unit within the user's slice.
	    systemctl status user.slice

  Loaded: loaded (/usr/lib/systemd/system/user.slice; static)
  Active: active since Sun 2013-09-08 01:23:40 MDT; 18h ago
    Docs: man:systemd.special(7)
  CGroup: /user.slice
          ├─user-1000.slice
          │ ├─session-21.scope
          │ │ ├─9226 sshd: pete [priv]
          │ │ ├─9229 sshd: pete@pts/4
          │ │ ├─9230 -bash
          │ │ ├─9262 sudo su -
          │ │ ├─9270 su -
          │ │ ├─9271 -bash
          │ │ └─9509 screen -R
          │ ├─session-18.scope
          │ │ ├─ 7939 sshd: pete [priv]
          │ │ ├─ 7942 sshd: pete@pts/0
          │ │ ├─ 7943 -bash
          │ │ ├─ 7982 sudo su -
          │ │ ├─ 7988 su -
          │ │ ├─ 7989 -bash
          │ │ ├─ 8206 SCREEN
          │ │ ├─ 8207 /bin/bash
          │ │ ├─ 8237 /bin/bash
          │ │ ├─ 8486 less NEWS
          │ │ ├─ 8489 /bin/bash
          │ │ └─10637 systemctl status user.slice
          ## truncated ##

Services can be added to a slice with the Slice=slicename directive in their unit configuration file. Arguments allowing resource limitation within a slice or service unit are described in man systemd.directives. See also man systemd.slice and man systemd.cgroup.
2.8.2.2. systemd-cryptsetup for TrueCrypt
Support for TrueCrypt in Fedora is expanded by systemd-cryptsetup support for the technology, allowing easy authentication during boot.
2.8.2.3. Filtering by unit state with systemctl
systemctl now supports filtering the unit list output by load state. The --state option will accept any value or a comma-separated list of the values of LOAD, SUB, or ACTIVE states. For example,
	   systemctl --state failed 

2.8.3. journald

2.8.3.1. Viewing the logs of a specific boot
journalctl can now be used to view the logs from a specific boot. For example, to view logs from the current boot:
	  journalctl -b
Or, view the logs from the previous boot:
	  journalctl -b -1
In addition to relative boot sequence, journald assigns a 128-bit boot ID that can be referenced. For example:
	  journalctl -b 38fd9c3303574ed38e822233457f6b77
2.8.3.2. Referencing the journal with cursors
journalctl can reference the contents of the journal by a record identifier known as a cursor. Similar to a git hash, the cursor uniquely identifies a point in the journal.
If you add --show-cursor to a journalctl query, the last line of output will contain the cursor value:
	  journalctl -b -u network --show-cursor --since 15:00
	  Sep 08 15:37:59 localhost.localdomain network[4074]: [FAILED]
	  Sep 08 15:37:59 localhost.localdomain systemd[1]: network.service: control process exited, code=exited status=1
	  Sep 08 15:37:59 localhost.localdomain systemd[1]: Failed to start LSB: Bring up/down networking.
	  Sep 08 15:37:59 localhost.localdomain systemd[1]: Unit network.service entered failed state.
	  -- cursor: s=13497722134642a2ac1544bada0c8836;i=1120d;b=8491c05dabd3444ca122e7069b5de0a9;m=db2118a46;t=4e5e7d81c7402;x=d177768ac95df831
The cursor can be used to identify that point in the journal in a broader query to provide context:
	  journalctl -c "s=13497722134642a2ac1544bada0c8836;i=1120d;b=8491c05dabd3444ca122e7069b5de0a9;m=db2118a46;t=4e5e7d81c7402;x=d177768ac95df831"
Scripts parsing journalctl's output can store the cursor value and use it on their next run to pick up where they left off:
	  journalctl --after-cursor "s=13497722134642a2ac1544bada0c8836;i=1120d;b=8491c05dabd3444ca122e7069b5de0a9;m=db2118a46;t=4e5e7d81c7402;x=d177768ac95df831"