Customizing the User Environment

---

This section will discuss how to tailor the login shell configuration scripts on a Slackware Linux system. In Chapter 4, Red Hat's login script framework was discussed. Readers should consult that chapter for comparison, but to put it briefly, Red Hat Linux makes use of the config.d drop-in configuration file model. Actually, this section is going to be very simple, since Slackware's user shell scripts are substantially similar to Red Hat's.

The basic model is the same as that used by Red Hat Linux. The main scripts (for both csh and sh shells) set some basic parameters, and then look in the directory /etc/profile.d for additional "drop-in" files for the shell. The sh-based shells (usually bash, ash, ksh, and zsh on Slackware) read files whose names end with .sh; the csh shell (which is almost always tcsh on Linux systems) look for files whose names end with .csh. This is the same mechanism used by Red Hat Linux, so readers should definitely consult Chapter 4.

However, there are some differences. First and probably most noticeably, Slackware's scripts are quite a bit simpler than Red Hat's, in keeping with the Slackware philosophy. Red Hat's, on the other hand, are arguably more sophisticated and do a bit more. It's the classic tradeoff of simplicity versus functionality, and we see yet again that Slackware leans toward simplicity.

The other major shell configuration difference between Slackware Linux and Red Hat Linux is in the use of the files. Red Hat uses the files /etc/bashrc and /etc/profile to manage bash and other sh-based shells, respectively. By using a separate /etc/bashrc file, Red Hat is able to configure the environments of bash users to take advantage of extended bash features. Slackware, in contrast, has no /etc/bashrc and simply "reuses" /etc/profile for all sh-derived shells. Also, Slackware curiously places all csh configuration in /etc/login—/etc/cshrc is empty.

Red Hat uses /etc/csh.cshrc for basic configuration and /etc/lcsh.login for configuration that's only appropriate for login shells (as opposed to shells that are started to run scripts).

Changing a User's X Window Desktop Environment

Chapter 4 mentioned the switchdesk program on Red Hat Linux that is used to change a user's preferred X Window desktop environment; this section will discuss how to accomplish the same task on Slackware Linux. Slackware doesn't have the switchdesk program (or any equivalent) and relies on a more traditional way of accomplishing the task.

By default, Slackware Linux uses the desktop manager from the KDE project, called KDM. KDM allows the user to select one of the installed desktop environments, and will use that environment for the duration of the user's session.

Note 

A desktop manager is the graphical program into which you enter your username and password to log into X. The other alternative is to start X from the command line via the xinit command.

When the user logs in, KDM executes the script /etc/X11/xdm/Xsession and gives it the name of the desktop the user selected as its first argument. The Xsession script then starts up the desktop environment corresponding to the user's choice. However, if the user has an executable program in her home directory called xsession, that program (which can be a script) will be executed instead, bypassing any selection the user made in KDM.

When the user selects a desktop from KDM, the selection is recorded in a file in the user's home directory called .wmrc. This file contains a single word indicating the user's most recently selected desktop. This file is used by KDM to "remember" the user's choice the next time he accesses KDM.

All that's fine and well, but it doesn't really answer the question of how a user changes her desktop environment. Well, given the mechanism just described, there are two ways. First, the user can simply edit the file ~/.wmrc and change the word in that file to another environment. However, this is rather pointless since it's probably easier to simply select a new desktop from the pull-down menu in the desktop manager. The second way is to create a ~/.xsession file that contains (or more frequently points to, via a symbolic link) a program to start the user's environment. This setting will always take priority over anything the user might select in the desktop manager. For example, the following link command will designate GNOME as the user's desktop environment.

 ln -s /opt/gnome/bin/gnome-session ~/.xsession 

If the user selected default and has no ~/.xsession file, the Xsession script simply executes the default environment by invoking /etc/X11/xinit/xinitrc (which itself is a symbolic link to one of the other files in /etc/X11/xini/xinitrc, each of which handles a different environment). It's probably becoming clear that the scripts that handle all this are fairly complicated. Other distributions, such as Red Hat Linux, are arguably even more complicated and elaborate. This complexity is why programs like Red Hat's switchdesk are written. Slackware keeps things comparatively simple, and users can change desktops manually by either creating a ~/.xsession file or selecting the desired environment from the desktop manager during the login process.

Adding New Hardware

One of the common complaints about Linux systems is that hardware support is occasionally spotty and sometimes difficult to configure. This section will discuss how to install and configure new hardware in Slackware Linux. In Chapter 4, Red Hat Linux's kudzu tool for automatically detecting and configuring new hardware was discussed; unfortunately, Slackware Linux has no equivalent tool, and the procedure is more manually intensive.

By now, we've seen several examples of the Slackware philosophy of simplicity and self-sufficiency. Perhaps the most explicit example of this is in its support for hardware. Recall that Slackware ships with stock Linux kernels. There's no easy way around it: the process for adding support for new hardware to a Slackware system is simply to configure the Linux kernel itself to support the new hardware (typically by configuring support for the device driver in kernel module form) and then load the module into Slackware.

In most cases, once you have the Linux kernel either compiled with the device driver built-in or compiled as a module, the kernel will either detect the device on startup or else automatically load it on demand. Slackware relies on this behavior for setting up hardware, and generally it's pretty straightforward to get the driver loaded. The main difficulty lies in configuring the rest of the system to make use of the rest of the new device; for example, adding a USB compact-flash card reader involves not only compiling and loading the kernel modules, but also creating a mount point and modifying the /etc/fstab file appropriately.

Red Hat's kudzu tool automates most of these tasks. Unfortunately, there's no easy way to do this on Slackware, and so administrators have to roll up their sleeves and dig into the system configuration. If a mount point needs to be created, it'll have to be done manually; if a module needs to be loaded in a certain order, it'll have to be done from /etc/rc.d/rc.local or rc.M; if a new block device (i.e. a disk) is installed, it will need to be configured in the /etc/fstab file.

This is all fine and well, of course, but it doesn't help the administrator much. There's no checklist that an administrator can go through to install new hardware; when it comes right down to it, there are just too many cases to consider to make a truly comprehensive checklist. What's an administrator to do, then? Hopefully this book will provide the tools and knowledge that are required to do this.

---