لطفا منتظر باشید ...
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
align=left border=0> There are also Web-based administration
tools, such as Webmin and SWAT. Indeed, Linuxconf can be used remotely via a
Web-based interface, as well as locally.
administration, they can also be used locally by pointing a Web browser at
its local system's Web-based administrative tool.
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
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
align=left border=0> The official Linuxconf Web site is
officially deprecated on both, and so may eventually disappear from these
distributions. It's unclear in early 2002 if Linuxconf will be replaced in
these distributions by another unified tool or by a series of server-specific
tools. Although it's most strongly associated with Red Hat and Mandrake,
versions of Linuxconf tailored to other distributions are available from the
main Linuxconf Web site.
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.)
Red Hat's implementation of this model, with the 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:
Control
Control Panel as shown in
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
can enable or disable the server for any of the specified runlevels by clicking
the checkboxes next to each runlevel number.
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
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
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.
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
of the network server startup variables are located in the Start-Variables
area. Click one of the specific options, as shown in
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.
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 optionsavailable 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 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.
operation.
Figure 4.6. GUI SysV
startup script editors let you click on a server name to modify its operation.
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. You can edit
SysV startup script and link features from dialog boxes by clicking the name of
a service in ksysv .
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
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.
