RUSH RENDER QUEUE
(C) Copyright 1995,2000 Greg Ercolano. All rights reserved.
V 102.42a6 06/26/06

How To Configure..


  1. Configuring 'rush -lj' and 'rush -laj' Reports
  2. Configuring 'donemail' for Windows
  3. Configuring User's Password to Never Expire
  4. Rush User Access to Network Server
  5. Samba Configuration for open user access
  6. Fix Your System Path
  7. Fix Windows Directory Permissions
  8. Using 'runas' to test for file server access problems
  9. Using 'telnet' to test for file server access problems

Configuring 'rush -lj' and 'rush -laj' Reports

Configuring 'donemail' for Windows

Configuring WORKGROUP Users to be Members of the Administrator Group

  1. Login as Administrator

  2. Invoke the User Manager:

    Start | Settings | Control Panel | Users And Passwords

  3. Double-click on the user's name

  4. Choose the "Group Membership" tab

  5. Click on the 'Other:' radio button, and select "Administrators"

  6. Hit Apply.

Configuring DOMAIN Users to be Members of the Administrator Group

  1. Login as Administrator

  2. Right click on "My Computer" and click "Manage".

  3. Click "Local Users and Groups", click Groups and double click on "Administrators".

  4. Click the "Add" button, and type in the domain qualified user's name, eg: DOMAIN\username

  5. Hit Apply.


Configuring User's Password to Never Expire

  1. Login as Administrator

  2. Invoke the User Manager:

    Start | Settings | Control Panel | Users And Passwords | Advanced | Advanced User Management | Users

  3. Double-click on the user's name

  4. Choose "Password never expires"


Rush User Access to Network Server

It's important for the Rushd service to have read/write access to your network server to prevent this problem.

Having access means being able to login as that user, and not get one of these dialogs when you try to browse over to the network disk:

To prevent that, make sure your disk server has that user configured with a correct password, or open the share permissions until you can login as the user, and access the server without getting that error.

If you're disk server supplies its disks via Samba, verify your Samba configuration is 'open enough' that normal users and the Rushd service user can interact.

'Open' Samba Configuration

You can configure Samba to automatically keep permissions open, and allow users that don't have accounts on the Samba server to access the drive(s) being shared. (note green text): 
# Disk entry excerpt from smb.conf
[jobs]
   comment = Jobs Disk
   path = /raid/jobs
   read only = no
   public = yes                   <-- public access
   guest ok = yes                 <-- guest access
   force create mode = 0666
   force directory mode = 0777
   hide dot files = no

This will open up permissions to your disk such that, for sure, you won't get the above dialog after you login and access the server.

Then tighten down security from there, making sure you don't re-induce the dialog. Make sure you have your Windows machines set up to correctly work with Samba to manage password logins correctly.

Here's an actual production smb.conf file used on a Mac OSX (Tiger) file server for a farm of PCs. Your mileage may vary -- for reference only: 


[global]
    workgroup = MYSTUDIO
    server string = Tahoe

    # Added to support browsing -- See BROWSING.txt
    browseable = yes
    domain master = yes
    local master = yes
    preferred master = yes

    # Logging..
    os level = 65
    log file = /var/log/samba/log.%m
    max log size = 50

    # Very open security
    guest account = render
    security = share
    encrypt passwords = yes
    
    # Remove limit on # of connections
    #     (If unset, default is 10!)
    #
    max connections = 0
    
    # DISABLE OPLOCKS TO ALLOW UNIX AND NT TO ALTER SERVER DATA
    #    If no: clients won't cache, but will stay in sync
    #    If yes: clients cache, but out of sync with unix
    #
    oplocks = no
    
    # Misc preferences
    socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192     
    dns proxy = no

[jobs]
    comment = Jobs on Tomas
    path = /Volumes/Raid5
    read only = no
    public = yes
    guest ok = yes
    force create mode = 0666
    force directory mode = 0777
    hide dot files = no

Fix your System Path

Installs of Houdini have been known to break the Windows system path such that standard programs like more and ping give 'Command not found' errors.

To fix this under Windows 2000:

  1. Login as Administrator, and bring up the "Environment Variables" panel:

    Start | Control Panel | System | Advanced | Environment Variables

  2. Under 'System variables', Double-Click on the "PATH" variable

  3. Carefully insert at the *very beginning* of the "Variable Value" field:

    C:\WINNT;C:\WINNT\SYSTEM32;

    There should be NO SPACES, and there should be a ';' at the end of what you typed, so that it separates your entry from the settings that follow it.

  4. Hit Apply, and OK.

  5. Open up a new DOS window, and see if commands like 'ping' and 'more' work now. Only new DOS windows will be affected by the change.


