Building a Reliable Cluster Account Authentication Mechanism

The system administrator would like to use a central LDAP server to administer all of the users accounts, but would also like to use the local /etc/ passwd and /etc/group files on each cluster node to improve the reliability and performance of the account authentication system. The system administrator also needs to support a few Unix servers that are currently NIS clients of an existing NIS system that is used along with the local /etc/passwd file on the existing Unix monolithic server. The Linux Enterprise Cluster in this case study will be protected by a firewall, and only internal employees will be allowed to access it.

The goal of this case study, then, is to make the /etc/passwd (and /etc/ group) file the same on all of the cluster nodes by using a simple script that will pull the account and group information out of the LDAP server. This script can then run as a regularly scheduled cron job on all of the cluster nodes.

Using the Local Passwd and Group File on Each Cluster Node

Unix and Linux systems normally store user accounts in the /etc/passwd file and encrypted user passwords in the /etc/shadow file. The historical reason for doing this is to protect the encrypted passwords by "hiding" them from users in a file that only the root account can access (so users can't grab the encrypted passwords and run a tool like Crack that will guess the password). In this case study, however, the cluster nodes sit behind a firewall, and the system administrator does not allow users access to a shell (where they might be able to run the crack program to guess encrypted passwords), so the encrypted passwords do not need to be stored in the /etc/shadow file. (Linux will use an encrypted password if it finds one in the second field in the /etc/ passwd file instead of consulting the /etc/shadow file.) We can therefore meet the needs of this organization by writing a simple script that pulls the user and group information out of the LDAP server and places it into the local /etc/group and /etc/passwd file on each node, and we need only update the /etc/nsswitch.conf file on the cluster nodes to tell them to use their local files for accounts and groups.

Note 

See http://webmin.com and http://symark.com for two additional methods of distributing user accounts to each cluster node.

A Simple Script

The script that runs on each cluster node could pull the user and account information out of the LDAP server using the ldapsearch command, but because this organization also needs to continue to support NIS clients, it has decided to purchase the NIS/LDAP gateway from PADL software (http://www.padl.com). With this software installed on the high-availability LDAP server (the cluster node manager running the LDAP server as a resource under Heartbeat's control), the cluster nodes can run the ypbind daemon and communicate with the LDAP server as if it were an NIS server. The script can therefore use the familiar ypcat command to access the user and group information that is stored on the LDAP server, even though the server is really an LDAP server and the /etc/nsswitch.conf file on the cluster nodes points to the local /etc/passwd and /etc/group files. The script then only needs to contain the following two lines:

 ypcat passwd > /etc/passwd ypcat group > /etc/group 

These commands will overwrite all of the /etc/passwd and /etc/group entries on the system with the information stored on the NIS (LDAP) server, so be sure to create all of the normal system accounts (especially the root user account) on the LDAP server.

One downside to this method is that a glitch in the network or NIS system may cause corrupted account information to overwrite the local /etc/passwd file on all cluster nodes. Thus, an even better way to apply the changes to each node is with the patch and diff commands; for example, with a shell script like this:

     ypcat passwd > /tmp/passwd     diff -e /etc/passwd /tmp/passwd > /tmp/passwd.diff     patch -be /etc/passwd /tmp/passwd.diff 

Because these commands use the ed editor (the -e option) to modify only the changed lines in the /etc/passwd file, this script can be run at any time without affecting users logged on to the system. To avoid corrupting the /etc/passwd file with garbage data, have this script check to make sure that the NIS server is operating normally with a test like this:

 ypcat passwd > /tmp/passwd if [ ! -s /tmp/passwd ]; then         logger "Empty password file retrieved from LDAP. Aborting."         exit 1 fi 

The if statement in this bash shell script code will check to make sure the file that contains the passwd lines that were downloaded from the LDAP server is not empty. This test should be done before the patch command is used to apply the changes (if there are any) to the local passwd file as described in the preceding paragraphs.

As you can see from this case study, choosing the right account administration technique for your Linux Enterprise Cluster will depend on your situation.