McFarm-Specific Linux Services Configuration

This document describes configuration of services required for operation of McFarm software. These include NIS, NFS and SSH.

NOTE: The McFarm software operates under its own account ‘mcfarm’.

NIS:

All farm nodes share the ‘mcfarm’ account within the cluster. To effect this sharing, NIS (yp) is used. Described below is the configuration necessary to use this service. It is required that all the farm nodes be on the same NIS domain for which the yp-server is the same as the job server, since the ‘mcfarm’ account is only created on the job server. Note that all these steps have to be carried out as root user.

Case I: NIS (yp) was enabled during RH 7.x LINUX installation. (Recommended)

In this case, you chose to enable NIS during LINUX installation and also chose the NIS domain name that you had for the farm, and also chose the name of the Job server as the NIS domain server.

On the NIS Domain Server ( Also the Job server of the farm):

1. Start the yp-server by running the command /etc/init.d/ypserv start.

2. Start the yp-passwd daemon by running the command
/etc/init.d/yppasswdd start

3. Add these commands to the /etc/rc.d/rc.local file so that these services are started automatically during startup.

4. After creating the mcfarm account, make sure you run the command /usr/lib/yp/ypinit –m. This command rebuilds the password database to be shared among machines on the cluster. It will prompt for all the NIS servers for this domain. For the farm, there is only one, which it will list anyway. Therefore answer with Ctrl-D at the prompt, and then ‘y’ at the next prompt. Note that this command needs to be run everytime a new account is added to the server, and you want the account to be propagated to all the other nodes on the cluster.

5. Start the yp-bind service: /etc/init.d/ypbind start. And then check by using the ypwhich command. This should echo back the name of the NIS domain server. This is not really required on the server, and is merely a diagnostic step to tell you that the yp-server is up and running.

Note that these steps need only be carried out once.

On any NIS client (i.e. Any node other than the job server on the farm):
1. Start the yp-bind service with the command /etc/init.d/ypbind start. Also put this command in the /etc/rc.d/rc.local file for automatic startup at reboot. Once again test with the ypwhich command.

Case II: NIS was not enabled during RH 7.x LINUX installation

For some reason, if you did not choose to enable NIS during installation, these are the steps you have to take to configure the farm for yp.

On the NIS Domain Server (Also the Job server of the farm):

1. Choose an NIS domain name. Then run the command
domainname YOUR_DOMAIN_NAME. This will set the domain name of this machine as YOUR_DOMAIN_NAME. Also add this command to the /etc/rc.d/rc.local file so that the NIS domain name is at startup.

2. Then modify the /etc/yp.conf file and add a line in the following format:
domain YOUR_DOMAIN_NAME server JOB_SERVER,
where JOB_SERVER is the full name of the farm job server. Also add a line to mention the yp-server explicitly: ypserver JOB_SERVER.

3. Then start the following daemons:
/etc/init.d/ypserv start
/etc/init.d/yppasswdd start
These daemons have to be started automatically at boot time. To do this, you need to add some links in the /etc/rc.d/rc*.d directories as follows:

a) Under the /etc/rc.d directory, you will find 6 directories with names of the form ‘rcN.d’, where the N stands for each of the run-levels in Linux, from 1 to 6. You will only have to modify directories rc3.d, rc4.d and rc5.d as directed below.

b) In each of the directories listed above, you will find links of the form “Sxx*” or “Kyy*”. These specify which services to start and kill respectively during boot time or shutdown time. The “xx” and “yy” represent numbers unique to that directory – i.e. if you see a “K29something” you will not see another “K29something-else” in the same directory. In each of the above three directories create links using the following commands:
ln –s ../init.d/ypserv SXXypserv
ln –s ../init.d/yppasswdd SYYyppasswdd
The “XX” and “YY” can be any numbers that unique to the directory you are working in as described above.

4. Then, run the command /etc/init.d/ypbind start to start the yp-bind daemon. Then you can run the command ypwhich, which should echo back to you the name of the NIS domain server, which in this case will be the full name of your farm job server machine. Note that this is merely a diagnostic measure to see that yp is running as it should be.

On Any NIS Client Machine: (i.e. Any node other than the job server on the farm):

