|
Rush Windows Install Instructions (C) Copyright 1995,2000 Greg Ercolano. All rights reserved. V 102.43 09/20/08 |
|
|
Rush Windows Install Instructions (C) Copyright 1995,2000 Greg Ercolano. All rights reserved. V 102.43 09/20/08 |
 |
|
|
|
Windows Install Instructions | |
|
||
| Installing Rush |
| |||||||
You can automate the Rush install procedure in a number of ways,
the following shows how to do it if you're running the 'remote shell'
service on the remotes. This way, step #2 can be done with the Windows
'rsh' command.
Example:
..where 'SOMEHOST' is the hostname of the remote machine to install on,
and 'C$' is the 'share name' the remote machine's C: drive is shared as.
You can do several machines at once with a command like:
Windows7: If you are using Windows Vista or up, you may find it necessary to first
turn off the UAC,
or the install script may fail with "access denied" errors even when running as Administrator.
Or you can automate this process using rsh, assuming you have
Remote shell services configured on your Windows machines; rsh
services are available from the net. One I've used is the
Winsock RSHD available from
www.denicomp.com.
An example of automated executing of the install script would be:
In versions of Rush 102.41 or older, run these 'Change ACL' commands
on the newly copied directory, to ensure Rush can access its own directory:
(In 102.42 and up, these commands are run automatically by the install.bat script.)
On WinXP you can use the 'SC' command:
Notes on the above:
If you don't have WinXP, you'll have to do the following steps
'a' and 'b' manually:
b) Double click on Rushd, and change the 'Log On' settings to:
NOTE: You can also stop/start the rushd service from the
DOS command line via:
Look in the c:/rush/var/rushd.log files,
or use 'rush -dcatlog +any'
Common errors (and their soultions) can be found
in the Admin FAQ.
Network Install
Once rush is setup and working on one machine, and the
C:\RUSH\ETC\HOSTS
file contains entries for all the machines on your net, it's then
a simple matter of copying the C:\RUSH directory to all the other
machines, then running the appropriate followup steps.
NOTE: Be sure you've already installed ActiveState Perl before installing Rush
on the network machines.
xcopy /e /i C:\RUSH \\SOMEHOST\C$\RUSH
for %i in ( nt1 nt2 nt3 ) do xcopy /e /i C:\RUSH \\%i\C$\RUSH
cd \rush\etc\bin
install
for %i in ( nt1 nt2 nt3 ) do rsh %i c:\rush\etc\bin\install.bat
cacls c:\rush\var /E /C /G everyone:F
cacls c:\rush\var\* /E /C /G everyone:F
cacls c:\rush\etc /E /C /G everyone:F
cacls c:\rush\etc\* /E /C /G everyone:F
sc config rushd obj= DOMAIN\USER password= PASS
net start rushd
If it's a Workgroup user, use '.' in place of the domain name, e.g. ".\rush"
If it's a Domain user, use the actual domain name, e.g. "YOURDOMAIN\rush"
a) Bring up 'Services':
WIN/NT:
Start -> Control Panel -> Services
WIN/2K:
Start -> Control Panel ->
Adminsitrative Tools -> Services
WORK GROUPS NTRUSH NETWORK USER
--------------------------- ---------------------------
This Account: rush This Account: DOMAIN\rush
Password: <PASSWORD> Password: <PASSWORD>
Confirm: <PASSWORD> Confirm: <PASSWORD>
(Replace DOMAIN with your Windows domain name)
net stop rushd
net start rushd
Uninstalling Rush
1) Run the C:\RUSH\ETC\BIN\UNINSTALL.BAT script
2) Remove the C:\RUSH directory
Note: You will *NOT* need to reboot after an uninstall.
Rush needs a uid and gid in order to run renders on Unix machines.
Jobs submitted from Unix machines simply record the uid/gid of the
submitting user, and uses that when rendering on Unix render nodes.
But since Windows has no concept of uid/gid values, when a Windows
machine submits a job, Rush has to be told what uid/gid to run these
renders as on Unix machines, so it gets this info from the ntrushuid/ntrushgid
settings in the rush.conf file.
The default values for these are 100/100, which should be changed to the uid/gid
of a valid user account on the Unix machines that you want Windows-submitted jobs
to run as. If you don't do this, you may encounter
this problem.
Normally, you would create a valid user account called 'rush' or 'render',
and set the ntrushuid/gid pair to that user's uid/gid. Be sure this account
has compatible permissions with the permissions of other users.
If you'll be writing your own custom submit scripts, then
you do NOT need to install perl just to use Rush. The Rush core
(rush,rushd,irush) has no dependence at all on perl, and is entirely
language agnostic when it comes to the submit and render scripts.
You can write Rush submit scripts in any langauge, including python,
ruby, csh, perl, even DOS Batch. (Just be sure the language you choose
is available on all the platforms you intend to use!)
Install Caveats
ntrushuid/ntrushgid -- The UID/GID that windows-submitted jobs run as on Unix
If Windows users will be submitting renders to run on Unix machines,
it's critical that the
ntrushuid and
ntrushgid
values are configured in the rush.conf file.
Consistent Rush files across Unix and Windows
Both Unix and Windows should have the same 'rush.conf', 'rush hosts' and
rush 'license.dat files, e.g.:
> C:\RUSH\ETC\RUSH.CONF is the same as /usr/local/rush/etc/rush.conf
> C:\RUSH\ETC\HOSTS is the same as /usr/local/rush/etc/hosts
> C:\RUSH\ETC\LICENSE.DAT is the same as /usr/local/rush/etc/license.dat
Consistent hostname lookups across Unix and Windows machines
Both Unix and Windows machines should be able to resolve each other's
hostnames, eg. you should be able to 'ping' Windows machines from Unix
and vice versa.
Perl For Windows
If you plan to use the example submit scripts that come with Rush
(in C:\rush\examples), it is highly suggested you use
ActiveState Perl,
since it is the best implementation of perl for the Windows platform
in general. Rush does not care which perl you use, but some perl
implementations for Windows are inherently buggy, experience has
shown.
With Rush, the idea is to ensure the c:\rush\var directory
is empty on all the cloned disks, so that the cloned machines don't
inherit stale files from the master (eg. old accounting logs, job
checkpoint files, daemon logs with irrelevant error messages),
as these files will negatively interfere with the cloned machines:
The disk is now ready to be cloned.
You can shut down the machine, but do not reboot it using this drive, or the daemon will start automatically,
That should be all you need to do.
If you made a mistake, and forgot to clear the c:\rush\var
directory, and cloned an entire farm accidentally, then run these
cleanup commands with the farm running:
This will clean up a farm that was accidentally cloned
with left over files in the c:\rush\var directory.
Network Install: Disk Cloning
If you are setting up a large farm, often you set up the software on
one machine, then 'clone the disk' to all the other machines.
The following commands will prepare the cloning 'master disk'; shut down the rush daemon on this machine
so that all files in the /usr/local/rush/var directory are closed, then clear out the 'var' directory
completely by removing and re-creating it. Run these commands as Administrator:
net stop rushd
rmdir /s c:\rush\var
mkdir c:\rush\var
cacls c:\rush\var /E /C /G everyone:F
and the c:\rush\var directory will have to be cleared again with the above commands.
If you didn't prepare the master disk for cloning, fix things by running these commands as Administrator:
net stop rushd
rmdir /s c:\rush\var
mkdir c:\rush\var
cacls c:\rush\var /E /C /G everyone:F
c:\rush\etc\bin\install
net start rushd
Installing www-rush
www-rush is the optional web GUI, which has pretty much been superceded
by the newer GUI irush that comes with the rush installation.
However, if you want to set up the web GUI which allows people to
monitor and control render queue jobs remotely via their web browser,
see the www-rush docs.
'www-rush' is a single perl script found in /rush/cgi-bin/www-rush.pl,
and should be installed on your internal network's web server.
It has been tested to work with either Apache/unix, or IIS/NT.
(IIS is Microsoft's web server that comes with NT Server)
www-rush will work with IIS, provided:
o You have properly installed IIS, and enabled 'cgi-bin' scripts.
o You have installed ActiveState perl (www.activestate.com).
On install, be sure to enable the check flags for IIS.
o You have installed rush on the server, and have included
the server's hostname in the /rush/etc/hosts file.
o You view www-rush with Firefox. (Explorer can have problems)
Then it's just a matter of putting the www-rush.pl script in IIS's
/inetpub/scripts/ directory, tweaking variables at the top if need be.
To install www-rush on an Apache web server, just put www-rush.pl
in the cgi-bin directory, like any other cgi-bin script.
Legacy Docs
Some old legacy docs are here which show how to manually configure
the service. These docs are no longer recommended.
Trouble Shooting
Check the Admin FAQ for common problems.
If you have installed the software, and started the daemon, you should
be able to open a new DOS window, and be able to run 'rush -ping'
to see the following (or similar) output:
C:\rush>rush -ping
myhost: RUSHD 102.20b PID=166 Boot=03/13/01,02:08:52 Online, 0 jobs, 0 procs
Some common errors:
o "The name specified is not recognized as an
internal or external command, operable program or batch file."
Make sure you ran the install.bat script first. It modifies your path
to include C:\RUSH\BIN. After you run this script, CLOSE the current dos window,
and open a new one, so that "rush" will now be in your path.
o "Connection refused"
This means the daemon did not start. Look in C:\RUSH\VAR\RUSHD.LOG for
error messages, and send them to:
Greg Ercolano
Possible error messages in the C:\RUSH\VAR\RUSHD.LOG
o "HOST_GetLocalHostname(): NO LOCAL HOST --- ABORT ---"
This means the local hostname for the machine is not in the
C:\RUSH\ETC\HOSTS file. If the local host is named farm37, then
make sure farm37 is an entry in that file.
o "bind(): address already in use"
This means there are either two daemons running, or you need
to wait a few minutes if you just told the daemon to restart.
Make sure you configured the Administrator user and password for
the service in the Control Panel->Services->Rushd screen.
Problems With Houdini
It seems for a while now, houdini's setup has some kind of bug
that breaks the PATH for DOS shells. After installing houdini,
one finds commands like 'ping' and 'nslookup' no longer work,
and are 'unknown commands'.
Houdini's setup program does something that breaks the PATH,
such that important things like C:/WINNT/SYSTEM32 are no longer
in the path.
To fix the problem in WINNT:
1) Go into Control Panel -> System -> Environment
2) Add C:/WINNT/SYSTEM32 to the "System Variables"
PATH. Be sure to include the proper semicolons to separte
this new addition from the other paths.
3) Hit APPLY, then OK.
4) Now open a NEW DOS WINDOW, and try invoking 'ping'.
If done correctly, 'ping' should print out a help report.
If done incorrectly, 'ping' will still give a command not
found error.
To fix the problem in Windows 2000:
Go into Control Panel -> System -> Advanced -> Environment Variables
and follow steps 2 through 4 above.