Fedora Daily Package - Wednesday Why

Wednesday Why: Getting an F8 LVM System Ready for F9

nospam@example.com (Chris Tyler) — Wed, 07 May 2008 00:01:00 -0400

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.

Wednesday Why: How does Pulseaudio start?

nospam@example.com (Chris Tyler) — Wed, 27 Feb 2008 00:01:00 -0500

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

Wednesday Why: Customizing the Grub Splash Screen

nospam@example.com (Chris Tyler) — Wed, 13 Feb 2008 00:01:00 -0500

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:

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".
Save the image to your /boot/grub directory with an extension of .xpm.gz
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.

Wednesday Why: Grub Boot Configuration

nospam@example.com (Chris Tyler) — Wed, 28 Nov 2007 00:01:00 -0500

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.

Wednesday Why: Package Categories

nospam@example.com (Chris Tyler) — Wed, 12 Sep 2007 11:25:50 -0400

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.

Wednesday Why: The Apache Welcome Page

nospam@example.com (Chris Tyler) — Wed, 05 Sep 2007 00:01:00 -0400

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.

Wednesday Why: Running a Local Repository Mirror

nospam@example.com (Chris Tyler) — Wed, 29 Aug 2007 00:01:00 -0400

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).

Wednesday Why: Audio Setting Persistence

nospam@example.com (Chris Tyler) — Wed, 22 Aug 2007 00:01:00 -0400

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.

Wednesday Why: Logins and Sessions

nospam@example.com (Chris Tyler) — Wed, 15 Aug 2007 00:01:00 -0400

Allen Halsey asked an interesting question a few days ago:

The bash man page says that .bash_profile is executed by login shells. But I log into my desktop using gdm. So I'm confused at what point is .bash_profile executed. Or is it? If it isn't, where should I define environment variables?

The answer to this question lies in the difference between a login and a session. A login occurs when you authenticate to the system in character mode
and a shell is started for you. Each user's shell is defined in /etc/password; here is my record from that file:

chris:x:500:500:Chris Tyler:/home/chris:/bin/bash

Fields in this file are separated by colons (":"), and the seventh field contains the name of the shell that will be executed upon login. This doesn't have to be a shell in the traditional command-interpreter sense; it can be any valid program, and it's not uncommon to use a menu program or a specific application (such as an e-mail program) for the convenience of inexperienced users or to constrain what the user can do. If the user should not be permitted to login at all, the program /sbin/nologin is specified as the shell, which simply prints the message "This account is currently not available" and exits (tip: you can create a custom message in the file /etc/nologin.txt).

The normal value for the login shell field on a Fedora system is /bin/bash, the Bourne-again shell (a nameplay on the Bourne shell, one of the first and most popular Unix shells). Like other shells, bash executes a startup script every time a shell starts (~/.bashrc) and two profile scripts at each login (/etc/profile and one of ~/.bash_profile, ~/.bash_login, or ~/.profile -- Fedora sets up new accounts with ~/.bash_profile by default). Note the difference: if you login once and then start three shells, /etc/profile and ~/.bash_profile will each be executed once, but ~/.bashrc will be executed three times.

A session, on the other hand, is the graphical version of a login. The session is started by the display manager gdm (or, alternatively, kdm or xdm) when the program starts. The session is under the control of a session manager, which starts standard clients (GUI programs), re-starts certain clients if they die, and optionally restarts clients that were open when the last session ended. The GNOME session manager is gnome-session and the KDE session manager is ksmserver, which is started by the startkde script. This process completely ignores the seventh field in /etc/passwd, and the login profiles are not executed.

But it's not quite that simple: the session manager is started by the script /etc/X11/xdm/Xsession, and in Fedora, that script does not execute the session manager directly. When starting a GNOME session, it executes this command:

exec -l $SHELL -c "$SSH_AGENT $DBUS_LAUNCH gnome-session"

And for a KDE session it executes:

exec -l $SHELL -c "$SSH_AGENT $DBUS_LAUNCH startkde"

The environment variables used in these commands are set by the script /etc/X11/xinit/xinitrc-common. Usually, SHELL is /bin/bash, SSH_AGENT is /usr/bin/ssh-agent, and DBUS_LAUNCH is "/usr/bin/dbus-launch --exit-with-session".

