Linux with Operating System Concepts

servicename
status
. 
This function begins by defining four local variables and assigning lock_file and pid_file to 
null. Next, it tests the number of parameters passed to this function.
If it received no parameters, it outputs a usage statement and returns error code 1. 
Otherwise, the function expects to receive one or more parameters. If there is one param-
eter, the parameter is the name of the daemon’s executable program, such as atd. The other 
possibility is that the function call includes one or two options: -l 
lock_filename
and –p 
pid_filename
. If the –p option is used, then status calls upon the function pids_var_run. 
Given the response from this function, if the 
pid_filename
exists and there is a PID associ-
ated with this process then status outputs
name
(pid 
PID
) is running …
where 
name
is the service name and 
PID
is the process ID assigned to this service, and 
returns a value of 0. Otherwise, based on the return value from the pids_var_run function, 
status will output one of
name
dead but pid file exists
or
name
status unknown due to insufficient privileges
If the –p option is not used, status then tests for the existence of the lock_file. If it exists, 
status responds with the output
name
dead but subsys locked
meaning that the process is not running but the 
lock_file
still exists and needs to be deleted. 
Finally, if there is no lock_file, then status responds with
name
is stopped

---

468
◾
Linux with Operating System Concepts
Other functions found in the function script are called 
success
, 
failure
, 
passed
, 
warning
, and 
action
among other supporting functions utilized by the various func-
tions mentioned above. With functions now loaded, the atd script continues.
exec
=
/usr/sbin/atd
prog
=
“atd”
config
=
/etc/sysconfig/atd
These three lines of code establish variables used within the atd script for convenience. 
Notice that 
prog
is the name of the service program to be executed and 
exec
is the full 
path to execute the program.
[ -e /etc/sysconfig/$prog ] && ./etc/sysconfig/$prog
lockfile
=
/var/lock/subsys/$prog
The above two lines first test to make sure the executable program for the service exists 
and then executes it. Then, 
lockfile
is set to the name of a file that atd will create to 
place the lockfile in its appropriate location, /var/lock/subsys. At this point, the atd script 
file defines a number of functions called from a case statement at the bottom of the file.
start() {
[ -x $exec ] || exit 5
[ -f $config ] || exit 6
echo -n $“Starting $prog: ”
daemon $exec $OPTS
retval
=
$?
echo
[ $retval -eq 0 ] && touch $lockfile
}
The start function will attempt to start the atd service. It first tests to see if the program 
/
usr/sbin/atd
is executable. If not, start immediately exits with an error code of 5. It 
then tests to see if the configuration file /
etc/sysconfig/atd
exists. If not, start exits 
with an error code of 6. Otherwise, it outputs a message that it is starting atd, calls the 
daemon function to execute /
usr/sbin/atd
with options of 
$OPTS
. As OPTS was not 
defined in this script, it will only have a value if it was established and exported by another 
script or set at the command line prompt. The daemon script will return 0 if successful 
or an error code if unsuccessful. This value is placed into the variable 
retval
. Finally, if 
retval is equal to 0 (success), then the 
lockfile
is created to indicate that atd was suc-
cessfully started.
stop () {
echo –n $“Stopping $prog: ”
if [ -n “`pidfileofproc $exec`” ]; then

---

System Initialization and Services
◾
469
killproc 
$exec
RETVAL
=
3
else
failure $“Stopping $prog”
fi
retval
=
$?
echo
[ $retval –eq 0 ] && rm –f $lockfile
}
The stop function operates somewhat like the opposite of the start function. First, it out-
puts a message indicating that atd is being stopped. It then calls upon the function 
pidf-
ileofproc
to see if atd has a PID and therefore is running. If so, the function 
killproc
is called to kill atd and the variable 
RETVAL
is set to 3; otherwise, the function 
failure
is called indicating that stop failed while trying to stop atd. The variable 
retval
(which 
differs from RETVAL) is set to the value of the most recent function call, which will either 
be that of killproc or failure. Killproc will return 0 upon success and so if retval is 0, it 
means that atd was successfully stopped. The lockfile file is then removed to indicate that 
the process is no longer running.
restart() {
stop
start
}
reload() {
restart
}
force_reload() {
restart
}
Restart simply calls the two functions stop and start, respectively. You would use restart 
if you have modified atd’s configuration file or you find atd to not be functioning correctly 
and wish to restart it. You can also separately call stop and start. Also shown above are 
reload and force_reload, both of which call restart to give you the same result. This allows 
the system administrator to restart atd using any of restart, reload, or force_reload.
rh_status() {
status $prog
}
The rh_status function appears to do nothing useful; it merely calls status passing it 
the name of the program, atd. In fact, rh_status is a type of wrapper function. We use 

