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