[WINDOWS] Fix Directory Permissions

The c:\rush\var and c:\rush\etc directories must have permissions that allow read/write access to the user the Rushd service is running as, or it will prevent the daemon from being able to access its own files (such as preventing messages from being appended to the rushd.log).

Since you set the name of the user the Rushd service runs as, you have to make sure these directories have permissions that allow access to this user.

You can either use the Window's GUI interface to modify the permissions, or you can use the DOS 'cacls' command. Here's some quick cacls examples: 

    USING CALCS TO VIEW EXISTING PERMISSIONS
    ----------------------------------------
    calcs c:\rush\var           -- view the permissions on the c:\rush\var directory
    calcs c:\rush\var\*         -- view the permissions on the files in c:\rush\var

    USING CALCS TO ENABLE ACCESS TO THE RUSHD SERVICE
    -------------------------------------------------
    net stop rushd                               -- stop the daemon first
    cacls c:\rush\var   /E /C /G everyone:F      -- full r/w access on c:\rush\var directory
    cacls c:\rush\var\* /E /C /G everyone:F      -- full r/w access for all files in c:/rush/var
    cacls c:\rush\etc   /E /C /G DOMAIN\user:F   -- service r/w access to c:\rush\etc directory
    cacls c:\rush\etc\* /E /C /G DOMAIN\user:F   -- service r/w access for all files in c:\rush\etc
    net start rushd

Replace "DOMAIN\user" with the username you have configured for the "Log On" tab the Rushd service is running as, eg. XYZSTUDIOS\render for a Domain 'render' user, or eg. .\render for a local render user.

See 'cacls /?' for more info.

[WINDOWS] Using 'runas' to test for user access

You can use the DOS 'runas' command to become the user the Rushd service is running as to debug file access problems between the file server and rush:

  1. Go into the "services" panel to verify what username the Rushd service is configured to run as:

  2. Invoke the following 'runas' command from DOS to become that user:

    runas /user:.\render cmd

    This will open a new DOS window that will be running as the user the Rushd service, and commands run in that window should have similar access permission.

  3. From the new DOS window, use the DIR and ECHO commands to attempt to access the files on your file server, to check for access problems:

    dir \\server\jobs\somedir\
    echo foo > \\server\somedir\foo.txt

    If you get 'Access is denied' or "File Not Found", then you can debug it from there as an account configuration problem.

To solve access problems, you need to make sure the user has read/write access rights to the file server. If your network is using "workgroups", both client and server must have the same account configured with the same password for the user.

If your network is using "Windows Domains", make sure the Rushd service is running as the DOMAIN user, not a local user. For instance if your Windows Domain is "MYSTUDIO", and the domain user you want Rushd to run as is "render", then the Rushd service's "Log On" tab should show:

In either case, make sure the user's password is configured to never expire.

If your file server is a unix Samba server, verify Samba is configured to be open enough to allow read/write access to all users that own the files.

[WINDOWS] Using 'telnet' to test for user access

You can use DOS telnet to simulate how rush runs things from the commandline in a 'service' context, since both the telnet service and the rush service run things in a similar security context:

  1. Enable the Microsoft 'telnet service' on your machine using the instructions appropriate for your platform:

    Note that both "Professional" and "Server" versions of Microsoft Windows both "come with" a Microsoft telnet server that you can enable.

  2. Go into the "services" panel to verify what username the Rushd service is configured to run as:

  3. Based on the username show in the above, telnet into your machine from DOS and use that exact name to login to telnet: 

    4.              C:\> telnet localhost
             Welcome to Microsoft Telnet Service

             login: .\render                 <-- get this from the "This Account:" field above
             password: ********

             C:\> dir \\some\path\youre\having\trouble\with\

  4. At the DOS prompt within telnet, try typing a DIR command that accesses the directory you're having trouble with.

    If you're having write permission issues, try also seeing if you can write to the directory using 'echo', eg: 

                 echo foo > \\some\path\youre\having\trouble\with\foo.txt
    If you get permission errors, then you've replicated the problem, and should at least be able to troubleshoot interactively (instead of through rush) as you make administrative tweaks to your file server.

  5. When done testing, be sure to disable your 'telnet server' config if you no longer need it.