---

470
◾
Linux with Operating System Concepts
rh_status because we may want to invoke it directly or indirectly through another func-
tion, rh_status_q (shown below). As there is no –l or –p option provided in the call to sta-
tus, status will test for a PID and if one exists, output the “running” message; otherwise, it 
will respond with the “dead,” “insufficient privileges,” or “stopped” message.
rh_status_q() {
rh_status 
>
/dev/null 2 
>
&1
}
This function is used to invoke the rh_status function from above. The notation 
>
/dev/
null 2 
>
&1
is common in system administration scripts indicating that STDERR mes-
sages should be redirected to the same output location as STDOUT. In the clause 
2 
>
&1
, 
the 2 refers to STDERR, the 
>
redirects any output of STDERR to &1, and the &1 indicates 
“point to STDOUT’s destination.” Prior to this, the code 
>
/dev/null
redirects STDOUT 
to /dev/null. This instruction ensures that any output or error from rh_status is not output to 
the user’s terminal window but instead sent to /dev/null.
Why would we want to prevent output from being seen in the terminal window when 
we are calling upon status to find out the service’s status? The reason for this is that calling 
upon rh_status_q to obtain the status of the service is being done to obtain not text output 
but a return code. We hope to receive a 0 to indicate that the service is running as expected. 
We will see below that rh_status and not rh_status_q is used when we want to obtain the 
service’s status while rh_status_q is used to start or stop the service. That is, we use rh_sta-
tus to output the status of the service while we use rh_status_q to obtain the service’s status 
in a nonoutput situation.
case “$1” in
start)
rh_status_q || exit 0
$1
;;
stop)
rh_status_q || exit 0
$1
;;
restart)
$1
;;
reload)
rh_status_q || exit 7
$1
;;
force-reload)
force-reload
;;
status)

---

System Initialization and Services
◾
471
rh_status
;;
condrestart|try-restart)
rh_status_q || exit 0
restart
;;
*)
echo $“Usage: $0 {start|stop|status|restart|
condrestart|try-restart|reload|
force-reload}”
exit 
2
esac
exit $?
The script ends with the above case statement. This statement tests the parameter passed 
to the script from the command line. Expected parameters are 
start
, 
stop
, 
restart
, 
reload
, 
force-reload
, 
status
, 
condrestart
, and 
try-restart
. If start is pro-
vided, then the case statement calls rh_status_q to determine if the service is already run-
ning. If rh_status_q exits with a value other than 0, then the exit 0 statement is executed 
and the script terminates. This indicates that there is nothing to do if we wish to start an 
already-running service. Otherwise, rh_status_q will return some other code (hopefully 3 
indicating that the service is stopped, but possibly 1, 2, or 4 indicating some kind of error 
with the service). In any of these cases, $1, which is the word “start,” is invoked. This calls 
the start function, which starts the atd service.
Notice that we are using rh_status_q rather than rh_status. The former function does 
not output status information but instead returns the status code (0, 1, 2, 3, 4). The same 
strategy is used for stop.
If the parameter, $1, is restart, then the case statement merely calls $1, which itself calls 
the restart function. For reload, rh_status_q is invoked as with start and stop. In this case, 
an error code of 7 is returned if the status is 0 (running); otherwise, the reload function is 
called. The reload function, as shown earlier, calls the restart function.
For force_reload, it merely calls force_reload. For status, the rh_status function is called. 
This function does output to the terminal window unlike rh_status_q. If condrestart or 
try-restart are specified as the parameter, then rh_status_q is called and restart is only 
called if rh_status_q returns a nonzero value.
Finally, the default clause is invoked if there was no parameter supplied, or the param-
eter is not one of the legal parameters. The default clause causes the script to then output a 
usage statement indicating how to use this atd script. In this echo statement, the $0 param-
eter is the script name itself (atd). The script exits with the error code of the last function 
called, which will be a 0 if everything worked correctly.
11.6 CONFIGURING SERVICES THROUGH GUI TOOLS
There are two ways to configure a service. In some cases, there are GUI tools (or wizards) 
available. This is true of the Linux firewall, Bluetooth, kdump (kernel crash dumps), cups 

