Team LiB
Previous Section Next Section

The sysconfig Directory

One of the things people either love or hate about SUSE is the fact that all standard services can be configured via a central flat file repository of configuration settings. The old way (previous to SUSE 8) was to use the rc.config file, but this has been superseded by sysconfig.

Sysconfig is a directory beneath /etc, which is familiar to Red Hat users, and this is one of the reasons SUSE chose this layout. Because of technical and usability issues, the SUSE developers wanted to split out the configuration options of the ever-increasing services controlled by the SUSE configuration tool YaST (a more in-depth view of YaST is given later in this appendix) into separate files. As the sysconfig directory is something many Linux users are used to, this was a natural choice.

The system and services configuration is split into separate files. For example, to change kernel parameters (think sysctl parameters), you would edit the file /etc/sysconfig /kernel. Table B-1 provides a short overview of the most common files and their respective services.

Table B-1: Files under /etc/sysconfig/

File

Service

Description

Postfix

Postfix

Configuration of the standard SUSE mail server

apache

Apache

Configuration parameters for the Apache web server

Lang

System Language

Parameters to control language settings for the system

Keyb

Keyboard

Settings for keyboard, including keymap, rate, and delay

SuSEfirewall2

SUSE Firewall

The standard SUSE firewall configuration

windowmanager

[X|K|G]dm

Default window manager (KDE, GNOME, and so on)

Mouse

Mouse configuration

Mouse model, extensions, and so on

Note 

Editing these files will only set the scene for commitment to the running configuration. To commit any changes that are made in /etc/sysconfig, you will need to run SuSEconfig. SuSEconfig is detailed later in the chapter, but it is a very important tool that any SUSE user should learn to use.

Network Scripts

Keeping with the sysconfig theme, SUSE uses /etc/sysconfig/network to store configuration for networking.

A very important and useful file in /etc/sysconfig/network is the config file. Many options to control the way your network connection (and the system) functions can be found here. For example, if you use a laptop there are parameters to unmount any active NFS mounts before your network shuts down. Again, any config file settings that need to 1be committed should be done with SuSEconfig.

Each network interface that is configured on the system (either via YaST or manually) has an ifcfg - interface file. For a standard ethernet interface, we can use the ifcfg-eth0 file to signify the first ethernet interface the system has found:

   BOOTPROTO='static'
   BROADCAST='192.168.255.255'
   IPADDR='192.168.1.80'
   NETWORK='192.168.0.0'
   REMOTE_IPADDR="
   STARTMODE='onboot'
   UNIQUE='WL76.gUpZQ_u5zzC'
   WIRELESS='no'

The configuration states the eth0 has a static configuration, with an IP of 192.168.1.80 and a network mask of 255.255.0.0. Setting BOOTPROTO to dhcp will tell the system to obtain an IP address and (if configured) other settings upon boot.

DHCP Configuration

If an interface has been configured as dhcp, the system will try to obtain an IP address when the system boots or via the rcnetwork control script. The values that the DHCP client will assign to various network-related settings can be controlled via the /etc/sysconfig/dhcp file.

DHCP allows an administrator to set the hostname of a client, routing tables and DNS servers to name a few. Most Linux DHCP clients allow a user to control whether those values are actually used. Table B-2 shows some options in the /etc/saysconfig/network/dhcp file.

Table B-2: Some Options in /etc/saysconfig/network/dhcp

Parameter

Description

DHCLIENT_SET_HOSTNAME

Should the hostname passed to the DHCP request be honored?

DHCLIENT_MODIFY_RESOLV_CONF

Should resolver parameters be saved in /etc/resolv.conf?

DHCLIENT_DEFAULT_ROUTE

Should the gateway/default route be honored?

As with most things that can be configured directly through the SUSE management system, the parameters are well documented and their value is either yes|no or a specific value. This gives users the ability to configure common services for "normal" use. The definition of normal has led to some controversy over the central configuration system that SUSE uses. Many power users of Linux prefer to configure services directly via the services' own configuration files. The reasoning behind the SUSE philosophy is that for new and intermediate users who need services configured as soon and as simply as possible, the central configuration is extremely useful. From a technical standpoint, YaST is able to store common changes that control services in a flat file.

Regardless of which camp you are in, the configuration element of SUSE provides power users the opportunity to configure services directly in the configuration file native to the service and lets novices/intermediates edit standardized files quickly and commit those changes.

The next section gives an introduction to another way of configuring the system: YaST, the SUSE management tool.

rc Scripts

Every Linux system has scripts that are used to start, stop, and query the status of a service, and SUSE is no different. As well as the standard init scripts for services being stored in /etc/init.d/, they are linked to rc scripts in /sbin and /usr/sbin.

