Section B.2. Configuring Applications and Environments

B.2. Configuring Applications and Environments

If you're familiar with administering Windows desktop systems, many of the issues involved in administering Linux desktop systems will be similar, but others are unique. Likewise, if you're already familiar with Linux system administration in other contexts (such as servers), desktop environments present some unique challenges. Some of the issues in Linux desktop configuration include understanding the difference between global and user configuration files, locating configuration files, creating default desktop configurations, and making desktop environments accessible as options at login time.

B.2.1. Global Versus User Configuration Files

Linux has long supported multiple users. Part of this support includes mechanisms to help keep users' configurations separateenabling two users to use the same computer but set different defaults for assorted application and desktop environment options. Even if a computer has a single user, Linux uses these features, maintaining nominally separate global and user configuration files. You can take advantage of this distinction to set global defaults, which users can then modify without impacting other users' settings. On a system with a single user, you can use this distinction to easily restore a user's settings to the default if the user's settings become corrupt.

Typically, global configuration files are stored in a system area. These files can be used in one or both of two ways:

• User programs can access the global configuration files directly, using them to direct program operation in a way that's invariant from user to user. If a program supports only this mode of operation, users can't change their default.

• Users or user programs can copy the global configuration files to a subdirectory in the user's home directory and then access the copied files for normal operation. This approach enables users to change their personal defaults without impacting other users.

Most user programs support use of local configuration files, at least as an option. Some programs automatically copy global configuration files the first time they're run. Others use the global files directly unless users copy the global files to their home directories or create their own configuration files from scratch. Sometimes a global file serves as a template that can be modified by a local file.

Ultimately, you'll have to consult a program's documentation to learn how it treats these two types of configuration files. This knowledge can be important when setting defaults. For instance, if a program always consults a global file, you can change defaults even for users who've already begun using a program, so long as they've not explicitly changed a default; however, if a program copies global configuration files to the user's home directory the first time it's run, changing the global configuration files affects only users who begin using the program after you make changes.

The precise methods used to modify configuration files differ from one program to another. Traditionally, Unix and Linux programs have used text-mode configuration files that can be edited in a text editor. This remains true, but many of the more sophisticated GUI programs now create very complex configuration files, often using the Extensible Markup Language (XML). Such files can be difficult to modify by hand, particularly if you're not familiar with XML or the specific XML conventions used by the program in question. Thus, one approach to making changes is to create a dummy account, change the defaults using that account, and copy the dummy account's local configuration files back to the global configuration file's location.

Don't blindly overwrite existing global configuration files. If you make a mistake, doing this can render a program unusable, at least to new users of the program. Before replacing a global configuration file, back it up someplace safe. If you don't, you may need to reinstall the program should you make a mistake in creating the new configuration file.

B.2.2. Locating Configuration Files

One location for global configuration files is /etc/skel. This directory holds template configuration files that may be copied to a new user's home directory when an account is created, depending on the options to useradd or other account-creation tools. Once files are copied from /etc/skel, user applications don't normally access this directory. Thus, making changes to files in /etc/skel won't normally affect how existing users' applications work.

Typically, /etc/skel contains a rather small set of filesperhaps just for your system's default shells, for instance. These files are normally all dot files, meaning that their filenames begin with dots (.), which means that they don't show up in file listings unless you include special options, such as the -a option to ls.

Other directories in /etc hold many other application-specific global configuration files, often named after the programs they control. For instance, /etc/gimp holds global configuration files for GIMP, /etc/xfce4 holds global configuration files for Version 4 of XFce, and /etc/xcdroast.conf is the global configuration file for X-CD-Roast. Most configuration files in /etc, though, belong to system utilities and servers rather than user applications.

Many desktop programs store their global configuration files somewhere in their own directory tree. One good way to locate these files is to use your package management system to list all the files that belong to a package. For many packages, though, this action produces a large list of filesdocumentation files in multiple languages, graphics files used to display icons in the program, and so on. You might get lucky by piping the result through grep to search for a string like conf, but this procedure isn't guaranteed to work.

Programs associated with the major desktop environments (particularly GNOME and KDE) often store their global configuration files in a directory along with the desktop environment. This location can vary from one distribution to another, as described shortly.

Some programs don't ship with global configuration files per se; they store their defaults in their executables and rely exclusively on user configuration files to override these defaults. If you want to change your systemwide default for such programs, you may need to generate user configuration files in a dummy account and then copy those files to /etc/skel. This approach won't change the defaults for existing users, though.

