Linux with Operating System Concepts

super-
server
in that it is capable of controlling multiple running services. In this case, the super-
server listens to the various ports for incoming messages and then invokes the service that 
corresponds to the port. For a system that might expect to receive any number of network 
communications, having xinetd running may be preferable than keeping a number of net-
work-oriented services running all the time. On the other hand, a dedicated server would 
run the appropriate service(s) instead. For instance, for a web server running Apache, we 
would expect the Apache web server program (httpd) to be running all the time rather 
than having it started and stopped by xinetd on demand.
The xinetd service will be invoked when an incoming message arrives. It will first utilize 
the file 
/etc/services
, which provides a mapping of services to ports. For instance, if a 
message arrives over port 22, it will be mapped to ssh. With this information, xinetd will 

---

500
◾
Linux with Operating System Concepts
examine its own configuration for how to respond to an ssh message (presumably resulting 
in the starting of the sshd service).
The xinetd service is configured in two ways. First, it has its own configuration file, 
/etc/
xinetd.conf
. The configuration file will consist of default directives. An example for the 
defaults is shown below.
defaults {
instances
=
50
log_type
=
RSYSLOG authpriv
log_on_success 
=
PID HOST DURATION EXIT
log_on_failure 
=
HOST
cps 
=
25 10
umask 
=
002
}
includedir /etc/xinetd.d
Instances provide a maximum number of simultaneous requests that can be handled. 
The logging directives specify who is responsible for logging and what to log on a success-
ful versus failed connection attempt. In this case, rsyslog is asked to perform logging using 
FIGURE 12.4 
An expired certificate.

---

Network Configuration
◾
501
authpriv as the source where a successful access will log the PID, host IP address, duration, 
and exit status of the communication while the failed attempt will log the host IP address. 
The directive cps establishes the number of connections per second of any given service 
and the amount of time that a service must wait before it can be restarted, respectively. The 
directive umask establishes the umask value for the service.
The includedir directive establishes the directory that will store various services’ con-
figuration files. Each service configuration file contains the options for the given service. 
For instance, the rsync service configuration file might look like the following:
service rsync
{
disable
=
yes
flags 
=
IPv6
socket_type
=
stream
wait 
=
no
user 
=
root
server
=
/usr/bin/rsync
server_args
=
--daemon
log_on_failure 
+=
USERID
}
In this example, we see that the rsync service, by default, will be disabled (not run-
ning). Its flags are only 
IPv6
. The type of communication is a 
stream
(as opposed to 
dgram
, 
raw,
or 
seqpacket
). The directive 
wait
indicates that this service should run 
as a single thread so that multiple requests cannot be handled in parallel but instead, any 
successive requests for rsync must wait until the current request has terminated. It runs 
under the user root and the executable of the program is at 
/usr/sbin/sync
that runs 
with only one option, --
daemon
. Finally, the 
+=
notation for 
log_on_failure
indi-
cates that 
USERID
should be added to any 
log_on_failure
options provided in the 
xinetd.conf
file.
In addition, you can add directives for protocol, group (like user), nice to specify a pri-
ority value for the service, 
only_from
to provide a list of remote hosts from which an 
incoming message will invoke the service (any other incoming messages will not be han-
dled by xinetd), 
no_access
to provide a list of remote hosts that this service will not 
handle (the opposite of 
only_from
, you would only use one of these two directives), and 
access_time
to control when the service can be invoked. You can also override any of 
the defaults, for instance, by including 
instance
, 
cps
, 
log_type,
and 
umask
in the 
specific service’s file. There are also about a dozen flags available aside from IPv6.
The xinetd service is preferred over inetd because inetd has greater limitations. For one, 
xinetd has security-oriented options such as the 
only_from
, 
no_access,
and 
time
directives. There are also more logging options available through xinetd. Finally, in inetd, 
all the specific services that inetd could handle would be enumerated in its configuration 
file, line by line. The use of individual service configuration files in xinetd is considered 
cleaner and easier to maintain.

---