Together, this means that bash is run as a login shell and therefore executes /etc/profile and ~/.bash_profile. It then starts ssh_agent, which then starts dbus-launch, which then starts the session manager. This chain ensures that environment variables set by the login profiles, ssh_agent, and dbus-launch programs are properly exported to the programs running within the session.

We can easily test this execution path by adding some code to the end of the ~/.bash_profile:

# display a message to stdout
echo ".bash_profile executed"
# display a message on the GUI display
zenity --info --text ".bash_profile executed"
# set an environment variable
export FDP=".bash_profile executed"

If we now login in character mode, we see these messages:

Last login: Wed Aug 15 12:04:27 2007 from dailypackage.fedorabook.com
.bash_profile executed

(zenity:3689): Gtk-WARNING **: cannot open display:
[chris@localhost ~]$

Notice that the message ".bash_profile executed" from the echo command is displayed correctly, but that zenity can't display its graphical message because there is no X server available. On the other hand, when we login graphically, the zenity dialog shown in the screenshot is displayed, but the output from echo is not visible (note that since there is no window manager running, the zenity window does not have window decorations such as a border, titlebar, or controls). Regardless of how we've logged in, if we check the environment variable FDP, we find that it has been correctly propagated:

$ echo $FDP
.bash_profile executed

So you can safely export environment variables from your .bash_profile in all cases.

However, if the profile needs to interact with the user, it should detect whether it is running in a character-mode or a GUI environment. If in a character-mode environment, the command tty will return success; if in a GUI environment, the DISPLAY variable should be set. To ask the user a question, you could use code such as this:

if [ "$DISPLAY" ]
then
if zenity --question --text "Do you want to foo?"
then
ANSWER="Y"
else
ANSWER="N" # Default if zenity can't connect to display
fi
elif tty --quiet
then
echo -n "Do you want to foo? "
read ANSWER
else
echo "No tty and no GUI!"
ANSWER="N" # Default if we can't ask the user
fi

In addition to the profiles executed at login and the ~/.bashrc script executed when a shell starts, the ~/.bash_logout script is executed when the user logs out. The Fedora default logout script simply clears the character-mode screen, ensuring that no confidential information is left visible.

Wednesday Why: Fast User Switching

nospam@example.com (Chris Tyler) — Wed, 08 Aug 2007 00:01:00 -0400

Fast User Switching enables more than one user to log in to a local graphical user interface on a computer equipped with a single seat (monitor/mouse/keyboard) and permits quick switching between logged-in users.

Under Gnome on Fedora, the fast user switching agent applet on the panel bar provides access to FUS; under KDE, use the Switch User option on the K Menu. In either case, you'll have the option to switch to an existing session or to start a new session.

When you ask to start a new session, gdm (the Gnome display manager) starts an additional X server on a new virtual terminal (or virtual console) and presents a graphical login prompt on that display. There are 63 virtual terminals available; the user can select any of the first 12 virtual terminals by pressing Ctrl plus Alt plus one of the function keys (F1-F12). In the default configuration, Fedora starts character-mode logins on VT1 through VT6, so X servers start on VT7 and above. As additional user log in, ConsoleKit sets up access to the console devices, such as sound and CD/DVD drives, and tracks which user is on which display and virtual terminal. Switching to an existing session is handled by simply changing VTs, just as you would if you pressed the key combination to select that VT.

You can invoke an additional login from the command line using the gdmflexiserver command. If Xnest is installed, you can also invoke a new session on an Xnest display using the -n option. The chvt command enables you to switch virtual terminals.

Fast User Switching takes capabilities that have existed for years in the Linux kernel and X Window System and makes them readily available and easy to use.

Fedora Wiki page on Fast User Switching (pre-F7 discussion): http://fedoraproject.org/wiki/Desktop/FastUserSwitching

Wednesday Why: Colour ls

nospam@example.com (Chris Tyler) — Wed, 01 Aug 2007 12:14:00 -0400

By default, the Fedora ls command colour-codes file listings when they are displayed on a virtual terminal or terminal window, but not when they are piped into another command. For example:

