Network Configuration Files

The /etc/hostname file contains the fully qualified domain name of the local host. Thus, the system emu, in the DNS domain cassowary.net , has the fully qualified domain name emu.cassowary.net . Independent of DNS is the local hosts file ( /etc/hosts ), which is used to list local hostnames and IP addresses. For a network with large numbers of hosts, using the /etc/hosts file is problematic because its values must be updated on every host on the network each time a change is made. This is why DNS (or NIS/NIS+) is a better solution for managing distributed host data.

However, the /etc/hosts file contains entries for some key services, such as logging, so it usually contains at least the following entries:

• The loopback address, 127.0.0.1, which is associated with the generic hostname 'localhost.' This allows applications to be tested locally using the IP address 127.0.0.1 or the hostname localhost.

• The IP address, hostname, and fully qualified domain name of the localhost, because it requires this data before establishing a connection to a DNS server or NIS/NIS server when booting.

• An entry for a log host, so that syslog data can be redirected to the appropriate host on the local network.

A sample /etc/hosts file is shown here:

 127.0.0.1     localhost 192.68.16.1     emu   emu.cassowary.net 192.68.16.2     hawk  hawk.cassowary.net     loghost 192.68.16.3     eagle eagle.cassowary.net 

In this configuration, the localhost entry is defined, followed by the name and IP address of the localhost (hostname emu, with an IP address 192.68.16.1). In this case, emu redirects all of its syslog logging data to the host hawk (192.68.16.2), while another host eagle (192.68.16.3) is also defined.

Configuring Network Interfaces

The ifconfig command is responsible for configuring each network interface at boot time. ifconfig can also be used to check the status of active network interfaces by passing the -a parameter:

 router# ifconfig -a lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232         inet 127.0.0.1 netmask ff000000 hme0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500         inet 10.17.65.16 netmask ffffff00 broadcast 10.17.65.255 hme1: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500         inet 204.17.65.16 netmask ffffff00 broadcast 204.17.65.255 

In this case, the primary interface hme0 is running on the internal network, while the secondary interface hme1 is visible to the external network. The netmask for a Class C network is used on both interfaces, while both have a distinct broadcast address. This ensures that information broadcast on the internal network is not visible to the external network. There are several parameters shown with ifconfig -a , including whether or not the interface is UP or DOWN (that is, active or inactive). In the following example, the interface has not been enabled at boot time:

 server# ifconfig hme1 hme1: flags=863<DOWN,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500         inet 204.17.64.16 netmask ffffff00 broadcast 204.17.64.255 

If the /etc/ethers database has been updated by the administrator to include details of the Ethernet addresses of hosts on the local network, there is also an entry displayed about the corresponding interface when using ifconfig :

 server# cat /etc/ethers 8:0:19:7:f2:a1 server server# ifconfig hme1 hme1: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500         inet 204.17.128.16 netmask ffffff00 broadcast 204.17.128.255 ether 8:0:19:7:f2:a1 

It can also be useful in detecting problems with a routing network interface to examine the Address Resolution Protocol (ARP) results for the local area network. This will determine whether or not the interface is visible to its clients :

 server# arp -a Net to Media Table Device   IP Address               Mask      Flags   Phys Addr ------ -------------------- --------------- ----- --------------- hme0   server1.cassowary.net 255.255.255.255       00:c0:ff:19:48:d8 hme0   server2.cassowary.net 255.255.255.255       c2:d4:78:00:15:56 hme0   server3.cassowary.net 255.255.255.255       87:b3:9a:c2:e9:ea 

Modifying Interface Parameters

There are two methods for modifying network interface parameters. First, the ifconfig command can be used to modify operational parameters and bring an interface online (up) or shut it down (down). Second, one can use ndd to set parameters for TCP/IP transmission, which will affect all network interfaces. In this section, we will examine both of these methods and how they may be used to manage interfaces and improve performance.

It is sometimes necessary to shut down and start up a network interface in order to upgrade drivers or install patches affecting network service. To shut down a network interface, for example, one can use this command:

 server# ifconfig hme1 down server# ifconfig hme1 hme1: flags=863<DOWN,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500         inet 204.17.64.16 netmask ffffff00 broadcast 204.17.64.255 

It also possible to bring this interface back up by using the ifconfig command:

 server# ifconfig hme1 up server# ifconfig hme1 hme1: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500         inet 204.17.64.16 netmask ffffff00 broadcast 204.17.64.255 

To ensure that this configuration is preserved from boot to boot, it is possible to edit the networking startup file /etc/rc2.d/S69inet and add this line to any others that configure the network interfaces.

It may be necessary to set several of these parameters in a production environment to ensure optimal performance, especially when application servers and web servers are in use. For example, when a web server makes a request to port 80 using TCP, a connection is opened and closed. However, the connection is kept open for a default time of two minutes to ensure that all packets are correctly received. For a system with a large number of clients, this can lead to a bottleneck of stale TCP connections, which can significantly impact the performance of the web server. Fortunately, the parameter that controls this behavior ( tcp_close_wait_interval ) can be set using the ndd command to something more sensible (like 30 seconds):

 server# ndd -set /dev/tcp tcp_close_wait_interval 30000 

However, administrators should be aware that altering this parameter will affect all TCP services, so while a web server might perform optimally with tcp_close_wait_interval equal to 30 seconds, a database listener that handles large datasets may require a much wider time window. The best way to determine optimal values is to perform experiments with low, moderate, and peak levels of traffic for both the web server and the database listener to determine a value that will provide reasonable performance for both applications. It is also important to check SunSolve for the latest patches and updates for recently discovered kernel bugs .

Configuring inetd

Services for inetd are defined in /etc/inetd.conf . Every time you make a change to inetd.conf , you will need to send a HUP signal to the inetd process. You can identify the process ID (PID) of inetd by using the ps command, and then sending a kill SIGHUP signal to that PID from the shell. In addition, commenting an entry in the /etc/services file will not necessarily prevent a service from running: strictly speaking, only services that make the getprotobyname () call to retrieve their port number require the /etc/services file. So, for applications like sendmail, removing their entry in /etc/services has no effect. To prevent sendmail from running, you would need to comment out its entry in /etc/inetd.conf , and send a SIGHUP to the inetd process.

A service definition in /etc/inetd.conf has the following format

 service   socket   protocol   flags   user   server_name    arguments 

where the service uses either datagrams or streams and uses UDP or TCP on the transport layer, with the server_name being executed by the user. An example entry is the UDP talk service:

 talk    dgram   udp     wait    root    /usr/sbin/in.talkd      in.talkd 

The talk service uses datagrams over UDP and is executed by the root user, with the talk daemon being physically located in /usr/sbin/in.talkd . Once the talk daemon is running through inetd, it is used for interactive screen-based communication between two users (with at least one user 'talking' on the local system).

In order to prevent users from using (or abusing ) the talk facility, you would need to comment out the definition for the talk daemon in the /etc/inetd.conf file. Thus, the line shown earlier would be changed to

 #talk    dgram   udp     wait    root    /usr/sbin/in.talkd      in.talkd 

In order for inetd to register the change, it needs to be restarted by using the kill command. To identify the PID for inetd, the following command may be used:

 bash-2.03# ps -eaf  grep inetd     root   206     1  0   May 16 ?       30:19 /usr/sbin/inetd -s 

To restart the process, the following command would be used:

 kill -1 206 

The daemon would then restart after reading in the modified inetd.conf file.