---

472
◾
Linux with Operating System Concepts
(printing service), along with a few others. Or, you can alter the service’s configuration 
file(s) and restart the service. In this section, we briefly explore a few GUI tools.
11.6.1 Firewall Configuration Tool
You can bring up the Firewall Configuration tool from the Administration submenu of 
the System menu (in Gnome), or by typing /
usr/bin/system-config-firewall
(see 
Figure 11.4). Making changes to either the GUI or the firewall’s configuration file requires 
root access.
First, you can select to enable or disable the firewall. In the figure, the firewall is cur-
rently enabled so you can only choose to disable it. The reload button causes any changes 
that you made but did not apply to be discarded. The wizard button allows you to make 
simple changes to the firewall such as whether to use a desktop-based configuration or a 
server-based configuration. For any other, more specific changes, you will have to actually 
enter information in the GUI. After making any changes to the GUI, you have to click on 
Apply for the change to take effect.
Aside from enabling/disabling the firewall or using the wizard to change settings, any 
other types of changes are made through a menu of rule types provided along the left side of 
the GUI. These selections offer different options for how you can specify firewall rules. You 
can specify firewall rules based on service type or port number, or through custom rules.
In Figure 11.4, Trusted Services has been selected and you can see some of the network 
programs listed. None of these programs have been selected so that the firewall currently 
will not permit messages from these types of programs. For instance, any attempt to send 
an FTP or DNS request will be rejected. If you were to scroll down, you would see by 
default only one program enabled, SSH. We would change our firewall if we wanted to 
FIGURE 11.4 
Firewall Configuration Tool.

---