$ ls -l /etc/sysconfig
auditd
authconfig
autofs
bittorrent
bluetooth
cbq
clock
console
cpuspeed
crond
dund
firstboot
grub
hidd
hsqldb httpd
hwconf
hw-uuid
i18n
init
ip6tables-config
iptables-config
irda
irqbalance
kernel
keyboard
kudzu
libvirtd
lirc
livna-config-display lm_sensors
modules
nasd
netconsole
network
networking
network-scripts
ntpd
oidentd
pand
prelink
readonly-root
samba
saslauthd
selinux sendmail
smartmontools
spamassassin
squid
syslog
system-config-securitylevel
system-config-users
tux
vdr
vdr-plugins.d
vncservers
wpa_supplicant
xendomains
xinetd

Notice that cbq, console, modules, networking, network-scripts and vdr-plugins.d are all in blue (indicating a directory); libvirtd and xendomains are in green (indicating an executable file); and selinux is in turquoise (indicating a valid symbolic link).

The ls output is in colour because ls is actually an alias:

$ alias ls
alias ls='ls --color=tty'

When ls is executed, the option --color=tty is automatically added (note to those in Commonwealth countries: color option has no u here!).

The actual colour associations are contained in the environment variable LS_COLORS, which is set by the script /etc/profile.d/colorls.sh (or colorls.csh if you use csh). This script, which is also responsible for setting up the ls alias, gets the colors from one of several possible configuration files; these are from highest to lowest priority: ~/.dir_colors.$TERM, ~/.dir_colors, ~/.dircolors.$TERM, ~/.dircolors, /etc/DIR_COLORS.$TERM, or /etc/DIR_COLORS (where $TERM is your current terminal type as specified by the TERM environment variable).

All that to say that unless you've customized your system, your ls colours are specified in /etc/DIR_COLORS.xterm and /etc/DIR_COLORS, depending on whether you're using an xterm-compatible terminal window or a virtual console.

The /etc/DIR_COLORS.xterm file contains these lines:

# Below are the color init strings for the basic file types. A color init
# string consists of one or more of the following numeric codes:
# Attribute codes:
# 00=none 01=bold 04=underscore 05=blink 07=reverse 08=concealed
# Text color codes:
# 30=black 31=red 32=green 33=yellow 34=blue 35=magenta 36=cyan 37=white
# Background color codes:
# 40=black 41=red 42=green 43=yellow 44=blue 45=magenta 46=cyan 47=white
NORMAL 00 # global default, although everything should be something.
FILE 00 # normal file
DIR 01;34 # directory
LINK 01;36 # symbolic link
FIFO 40;33 # pipe
SOCK 01;35 # socket
BLK 40;33;01 # block device driver
CHR 40;33;01 # character device driver
ORPHAN 01;05;37;41 # orphaned syminks
MISSING 01;05;37;41 # ... and the files they point to

# This is for files with execute permission:
EXEC 01;32

# List any file extensions like '.gz' or '.tar' that you would like ls
# to colorize below. Put the extension, a space, and the color init string.
# (and any comments you want to add after a '#')
.cmd 01;32 # executables (bright green)
.exe 01;32
.com 01;32
.btm 01;32
.bat 01;32
.sh 01;32
.csh 01;32
.tar 01;31 # archives or compressed (bright red)
.tgz 01;31
.arj 01;31
.taz 01;31
(...lines snipped...)

As you can see, each file type or extension is matched up with a corresponding list of attributes and colors to be used. The color and attribute codes are listed in the comments within this file.

You can easily make a personal copy of this file and modify it to suit your needs:

$ cp /etc/DIR_COLORS.xterm ~/.dir_colors.xterm

If you wanted to show .doc files in white-on-magenta, for example, add this line to ~/.dir_colors.xterm:

.doc 01;37;45

Since 01 is the attribute code for bold, 37 is a white foreground, and 45 is a magenta background.

Wednesday Why: Syslog

nospam@example.com (Chris Tyler) — Wed, 25 Jul 2007 00:01:00 -0400

The /var/log directory contains a number of different log files. Many of these logs are generated by syslogd, which accepts log messages from programs and routes them to log files, the screen, and remote log monitors.

The file /etc/syslog.conf configures message routing. This is the file as shipped in Fedora 7:

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern. /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none /var/log/messages

# The authpriv file has restricted access.
authpriv. /var/log/secure

# Log all the mail messages in one place.
mail. -/var/log/maillog

# Log cron stuff
cron. /var/log/cron

# Everybody gets emergency messages
*.emerg

# Save news errors of level crit and higher in a special file.
uucp,news.crit /var/log/spooler

