The Linuxconf utility is a modular configuration tool; it consists of a framework that accepts configuration modules to handle specific servers and other configuration
. You can run Linuxconf in text mode (in which it uses text-based
), in GUI mode (in which it runs in a separate window), or via a Web-based interface (accessed via a Web browser, as discussed in Chapter 16). The GUI interface requires not just the main
package, but a separate package typically called
. If Linuxconf can use its GUI tools, it does so automatically;
back on its text-based mode. This section emphasizes the local GUI access
, but the same options are available in text-mode or Web-based access; only the details of the
interface are different. The details of the GUI interface
somewhat from one distribution to another. In particular, Red Hat uses a single window and displays all the configuration modules in that window, whereas Mandrake uses separate
for each configuration module.
When first launched, Linuxconf
an expandable list of configuration areas, broken down into three tabs: Config, Control, and Status. Each area has subareas, until you reach specific configuration modules. (In Mandrake's implementation, you click on one area to obtain a separate window showing the options within that area, and so on until you reach the configuration module you want.) Figure 4.2 shows Red Hat's implementation of this model, with the Control
Control Service Activity module selected. This module allows you to control SysV startup scripts and servers started through
. To enable or disable a server, follow these steps:
Start Linuxconf and locate the Control
Control Service Activity module, as shown in Figure 4.2.
Figure 4.2. You can use
to control many aspects of a Linux system's operation.
Locate the server you want to control in the list on the right. For instance, to control sendmail, you'd locate the sendmail item and click it. The result is a new tab on the right of the Linuxconf window showing the current status of the server.
Click the Run Levels tab. The display should now resemble Figure 4.3. You can enable or disable the server for any of the specified runlevels by clicking the checkboxes
to each runlevel number.
Figure 4.3. You can control servers through Linuxconf by enabling or disabling a server in any of its runlevels.
Click Accept in the Service tab, then click Dismiss in the Service Control tab.
Act/Changes from the Linuxconf menu bar. The program will display a list of the things it will do. Click Do It to accept these changes.
At this point, your system should be reconfigured to launch the servers in the runlevels you've selected. You can verify this with
or by examining the filenames in the SysV script link directory.
In addition to enabling or disabling servers, Linuxconf includes the ability to configure some servers. As Red Hat and Mandrake have been moving away from the use of Linuxconf, they have omitted more of these configuration modules with each new version of their distributions. You can locate many of them on the Linuxconf Web site, although they don't always work correctly. The problem is that server configuration file locations, and even the contents of the files, vary from one distribution to another or from one version of a server to another. This makes creating a truly universal configuration module
for many servers.
Using YaST and YaST2
SuSE's Yet Another Setup Tool (YaST) and YaST2 are text-based and GUI configuration tools, respectively. Although they feature different user interfaces, the two tools provide very similar options. This section emphasizes the use of YaST2, but you shouldn't have trouble using YaST if you choose to do so. (For simplicity's sake, I use the word
to refer to both tools unless the distinction is important.) You can launch the text-mode YaST by typing
, or YaST2 by typing
. The main YaST2 window resembles the one shown in Figure 4.4. You select broad areas of configuration from the list on the left, and specific configuration tools from the options on the right.
Figure 4.4. YaST provides several specific configuration tools that are grouped into a handful of specific configuration categories.
Because SuSE uses the
file to control the startup process, as well as the naming of files in the SysV script link directories, YaST must alter the configuration file to handle server
. In fact, this is the primary means that YaST uses to control server startup. The naming of the tool to alter these options reflects this fact: It's the RC-Config Editor tool in the Misc section. Click this tool, and YaST2 displays the window shown in Figure 4.5. Most of the network server startup variables are located in the Start-
Start-Network area. Click one of the specific options, as shown in Figure 4.5, and YaST allows you to edit the variableusually to set it to Yes or No, which causes the server to start or not start, respectively.
Figure 4.5. Network server startup in YaST involves setting variables to Yes or No.
YaST can also control many other aspects of network configuration. Indeed, many important variables for specific servers are stored in the
file, so the same configuration tool you use to control SysV server startup can set these variables. For instance, you can set your hostname (Network
Network-Basics) or tell SuSE whether or not to accept remote
Security-Basics). You may want to browse through the options available in this tool to familiarize yourself with its capabilities.
Other YaST tools, particularly in the Network area, can be used to configure specific servers. For instance, the Network area
both an NFS tool and a Sendmail Configuration tool, which are used to configure NFS and sendmail, respectively. (These topics are covered in Chapters 8 and 19, although these chapters don't focus on YaST configuration.)
Earlier in this chapter, I described the
tools for managing SysV startup scripts (and sometimes servers launched through a super server). These tools are useful, but if you're a fan of fully GUI administrative tools, they may not be quite enough to suit your tastes. There are some fully GUI alternatives, though, such as
. The former is part of the KDE project, but can be used in other environments if you prefer. The latter is not associated with any particular GUI suite. Both are most likely to work smoothly with Red Hat or its derivative distributions. Figure 4.6 shows
Figure 4.6. GUI SysV startup script editors let you click on a server
to modify its operation.
feature a list of available SysV startup scripts in a scrollable list box to the left of the window, and lists of servers that are set to start and stop in various runlevels in the rest of the window. Clicking on an entry in either type of list produces information on the startup script, but the information
depending upon whether you click in the Available Services list or in a specific runlevel list. In the former case,
presents a dialog box that includes a description of the service, and in which you can start, stop, or restart the service or change the permissions or filename for the script. If you click on a service name in a runlevel list, the dialog box also provides a description of the service (in the Service tab), and you can edit the link's name, the startup script to which it points, and the sequence number, as shown in Figure 4.7.
Figure 4.7. You can edit SysV startup script and link features from dialog boxes by clicking the name of a service in
To change which servers start automatically, click and drag a server name from the Start to the Stop runlevel list, or vice versa. You can also drag a server from the Available Services list to the desired runlevel list. In any of these cases,
will assign the service a default sequence number based on where you drag it. For instance, if you drag a service in between services with sequence
of 20 and 30,
will assign a default sequence number of 25. You can change this number by clicking the service name in the runlevel list and editing the Sorting Number field, as shown in Figure 4.7. Unfortunately,
doesn't know what sequences are most appropriate for your system, so you'll have to pay careful attention to this detail. Also, it's possible to configure the system to have a service listed in both the start and stop lists using
, so you should be careful not to do so.
On the whole, GUI startup script utilities like
are less flexible than tools like Linuxconf or YaST. This is by design; the SysV script tools are intended to do just one job, not the many jobs performed by more general-purpose configuration tools. The SysV script tools can help you tweak your SysV startup scripts, but they aren't a substitute for knowing how the system works. You must understand runlevels and the startup sequence for your scripts, or at least the basic principles of SysV startup script sequencing.