1.7. My Users Mess Up Their Desktops
Once you've made all of these changes, you may want to keep your users from messing them up. While I personally prefer allowing every user to customize his system, your managers may not agree.
There are two basic approaches to this process. First, you can disable access to the key tools. Second, you can change ownership and permissions on associated configuration files to prevent changes by regular users.
You can also make your changes a part of the /etc/skel directory, which causes them to be copied into the home directories of all users created subsequently. For example, the following command creates the new user nancy; the -m option (not required on Red Hat/Fedora) creates Nancy's home directory in /home/nancy, and activates the defaults in /etc/default/useradd, copying the files from /etc/skel,with appropriate ownership and permissions, into Nancy's home directory:
useradd -m nancy
1.7.1. Disabling Changes on KDE
The KDE desktop configuration is driven by both default and individual configuration files. Naturally, what you do depends on what you want to customize; do you want a standard desktop for just a few users or for every user on your network?
The default configuration files depend on the distribution, as shown in Table 1-8.
Individual configuration files are stored in each user's home directory in the ~/.kde/share/config directory. If you haven't yet configured custom settings for a specific user, the user-specific configuration file probably does not yet exist.
Once you make desired changes to one individual's ~/.kde/ directory, you can copy it to the home directory of other users. You can also copy it to the /etc/skel directory. As described earlier, this directory is often used to populate the home directories of new users with standard configuration files.
The key to preventing changes by pesky users is the immutable flag. In KDE configuration files, you can specify it through [$i]. For example, to lock the standard configuration, I've added this flag to the beginning of each stanzafor example:
In any case, changes aren't displayed until the next time you log in to the KDE desktop environment.
1.7.2. Restricting Actions on KDE
The KDE desktop environment includes a number of options suitable for kiosks, which are common locations for public terminals. If you administer a public terminal, you'll probably want to freeze the desktop configuration of that terminal. What you do for workstations in an office may also incorporate some of the same limitations.
In the previous section, I've covered some of the things you can do to disable configuration changes. You can also restrict such actions as starting a command-line interface, running as the root user, or changing the background. Open a kdeglobals configuration file and start a stanza with the following title:
[KDE Action Restrictions][$i]
On a workstation, you may want to keep certain users away from the command-line interface. You can do so in this stanza with the following directive:
By default, users can also start applications from the Run Application window, invoked through Alt-F2. If you want to disable access to this window, add the following directive:
You can keep users from using any KDE utilities that require the root account with a directive such as:
But users don't need the root account to customize many things on the KDE desktop. You can further limit access to different modules in the KDE Control Center, in a different stanza, starting with:
[KDE Control Module Restrictions][$i]
Here, you can limit access to the modules of your choice. For example, if you want to keep users from changing their own KDE desktop backgrounds, add the following directive to this stanza:
To keep your users from changing their screensavers, include the following directive:
If you want to limit access to another module, you simply need to know the name, as defined in the output from the following command:
Then, to limit access to the module of your choice, just substitute the name of that module in the following directive:
1.7.3. Disabling Changes on GNOME
The key to a standard GNOME desktop environment is the GConf system. Readers familiar with Microsoft Windows might notice parallels to the Registry Editor. You can start the GConf editor with the gconf-editor command (normally, it's in the /usr/bin directory; on SUSE, it's in the /opt/gnome/bin directory). There are three types of GNOME settings. What each user sees is an amalgamation of these:
22.214.171.124. Configuring system-wide GNOME desktop settings
To configure system-wide settings on the GNOME Desktop Environment, open the GConf editor as the root user. In some distributions, this is possible only with the sudo command; for example, on Debian Linux, I can open GConf while logged in to the K Desktop Environment with the following command:
1.7.4. Disabling Menu Items on GNOME
Sometimes the easiest way to keep users from changing their standard desktop environments is to disable the GUI menu items. In other words, if the user doesn't see the administrative tool, he's less likely to want to try to use it.
Default GNOME main-menu files are located in the /usr/share/applications directory. User-specific menu files are located in each user's home directory, in ~/.config/menus. Managing the GNOME menu items is a straightforward process; for example, if your SUSE Linux computers are configured with the GNOME Desktop Environment, and you want to disable GNOME menu-based access to the YaST configuration tool, move (don't delete) the YaST.desktop file from the /usr/share/applications directory. (I move it to my home directory, in case I ever want to restore the menu option.)
If you're already in the GNOME Desktop Environment, check your menu. The changes are shown immediately on the Red Hat/Fedora and Debian distributions. The changes aren't shown on SUSE Linux until the next time you start GNOME.
Now you can implement these changes to the other desktop systems on your network. Remember, if you're removing items from the GNOME desktop menus, you'll have to remove the corresponding items from the /usr/share/applications directory on each of your target systems.