Networking / Beginners

---

Processes controlling processes

Beyond knowing what processes are running, the system administrator must be able to schedule the proper services to run at the proper time. UNIX provides four means of controlling processes: inti, xinetd (inetd), chkconfig, and service.

The init process

After the UNIX kernel boots, it will place the operating system into one of several runlevels. The runlevel will determine which processes and services are started (or stopped). The following describes the seven runlevels in Linux:

• Runlevel-This is the shutdown state. When a system is properly shut down, it is transitioned into this runlevel. During that transition, certain processes or services will be killed (stopped), as defined in the /etc/rc.d/rc0.d directory.
• Runlevel 1-This is the single-user mode. The system has one session (the command prompt) and the user is always root. This state is typically used to troubleshoot the workstation or when conducting backups. Some administrators might prefer to pass through this runlevel when starting up and shutting down the workstation. The processes started and stopped in runlevel 1 are governed by the files in the /etc/rc.d/rc1.d directory.
• Runlevel 2-This is multi-user mode without networking. This state is rarely used. The processes started and stopped in runlevel 2 are governed by the files in the /etc/rc.d/rc2.d directory.
• Runlevel 3-This is multi-user mode with networking. This is the normal state to which the system will boot. Some systems are configured to boot directly into Xwindows (runlevel 6). The processes started and stopped in runlevel 3 are governed by the files in the /etc/rc.d/rc3.d directory.
• Runlevel 4-This is unused on many versions of UNIX. The processes started and stopped in runlevel 4 are governed by the files in the /etc/rc.d/rc4.d directory.
• Runlevel 5-This is typically the XWindows mode. Systems are sometimes configured to boot into this state. Otherwise, this runlevel is entered by starting XWindows (startx) from runlevel 2 or 3. The processes started and stopped in runlevel 5 are governed by the files in the /etc/rc.d/rc5.d directory.
• Runlevel 6-This is the reboot state. When reboot or a similar command is issued, the system transitions into this runlevel. The processes started and stopped in runlevel 6 are governed by the files in the /etc/rc.d/rc6.d directory. All of the files in this directory are set to either kill processes or to start processes, which will in turn kill all other processes and force the reboot.

The scripts in the /etc/rc.d/rc<runlevel>.d directories begin with an S to start a process or with a K to shut down (kill) a process. The numbers following the letters (S or K) determine the order of execution from lowest to highest.

When UNIX boots, the kernel executes /sbin/init, which starts all other processes. The init process determines which runlevel to load by reading the /etc/inittab file.

For example, the kernel will boot into the runlevel in the initdefault line in the /etc/inittab file, such as follows:

id:5:initdefault:

In this case, the default is runlevel 5, or XWindows.

The /etc/inittab file describes which processes are started at bootup and during normal operation (for example, /etc/init.d/boot, /etc/init.d/rc, gettys...). init distinguishes multiple runlevels, each of which can have its own set of processes that are started. Valid runlevels are 0 through 6 plus A, B, and C for on-demand entries. An entry in the inittab file has the following format:

id:runlevels:action:process

An important security feature that can be controlled by init is the process that runs when a user simultaneously presses the three keys Ctrl+Alt+Delete. The system administrator may need to limit a non-root user's ability to shut down a key server. The following line in the /etc/inittab file will set the Ctrl+Alt+Del interrupt to run the exit process. This would log off the user but would not reboot the machine.

ca::ctrlaltdel:/sbin/shutdown -nh now

Use the command ps -aux to view all process on your machine.

The xinetd process

The xinetd process (inetd on some platforms) is a service that starts other services on demand. It only runs the daemon when a connection request is made for the particular service. A simple configuration file identifying the port and the service to run is put in the /etc/xinetd/ directory. The following is a listing off one of these configuration files for the POP3 service:

# cat /etc/xinetd.d/ipop3
# default: off
# description: The POP3 service allows remote users to access their mail \
# 	       using an POP3 client such as Netscape Communicator, mutt, \
# 	       or fetchmail.
service pop3
{
	socket_type 	= stream
	wait 		= no
	user 		= root
	server 		= /usr/sbin/ipop3d
	log_on_success += HOST DURATION
	log_on_failure += HOST
	disable 	= yes
}

Of particular interest is the last line of the configuration, disable = yes. This will prevent xinitd from responding to a request on the POP3 port. To enable POP3, the yes is changed to no.

Note that the port for POP3 is not provided in the preceding configuration file. When the port is not designated, xinetd uses the port listed in the /etc/services file, as follows:

# grep pop3 /etc/services
pop3 	110/tcp 	pop-3 		# POP version 3
pop3 	110/udp 	pop-3
pop3s 	995/tcp 			# POP-3 over SSL
pop3s 	995/udp 			# POP-3 over SSL

Because the services controlled by xinetd are on demand, they will not run until the associated port is hit from the network. Assuming that the POP3 service is enabled (disable = no in the configuration file), you will see the open port in the following (shortened) netstat output:

# netstat -ap
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State 	PID/Program name
tcp 	   0 	  0 *:pop3 	  *:* 		  LISTEN 	2295/xinetd

However, when you look at the ps output, you do not see pop3 running because the port has not yet been hit from the network.

# ps -aux | grep pop3
root 	2307   0.0   0.0   3568   624 pts/2 	S    07:44   0:00 grep pop3

The xinetd process can control processes in numerous ways. There are means for special logging and controlling of the services. There are several ways to lower the risk of a denial-of-service (DoS) attack.

The man pages for xinetd.conf provide a detailed listing of these options.