System Initialization and Services
◾
473
permit other types of messages to be allowed through. For instance, if you were going to 
implement a web server on this Linux machine, you would have to allow HTTP and prob-
ably HTTPS messages (not seen in the figure). Or, if you wanted to establish a DNS server, 
you would enable DNS.
For each service in the list, we also see the port(s) and protocol(s) associated with it. 
These details help flesh out the firewall rules. For instance, SSH uses TCP over port 22. If 
you select DNS and apply the change, a rule is then generated for the firewall that permits 
TCP and UDP messages over port 53. Conntrack Helper is short for Connection Tracker 
Helper. These programs help track connections of various types. For instance, amanda is a 
program used to track Amanda Backup Client messages.
The Other Ports selection allows you to add ports that are not listed under Trusted 
Services. For instance, telnet is available over port 23. You would have to select this through 
Other Ports rather than Trusted Services. Additionally, you could open up ports that are 
not the typical port such as adding port 8080 to HTTP. HTTP requests default to port 
80. Aside from the port, or range of ports, you also specify the acceptable protocol for the 
given port.
Trusted Interfaces include eth
+
devices (e.g., eth0, eth1, eth2, etc.), ippp
+
devices, isdn
+
devices, ppp
+
devices, tun
+
devices, and wlan
+
devices. Each network interface is listed 
separately. The default is for none of these to be selected. You can also add your own inter-
face to the list if you have interface devices not listed.
Masquerading contains the same interfaces as trusted interfaces. The difference is that 
masquerading hides your local network so that your host appears as a single Internet 
address. If masquerading is turned on, then port forwarding is enabled.
Port Forwarding allows you to specify forwarding rules. You would use forwarding 
if your device were not an end-user of the network but a device that routed messages 
(e.g., router, gateway). Forwarding permits messages to be forwarded from your device 
to another. Port forwarding are the rules that specify which messages should be passed 
along and which should not. These rules must list the interface(s), port(s), and protocol(s) 
of incoming messages and the destination address(es) and port(s) permitted. For instance, 
you might specify that TCP messages received from eth
+
over port 80 can be forwarded 
to IP address 10.11.1.2. If any other local machine’s IP address is present in the destination 
address of a received message, it is not forwarded.
ICMP Filter permits messages that are sent by troubleshooting programs such as ping. 
Selections include destination unreachable, parameter problem, redirect, router advertise-
ment, and time exceeded. Finally, custom rules allow you to enter your own firewall rules. 
These rules are specified using the iptables format, which we will explore in Chapter 12.
11.6.2 kdump Configuration Tool
The Kernel Dump Configuration Tool can be used in place of the 
kdump
configuration file 
kdump.conf
. The kdump service is called upon when the kernel crashes so that a record 
of why the kernel crashed can be saved as a core dump. As with the Firewall, this GUI 
offers convenient ways to alter kdump’s behavior. Figure 11.5 illustrates the main window 
for the Kernel Dump Configuration Tool. From the main panel, your choices are to enable/

---

474
◾
Linux with Operating System Concepts
disable the kdump service and establish the size of a kernel dump. There are three other 
settings to select, Target settings, Filtering settings, and Expert settings.
Through the other tabs, you are able to specify other kdump information. In Target set-
tings, you specify the location and filename for a kernel dump, which can be somewhere in 
the local filesystem, for example, /var/crash, a raw device, or a network location accessed 
either through NFS or SSH. The Filtering settings tab gives you the ability to establish how 
much data to dump by specifying a filtering level. Expert settings allow you to change the 
kernel (default or a custom kernel) and the command line specification for starting the 
kernel. Figure 11.6 combines these three tabs’ windows.
FIGURE 11.6 
Other Kdump GUI Settings.
FIGURE 11.5 
Kernel dump configuration GUI tool.

---

System Initialization and Services
◾
475
11.7 CONFIGURING SERVICES THROUGH CONFIGURATION FILES
We now turn to using configuration files to configure services. This approach requires that 
you edit the appropriate service configuration file(s). In many cases, there is a single con-
figuration file for the given service. In some cases though, there might be several files such 
as a configuration file and a rule file. Most of these files are located under /etc, although in 
many cases, they are in subdirectories such as /etc/sysconfig, or they are located under a 
directory specific to the service.
The entries in these files differ from service to service but primarily the format is to list 
directives with values. Directives are options using reserved terms and may appear like 
assignment statements, such as
AUTOCREATE_SERVER_KEYS
=
YES
as found in the sshd configuration file /etc/sysconfig/sshd, or they may appear as directives 
and arguments (parameters), as in
path /var/crash
from the kdump configuration file /etc/kdump.conf.
In other cases, the configuration file stores lists of entries such as a list of usernames or 
a list of IP addresses and IP aliases. The /etc/at.allow file lists usernames of all users who 
would be allowed to issue at commands. The /etc/hosts file lists IP address and IP alias 
pairs for IP aliases that can bypass the DNS process by converting the IP alias into its IP 
address locally.
11.7.1 Configuring Syslog
Our examination of configuration files will start with a look at the logging service syslogd. 
The configuration file is /
etc/syslog.conf
. In newer versions of Linux, the service is 
called 
rsyslogd
and the file is rsyslog.conf. The rsyslog.conf file begins with a number of 
$ModLoad
statements to load needed modules for logging actions, followed by any global 
directives. These statements do not occur in the older syslog.conf file.
The file then consists of logging rules. Rules take on the following format: