Rush Logo Rush Mac Upgrade Instructions
V 103.07b 05/11/16
(C) Copyright 2008, 2016 Seriss Corporation. All rights reserved.
(C) Copyright 1995,2000 Greg Ercolano. All rights reserved.

Mac OSX Upgrade Instructions

   Upgrading Rush  
    Start with the license server first.
    Do all commands below while logged in as root.

    1) Make sure no jobs are running.

    • Go into Irush, and click 'All Jobs'.
    • Highlight all jobs running, and click the 'Dump' button at the left.
    • Repeat 'All Jobs' until no jobs are running.

    2) Stop rushd on the license server.

      /usr/local/rush/etc/S99rush stop

    3) Rename out the old version on the license server.

      mv /usr/local/rush /usr/local/rush.MM-DD-YYYY

    4) Extract the new version on the license server.

      Be sure to include the 'p' flag to preserve permissions.

      cd /usr/local
      tar xvfzp /var/tmp/rush-103.xx-mac.tar.gz

    5) Copy old license/hosts file from the old version.

      cp /usr/local/rush/rush.MM-DD-YYYY/etc/{hosts,license.dat} /usr/local/rush/etc

    6) Manually merge your changes from the old rush.conf file.

      Don't overwrite the old rush.conf over the new; merge in your changes manually either with a text editor, or something like xdiff.

        xdiff /usr/local/rush/rush.MM-DD-YYYY/etc/rush.conf /usr/local/rush/etc/rush.conf

      The most common rush.conf commands to customize:

      Commands commonly customized in rush.conf
      Used in mixed environments of Windows and Unix.
      Tells rush what uid/gid to use when running Windows submitted jobs.
      Used to force renders to run as a specific uid/gid on unix machines.
      (The default is for jobs to run as the user who submitted the job.)
      Used for rush's mail delivery. Set to your mail server, and the
      'from' email address for rush emails.
        permit   Sets the names of users who can administer rush.

      For a list of all the rush.conf file options, see the complete list. (In that document, red stars indicate new features in this release)

    7) Run the install script.


    8) Start the daemon, verify it's running OK.

      /usr/local/rush/etc/S99rush start

      Then ping the daemon to see if it started:

        rush -ping

      If you get any errors, check the rushd.log for messages that indicate the problem:

        tail -f /usr/local/rush/var/rushd.log

    9) Use next section to upgrade the rest of the network.

   Network Upgrade  
    1) Stop rush on all machines.

      rush -dexit +any -t 5

    2) Install new version on each machine.

      The easiest way to do this is to pick a machine that has the new version successfully installed (usually the license server), and use rsh/rcp to distribute the new version to the network:

      Installing Rush Upgrade on Other Machines
      for i in host1 host2 host3 ..; do
          echo --- $i
          rsh $i mv /usr/local/rush /usr/local/rush.MM-DD-YYYY
          rcp -rp /usr/local/rush ${i}:/usr/local/rush
          rsh $i /usr/local/rush/etc/bin/ \; /usr/local/rush/etc/S99rush start   

    3) Verify entire network is up.

      When you're done, check your work with:

        rush -ping +any

      ..all machines should reply with the NEW version number. Any that don't, recheck the install manually.

      For machines that don't respond, check the rushd.log:

        tail -f /usr/local/rush/var/rushd.log

      If a machine complains about 'bind(): address in use' for more than 2 minutes, you may need to reboot that machine.

   Upgrading Submit Scripts  
    Upgrading the submit scripts is usually optional; in general Rush is backwards compatible with submit scripts from previous versions.

    However, often there are many user oriented benefits to upgrading the submit scripts; often there are many new and useful features in the newer submit scripts, to track new features in renderers.

    If you already have working submit scripts, you probably want to install the new ones in a separate directory on your file server, so that you can test them while production continues to use the old scripts, then when ready, you can either rename out the old and replace with the new, or simply tell production to modify their desktop shortcuts to point to the new submit script directory.

    1) Install the new submit scripts on your server

      cp -rp /usr/local/rush/examples /yourserver/jobs/rushscripts-new/

    2) Merge over your local customizations from old submit scripts

      Often there are local customizations made to e.g. the FixPath() function in "", or to the individual submit script's environment variable settings for your renderers. Do NOT copy over the new with the old; there are often new functions added to the file that the new scripts need. Merge your changes into the new file. This can often be made easy with a good 'differences' tool like xdiff, "vim -d", or Mac's own FileMerge (comes with the Mac's free developer tools on the OSX CDs).

      xdiff /yourserver/jobs/rushscripts-old/     /yourserver/jobs/rushscripts-new/perl/
      xdiff /yourserver/jobs/rushscripts-old/ /yourserver/jobs/rushscripts-new/perl/

    3) Test the scripts from the command line for errors

      When testing the modified scripts, invoke the scripts from the command line, so that you can see errors you wouldn't otherwise see when invoked from desktop shortcuts (because there's no TTY associated with desktop invocations).

      yourprompt % perl -w /yourserver/jobs/rushscripts-new/perl/

   Upgrading www-rush  
    1) If you've never installed www-rush before, see installing www-rush, otherwise continue to step#2.

    2) Replace your old www-rush with the new one in rush/cgi-bin.

      Upgrading www-rush is a simple matter of replacing your current www-rush perl script on your web server with the new one from your new Rush directory, /usr/local/rush/cgi-bin/www-rush (unix/mac), or c:/rush/cgi-bin/www-rush (windows).

      Just rename away your old one, and install the new one.

      Make sure the permissions on the script are consistent with your old one, ie. chown/chmod +x (unix) or cacls (windows).

    3) Compare the old script to the new one to check for customizations.

      Using tools like xdiff, windiff, or just comparing the files by eye, check the the 'MODIFIABLE VALUES' section of the top of the script to see if there were any customizations to the old script that need to be brought over to the new script to preserve customized behavior that the previous users are used to.

      Sometimes it's necessary to change the defaults in that section for your local environment.

    4) Test the script: verify it works, check http error logs.

      Exercise the new script, and check your http server's error logs for warnings or errors from the script.

    5) That's it, you're done.

   Backgrading Rush  

      BACKOUT PROCEDURE. In the event you need to back out the new release, just stop the daemon on all machines, rename back the old directory, and restart. Again, start with the license server.