7.3. System Administration

The DNS system in the cluster sometimes causes Ganglia to record bogus node names (usually their IP addresses). To clear this situation, restart the "gmond" and "gmetad" services on the frontend. This action may be useful later, as it will flush any dead nodes from the Ganglia output.

# service gmond restart # service gmetad restart

This method is also useful when replacing or renaming nodes in your cluster.

This indicates a parse error in the Ganglia gmond XML output. It is generally caused by non-XML characters (& especially) in the cluster name or cluster owner fields, although any ganglia field (including node names) with these characters will cause this problem.

We hope future versions of Ganglia will correctly escape all names to make them XML safe. If you have a bad name, to edit /etc/gmond.conf on the frontend node, remove the offending characters, then restart gmond.

While there is no certain method to do this correctly, if necessary we recommend you use "ypcat" to periodically gather external NIS user accounts on the frontend, and let the default 411 system distribute the information inside the cluster.

The following cron script will collect NIS information from your external network onto the frontend. The login files created here will be automatically distributed to cluster nodes via 411. This code courtesy of Chris Dwan at the University of Minnesota.

(in /etc/cron.hourly/get-NIS on frontend) #!/bin/sh ypcat -k auto.master > /etc/auto.master ypcat -k auto.home > /etc/auto.home ypcat -k auto.net > /etc/auto.net ypcat -k auto.web > /etc/auto.web ypcat passwd > /etc/passwd.nis cat /etc/passwd.local /etc/passwd.nis > /etc/passwd.combined cp /etc/passwd.combined /etc/passwd ypcat group > /etc/group.nis cat /etc/group.local /etc/group.nis > /etc/group.combined cp /etc/group.combined /etc/group

There is no way to insure that UIDs GIDs from NIS will not conflict with those already present in the cluster. You must always be careful that such collisions do not occur, as unpredicatble and undefined behavior will result.

While rocks enforces that the compute nodes use the DNS server on the frontend, you may have the compute nodes use specific DNS servers from your organization to resolve names.

Instruct the frontend DNS server to use your desired servers as designated forwarders. This will "expand" the rocks server's knowledge to include names served by your DNS servers. (Submitted by Matt Wise)

1. Edit "/etc/named.conf" on your frontend.

   In the "options" paragraph, add the following lines:

   forward first; forwarders { (local named server); };

2. With an example forwarder 198.202.75.26, the file would look like this:

   // // named.conf for Red Hat caching-nameserver // options { directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; /* * If there is a firewall between you and nameservers you want * to talk to, you might need to uncomment the query-source * directive below. Previous versions of BIND always asked * questions using port 53, but BIND 8.1 uses an unprivileged * port by default. */ // query-source address * port 53; forward first; forwarders { 198.202.75.26; }; };

3. Restart the named service:

   service named restart

Your compute nodes will be able to resolve names served by your nameserver.

Assume your NAS node is called "bigbird" and users directories are exported from "/export/users". To add the user "dave" with home area as bigbird:/export/users/dave

Use "useradd" to make an account for dave.

# useradd --netserver bigbird -d /export/users/dave dave

In the example above, the directory bigbird:/export/users must be both mountable and writable by root on the frontend. If the directory is not writable by root then the users directory must be created by other means. See the "-M" option to useradd.

You can use the -d flag to use a different directory than the example above