Step 4: Prevent Services from Running

Once you have determined the services that should be and should not be running, the first thing you should do to control services is to alter configuration so that unnecessary services do not get turned on at startup. Your goal is not just to shut down unnecessary services, but to make sure they don t accidentally get started again. Instead of turning the service off, you can configure it to not start and then reboot. For instance, if the sendmail service is running right now and you do not need the SMTP service it provides, change its configuration to prevent startup and reboot. The service will not be running anymore. The next thing to do to control services is to change the startup scripts and configurations so that services you do require start only when you intend. Finally when all service configurations are changed, the next step (step 5) is simple: reboot.

One aspect of the Linux services model can be confusing if you are new to it. Some services run as their own daemon and some are started from a special daemon called the Internet daemon.

The services that run as their own program are called daemons. One group of daemons, called network daemons, are services that are listening on the network interface for connections from clients . Once the client connects to a daemon, the daemon usually performs some action. On Linux systems, daemons have their startup scripts under either the /etc/init.d directory or /etc/rc.d directory depending on which distribution is being used.

The second group of services are started by the Internet daemon. The Internet daemon is inetd in the SUSE and Debian distributions and xinetd in the Red Hat distribution. These daemons configurations are in /etc/inetd.conf and /etc/xinetd.d, respectively. Service configuration changes of this type involve changing only this single daemon. Fortunately, some configuration tools, such as the text-based chkconfig , do not require knowledge about where the configuration occurs because the knowledge of the service differences is built into the tool. It will not require you to know which it is changing, but it will change the correct one. The chkconfig command is detailed later in the section Use chkconfig.

Use Tools to Alter Startup Scripts

There are several different tools that can help alter the startup scripts of a Linux system. Table 2-7 lists the tools available on a few distributions.

Table 2-7: Tools for Altering init Scripts and the Distributions in Which They Occur

Distribution	Service Configuration Tools
Debian	rcconf chkconfig
Red Hat	ntsysv serviceconf chkconfig
SUSE	YaST2 chkconfig

The correct tool to use depends on which distribution you are using and what you are trying to accomplish. The GUI tools described here are YaST2 for SLES8 and serviceconf for Red Hat Enterprise Linux AS 3.0. A third type of tool, called System V Init tools, is also briefly described.

In all cases, you will need root authority in order to make changes. Start by logging in as root or type su - root in a terminal window if you are invoking the tool from the command line. When you are invoking a GUI from the command line, but are not logged into the window manager as root, you may need to type xhost +localhost to authenticate your session to the window manager. If you get an error saying something like could not open display, this is the problem. This depends entirely upon the flavor of Linux you are using, because different versions of Linux use different models.

There is no additional risk if you type the xhost command with +localhost , however, if you do not include localhost you are making a serious security error.

Heads Up  

Sometimes people solve window manager authentication problems with xhost + . This is not the right way to use the xhost command because it allows anyone to authenticate to the display on your window manager.

Use YaST2 with SUSE

If you are running SUSE, use the GUI service configuration tool YaST2. You can invoke YaST2 by clicking the hammer and wrench icon, then YaST2 Modules System Runlevel Editor. You can see an example of traversing the menu hierarchy in Figure 2-1.

Figure 2-1: SLES8 YaST2 menu hierarchy for the Runlevel Editor

Once the YaST2 Runlevel Editor comes up, the next step is to select the default runlevel for your system. If the system is a dedicated server, the correct runlevel is 3. Next, click Runlevel Properties. This will bring up a list of services that looks like Figure 2-2.

Figure 2-2: Runlevel Editor detail in SLES8

Scroll through the list of services and make sure the only services with a Yes in the second column of Table 2-2 are the services you chose when determining your requirements in step 2. It is better to err on the side of caution, since you can always come back here and enable something else later. If you are unsure what something does, look the service up in Table 2-4. At the bottom of the Runlevel Editor window is a group of checkboxes that indicate for each runlevel whether that service will be running. Concentrate first on your default runlevel 3 since that is the most important. When you are done with your changes, click Finish.

To finish your services configuration in SUSE, check which services are started by inetd . Again, click the hammer and wrench icon, then YaST2 Module Network/Basic Start/Stop Services (inetd), as shown in Figure 2-3.

Figure 2-3: YaST2 menu hierarchy for invoking inetd services GUI

