Advanced.Linux.Networking..Roderick.Smith [Electronic resources]

Using GUI Tools

Many Linux distributions provide GUI interfaces that permit configuration of basic networking features, common servers, and often other aspects of system operation. These tools vary substantially from one distribution to another, although they do share certain commonalities. They can usually be launched from a menu option in the distribution's default K Desktop Environment (KDE) or GNU Network Object Model Environment (GNOME) desktops, or they can be launched by typing their names in xterms. (You may need to be root to launch these tools, particularly in the latter way.) These tools include Linuxconf (used by Red Hat and many of its derivatives, including Mandrake), YaST and YaST2 (used by SuSE), and ksysv (a GUI variant on ntsysv , discussed earlier).

NOTE

Using Linuxconf

The Linuxconf utility is a modular configuration tool; it consists of a framework that accepts configuration modules to handle specific servers and other configuration tasks. You can run Linuxconf in text mode (in which it uses text-based menus), 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 linuxconf package, but a separate package typically called gnome-linuxconf or linuxconf-gui . If Linuxconf can use its GUI tools, it does so automatically; otherwise it falls back on its text-based mode. This section emphasizes the local GUI access methods, but the same options are available in text-mode or Web-based access; only the details of the user interface are different. The details of the GUI interface differ 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 windows for each configuration module.

NOTE

When first launched, Linuxconf presents 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 Panel Control Service Activity module selected. This module allows you to control SysV startup scripts and servers started through xinetd . To enable or disable a server, follow these steps:

1.

Start Linuxconf and locate the Control Control Panel Control Service Activity module, as shown in Figure 4.2 .

Figure 4.2. You can use linuxconf to control many aspects of a Linux system's operation.

2.

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.

3.

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 next to each runlevel number.

Figure 4.3. You can control servers through Linuxconf by enabling or disabling a server in any of its runlevels.

4.

Click Accept in the Service tab, then click Dismiss in the Service Control tab.

5.

Select File 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 chkconfig 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 impossible 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 YaST to refer to both tools unless the distinction is important.) You can launch the text-mode YaST by typing yast , or YaST2 by typing yast2 . 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 /etc/rc.config 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 startups. 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-Variables 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 /etc/rc.config 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 root logins (Security 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 hosts 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.)

Using ksysv

Earlier in this chapter, I described the chkconfig and ntsysv 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 ksysv and tksysv . 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 ksysv in operation.

Figure 4.6. GUI SysV startup script editors let you click on a server name to modify its operation.

Both ksysv and tksysv 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 differs depending upon whether you click in the Available Services list or in a specific runlevel list. In the former case, ksysv 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 ksysv .

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, ksysv 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 numbers of 20 and 30, ksysv 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, ksysv 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 ksysv , so you should be careful not to do so.

On the whole, GUI startup script utilities like ksysv and tksysv 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.