20.6 Miscellaneous Services

20.6 Miscellaneous Services

This section provides summary information on several other services that you may use in your cluster.

20.6.1 The Internet Server Daemon (inetd)

The internet daemon (inetd (8)) is responsible for starting many other server daemons in response to incoming network requests. The inetd's configuration file (/etc/inetd.conf) is a cluster-wide file. It provides a mechanism for requesting daemon-based services that should run identically on every member. In a cluster, there is another configuration file (/etc/inetd.conf.local) that is used to configure services that are per member. To disable a service on a particular member in the cluster, alter the "local" configuration file such that it reflects "disable" in the "ServerPath" field in the /etc/inetd.conf.local file.

Caution

In V5.0A and V5.1, the "disable" does not work. This fact is clearly stated in the release notes. In V5.1A, it does work, but the Release Notes still state that it is broken.

20.6.2 Mail

All cluster members running a mail utility must have the same mail configuration and use the same protocols. For instance, if SMTP is used on one cluster member, it must be used on all cluster members. SMTP is a cluster-aware protocol and will use the default cluster alias. Other mail protocols (MTS, UUCP, X.25, DecNET Phase IV, DecNET Phase V) will treat cluster members as standalone systems. The mailstats (8) utility will return member-specific results because it references the member-specific /usr/adm/sendmail/sendmail.st file. Caution, the mailstats command will not work in an unpatched V5.1A system. The command works in V5.1B.

Cluster alias selection priority and selection weight can be used to load balance mail activities over the cluster members if desired (see Chapter 16 for more information). Configure mail with mailconfig (8) or mailsetup (8) but do not switch between utilities since they use different configuration file formats.

20.6.3 NIFF - NetRAIN

The Network Interface Failure Finder daemon (niffd (8)) must run on every member in order to monitor network connectivity. NIFF is also used in conjunction with the cluster alias subsystem. The aliasd forks a child (aliasd_niff) that is used to subscribe the niff-related EVM events and notify aliasd when an interface goes down so that alias routing can be adjusted.

The NIFF daemon can be used to monitor a NetRAIN pseudo device, if desired. NetRAIN identifies a series of physical network devices as one virtual network device. If the active interface in the set fails, the NetRAIN software fails over to another network interface in the set using the same IP address.

NIFF and NetRAIN are covered in Chapter 9 and Chapter 12. Also see the Tru64 UNIX Network Administration manuals in the documentation set for further information on these options.

20.6.4 The ifaccess.conf File

In order to prevent the great unwashed from deciding to masquerade as a member of your cluster and get access to all of your precious data, the system provides an interface access filter file (/etc/ifaccess.conf). This file provides a mechanism whereby an interface can define and limit access to the interface from various networks or subnets. If your cluster uses a LAN interface, each member must provide an /etc/ifaccess.conf file with an entry for the virtual network address (typically 10.0.0.1) and an entry for the network address for each physical interface. (The Memory Channel does not require the physical address entries but does require an entry for the virtual network interface address.)

On each cluster member other than the first member, you must manually edit the /etc/ifaccess.conf file and add a line for the physical network addresses for each network interface. The following output shows the contents of the /etc/ifaccess.conf file:

 #                  Interface Access Filtering Configuration File # # Description: The ifaccess.conf file contains the permit/deny mode for #                      one or more interfaces running the Internet Protocol. # # Syntax:           interface-name address mask action # # Comment lines begin with number sign (#). # # Example: # # ln0 16.1.0.0 255.255.255.0 permit     # permit net 16.1.0 on ln0 # ln0 16.0.0.0 255.0.0.0 denylog        # deny and log net 16 on ln0 # tu1 192.15.32.0 255.255.255.0 deny    # deny net 192.15.32 on tu1 # # Refer to the ifaccess.conf(4) man page for further explanation. # sl0 10.0.0.0 255.255.255.0 deny tu0 10.0.0.0 255.255.255.0 deny tu1 10.0.0.0 255.255.255.0 deny tu2 10.0.0.0 255.255.255.0 deny 

For extra security, be sure to run the ifconfig command and specify the "filter" parameter after adding information to the ifaccess.conf file. As of this writing, the filtering must be turned on by hand.

 # ifconfig tu0 filter 

20.6.5 NTP

In order to keep all cluster members in virtual synchronization with respect to time, the Network Time Protocol (NTP) is used. NTP uses a time stratum strategy whereby time can be considered to be more accurate when delivered from one NTP server as compared with another. The most accurate time is delivered from a "stratum 1" server that has an accurate time derived from some highly reliable source (see http://www.ntp.org for a list of public servers). If a member serves out time that was acquired from a stratum 1 server, the time value served out by that member is treated as if it came from a stratum 2 server and so forth. If an NTP client receives time from several NTP servers, it simply selects the time from the lowest stratum rated server.

According to the Tru64 UNIX Cluster Installation manual, NTP is automatically configured on the first member of your cluster when you issue the clu_create (8) command. However, as of V5.1A, the clu_create script simply checks to see if you have NTP configured, and if not, it errors out. Therefore, we recommend installing NTP prior to installing the first cluster member. If you will be using one or more external time sources, it is imperative to install NTP as described above because when/if the software catches up with the documentation, the clu_create and clu_add_member commands will set up the members as NTP peers of each other.

Additional cluster members have NTP automatically configured as they are added to the cluster. All members in the cluster are configured as NTP peers. This allows all cluster members to provide their version of time to other cluster members. This mechanism usually provides synchronization within ten thousandths of a second. Note that two members that are out of time sync will gradually (as opposed to instantaneously) be brought back in sync. This avoids the potential for software repercussions if time changes too drastically and too quickly.

To avoid the blind leading the blind, we would recommend configuring NTP on your initial system such that it is synched to an accurate external source; although for starters, you may want to have one member synch to 127.127.0.1 (the local reference clock – for more information see the ntp_manual_setup (7) and ntp.conf (4) reference pages).