The first step in working with the inetd configuration GUI is to select the radio button for on with custom configuration and the click Next (the Finish button changes to Next after you choose to do the custom configuration). The next screen has instructions on the left. All the services are off by default as evidenced by the number symbol (#) on the left of each line. This # is carried over from the configuration file itself. To have any of the configurations turned on, merely click on the line and then click the Activate or Deactivate button. Repeat this step as many times as there are changes to make. When you are done, click Finish. Notice the word Active appears in the list next to the service name . Conversely, if you were turning off services, you should do this exact procedure and the difference would be that the word Active disappears and is replaced by the number symbol.

If you wanted to perform this configuration modification by hand, you would merely edit the /etc/inetd.conf file and put a # on any line you wanted to make inactive. After saving the file, the Internet daemon needs to reread its configuration by restarting or by being sent a SIGHUP ( kill -1 ) signal. You could do this by typing the following at the command line:

 kill -1  process-id  

Use serviceconfig with Red Hat

Service configuration is easier in Red Hat since both daemons and xinetd services can be turned on and off from the same GUI tool.

Invoke serviceconf by clicking the Red Hat icon, then System Settings Server Settings Services, as shown in Figure 2-4. The window that comes up has a single list, as shown in Figure 2-5.

Figure 2-4: Menu hierarchy for serviceconf in Red Hat Enterprise Linux AS 3.0

Figure 2-5: serviceconf window with default services enabled

The serviceconf tool is simple to use:

• At the top of the window is the Edit Runlevel pull-down menu that indicates which runlevel s configuration you are currently configuring. The first thing to do is make sure the runlevel you are configuring is the runlevel that your server will be at when it is deployed. Click Edit Runlevel Runlevel 3. Shown in Figure 2-5, Runlevel 3 allows your server to be working on tasks instead of running a Window Manager and is therefore the desirable runlevel for your deployed server.

• Each of the possible services is presented in a list. Next to each item is a checkbox for turning on and off the service. If the checkbox has a check in it, the service is on. Go through the list and make sure there is a reason for each service that has a check next to it. At the same time, make sure there are no checks next to services you do not need. After you make a change, you can click the Start button at the top of the window if you want to turn the service on immediately, or click the Stop button if you want to stop the service immediately.

• Save your changes by clicking File Save Changes before closing the window, as shown in Figure 2-6.

  
  Figure 2-6: Save changes in serviceconf

  Heads Up  

  After you are done, be sure to save your changes. If you just exit the program, your changes will not be saved and services that you do not want to run will still be able to do so. The Start and Stop buttons only affect the current state of the server.

Use System V Init Type Programs

Another group of GUI tools are available in some Linux distributions or can be installed separately. They are common, have been around a long time, and are standard in distributions other than Red Hat and SUSE. They are very similar to each other and are referred to as System V Init type programs. They include tksysv , ntsysv (Red Hat), and ksysv . These tools operate almost identically ”in fact according to its About message, ntsysv was inspired by tksysv . There are minor differences between these tools, for instance, ksysv has drag and drop support. If any of these tools are installed, they can be invoked from the command line by typing the name, such as tksysv . Figure 2-7 shows what the tksysv GUI looks like.

Figure 2-7: The TKSYSV GUI

To add a service:

1. Determine the name of the service.

2. Locate the service in the left column.

3. Select the service, then click Add.

4. At the prompt requesting the runlevel for the service, select a runlevel checkbox, then click Done.

5. At the prompt for the order to initiate the service, The number for [service] is, a proposed possible order for service startup is displayed. This is only important if the service is required to start before another service at that runlevel.

To remove a service at a runlevel is even easier:

1. Locate the service listed at the runlevel you would like to remove and select it.

2. Click Remove and the service will not be invoked at that runlevel at the next bootup .

Turn Off Unnecessary Services: Command Line Tool

There are at least two different ways you can turn off system services from the command line. One method uses a command like chkconfig . The command chkconfig is available in both SUSE and Red Hat. It operates a little differently in the two environments. In SLES8, typing the command returns a list of each service and whether it is running or not. For Red Hat you need to use the flag -list , as in / sbin/chkconfig -list .

Use chkconfig

If you find that the display is too long, you can pipe the output to the more filter to make it readable, like this:

 /sbin/chkconfig --list  more 

Figure 2-8 shows what the chkconfig information looks like.

Figure 2-8: Runlevel information for systems services from chkconfig

If you are not the root user you can still run the command if you supply the complete path /sbin/chkconfig, but you will not be able to make any changes to the configurations. If you were using Red Hat and trying to turn off sendmail, you could run the following:

 chkconfig --list sendmail 

You would see that sendmail is running under runlevels 2, 3, 4, and 5. The command to turn sendmail off during these runlevels would look like this:

 chkconfig --level 2345 sendmail off' 

You need to put the runlevels you are changing right next to each other without spaces or commas. To make sure the change happens the way you intend, you can run the following command again and notice that Off is next to runlevels 2, 3, 4, and 5 instead of On:

 chkconfig --list sendmail 

The SUSE distribution uses the SMTP server postfix instead of sendmail. To check if mail is on in SLES8, type chkconfig postfix .

Use Startup Scripts

The second command line method for turning off and on a system service requires you to know what runlevel the service starts at, and whether the service is invoked as a daemon or from the Internet daemon. When your server starts up, the scripts for each runlevel are run. The same type of thing happens at shutdown time too. The startup scripts can be found in a directory named after each of the runlevels under the /etc/ directory. For instance, the scripts for runlevel 5 are under /etc/rc.d/rc5.d/. When a system starts, it runs all the scripts in that directory that start with the letter S. When a system is shutting down or rebooting, all the scripts in the directory that start with a K will be executed. The nice thing about these scripts is that they run in numerical order. For example, S09sshd will be executed before S17cron . Since the order of execution is based on the numerical order, this allows precise control over which program runs before which other program.

In SLES8, the startup scripts for each runlevel are in /etc/rc.d/rc*.d. For example, in runlevel 3 the startup scripts are in /etc/rc.d/rc3.d. Technically, the scripts themselves reside in the /etc/rc.d directory, and special files called soft links are made in each directory to point back at the /etc/rc.d directory. This is useful for a few reasons. One reason is that if changes need to occur in the startup scripts, the changes can be made in one place, but they affect each instance where a script is used. Another reason to use soft links instead of files is that if you would like to disable a service at a certain runlevel, you can merely remove the soft link and the startup script itself is unchanged. To remove a soft link, treat it like a file and type

 rm  filename  

For example:

 rm /etc/rc.d/S01isdn 

The easiest way to create a soft link is to cd into the directory where you want the link to be and type

 ln -s script-to-link-to soft-link-to-make 

For example, the following creates the soft link deleted in the previous listing:

 ln -s /etc/rc.d./isdn S01isdn 

Type ls -l and notice that all the files in the directory are actually soft links pointing at the actual files that are up one directory.

The directory layout for startup scripts in Red Hat Enterprise Linux AS 3.0 is slightly different than in SLES8. In Red Hat, the startup scripts are in the directory /etc/rc.d/init.d instead of /etc/rc.d/. The soft linking process is the same except the soft link points at a different directory structure. To create the soft link to start the isdn service, first cd into the desired runlevel, such as cd /etc/rc.d/rc3.d . Then type the following:

 ln -s /etc/rc.d/init.d/isdn S09isdn 

Linux distributions that are Linux Standard Base compliant have an elegant mechanism for dealing with the soft linking process. The packager installer program ( rpm ) runs a postinstall script, which in turn uses the program /usr/lib/lsb/install_initd to configure the distribution s boot script system to call the package s init.d file at the appropriate time. The install_initd program takes a single argument, the pathname to the /etc/init.d file. When removing a package the converse is also true. When a software package is removed, the package s preuninstall script should call /usr/lib/lsb/remove_initd and pass the path name to the /etc/init.d file. The package manager is still required to remove the /etc/init.d file. The remove_initd program is provided in case the distribution needs to clean up any other modifications in the distribution s boot script system that might have been made by the install_initd program.

Another benefit provided by LSB-compliant startup scripts is that each script can take the arguments start , stop , restart , force-reload , and status . Also, LSB compliance dictates that startup scripts need to behave sensibly if invoked with start when the service is already running, or with stop when it isn t, and that they don t kill unfortunately named user processes.

This is added to the fact that the init script must return an exit status of zero if the action described by the argument has been successful. This ensures that a consistent approach toward working with startup scripts yields predictable behavior no matter which distribution you are working with. It is unlikely that you will need to be able to recite these details from memory because tools like YaST2 perform all these behaviors behind the scenes. You can read more about this at http://www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB.html#INITSRCINSTRM.

One last approach to consider allows you to leave the scripts intact but not have them execute. All that is needed is to change the case of the init script from a capital letter to a lowercase letter. If the script doesn t begin with a capital, it will not be executed. If you decide you want the script to execute, change the case of the first letter back to a capital.