- Be sure your network meets
these prerequisite requirements.
This is essential to ensure a stable network so Rush can operate reliably.
It's important machine's hostnames and IP addresses don't change after
casual reboots. IP addresses should be consistent through reboots,
which a well configured static DNS (or /etc/hosts) configuration provides.
-
Make sure the machine's hostname is set correctly
Use either scutil, or on older Macs use a HOSTNAME=xxx
entry in the /etc/hostconfig file.
You want to avoid the 'hostname.local' rendezvous/Bonjour stuff
that causes hostname instability (the hostname changes randomly).
Setting the hostname in System Preferences > Sharing
isn't sufficient; you'll still see the hostname(1) command show
inconsistent names like "Fred's Mac" or end in ".local", which is bad.
Current OSX Releases (OSX 10.8/Mountain Lion, and up)
|
In Mountain Lion and up, use the scutil command.
So if the machine should be called 'tahoe', run this as root:
scutil --set HostName "tahoe"
scutil --set LocalHostName "tahoe"
scutil --set ComputerName "tahoe"
It's best to set all three values to the same name.
Hostnames can /only/ contain combos of alphanumeric characters and dashes,
nothing else. Don't use spaces, underbars, etc. Leave off the domain name
extension; the right place for the domain name is in the "Search Name".
After making your changes, reboot.
|
Older OSX Releases (OSX 10.7/Lion, and Older)
|
On older versions of OSX, add a HOSTNAME=xxx entry in the /etc/hostconfig file instead.
So for a host called "tahoe", use:
If the entry doesn't already exist, add it as a new line.
If there's an existing entry in the file that reads "HOSTNAME=-AUTOMATIC-",
replace it with the above. Do NOT include dashes around the hostname.
Be careful when editing /etc/hostconfig:
- Use an ascii text editor
to ensure no font formatting characters get into the file.
- Don't make typo's! This file is parsed during boot.
After making your changes, reboot.
|
- Extract the rush tar file.
Extract the tar file to /usr/local/rush.
Open a terminal window, and login as root, and extract the tar file as:
Extracting Rush Tar File
|
cd /usr/local
sudo tar xvfzp /tmp/rush-xxxxx.tar.gz
|
Some notes on extraction:
- The tar 'p' flag is important!
It will preserve the permissions needed to make the daemons run properly.
- If /usr/local doesn't exist, create it first:
mkdir -m 755 /usr/local
chown 0:0 /usr/local
- To install Rush on a large network..
First complete all these install steps you're reading
for setting up the first machine, then you can use the Network Install instructions
to set up the rest of the network easily by just copying
the /usr/local/rush directory to the other machines.
- Installing rush in locations other than /usr/local/rush is not recommended.
But if you /really/ must, refer to
these instructions.
- Do *not* install the rush directory completely on an NFS drive.
Install it in a local directory on each machine.
Here is why.
For cloud configurations, you may want to install Rush on an NFS server.
But you'll need to make sure at least the rush/var directory is local.
This is because rush read/writes host-specific files to this directory,
and assumes the var dir is unique to each machine. So it must
be local. All the other rush/* subdirs could be symlinks to the server.
- Configure the /usr/local/rush/etc/hosts file.
It should contain the hostnames of all machines that will be rendering or submitting jobs,
in addition to the license server.
See Hosts File for a description of this file's format.
- Install the license that was emailed to you as
/usr/local/rush/etc/license.dat
- Security issues and special configurations.
- Disable the OSX firewall.
Apple now includes a firewall that is default 'on' in some
versions of OSX which, if left enabled, will prevent Rush
from being able to communicate with remote machines.
Disable the the firewall via:
Firewall Disable
|
10.4 and older
(Tiger and older)
|
System Preferences > Sharing > Firewall > Stop
|
10.5 and newer
(Leopard, Snow Leopard..)
|
System Preferences > Security > Firewall > Stop
|
Or, if you want the firewall enabled, make sure TCP and UDP port 696
is left open in the 'Settings' menu. If you want Rush to be able
to send email on job completions, you'd better allow port 25 to be able
to reach your mail server as well.
- If security is a concern at your site, carefully review the
Admin FAQ on Security
for security precautions and configuration.
- (OPTIONAL) Review the
/usr/local/rush/etc/rush.conf file.
For most situations the defaults suffice, but sometimes it pays to be pedantic.
- (OPTIONAL)
Register your settings for serverport
in /etc/services or equivalent (NIS, NetInfo, etc). See
serverport
for an example services entry.
- Run the install script.
/usr/local/rush/etc/bin/install.sh
Watch for any error messages in the output.
- Start the daemon, and test it.
Start the daemon by invoking the boot script:
/usr/local/rush/etc/S99rush start
Then open a *new terminal window* and invoke 'rush -ping' to verify the daemon's running:
Testing The Daemon
|
% rush -ping
yourhost: RUSHD 102.42 PID=XXXXX Boot=10/15/00,03:25:49 Online, 0 jobs, 0 procs
|
Some errors that may occur:
- connection refused
This means the daemon wasn't able to start.
Look in the /usr/local/rush/var/rushd.log for error messages.
- can't open port lock file '/usr/local/rush/var/nextport': Permission denied
You either weren't running as root when you ran the install script,
or somehow skipped running the install script.
To fix this, be sure you are logged in as root, and re-run the install script.
To test if the daemon is working, you can run the following test submit script
just to verify jobs can be started, listed, and dumped:
/usr/local/rush/examples/test-submit
- Install the submit scripts for the users
If you haven't already installed the scripts on your server yet, follow these instructions
for installing the submit scripts on your file server:
'Making Scripts Available To Users'.
Once installed, users can make desktop shortcuts to the scripts by using these instructions:
'Making Desktop Shortcuts To Submit Scripts'
To submit a real job, similar to what TDs use, you can run
this test which includes
complete instructions for someone who has never used rush before.
- (OPTIONAL) Miscellaneous configuration settings
- Pathname Translations
If you need them, set up "path_convert" commands in the
rush/etc/path_convert file
to configure pathnames in a from/to format. For instance,
converting Windows "Z:/share" paths
to cross platform "//ourserver/share" paths.
- Automatic Drive Mappings (Windows)
If you need them, set up "drive_map" commands in the
rush/etc/path_convert file
to configure drive letter mappings. For instance,
mapping "Z:" to "//ourserver/share".
- Cpu Accounting
By default, Rush maintains a history of cpu utilization information in the
/usr/local/rush/var/cpu.acct file, which is local to each render node.
If you don't want this file to grow too large, you might want to have it
rotated on a monthly basis, eg:
0 0 1 * * root /bin/mv /usr/local/rush/var/cpu.acct /usr/local/rush/var/Ocpu.acct
If, however, you want to keep the cpu accounting data, you can centralize
the data to a file server using the new rush.conf command
cpuacct.dbasedir. This tells
the rush daemons to regularly write the cpu accounting data to a file server,
and rush will regularly update the file info into a date stamped directory
to make it easy to get at the data.
- That's it.
Once you have things working on the first machine, then you can easily
install Rush on the rest of the machines. See 'Network Install' below..
|
|