Wednesday Why

Fedora 9 is only a few days away, as the counter on the front page testifies. Although it's possible to upgrade an earlier Fedora system to F9, it's generally agreed that a fresh installation is cleaner and has less potential for problems. If your system uses LVM (which has been the default for the last several Fedora releases), it's particularly easy to perform a fresh installation while maintaining access to your previous data, because you can create new Logical Volumes within your existing Volume Group. You can then mount your old filesystems and migrate data over with ease.

This type of installation will be covered in the upcoming F9 Focus Week, but in order to prepare for it, you'll need some free space within your volume group -- I'd recommend at least 6-10 GB. If you're not really comfortable with the LVM commands, you can explore and adjust your LVM configuration using the system-config-lvm tool; however, to reduce the size of a logical volume and free up some space, the filesystem within that logical volume must be unmounted -- and in the case of the root filesystem, that means that the system can't be running in its normal way, which pretty much precludes the use of system-config-lvm. To reduce the size of the root filesystem, see the article on Using LVM In Rescue Mode from System Recovery Week.

(Note the links above -- sorry if they're not very visible or obvious due to the styling).

Update: KageSenshi points out that system-config-lvm is on the Fedora live disc images. You can resize the root filesystem on the hard disk by simply booting from a live disc and running the system-config-lvm command from a terminal window.

PulseAudio became the standard audio system in Fedora 8, but how does the pulseaudio daemon start in a Gnome session?

Gnome sessions are managed by gnome-session, which starts a standard set of clients (as well as any programs which you have configured for your account) each time the Gnome desktop is started. The file /usr/share/gnome/default.session file, which configures the default list of clients, looks like this:

# This is the default session that is launched if the user doesn't
# already have a session.
# The RestartCommand specifies the command to run from the $PATH.
# The Priority determines the order in which the commands are started
# (with Priority = 0 first) and defaults to 50.
# The id provides a name that is unique within this file and passed to the
# app as the client id which it must use to register with gnome-session.
# The clients must be numbered from 0 to the value of num_clients - 1.

[Default]
num_clients=5
0,id=default0
0,Priority=60
0,RestartCommand=pam-panel-icon --sm-client-id default0
1,id=default1
1,Priority=10
1,RestartCommand=gnome-wm --default-wm gnome-wm --sm-client-id default1
2,id=default2
2,Priority=40
2,RestartCommand=gnome-panel --sm-client-id default2
3,id=default3
3,Priority=40
3,RestartCommand=nautilus --no-default-window --sm-client-id default3
4,id=default4
4,Priority=40
4,RestartCommand=gnome-volume-manager --sm-client-id default4

As you can see, the PulseAudio daemon is not among the programs listed (note that gnome-volume-manager is the mounted filesystem volume manager, not an audio volume manager). But this list isn't exhaustive: commands listed in .desktop files in /usr/share/gnome/autostart are also executed when a session is opened -- but on my system the only files in there are bluetooth-applet.desktop, gnome-volume-manager.desktop, and
gnome-power-manager.desktop, and none of those files contain any reference to PulseAudio.

So what starts pulseaudio? A quick check of the output of ps reveals that its parent process is in fact gnome-session, and strace confirms this.

A look at the rpm packages that start with "pulse" reveals something interesting:

$ rpm -qa|egrep '^pulse'
pulseaudio-libs-0.9.8-5.fc8
pulseaudio-module-x11-0.9.8-5.fc8
pulseaudio-0.9.8-5.fc8
pulseaudio-libs-glib2-0.9.8-5.fc8
pulseaudio-utils-0.9.8-5.fc8
pulseaudio-core-libs-0.9.8-5.fc8
pulseaudio-module-gconf-0.9.8-5.fc8
pulseaudio-esound-compat-0.9.8-5.fc8
pulseaudio-libs-0.9.8-5.fc8

The esound daemon (esd) was the audio daemon historically used by Gnome. A quick look at the files included in pulseaudio-esound-compat shows that it provides a dummy esd command:

$ rpm -ql pulseaudio-esound-compat
/usr/bin/esd
/usr/bin/esdcompat
/usr/share/man/man1/esdcompat.1.gz

$ file /usr/bin/esd*
/usr/bin/esd: symbolic link to `esdcompat'
/usr/bin/esdcompat: Bourne shell script text executable
/usr/bin/esd-config: Bourne shell script text executable

The man page for esdcompat tells a bit more of the story:

esdcompat is a compatiblity script that takes the same arguments as the ESD sound daemon esd(1), but uses them to start a the PulseAudio sound server with the appropriate parameters. It is required to make PulseAudio a drop-in replacement for esd, i.e. it can be used to make gnome-session(1) start up PulseAudio instead of esd.

This brings us to the final question: why does gnome-session start esd if it's not mentioned in any of the configuration files? Surely it can't be ... hardcoded?!

$ strings -a /usr/bin/gnome-session | egrep '\/usr\/bin\/esd'
/usr/bin/esd

A Fedora system usually begins its boot process with a startup screen (or menu) displayed by the bootloader Grub. The background for this screen is provided by the wonderfully talented Fedora artTeam. The image is in the file /boot/grub/splash.xpm.gz from the package fedora-logos.

Customizing your boot screen with a favorite photo, your company logo, or even a cartoon is quite straightforward:

1. Prepare a suitable image. The image must be 640x480 pixels and have a maximum of 14 colours, because the VGA mode used during boot has a resolution of 640x480 pixels with 16 colours and 2 colours are reserved for text (white and black). If you're using the Gimp graphics editor, simply ensure that your image is 640x480 pixels (the titlebar of the image window displays the image size) and then select the menu option Image>Mode>Indexed, entering 14 as the "Maximum number of colours".
2. Save the image to your /boot/grub directory with an extension of .xpm.gz
3. Edit your /boot/grub/grub.conf file so that the splashimage entry points to our new image file. This path will be relative to the start of the /boot partition, so /boot/grub/myimage.xpm.gz would be written as (hdX,Y)/grub/myimage.xpm.gz (where X is the BIOS/Grub disk number and Y is the BIOS/Grub partition number).
   
   # grub.conf generated by anaconda
   #
   # Note that you do not have to rerun grub after making changes to this file
   # NOTICE: You have a /boot partition. This means that
   # all kernel and initrd paths are relative to /boot/, eg.
   # root (hd0,0)
   # kernel /vmlinuz-version ro root=/dev/concord3/f8root
   # initrd /initrd-version.img
   #boot=/dev/md0
   default=0
   timeout=5
   splashimage=(hd0,0)/grub/myimage.xpm.gz
   hiddenmenu
   title Fedora (2.6.23.15-137.fc8)
   root (hd0,0)
   kernel /vmlinuz-2.6.23.15-137.fc8 ro root=/dev/concord3/f8root rhgb quiet
   initrd /initrd-2.6.23.15-137.fc8.img
   title Fedora (2.6.23.14-115.fc8)
   root (hd0,0)
   kernel /vmlinuz-2.6.23.14-115.fc8 ro root=/dev/concord3/f8root rhgb quiet
   initrd /initrd-2.6.23.14-115.fc8.img

Reboot to see the result.

The XPM format used by Grub is very unusual: it's actually a snippet of C source code containing an ascii-to-colour translation table and the image encoded as ASCII art. You can see this by using gunzip to decompress the file and then viewing it as text.

Tips on preparing a grub splash image:

• Choose an image with a small number of colours to avoid excessive dithering or solarization when converting to indexed format.
• Grub displays text in white with a black drop-shadow, so it should be visible against any colour background -- but it it's best to avoid white or really light colours for maximum readability.
  

Fedora, like most current Linux distributions, uses Grub as its bootloader on 32- and 64-bit x86 systems. Grub's configuration file, /boot/grub/grub.conf, typically looks something like this:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,1)
# kernel /vmlinuz-version ro root=/dev/main/root
# initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,1)/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.23.1-49.fc8)

root (hd0,1)
kernel /vmlinuz-2.6.23.1-49.fc8 ro root=/dev/main/root rhgb quiet
initrd /initrd-2.6.23.1-49.fc8.img

title Fedora (2.6.23.1-42.fc8)

root (hd0,1)
kernel /vmlinuz-2.6.23.1-42.fc8 ro root=/dev/main/root rhgb quiet
initrd /initrd-2.6.23.1-42.fc8.img

title WindowsXP

rootnoverify (hd0,0)
chainloader +1

This file contains general options (in green), boot stanzas for Fedora (blue), and a boot stanza for Windows (red).

The general options are:

• default - selects the boot stanza which will be selected by default unless the user intervenes. These are numbered starting at zero.
• timeout - the time in seconds before the default is loaded, if the user does not press a key. To make Grub wait indefinitely for user input, remove this entry. To immediately proceed with the default entry, set the timeout to 0.
• hiddenmenu - hides the boot menu unless the user presses a key. To make the menu appear every time, remove this entry.
• splashimage - selects the image to be displayed in the background of the boot display.

The Fedora stanzas (and those for other Linux distributions, if any) each consist of a title line followed by lines for:

• root - sets the partition for the boot files. Note: this is not the root filesystem! -- this is the partition from which the boot files are loaded.
• kernel - selects the kernel and specifies kernel boot options.
• initrd - specifies a file which contains a compressed filesystem image which is loaded into memory and used as a ramdisk during the boot process.

Grub will load the kernel and initrd from the specified root device, then execute the kernel. Other operating systems, such as Windows, are loaded differently -- so Grub hands the boot process over to whatever bootloader was installed with the operating system, using these lines:

• rootnoverify - like the root line in a Linux boot stanza, this selects the partition which contains the boot files.
• chainloader - instructs Grub to execute the bootloader code located at the second (+1) sector of the selected partion.

Throughout this file, partitions are referred to as (hdX,N) where X is the drive number in the order in which drives are discovered by the BIOS, numbered starting at zero, and N is the partition number, also numbered starting at zero. If your system only has one drive installed, the partition /dev/sda2 (/dev/hda2 under Fedora 6 and earlier) will therefore correspond to (hd0,1) in Grub notation.

If you're using Xen, your Fedora boot stanza will look something like this:

title Fedora (2.6.21-2950.fc8xen)

root (hd0,1)
kernel /xen.gz-2.6.21-2950.fc8
module /vmlinuz-2.6.21-2950.fc8xen ro root=/dev/main/root rhgb quiet
module /initrd-2.6.21-2950.fc8xen.img

In this case, the "kernel" is actually the Xen hypervisor, and the actual dom0 kernel and initrd are loaded as modules to the hypervisor. Any kernel arguments must therefore be added to the module line which references the kernel (/vmlinux-*).

Since gub.conf is a regular text file, you can edit it with the text editor of your choice, such as vi, gedit, or kate. However, if you introduce an error into this file, you may not be able to boot your system from the boot menu. To reduce risk, it's a good idea to keep a known-good stanza in the file -- and in the worst case, you can always edit a boot stanza using the options provided by Grub during the boot process.

During system installation with Anaconda and when managing packages using the Browse mode of Pirut (which appears on the menu as >Applications>Add/Remove Software and identifies itself as Package Manager in its window title), you are given the option of selecting packages by groups arranged into broad categories. Each group may contain mandatory and optional packages, and optional packages in each group may be included or excluded for installation by default. Some packages are not included in any category and cannot be installed through this hierarchy.

The package taxonomy is created by the comps XML files, which are found in /var/cache/yum/*/comps*.xml -- each repository may have its own comps file. These files use an XML format which looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE comps PUBLIC "-//Red Hat, Inc.//DTD Comps info//EN" "comps.dtd">
<comps xmlns="">

<group>

<id>short-group-id</id>
<name>human-readable-group-name</name>
<uservisible>true</uservisible>
<packagelist>

<packagereq type="mandatory">always-installed-package</packagereq>
<packagereq type="default">installed-by-default-package</packagereq>
<packagereq type="optional">not-installed-by-default-package</packagereq>
<packagereq type="conditional" requires="other-package">conditional-installed-package</packagereq>
. . .

</packagelist>

</group>

. . .

<category>

<id>simple-category-id</id>
<name>human-readable-category-name</name>
<description>category-description</description>
<display_order>5</display_order>
<grouplist>

<groupid>short-group-id</groupid>
. . .

</grouplist>

</category>

. . .

</comps>

As you can see, the <category> tag defines the groups in a category, and the <group> tag defines the packages in a group. Text such as the name and description of each category and group is usually provided in multiple languages through the use of the xml:lang attribute.

Packages marked with a type of mandatory in the <packagereq> tag are always installed if the group is installed. Conditional packages are treated as mandatory if the requires package is present: for example, if you install the French language group and have Moodle installed, then French language support for Moodle will automatically be installed. Packages with a type of default or optional appear on the optional package list for the associated group; initially, the default packages are selected, and the optional packages are deselected.

If you install the Apache web server on your Fedora system, start it, and then access it before adding any content, you'll see the "Fedora Test Page" or "Welcome Page" as shown here. Where does this page come from, where is it configured, and how does it disappear once you add content?

This page clearly isn't configured in the main Apache configuration file, /etc/httpd/conf/httpd.conf -- there is no mention of it there at all. Instead, the configuration for this page is actually specified in /etc/httpd/conf.d/welcome.conf, which looks like this:

#
# This configuration file enables the default "Welcome"
# page if there is no default index page present for
# the root URL. To disable the Welcome page, comment
# out all the lines below.
#
<LocationMatch "^/+$">

Options -Indexes
ErrorDocument 403 /error/noindex.html

</LocationMatch>

The LocationMatch directive ensures that this configuration applies only to requests with a path of / (or multiple slashes), which matches only requests to the DocumentRoot (http://ServerName/). For any such request, the Indexes option is disabled, so you cannot get an automatic index or directory listing. If a pre-built index page exists, such as index.html or index.html.var, that file is served; but if it doesn't exist, an HTTP 403 error is generated ("Forbidden"). The ErrorDocument directive specifies the page to be served in that case: /var/www/error/noindex.html. As soon as you create an index page, the 403 error is no longer generated, and the Welcome page disappears.

The configuration file /etc/httpd/conf.d/welcome.conf is owned by the httpd (Apache) package. Most of the other configuration files located in /etc/httpd/conf.d are owned by web application packages such as webalyzer, BackupPC, gallery2, or squirrelmail, and specifically configure Apache for that one application; removing the package removes the corresponding configuration file, removing the application-specific Apache configuration.

If you have a large number of Fedora systems (including virtual machines), you can speed up your system updates by creating a local mirror of the Fedora repositories. This will enable you to download packages once for all machines on your network instead of once per system.

Here is one way to do this:

You will need a machine with a large amount of free space in /var (100GB is safe) and the rsync and httpd packages.

First, create a small script to create and update your repository:

#!/bin/bash
ARCH=i386	# Set to the architecture of your systems
DIR=/var/www/html/fedora/updates/$ARCH/
URL=rsync://mirror/directory/      # See below, include trailing slash
mkdir -p $DIR
cd $DIR || exit
rsync --recursive --delete -v $URL .  # Don't miss the . at the end

Warning: using rsync with the --delete option can have disasterous effects if run in the wrong directory.

Save the script and make it executable (chmod u+rx scriptname). When run, this script will copy the repository identified by the URL to /var/www/html/fedora/updates/$ARCH.

To determine the URL to be used, view the Fedora mirror list at http://mirrors.fedoraproject.org/publiclist/Fedora/7/ and select one of the rsync mirrors. Test it out using the rsync command:

$ rsync -v rsync://selectedhost/

This will show you the contents of the root rsync directory on the remote host. You may need to experiment until you find the directory that contains the RPMS subdirectory for your release of Fedora and machine architecture-- the mirror servers seem to have their own particular directory layouts. You're looking for the directory named os. For example, you might end up with a URL such as rsync://selectedhost/fedora/updates/7/i386/os/

Start the Apache web server (service httpd start) and opening a hole in your firewall for port 80 (use the menu option > System > Administration > Firewall and SELinux) so that your web server is accessible. You will be able to access your local repository mirror as http://yourserver/fedora using a browser.

Finally, configure your systems to use your local repository for updates by setting up a baseurl entry in /etc/yum.repos.d/fedora-updates.repo as described here. Test it out, and once you have it working, configure the cron daemon on the server to run the repository update script daily using this command:

# (crontab -l ; echo "0 4 * * * /path/to/update-script") | crontab

Replace /path/to/update-script with the absolute pathname of the script, and adjust the time according to your needs ("0 4 * * *" means 4:00 am every day).

Fedora employs the Advanced Linux Sound Architecture (ALSA) system, a feature of the 2.6 kernel series. In addition to the kernel drivers, ALSA incorporates a library and a set of utility programs.

You've probably noticed that ALSA settings for various input and output controls are preserved across reboots. The audio device state is saved in the file /etc/alsa/asound.state, a text file which contains a description of each device control and the current values.

This file is created and read by the program /sbin/salsa, which is part of the alsa-utils package. At shutdown, the script /etc/rc.d/init.d/halt calls /sbin/salsa with the -s (save) argument:

# Save mixer settings, here for lack of a better place.
grep -q "\(alsa\)" /proc/devices

if [ $? = 0 -a -x /sbin/salsa ]; then

action $"Saving mixer settings" /sbin/salsa -s

fi

When the udev subsystem discovers audio devices -- usually at system startup, but possibly at later time if an audio device such as a USB soundcard is not present at boot and hot-plugged later -- these two rules in /etc/udev/rules.d/90-alsa-rules are invoked:

SUBSYSTEM=="sound", KERNEL=="controlC*" RUN+="/sbin/salsa"
SUBSYSTEM=="sound", KERNEL=="pcm*" RUN+="/sbin/salsa"

The RUN part of each rule executes /sbin/salsa to restore the audio settings for all devices.