To control a service, use the following commands:

  • rcservice start-Start the service.

  • rcservice stop-Shutdown the service.

  • rcservice status-Check the status of the service (whether it is running).

  • rcservice reload-This is service dependant, but is similar to sending a HUP signal to the process to reload its configuration files.

A problem many people new to SUSE have is how to find out what the name of a service is. There a few methods to this, but the best is to run the following command (again taking postfix as an example):

   # rpm -ql postfix | grep rc

This will grep through the listing of all files in the postfix rpm that has been installed, to find the rc script. Once you know this you can use it to control the service.

chkconfig

The boot up process of a Linux system is usually controlled by run level scripts (stored in /etc/init.d) linked into run level directories. To stop system administrators from going made with symbolic links, the chkconfig utility is used to control the startup and precedence of system services.

Running chkconfig with no parameters will list all services and whether the service is on in the current runlevel. For a more in-depth look at services and their runlevels, adding the list parameter will display all services, all runlevels, and whether the service is on or off in those levels.

A SUSE service init script contains a header to tell the system what the default runlevels this script should reside in and default actions for those runlevels. To turn on postfix in its default runlevels (3 and 5), the command

   # chkconfig -a postfix

will setup the links needed to start postfix by default in runlevel 3 and 5, along with the respective kill script to shut the service down in the correct priority.

The same is true for the reverse, removing a service from the init sequence.

   # chkconfig -d postfix

chkconfig will then remove links in runlevel directories, and signify this with a listing of the postfix runlevel status.

chkconfig is a powerful utility to manage services from a scripted management system, and also for one off configurations by the administrator. For more information on chkconfig, see the chkconfig(8) man page.

X Configuration with SAX

SUSE's configuration tools help the user at every step, and with its history in X server development, SUSE has provided the sax2 tool to automatically configure X windows for a user environment.

Why sax2? The original sax tool was written for XFree86 version 3, and with the release of Xfree86 version 4, SUSE had to rewrite a lot of the sax tool as the underlying configuration of X changed so drastically.

During installation, sax is used to configure the video hardware. If for any reason (new graphics card or monitor) the display needs to be reconfigured, sax2 can be used to reinitialize display parameters and tweak the display to the user's requirements.

To start sax, issue sax2 at the command line in an init level other than 5 or with no X server or display manager running. Figure B-1 shows the sax2 initial screen.

Click To expand
Figure B-1: sax2 initial screen.

Once started, you will be able to configure display parameters (video card, monitor, and so on), input parameters (mouse, keyboard, tablet), multiheacl display, and AccessX.

Selecting Graphics Card will allow you to provide specific information to sax that will enable accelerated features of your graphics card (extended 2D features). In our case we will select the framebuffer device (see Figure B-2) as this is the catch (nearly!) all setting that can be used with VESA 2.0 capable cards.

Click To expand
Figure B-2: sax2 graphics card configuration.

Once the graphics card has been configured, the resolution and monitor configuration needs to be set. Sax is capable of selecting a default monitor configuration based on DCE feedback during sax2 initialization. If your monitor is not DCE aware, you will need to use parameters from your monitor manual to configure it safely.

Selecting Monitor will provide you with the option of selecting the currently used monitor. Figure B-3 shows the sax2 monitor configuration screen. Clicking on properties will allow you to set parameters such as resolution and frequency settings.

Click To expand
Figure B-3: sax2 monitor configuration.

Once configured you will then need to configure the color depth and resolution of your graphics card. If using the framebuffer device, most of the screen drawing routines will be carried out by the processor of the main system, so the higher the bit depth used for displays, the more work the processor will have to do. To combat this, the lowest screen depth possible for day-to-day work should be selected. This is usually 8 bits (256 colors).

Selecting Color and Resolution allows you to set the screen depth and also resolution of X, as shown in Figures B-4 and B-5.

Click To expand
Figure B-4: sax2 color depth configuration.
Click To expand
Figure B-5: sax2 resolution configuration.

Once configured, it is advisable to check the virtual resolution settings, as it is quite possible that the annoying feature may have been enabled.

3-D configuration is beyond the scope of this chapter, but you should take a look at the SUSE documentation for more information on configuring your system to take advantage of these features.

After you have saved your configuration, it is advisable to take Sax's advice and test your new settings. If you are running a default runlevel of 5, and the configuration of X is incorrect, your system will keep trying to initialize the display until the respawn threshold has been met. If there are problems at a later date, you can boot your Linux system into runlevel 1 (single-user mode) without X by passing a value of "1" to the grub boot loader when the system starts up.


Team LiB
Previous Section Next Section