502
◾
Linux with Operating System Concepts
12.3.5 Two /etc Network Files
The /etc directory stores other files that impact the network that we need to explore. First, 
is the file /etc/hosts. Through this file, the system administrator can establish IP alias to 
IP address mappings that can bypass a DNS lookup. The advantage in doing this is to 
save time. However, given that IP addresses can change over time, the risk you face is 
that an IP address entered into the 
/etc/hosts
file may become out of date and lead to 
errors in attempting to resolve a mapping request. Therefore, you should only place static 
IP addresses in this file and only those that you are sure will not change, or are static IP 
addresses that you control (so that if you change the static addresses, you can modify the 
hosts table).
The syntax for the host table is a series of rows, each specifying a mapping. The entries 
are in this form:
ip_address ip_alias1 ip_alias2 
…
As you can see, multiple IP aliases can share the same IP address. For instance, we might 
find a computer like www.nku.edu has a real (canonical) name of machine1.nku.edu and 
may also be known as ns1.nku.edu. If that machine’s IP address was 10.11.12.13, the entry 
might read
10.11.12.13 www.nku.edu machine1.nku.edu ns1.nku.edu
The order of the aliases is unimportant, but the entries are scanned in order; so, we 
would probably want to list them in decreasing order of usage so that the most common 
name came first.
The hosts table can also store other information. First, we can establish which should be 
examined first in an IP address resolution: 
hosts
or 
bind
. Hosts refer to accessing this 
file while bind is a DNS server program for Linux. We examine bind in detail in Chapter 15 
(available at http://www.crcpress.com/product/isbn/9781482235890). If we want to make 
sure the 
/etc/hosts
table is consulted before a name server, we would use
order hosts, bind
The order command can also include nis to indicate that name resolution takes place 
through NIS (the network information service).
The other file to explore is 
/etc/resolv.conf
. This file is used to specify the location(s) 
of your IP alias name resolver, that is, your DNS server. If properly configured, this file will 
be automatically filled with the proper name server addresses upon starting your network 
service. This is accomplished via zero configuration. Otherwise, you might be responsible 
for setting up this file yourself.
The primary entry for this file is the list of IP addresses for the local DNS server(s). 
Any such entry is placed after the directive 
nameserver
. Other common directives are 
search
and 
domain
. Only nameserver is required. The search and domain entries can 

---

Network Configuration
◾
503
be used to establish the search domain name and the domain name of your computer. The 
search domain name, by default, is the same as the domain name. However, you can add 
to the search entry other domain names to use when the current domain is one of sev-
eral subdomains. Other directives include 
sortlist
to establish an ordering behind IP 
addresses that are returned by the C function 
gethostbyname
, and 
options
to alter 
default values of variables used by the various C functions that implement name resolution 
(e.g., 
res_init
, 
res_query
, and 
res_search
). As an example of a resolv.conf file, we 
might see the following entries:
domain somedomain.somecompany.com
search somedomain.somecompany.com
nameserver 10.11.12.13
nameserver 10.11.12.14
nameserver 172.15.183.1
Here, we see that this machine is part of somedomain.somecompany.com and has three 
local name servers to call upon.
12.4 OBTAINING IP ADDRESSES
IP addresses can be assigned in two ways: static IP addresses assigned once by an adminis-
trator (and seldom changed once established), and dynamic IP addresses typically assigned 
whenever the computer is booted/rebooted. Static IP addresses are permanent, or persis-
tent. Changing one requires modifying DNS tables. Today, most IP addresses are generated 
dynamically. For this, you need access to a DHCP. The DHCP server will need to know the 
range of available IP addresses that it can hand out. This will vary from organization to orga-
nization as IP addresses are provided to each organization by an IP authority. In this sec-
tion, we look at setting up static IP addresses, obtaining IP addresses from a DHCP server, 
and setting up a DHCP server in Linux. We start with the easy case, static IP addresses.
12.4.1 Static IP Addresses
To establish a static IP address, you must first have an address available. For an organiza-
tion, you will be allotted some number of IP addresses for your resources. Someone then 
has the task of assigning the addresses to the individual machines that will have static 
addresses. Once assigned a static IP address for your computer, you would perform the 
following activities (for Red Hat Linux).
First, you would edit the file 
ifcfg-eth0
under 
/etc/sysconfig/network-
scripts
(see Section 12.3). In this file, you will place the IP address in the variable 
IPADDR
and assign 
BOOTPROTO
to “static.” The former establishes the IP address and 
the latter indicates that the computer’s address is static and not dynamic. Additionally, you 
would assign 
HOSTNAME
the value of the machine’s hostname, which would then be used 
to form the machine’s IP alias. For instance, if the hostname is Machine1 and it is located 
within the domain somecompany.com, the full IP alias becomes Machine1.somecompany.
com. You would also supply the netmask in the variable 
NETMASK
.

---

504
◾
Linux with Operating System Concepts
In addition to modifying the ifcfg file for your interface device(s), you must modify the 
file 
/etc/sysconfig/network
. Specifically, you want to include both the host name 
and the IP address of the machine’s 
gateway
. The gateway is your local network’s con-
nection to other networks. The gateway is the destination for messages from your com-
puter that are to reach other networks. You would assign these two values to the variables 
HOSTNAME
and 
GATEWAY,
respectively.
Now that your computer knows its own IP address and IP alias, we now must alert 
other computers of your address. Recall from Section 12.2 that DNS servers are used to 
perform IP alias to IP address mappings. Your own local organization or your Internet 
service provider will store its own DNS server. This server primarily maps IP aliases to 
internal computers. That is, your local DNS is an authority of the local domain, knowing 
for each specific internal host with a static IP address what that address is or where to go to 
retrieve that information. This DNS server’s table must be modified to include an entry for 
your computer. Once both your computer and your DNS server have been provided the IP 
address, you are ready to go. Just restart the network service on your computer and you will 
find that your IP address has been assigned (e.g., use ip addr or ifconfig).
If you wish to change static IP addresses, you would modify the ifcfg file to update the 
IPADDR and possibly NETMASK entries. You would also have to notify your local DNS 
server(s) of the modification. And, of course, you would have to restart your network ser-
vice to use the new IP address. If you do not modify the DNS server, you may find that 
responses to your outgoing messages do not make it back to your computer.
If you wish to establish a static IP address for a Ubuntu machine, the process is slightly 
different. Rather than editing the ifcfg file(s), you would instead modify 
/etc/network/
interfaces
by specifying the IP address, network address, netmask, broadcast address, 
and gateway address. What follows is an example:
iface eth0 inet static
address 10.11.12.13
network 10.11.0.0
netmask 255.255.192.0
broadcast 10.11.51.1
gateway 172.83.11.253
12.4.2 Dynamic IP Addresses
DHCP was developed to replace the outdated Bootstrap Protocol from the early 1990s. The 
Bootstrap Protocol was set up to supply clients with IP addresses upon boot, but did not 
have the functionality that DHCP provides. With DHCP, not only can you obtain dynamic 
IP addresses but DHCP will also respond with other configuration information such as 
the addresses of the local network’s router and the network’s DNS server(s). Additionally, 
because dynamic addresses are only granted temporarily, with DHCP, IP addresses can be 
set to expire.
As the DHCP server must be able to inform local clients of network-specific informa-
tion, the DHCP server’s domain is limited to small networks. The DHCP server will only 

---

Network Configuration
◾
505
service computers that share the same network link (the bottommost layer in TCP/IP). 
Thus, any organization whose network consists of many subnets will require several DHCP 
servers. Each server should be provided its own range of IP addresses.
Upon booting, a client of the DHCP server will send a broadcast query on its local net-
work, requesting an IP address and configuration from the DHCP server. If the local sub-
net does not have its own DHCP server, the router can forward the request to the DHCP 
server located on other subnetworks and await a response to return to the client.
The server stores a table of available and used IP addresses. It selects an unused address 
and sends to the client the address, the default gateway address, the domain name, the DNS 
server addresses, and possibly other information (time, date, and duration of validity for the 
IP address). Now, the client can set its own internal information such as in the file 
/etc/
sysconfig/network-scripts/ifcfg-eth0
. Once this information has been stored, 
the client can (re)start its network service. For convenience, a client can request from the 
DHCP server the last used IP address. If available, the DHCP server can permit this. By doing 
so, other tables that have cached your computer’s IP address will not need to be modified.
Linux uses the program 
/sbin/dhclient
to perform the operations needed to set up 
your client computer with dynamic IP addresses. In CentOS, all you have to do is modify 
the appropriate ifcfg file (e.g., ifcfg-eth0) to call upon 
dhclient
. Specifically, you will 
modify the 
BOOTPROTO
from 
static
to dhcp. You would also remove the entries for 
both 
IPADDR
and 
NETMASK
, as these will be filled in by the DHCP server.
Another entry worth exploring is 
PERSISTENT_DHCLIENT
. By setting this variable 
to 
1
, you are asking your computer to query the local router or DHCP until an IP address 
has been granted. Without this, if your first request does not reach a DHCP or if for some 
reason, you are not provided an IP address, then you have to try again. You would restart 
the network service and upon restarting this service (or the next boot), you will obtain 
your IP address and configuration information from the DHCP server.
12.4.3 Setting up a DHCP Server
To set up a DHCP server in Linux, you will need the 
dhcp
package. You can obtain this 
via source code or an executable using rpm or yum. Using yum, issue the instruction 
yum 
–y install dhcp
. Installation includes numerous files. First, the dhcpd service-con-
trolling script is placed in 
/etc/init.d/dhcpd
. The dhcpd service is stored as 
/usr/
sbin/dhcpd
. There are also configuration and data files created and stored as 
/etc/
sysconfig/dhcpd
and 
/etc/dhcp/dhcpd.conf
.
To establish your DHCP server, you will have to modify the conf file. When DHCP is 
installed, a sample conf file is provided for you under 
/usr/share/doc/dhcp