# Save boot messages also to boot.log
local7. /var/log/boot.log

This file consists of comment lines, which start with #, and routing lines, which consist of a message specification and a destination. The message specification consists of one or more selectors, which specify a pattern of facilities and levels separated by a period.

The facility indicates the origin of the log entry. Possible values are authpriv, cron, daemon, ftp, kern, local0 through local7, lpr, mail, news, syslog, user, and uucp. The level is a priority value and may be (in order of increasing severity) debug, info, notice, warning, err, crit, alert, or emerg.

In selectors, a level written by itself selects messages of that level or highers, a level preceeded by an equal sign indicates messages only of that level, a prepended exclaimation mark means "not", and an asterisk matches anything. The dummy level none is equivalent to !* and is used to prevent all matches with a particular facility. A semi-colon is used to AND multiple selectors, and a comma is used to OR facilities or levels within a selector.

Interpreting the default syslog.conf file, we see that all messages of info level and higher except those from the mail, authpriv (authentication), and cron systems are placed into /var/log/messages. Messages from authpriv are placed in /var/log/secure (because they may reveal sensitive information and require more restrictive read permissions on the log file), messages from mail are placed in /var/log/maillog (the leading - indicates that the file's buffers are not flushed after each write), and messages from cron are placed in /var/log/cron. Emergency (and higher) messages are written to all open terminals (*), critical messages from uucp and news are additionally placed in /var/log/spooler, and boot messages (local7) are placed in /var/log/boot.log.

It's often useful to log your own sysadmin activity in /var/log/messages. Since these are interleaved with messages from system processes, it's easy to determine the the sequence of events. You can create log entries from the command line or in a script by using the logger program; it is perhaps most convenient to define an alias to do this:

$ alias note="logger -p local4.notice"
$ note Edited httpd.conf to create a virtual host for fedorabook.com

You can execute the note alias with a some text any time you want to create an entry in the log file.

It can be useful to collect messages from a group of machines (or virtual machines) into one log file. This centralizes your logs for easy examination, and it makes it harder for an intruder to hide their tracks by altering the log file (since they need to compromise the log server in addition to the primary attack target). To configure the log server to accept messages from remote machines, add -r to the SYSLOGD_OPTIONS line in /etc/sysconfig/syslog, open up UDP port 514 on the server's firewall, and restart syslog with the command service syslog restart

To configure a client system to send messages to a log server, add a line to /etc/syslog.conf with a destination of @logserver, where logserver is the hostname of the system accepting log messages (make sure the hostname is resolvable by placing it in /etc/hosts). Here is an example, which logs all messages of priority notice and higher to the host logmaster:

*.notice @logmaster

Many LAN devices such as routers and networked printers can also be configured to send messages to a log server.

Warning: It is possible to cause a denial-of-service condition--intentionally or accidentally--by flooding a log server with so many messages that the filesystem storing the logs overflows. It is a good idea to use a separate filesystem for /var/log/messages on a log server so that excessive log entries do not interfere with the normal operation of that system.

An enhanced version of syslog named syslog-ng is available in the Fedora repositories. Fedora 8 will introduce rsyslog, which supports encrypted and authenticated log message forwarding, message rewriting, filtering based on message content, and the use of MySQL as a message store (enabling advanced reporting using SQL queries).

Wednesday Why: Crontab

nospam@example.com (Chris Tyler) — Wed, 18 Jul 2007 00:01:00 -0400

Cron is the Unix/Linux task scheduler. It uses crontab (cron table) files to specify the date and time that specific tasks are to be executed. The master system-wide crontab file is /etc/crontab; additional system-wide crontab files may be placed in /etc/cron.d, and personal crontab files (which are managed with the crontab command) are placed in /var/spool/cron/.

The master crontab file looks like this:

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# run-parts
01 root run-parts /etc/cron.hourly
02 4 root run-parts /etc/cron.daily
22 4 0 root run-parts /etc/cron.weekly
42 4 1 * root run-parts /etc/cron.monthly

The name and value pairs at the start of this file set up exported environment variables. The remaining lines contain five date and time fields (minute, hour, day of the month, month of the year, and day of the week), the account name under which the command should be executed, and the name of the command. (Personal crontab files are installed with the crontab command and do not contain the account name field).

The run-parts script simply runs each of the scripts within the specified directory. One of the scripts in each of those directories is named 0anacron and is designed to update timestamp files stored in /var/spool/anacron; these timestamps are used by the anacron system at boot time to ensure that the daily, weekly, and hourly jobs still get executed even if the computer is never on between 4:00 and 5:00 am.

For example, an office system which is turned off by the user each evening and turned on at 9:00 am each morning will never be on at 4:22 am when the scripts in the /etc/cron.weekly directory are executed. One of the jobs performed weekly is makewhatis, which rebuilds the whatis database used by the apropos, man -k, and whatis commands, so those commands would never have access to an up-to-date index. To solve this problem, when the system is booted, the init script /etc/rc.d/init.d/anacron checks the file /var/spool/anacron/cron.weekly to see when the scripts in /etc/cron.weekly were last run; if it was more than 7 days ago, the scripts are executed after a brief delay using run-parts.

Packages that requires scheduled execution of jobs can be configued in either of two ways: they can include a crontab file which will be placed in /etc/cron.d (the approach used by the smolt package), or they can include a script file which will be placed in /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, or /etc/cron.monthly (which is the approach used by cups).

Wednesday Why: Menus

nospam@example.com (Chris Tyler) — Wed, 11 Jul 2007 12:43:41 -0400

Fedora's application menus include many different programs from different packages. Fedora supports multiple desktop environments, including GNOME, KDE, and Xfce, and each of these has a different menu structure, which may include or exclude certain proograms, such as the control panels for each environment. Each menu title and menu entry can be be presented in multiple languages. Furthermore, the menu layout has changed between Fedora releases, even though some of the packages have not changed. How does this all work?
Continue reading "Wednesday Why: Menus"

Wednesday Why: The login prompt

nospam@example.com (Chris Tyler) — Wed, 04 Jul 2007 00:01:00 -0400

Most Fedora users realize that there are two ways to locally log in to a Fedora system: using a character-mode display, or through the graphical user interface. In the default configuration, six separate character-mode login screens are available, accessed by pressing Ctrl-Alt-F1 through Ctrl-Alt-F6. The X server which underlies the GUI display operates on another virtual terminal, accessed with Ctrl-Alt-F7. When you boot your system into runlevel 3, only the character-mode logins are available; when you boot into runlevel 5 (which is the default), the GUI is also started. To change the default runlevel, edit /etc/inittab and change the second field of the initdefault line; it makes sense to boot server systems into runlevel 3, because the GUI will be rarely used and unnecessarily consume memory which could be better used for other purposes (you can start the GUI at any time by switching to runlevel 5 (init 5) or by starting the GUI after login (startx)).

The login prompt presented on the character-mode screens is taken from the file /etc/issue. In some old versions of Fedora the /etc/issue file was overwritten at each boot by the startup scripts, but this is no longer the case. The default login prompt looks like this:

Fedora Release 7 (Moonshine)
Kernel 2.6.21-1.3228.fc7 on a x86_64
foomaster login:

The italicized text will vary according to your kernel, CPU architecture, and hostname. This is configured in /etc/issue as:

Fedora release 7 (Moonshine)
Kernel \r on an \m

Several substitutions are available within the text:

Sequence	Expanded Value
\d	date
\l	virtual terminal
\m	CPU architecture
\n	network node (usually equal to the fully-qualified hostname)
\o	domain name
\r	kernel version
\t	time
\s	OS name
\u	number of current users
\U	number of current users, followed by the text " users"
\v	OS version (kernel compilation date)

The line ending in "login:" comes from the mingetty program.

You can include as much or as little text as you want in this file, but it's foolish to include more than one screenful. Some examples:

Welcome to hostmaster.example.com!

Or:

Webserver #1 (www1.example.com)
System administrator: r.k.ryale
Phone 905-555-5555 extension 4321 before taking this system offline or in the case of problems.

Or:

Private system. Unauthorized access prohibited and will be prosecuted to the full extent of the law. All access is monitored.

Or:

This is the experimental scratch system "demo". To login, enter the user ID "guest" and the password "please". The root password is "root". Enjoy! If you destroy the system, please reinstall Fedora 7 with the same passwords.

If you provide telnet access to your system, which should only be done for low-security / no-security systems, a similar pre-login message can be provided for remote users in the file /etc/issue.net.