B.2.3. Creating Default Desktop Configurations

Perhaps the most important type of configuration file you might want to modify is that for your desktop environmentKDE, GNOME, XFce, or what have you. Users see their desktop environments when they first log in; making frequently used programs, file shares, and so on easy to access on your network's standard desktop will go a long way to helping your users make the transition to Linux and be productive in that environment. Typically, the way you manage this task is to create a desirable template configuration in a dummy account and then to copy that template configuration to the desktop environment's global configuration file area.

B.2.3.1 Creating a template configuration

To begin the task, create a new "dummy" userone who exists only to enable you to create a new desktop configuration. Log into this account using the desktop environment you want to modify. (If this environment isn't an option when you log in, consult the later Section B.2.4.) You can then tweak the desktop environment as you see fit. Features you might want to adjust include:

Desktop icons

Most desktop environments, including KDE and GNOME, enable you to create desktop icons that launch programs or open file browsers on particular directories. Creating such icons for important programs and directories can help users navigate the system. Don't go overboard, though; too many icons can clutter the desktop and be confusing, particularly for users who've never used a system before.

Program launching menus

Most desktop environments include a tool, often called the Panel, which houses program-launching icons. Some icons appear directly on the Panel, but more can be referenced in menus. Most distributions attempt to provide ready access to most common programs from their Panel menus, and many will automatically add programs when you install them using the distributions' package-management tools. Nonetheless, you might want to rearrange the menus, delete programs to reduce clutter, or add programs that aren't added by default. Some desktop environments, such as KDE, maintain separate global and user program launch menus. To make global changes, the best approach is to change the global file, which for KDE is called applnk and is usually located in /usr/share, /usr/kde/version/share or a similar location.

General desktop defaults

Desktop environments all present numerous defaults that influence the overall look and feel of the system. These include default program fonts, desktop background images, keyboard repeat rate, window border decorations, and so on. Technically, these defaults may apply to dozens of different programs; however, most desktop environments provide a centralized control panel through which most or all of these options may be set. Although all major Linux distributions ship with defaults that are at least somewhat reasonable, you might want to change some, either because you think the default is not the best or to customize the system for your environment (say, using a background image with your company's logo).

You can set certain font defaults in a desktop environment; however, these defaults apply only to the desktop environment and to affiliated programs. You may need to change default fonts in many programs individually to make such a change truly universal. Actually installing new fonts that don't ship with the distribution is another matter, too; the Section B.5 later covers this issue in more detail.

When you're done making these changes, log out and then log back in again to be sure they're working as you intended. Some programs (particularly older ones or those that aren't officially part of a desktop environment) require you to explicitly save a configuration before its changes are saved, so it's easy to make changes and then lose them when you log out.

You may want to consult with your end users when designing a default desktop environment. Try creating two or three possible defaults and ask a few typical users to comment on them.

B.2.3.2 Copying the template to be a global configuration

Your template user's configuration is now saved in the template user's home directory. You can look for it using the -a option to ls (the -F option can also be helpful because it distinguishes directories from files).

# ls -aF /home/genie ./             .bashrc   .gnome/            .metacity/        Desktop/ ../            .dmrc     .gnome2/           .nautilus/ .ICEauthority  .gconf/   .gnome2_private/   .recently-used .bash_profile  .gconfd/  .gtkrc-1.2-gnome2  .xsession-errors

This example shows the files created by the desktop environment (GNOME in this case), as well as those copied from /etc/skel during account creation and any others created during the login process. The .ICEauthority, .bash_profile, .bashrc, .dmrc, and .xsession-errors files aren't part of the desktop environment configuration. The .recently-used file, although used by GNOME, can be safely ignored because it holds information on recently accessed files; chances are you don't need or even want to copy that information into new accounts.

To copy the template you've created so that all new users can access it, you must copy the files and directories to an area in which they'll be used by new accounts. One way to do this is to copy everything into the /etc/skel directory. When you do this, the files will be copied whenever a new account is created and its initial files set from the /etc/skel template.

B.2.4. Adding an Environment as a Login Option

If you want your users to be able to log into a specific GUI environment, you must be able to tell the computer to make that environment the default, or at least to present the environment you want as a default. To do this, you must first understand how to get a GUI login tool running. Once this is done, you need to know how to change defaults and present options with your tool of choice.

B.2.4.1 Running a GUI login tool

Many Linux distributions today come configured to boot directly into GUI mode by default. Most distributions, including Fedora, Mandrake, Red Hat, and SuSE, enable you to control this feature by editing a single line in /etc/inittab:

id:3:initdefault:

The number in the second colon-delimited field (3) in this example sets the default runlevel. Typically, runlevel 3 corresponds to a text-mode boot, whereas runlevel 5 corresponds to a full GUI boot. (Some distributions, such as older versions of SuSE, used runlevels other than 3 and 5 for these functions.) The latter is very much like the former, except that in a GUI boot, an XDMCP server is launched, as described in Chapter 11. The purpose in a default configuration isn't to provide remote access, though; the default XDMCP configuration locks down the XDMCP server so that it provides only local GUI login access.

A few distributions, such as Debian and Gentoo, do things differently: rather than use the runlevel to signal whether a GUI login should be enabled, they set a SysV startup script to do the job. You can enable or disable this startup script to change the distribution's GUI login status. Debian uses scripts called xdm, gmd, or kdm for the X Display Manager (XDM), GNOME Display Manager (GDM), or KDE Display Manager (KDM) tools, respectively. Gentoo has a single script called xdm that starts whichever tool you've chosen to use.

All distributions provide some method of selecting which XDMCP server to run. Most distributions do this by setting a variable in a configuration file. Fedora, Red Hat, and Mandrake use /etc/sysconfig/desktop; Gentoo uses /etc/rc.conf; and SuSE uses /etc/sysconfig/displaymanager. In all these distributions, you set the DISPLAYMANAGER variable. Most distributions accept either the name of the XDMCP server, such as KDM, or the name of an associated desktop environment, such as KDE. Debian works a bit differently; it sets the path to the default XDMCP program in the /etc/X11/default-display-manager file.

B.2.4.2 Presenting desktop environment options

Different XDMCP servers require different configurations to present login options to users. The simplest of these tools, and the least convenient from a user's point of view, is XDM. This server presents no login-time options; instead, it relies on a configuration file to set the default desktop environment. The global version of this file is /etc/X11/xdm/Xsession, which is often a link to /etc/X11/Xsession. Users can override this default by providing a file called .xsession in their home directories. In either case, this file is a script, so you can configure it to run a particular desktop environment by providing appropriate commands, such as gnome-session to run GNOME, startkde to start KDE, or startxfce4 to start XFce. A simple script can contain nothing but a reference to the environment startup script:

#!/bin/bash /usr/bin/startxfce4

More complex scripts are possible, of course. The default XDM Xsession script typically tests for the existence of several desktop environments and, from among those that are available, starts the one that's most preferred by the distribution maintainer.

KDM and GDM are both more complex. They provide the user with a set of options, typically accessed by clicking a button in the GUI display. In most cases, when you add a new desktop environment, your KDM and GDM configurations will be modified to present the new desktop environment as an option to users. Sometimes, though, you need to take extra steps to see that this happens.

KDM and GDM both look in a directory for a list of sessions. This is often the /usr/share/xsessions directory, although it could have another nametry typing find /usr -name "*.desktop" to locate the directory if you can't seem to find it. Both KDM and GDM look for files whose names end in .desktop. These files provide information on how to launch a desktop environment. If you need to add such a file, you should probably begin by copying an existing one and modifying it. Existing files are likely to be rather long because they often contain options to set the name in multiple languages. A short example looks like this:

[Desktop Entry] Encoding=UTF-8 Name=KDE Comment=This session logs you into KDE Exec=startkde TryExec=startkde Type=Application

To modify the system, edit the Exec and tryExec lines to point to the desktop startup command. Modifying the Name and Comment lines will also enable your users to correctly identify the environment.

Many distributions install a large number of .desktop files in some other location, such as /usr/share/apps/kdm/sessions/. These files might not be used by default, but you should be able to copy them to the appropriate directory rather than create new files. If your distribution does this, you can locate it with the find command mentioned earlier.

Once you've added a new environment to the configuration, you'll have to restart the XDMCP server. In most distributions, you can do this by typing telinit 3 followed by telinit 5 at a command prompt. This action brings the system to runlevel 3, then back to runlevel 5. In the process, it shuts down the XDMCP server and restarts it. With Debian and Gentoo, you can use the SysV startup scripts to shut down and then restart the XDMCP server.

Restarting the XDMCP server also shuts down the console's X session. Thus, you should save any unsaved work before attempting this procedure.