1. Follow steps 1 & 2 as described above to configure your domain name, and the yp config file.

2. Then since you did not enable NIS during installation, you need to configure the machine so that any login first tries to authenticate itself from the NIS server. To do this, you have to change the /etc/nsswitch.conf file. This file contains a list of all the services required for the authentication process, like ‘passwd’, ‘group’, ‘shadow’, ‘hosts’ and a bunch of other services. The important ones are the ones listed above. Each of these services will be described in a line by itself, followed by one or more of the entries ‘nis’, ‘files’ or ‘nisplus’ after the service name. You have to make sure that the FIRST entry in that list after each of the preceding service names is ‘nis’. This will force initial authentication to come through NIS.

3. Then run the command /etc/init.d/ypbind start to bind to the NIS server. Once again use the ypwhich command as a diagnostic. Then you can test the NIS configuration by trying to login as ‘mcfarm’ on this node. Also, add the command /etc/init.d/ypbind start to /etc/rc.d/rc.local to start ypbind automatically at startup.

NFS:

The farm relies heavily on sharing files and directories through NFS. This requires that ALL farm machines have an NFS server installed on them during LINUX install, and that the NFS daemon be started up automatically during startup. This is effected by adding the line: /etc/init.d/nfs start to the /etc/rc.d/rc.local file.

Specifics of how to export directories and partitions on individual nodes are described in the documents describing the actual setup of the nodes.

SSH:

NOTE: Do this only after you have all the nodes on the farm up and running. You then need to perform these steps on the job-server and every other node on the farm.

The farm requires that nodes within the farm be configured for host-based-access. This means that one should be able to login to any node in the farm from another node within the farm without having to type in a password under the ‘mcfarm’ account. The following steps need to be taken to effect this:

1. SSH version 2 is automatically installed during LINUX installation. It must be possible to login to the farm using SSH first before one can configure it for host-based access. If you are not able to login to the farm using SSH, make sure that /etc/hosts.allow allows incoming SSH, and that /etc/hosts.deny does not deny incoming SSH.

2. This step has to be carried out on BOTH the node being configured as well as the Job server. As root user, change the /etc/ssh/ssh_config file and add these four lines: (Note that you have to use wild card characters in the host names in the following lines. It helps if all the farm nodes as uniformly named. For example, our HEP farm has all nodes with names of the form hepfmXXX.uta.edu. In this case to describe all these nodes with wildcard characters, we simply use hepfm*. This is used in the following example):
Host hepfm*
ForwardX11 yes
HostbasedAuthentication yes
PreferredAuthentications publickey,hostbased,password,keyboard-interactive
You should only have to change the first line to describe the nodes within your farm. The rest of the lines should be exactly as described. The privileges on this file must be 444. (To effect this, do chmod 0444 /etc/ssh/ssh_config as root user.)

3. This step has to be carried out on both the Job server as well as the node being configured. In the /etc/ssh/sshd_config file, change the value for the variable HostbasedAuthentication from ‘no’ to ‘yes’. Also change the value of the variable IgnoreRhosts from ‘yes’ to ‘no’. The privileges on this file must be 444.

4. Then restart both the job server as well as the node.

5. Then as user mcfarm on the job server, edit the .shosts file in the /home/mcfarm directory (create it if it is not there) and add a line for each machine in the farm in the following manner:
FULL_NODE_NAME mcfarm.
Also, this file must be owned by mcfarm, and only mcfarm must have read-write privileges on this file. (To effect this, do chmod +600 .shosts as user mcfarm.)

Now you should be ready to use host-based accesses on the mcfarm account. Test this by logging in as mcfarm on the job server and trying a command like ssh SOME_NODE_NAME ls. It should show you a listing of all the files in the /home/mcfarm dir without prompting you for a password. On the first time, it will ask you if you want to accept a host key from the remote machine. Answer ‘yes’ at the prompt, and you should be ready to go. Do this both ways so that the keys are generated for host-based access both ways – to and from the Job Server. Be sure to do this in both directions using BOTH the simple nodename AND the the full URL name, in order to get the "yes/no" verification reply out of the way regardless of which form is used in the future.