Using DrQueue In a Cross-Platform Network

INTRODUCTION
This guide explains the procedure I used to create a small renderfarm including computers running Mac OSX, Debian Linux, and Windows XP Home Edition. I have essentially combined information provided in earlier tutorials provided by Shawn Parr (OSX setup), Jason Ekstrand (Windows in a cross-platform network), and Brian Drescher (Windows XP renderfarm) along with support from Jorge Daza in the DrQueue forums.

I have only tested the OSX instructions in OSX 10.4 (Tiger). I believe they will work with earlier versions, and would appreciate feedback on any differences. In Windows I have only tested with Windows XP Home Edition, Service Pack 2. My Windows instructions are just a slight revision of the Brian Drescher instructions, and I believe they have been successfully used for other XP versions. I am not aware of any way of making DrQueue run in versions of Windows earlier than XP. On older computers I suggest the much easier method of upgrading the OS to some distribution of Linux.

This tutorial assumes that DrQueue master will be run on a Mac or Linux computer. I believe OSX and Linux slaves can be added to a renderfarm with a Windows master, probably using SMB to mount the shares and then some adjustments to /etc/drque/slave.conf, however I will leave it to others to test and document that process.
LEGAL STUFF
This document is provided for informational and entertainment purposes only. This information is provided "as is". The provider of this information does not provide any warranty of the information whatsoever, whether express, implied, or statutory, including, but not limited to, any warranty of merchantability or fitness for a particular purpose or any warranty that the information will be error-free. In no respect shall the Author incur any liability for any damages, including, but not limited to, direct, indirect, special, or consequential damages arising out of, resulting from, or any way connected to the use of the information, whether or not based upon warranty, contract, tort, or otherwise; whether or not injury was sustained by persons or property or otherwise; and whether or not loss was sustained from, or arose out of, the results of, the information, or any services that may be provided in this document.

In plain English: backup, and be careful – you’re on your own.
OPTIONAL MAC STUFF
There are a couple of things that can make working on your Mac clients a little easier, especially if you’re a network administrator more comfortable with command line interfaces and not quite so familiar with OSX.
1. Enable terminal logins: rather than running around your network making all these changes on each box you can just launch a terminal anywhere and use ssh to connect to the Macs’ command line. This can be useful as much of our work has to be performed from a command line anyway. Also you will be able to launch slaves remotely if you chose not to include the scripts to launch automatically on boot. On each Mac just click on System Preferences, then “Sharing”, and make sure Remote Login is checked. You will then be able to use ssh to connect to the Mac from any terminal on the local network (you will of course need a user account on each mac).
2. Activate the “root” user: throughout this tutorial there will be several occasions where I will use “sudo” to allow a non-root user to execute operations requiring root access. To avoid having to type “sudo” and confirm with the password you may prefer to either log in as root, or be able to “su” to root once. This is generally considered to weaken security, but if you’re in a secure environment and use non-trivial passwords you may want to activate this option.
  
  Open /Applications/Utilities/NetInfo Manager.app; click the lock and enter the administrator password to allow changes. From the menu select Security – Enable Root User.

REQURED MAC BASE INSTALLATION
1. OS requirement: As stated above, I believe this procedure will work on most OSX systems, but I have only tested it in Tiger. I also remain current with all the system updates, so my system as of this writing is 10.4.7. Also, the rendering clients will need a working installation of whatever rendering software you are using which may have additional minimum requirements. I have only used Blender, so I cannot guarantee this procedure will work with any other programs, or provide support for them. At least one Mac on your network will need to have a development environment to compile the binaries that all of the slaves will run. The remaining requirements below are for that development computer, but not necessarily required on each slave.
2. X11: By default the Tiger installer does not install the XWindow system. Go back to your system installer and add it (needed for any Mac that may want to run the queue manager “drqman”).
3. XCode: Not installed by default, you need XCode Tools. Your OS CD/DVD should provide an installer, or you can download the latest from Apple Developer Connection (a free registration is required).
4. Fink: “The Fink project wants to bring the full world of Unix Open Source software to Darwin and Mac OS X. We modify Unix software so that it compiles and runs on Mac OS X ("port" it) and make it available for download as a coherent distribution. Fink uses Debian tools like dpkg and apt-get to provide powerful binary package management. You can choose whether you want to download precompiled binary packages or build everything from source.” Fink enables the use of freely available shared code (programs and libraries) traditionally developed in Linux environments. Start by downloading and installing the base package from http://fink.sourceforge.net/.
5. Fink Commander (optional): the base install of Fink makes the Debian “apt-get” commands available from a Mac command line, Fink Commander gives the package manager a more user-friendly, Mac-standard GUI interface. Fink Commander is available from http://finkcommander.sourceforge.net/.

PREPARE THE NETWORK ENVIRONMENT
It is assumed that you have a local network and the IP addresses are only visible within that network. No security is provided by DrQueue, and to simplify the tutorial it is assumed that the network is trusted so I will give directions that give unlimited read-write access to all of the DrQueue files. If security is an issue you will need to work out users and groups and permissioning to suit your environment.

All of the computers in your renderfarm should be connected by Ethernet, and most likely receiving configuration information from DHCP so that each computer has its own local IP address assigned by a router.
1. Determine which computer will run master: If you are creating a new renderfarm select a computer to be master and record its IP address. You can find the IP address of a Mac from System Preferences, click Network, select the network connection (usually “Built-in Ethernet”). From the TCP/IP tab record the IP Address. For this tutorial I will use “192.168.1.xxx” for the master IP address. If you are adding Mac slaves to an existing renderfarm find out the IP address of the existing master.
2. Create the DrQueue shared directory: If you are adding Mac slaves to an existing renderfarm you can skip to part C, but first determine the IP address and path of your existing shared DrQueue shared directory. You will only perform this step on the Mac that will host the shared rendering directory, record the IP address for this Mac. Our goal is to create a shared file location that will appear to have the same path on every computer in the farm. For OSX and Linux computers NFS is the best solution. For this tutorial I will use “/mnt/render” as the shared directory.
  1. Create the physical directories: for ease of installation all of the computers in the farm should “see” this directory as the same path from the root directory. Normally you cannot create directories at the root level in OSX, so this is the first time we will use the Terminal. A simple terminal is included in the OSX installation at /Applications/Utilities/Terminal.app. Launch terminal, and from the command line type the following:
    
    sudo mkdir -p -m 777 /mnt/render
    
    You will be prompted for the administrator password. This command will create the render directory and also create /mnt if it does not exist already (it probably doesn’t). It will also try to set the permissions for both directories to allow owner, group, and everyone to read, write, and execute (actually due to system restrictions /mnt will end up writable only by root, which is as it should be).
  2. Export the shared directory: There are several ways of doing this including modifying system files from the command line, or using the NetInfo Manager utility included with OSX. To keep this tutorial simple I will only describe the method using the shareware utility “NFS Manager”, available from Marcel Bresink Software-Systeme:
    1. Download, install, and run NFS Manager.
    2. Click the lock button to authenticate with an administrator short name and password.
    3. Click to the “NFS Shares” tab.
    4. Click “Add Entry”
    5. Set “Folder to share” to /mnt/render
    6. Set the access button and middle panel to match your security requirements and network environment. For my own installation I selected “only compters in a specified IP subnet” and set the address and mask to the same as the dhcp server for my local network, so only addresses assigned by my router have access.
    7. Make sure “Allow read access only” is NOT checked.
    8. Accept the rest of the default settings, and click OK.
    9. Click “Activate Changes…” and enter the password if prompted or click OK as needed, then quit from NFS Manager.
    10. Restart the computer to make sure all changes are active and will carry across restarts.
3. Mount the shared directory: You will need to perform this on every Mac in the renderfarm except the one which is hosting the shared directory. Once again I will simplify the directions by assuming you are using NFS Manager.
  1. If you skipped part B - download, install, and run NFS Manager as instructed in B.2, otherwise just launch NFS Manager.
  2. Click the lock button to authenticate with an administrator short name and password.
  3. This time stay on the NFS Connections tab.
  4. Click “Add Entry”
  5. You may be able to locate the share using the browse button. If not, determine the IP address of the computer exporting the NFS share and enter the following:
    - NFS Server: 192.168.1.xxx (the actual IP of your shared file server)
    - NFS Share: /mnt/render
    - Mount Point -> Create Alias At: /mnt/render
    - Make sure connect as read-only is not checked
4. Add DrQueue variables to the environment: You will need to do this on every machine that will run slave, master, or drqman. We will be adding lines to the file /etc/profile. Once again we will do this from Terminal. There are several ways of editing this file, but being an old-timer I’ve always used vi.
  1. From the command line: sudo vi /etc/profile
  2. Enter the admin password when prompted.
  3. Hit the “I” key to enter insert mode.
  4. Use the arrow keys to get to the very end of the document, hit return a couple of times to set off your new entries with a little white space.
  5. Add the following lines:
    
    export DRQUEUE_ROOT=/mnt/render # use your own path if different
    
    export DRQUEUE_MASTER=192.168.1.xxx # use the actual master IP address
  6. Hit the “esc” key to get out of insert mode and into command mode.
  7. Type :wq [return] (be sure to include the colon!). This will save your work and exit the vi editor.
5. Add DrQueue variables to the startup environment: This will be needed if you plan to use the scripts we will create later to make master and/or slave run automatically at startup. Again from the terminal we will be editing /etc/rc.common.
  1. From the command line: sudo vi /etc/rc.common
  2. Follow the instructions V.D.2-7 to make the same changes to rc.common.
6. Set up the X11 environment: This needs to be done for any Mac and any user account that will run the queue manager “drqman”. By default, OS X loads the .xinitrc file in the user's home directory. However, if you’re just starting using X11 you probably don't have one of these files. First check to see if you have one. In terminal first make sure you’re in your home directory. Type cd [return]. Then type pwd [return]. This should return something like
  /Users/usershortname
  Next see if you already have a .xinitrc by typing ls -l .xinitrc. If it returns a line like
  
  -r--r--r-- 1 name group 696 Jul 10 18:47 .xinitrc
  the file exists, otherwise it will return
  ls: .xinitrc: No such file or directory
  Note that the filename starts with a period.
  1. If you already have a .xinitrc skip to step 2. Otherwise copy the system default configuration by typing the following at the command line from your home directory
    cp /private/etc/X11/xinit/xinitrc .xinitrc
    Note that the file inside the private directory does not start with a period, but the file you are creating in your user directory does.
  2. At the command line from inside your home directory: sudo vi .xinitrc
  3. Follow the instructions V.D.2-7 to add the configuration to .xinitrc
7. Create a “drqueue” user account: This will be used later when we are compiling, and also to share the directories with Windows slaves (Windows does not play nicely with NFS). If you are not compiling and sharing from the same computer you will need to create this account on both computers.
  1. Create the account: Open System Preferences, click “Accounts”. Click the lock icon and enter the administrator password. Click the “+” below the user list, and in the dialog box enter a name and password, for my system gave the user name “drqueue”. Do NOT check the “Allow user to admister this computer” box. Click “Create Account”.
  2. Enable Windows Sharing for the drqueue account: from System Preferences click “Sharing”, make sure “Windows Sharing” is checked. With “Windows Sharing” highlighted click the Accounts… button (you may need to click the lock button and authenticate to enable changes). Check the box next to drqueue, and enter the drqueue account password when prompted.
  3. Change the drqueue account home directory: When your windows slaves login to access the drqueue directory, they still won’t have access to /mnt/home – this change puts them right there:
    1. Open /Applications/Utilities/NetInfo Manager and click the lock to authenticate.
    2. In the second panel click on “users”, then in the third panel click on “drqueue”.
    3. Find the property “home”, and change it to /mnt/render.
    4. While you’re in NetInfo Manager, make a note of the properties uid and gid (probably both the same 3-digit number starting with 5, we will use these later when we compile).
    5. Quit NetInfo Manager.
  4. “Hide” the drqueue account (optional): You may not want the drqueue account to appear in the login window. In 10.4 Tiger, this page explains how. For earlier versions, try this page (which answers a question asked about Tiger with a method that doesn't work for Tiger, but it does work in Panther and earlier OSX).
8. Make a link to allow access to your rendering application from the command line: I have only used DrQueue with Blender, but other rendering programs may require something similar. A normal installation provides an application “package” blender.app which you run interactively. To get to it from the command line you will need a link to the actual executable inside the package placed where slave can find it. In my case the blender application is located in its own folder inside Applications, so my path starts with /Applications/Blender/blender.app. Your path may be different. From the Terminal:
  
  sudo ln -s /Applications/Blender/blender.app/Contents/MacOS/blender /usr/bin/blender

COMPILE THE OSX EXECUTABLES
DON'T PANIC :-) If you've never compiled a program from source before, it's not as difficult or scary as it sounds. This may even open up a whole new world of open source (what some people call "free") software to you. To paraphrase the old "Quincy" TV show opening, you are about to enter the most fascinating sphere of computer work.

At this point you should have at least one Mac, preferably running OSX 10.4 Tiger with the latest automatic upgrades, with X11 installed, along with the latest XCode development environment and Fink. If you’re not sure, review section III. A basic installation of OSX and this development environment will take about 7 GB, and as stated above has only been tested in OSX 10.4 Tiger. The Mac that will be compiling DrQueue is either hosting the shared files at /mnt/render, or it has read/write access to the NFS share mounted at /mnt/render.
1. First we will use Fink to fulfill the dependencies for DrQueue. If you have installed Fink Commander you can install these packages by selecting and installing them within that graphical browser. The instructions below are for installing the packages from the terminal, and do not require the installation of Fink Commander. Type the following commands from the terminal:
  
  sudo apt-get update
  
  sudo apt-get install glib2-dev
  
  sudo apt-get install gtk+2-dev
  
  sudo apt-get install pkgconfig
  
  sudo apt-get install atk1
  
  sudo apt-get install pango1-xft2-dev
2. Download the latest DrQueue source from http://www.drqueue.org/download.php
3. Expand the source code. Probably the easiest way to do this on a Mac is with “Stuffit Expander”, which is probably already installed. If not, get the latest free expander at http://www.stuffit.com/mac/expander/download.html. Alternatively you can navigate to the directory containing the downloaded source in a Terminal and type:
  
  tar -xvzf drqueue.0.63.3.tgz
  
  (Replace drqueue.0.63.3.tgz with the filename of the source file you downloaded). You can build source from any location on your disk, however I like to keep sources in a central location, in my case I generally work from a folder named source inside my Documents directory. My full path is /Users/shortusername/Documents/source.
4. In Terminal, navigate to the directory you expanded in step C. From your home directory that might be cd Desktop/drqueue-0.63.3 – or using my preferred source location, cd /Documents/source/drqueue-0.63.3.
5. Run the following commands to build and install the binaries:
  
  make clean
  
  make
  
  make INSTROOT=$DRQUEUE_ROOT INSTUID={a user account/number, from part IV.G.3.d} INSTGID={a valid group ID for that user} install
  
  This will create the executables, build the directory structure under the previously created shared directory if it does not exist already, and install the files. If you are joining an existing renderfarm this will basically just add master.Darwin, slave.Darwin, and drqman.Darwin to the existing structure. A possible side effect when joining an existing renderfarm is that other shared files may be replaced with new ones built from the current source. If you are creating your renderfarm from scratch, this is a non-issue. If you are adding Mac clients to an existing renderfarm either you already know how to address this issue, or you should consult with the network administrator in charge of the existing farm before running the make install.

LAUNCH DRQUEUE DAEMONS AUTOMATICALLY ON BOOT
The objective of this section is to launch master, slave or both automatically upon booting any Mac on the network. We will create startup scripts for master, and for slave. The slave startup scripts will need to be installed on any Mac running slave, The master startup scripts will only be installed on the Mac running master. If the master computer will also be running slave you will need to install both scripts on that computer.
1. Create the startup scripts for master: Only perform this on the one Mac you will be using as master for the renderfarm. If you are only adding Mac slaves to an existing renderfarm skip to part B.
  1. Create the DrQMaster startup directory: In terminal run the following command:
    
    sudo mkdir /Library/StartupItems/DrQMaster
  2. Create the StartupParameters file:
    
    sudo vi /Library/StartupItems/DrQMaster/StartupParameters.plist
  3. Enter insert mode in vi by hitting the I key.
  4. Type the following:
    
    {
    
    Description = "DrQueue Master";
    
    Provides = ("DrQMaster");
    
    Requires = ("NFS");
    
    OrderPreference = "Late";
    
    Messages =
    
    {
    
    start = "Starting DrQueue Master";
    
    stop = "Stopping DrQueue Master";
    
    };
    
    }
  5. Hit the “esc” key to get out of insert mode, then type :wq [return] to save the file and quit from vi.
  6. Create the DrQMaster startup script:
    
    sudo vi /Library/StartupItems/DrQMaster/DrQMaster
  7. Enter insert mode in vi by hitting the I key.
  8. Type the following:
    
    #!/bin/sh
    
    . /etc/rc.common
    
    StartService ()
    
    {
    
    ConsoleMessage "Starting DrQueue Master"
    
    /mnt/render/bin/master
    
    }
    
    StopService ()
    
    {
    
    ConsoleMessage "Stopping DrQueue Master"
    
    killall master.Darwin
    
    }
    
    RestartService ()
    
    {
    
    ConsoleMessage "Restarting DrQueue Master"
    
    killall master.Darwin
    
    /mnt/render/bin/master
    
    }
    
    RunService "$1"
  9. Hit the “esc” key to get out of insert mode, then type :wq [return] to save the file and quit from vi.
2. Create the startup scripts for slave: Perform this on every Mac you will be using as slave for the renderfarm.
  1. Create the DrQSlave startup directory: In terminal run the following command:
    
    sudo mkdir /Library/StartupItems/DrQSlave
  2. Create the StartupParameters file:
    
    sudo vi /Library/StartupItems/DrQSlave/StartupParameters.plist
  3. Enter insert mode in vi by hitting the I key.
  4. Type the following:
    
    {
    
    Description = "DrQueue Slave";
    
    Provides = ("DrQSlave");
    
    Requires = ("NFS");
    
    OrderPreference = "Late";
    
    Messages =
    
    {
    
    start = "Starting DrQueue Slave";
    
    stop = "Stopping DrQueue Slave";
    
    };
    
    }
  5. Hit the “esc” key to get out of insert mode, then type :wq [return] to save the file and quit from vi.
  6. Create the DrQSlave startup script:
    
    sudo vi /Library/StartupItems/DrQSlave/DrQSlave
  7. Enter insert mode in vi by hitting the I key.
  8. Type the following:
    
    #!/bin/sh
    
    . /etc/rc.common
    
    StartService ()
    
    {
    
    ConsoleMessage "Starting DrQueue Slave"
    
    /mnt/render/bin/slave
    
    }
    
    StopService ()
    
    {
    
    ConsoleMessage "Stopping DrQueue Slave"
    
    killall slave.Darwin
    
    }
    
    RestartService ()
    
    {
    
    ConsoleMessage "Restarting DrQueue Slave"
    
    killall slave.Darwin
    
    /mnt/render/bin/slave
    
    }
    
    RunService "$1"
  9. Hit the “esc” key to get out of insert mode, then type :wq [return] to save the file and quit from vi.

ADD WINDOWS SLAVES
If your files are hosted on an OSX computer, and you followed all of the instructions in section V.G, the same directory Linux and OSX computers see as “/mnt/render” is also available as a shared directory to Windows computers. If the computer hosting the shared files is running Linux, you will need to use SAMBA to share that directory in a way Windows understands. SAMBA is not difficult to compile, install, setup, and manage - but it is beyond the scope of this tutorial.
1. Map the shared directory to an unused drive letter (for this tutorial we will use Z): Right click on “My Computer” and select “Map Network Drive…”. Select the drive letter and try browsing to the shared folder. If the server or shared folder do not appear, just type in the path: \\[name or IP address of server]\drqueue. Check the “reconnect at logon” box, and click “Finish”. You should be prompted for a username and password – enter the name and password you set up in section V.G.
2. Download the Windows installer binary from http://www.drqueue.org/download.php and install selecting to install as slave when prompted.
3. Set the DrQueue environment variables: Right-click on “My Computer”, select “Properties”, and click the “Advanced” tab. Near the bottom of the dialog box click “Environment Variables”. You should find the following items, edit or create the variables to match your system. Basically, all of the variables should point to your local machine except for logs, master, and tmp. Master will be the IP address of the computer running master, tmp and logs will point to the mapped directory.
  - DRQUEUE_BIN = C:\Program Files\drqueue\bin
  - DRQUEUE_DB = C:\Program Files\drqueue\db
  - DRQUEUE_ETC = C:\Program Files\drqueue\etc
  - DRQUEUE_ISSLAVE = 1
  - DRQUEUE_LOGS = Z:\logs
  - DRQUEUE_MASTER = 192.168.1.xxx
  - DRQUEUE_ROOT = C:\Program Files\drqueue
  - DRQUEUE_TMP = Z:\tmp
4. Add drqueue root directory to the path: Still (or again) in the Environment Variables find the variable “Path” and click the “Edit” button. Be careful not to change or remove any of the existing entries. Scroll to the end of the list and add “;c:\Program Files\drqueue” (assuming the default installation, otherwise the path to the DrQueue installation directory on the local machine - make sure to separate the new entry with a semicolon [;]).
5. Make the rendering program available to slave: Again, I will include instructions only for Blender, however a similar procedure may be required for other rendering programs. As in step D above, edit your Path variable. I believe the Windows installer for Blender adds an entry which will probably be “;C:\Program Files\Blender Foundation\Blender”. If there is not an entry like that, add one with the actual path to the folder enclosing blender.exe.
6. Edit drqueue.conf: This is not strictly necessary, since setting the environment variables as above should allow slave to work correctly despite the warning on startup. On each windows slave go to the DRQUEUE_ETC directory (C:\Program Files\drqueue\etc) and edit the file “slave.conf” it should read:
  
  #
  
  #
  
  # This lines will be ignored
  
  #
  
  #
  
  logs=Z:\drqueue\logs
  
  tmp=Z:\drqueue\tmp
  
  pool=
  
  Leaving pool blank will result in a warning upon launching slave, but it will put this slave in the same “Default” pool as the rest of the network.
7. Download and install a modified slave.exe: Now that the file-sharing issue has been overcome, the remaining problem in getting Windows slaves to work with DrQueue is that master sends a fixed path to the job script. For slaves that can arbitrarily define a path with NFS (Linux and OSX) we have created that path – but Windows slaves are looking for files in the path /mnt/render, which doesn’t exist; Windows sees those files in the path Z:\. Jason Ekstrand provided a modified slave.exe and supporting files that intercept the messages from master and rewrite the path so that slave.exe can now find the shared files.
  1. Download the zip file from http://www.drqueue.org/twiki/pub/Main/CrossPlatformRendering/WindowsSlave.zip.
  2. Expand the zip file, and place all of the contents in C:\Program Files\drqueue\bin on each Windows slave. Click OK to overwrite the existing slave.exe, or rename slave.exe (slaveOriginal.exe, or something) if you want to keep it.
  3. Edit the new file C:\Program Files\drqueue\bin\tcshcmd: When finished it should read:
    
    #!/bin/tcsh
    
    tcsh `echo $* | sed 's/\/mnt\/render/Z:/'`
    
    It is important that the file reads exactly as shown above, including the backticks (`) enclosing the part after tcsh, the apostrophes enclosing the substitution string, and the backslashes to escape the slashes in the path. If your path to DRQUEUE_ROOT is different, make sure to escape all /'s with a \.
8. Edit the shared file “blender.sg”: One more time, I am only providing instructions for Blender, which I have tested. Enabling other renderers is left as an exercise for the student.
  1. Open the shared file /mnt/render/etc/blender.sg: You need to edit the file that drqman will see. In this tutorial I am assuming this is in the shared directory. If you are working in an environment where drqman might be run from a computer with DRQUEUE_ETC defined as a local directory, you will need to edit the local blender.sg file(s).
  2. Find the line “set SCENE=`"$DRQUEUE_BIN/cygpath.exe" -w $SCENE`” and replace it with the following lines:
    
    # set SCENE=`"$DRQUEUE_BIN/cygpath.exe" -w $SCENE`
    
    set SCENE=`echo $SCENE |sed 's/\/mnt\/render/Z:/'`
    
    The # character turns the original line into a “comment” which is not executed, the second line forces the replacement of the path the rest of the network uses with the path the Windows slave can find. Since this line is included inside an if statement, it will only be executed by Windows slaves, so the rest of the network will operate normally.
9. Remove the drqueue tray icon: It has been widely reported that the tray icons and automatic startup features of the standard DrQueue windows install do not work properly. Stop it from loading by opening up the Startup folder in Programs from the Start menu and delete the DrQueue services item.
10. Reboot: we need to make sure all these changes “took”, and survive across restarts.
11. Launch slave from the command line: I do not yet have a means of making Windows slave start at boot time and run in the background, further I do not know of a way of launching programs on an XP box remotely from a terminal – so to activate your windows slaves you will need to open a “command prompt” on each windows slave, navigate to the local drqueue directory and launch slave. Using the -c option forces slave to read the specified configuration file (C:\Program Files\drqueue\etc\slave.conf). Quotes are required because of the way Windows Command Prompt deals with spaces in directory names:
  
  cd "C:\Program Files\drqueue\bin"
  
  slave -c "C:\Program Files\drqueue\etc\slave.conf"

TEST THE RENDERFARM
1. Reboot Everything: If you have followed the tutorial so far, several of the changes would have required that you reboot anyway. If you have included the options of having services start at boot we want to make certain that they really do start at boot time.
2. Launch any slaves that do not auto-start at boot time: If you did not install the startup scripts in your OSX slaves, use a terminal to ssh to each machine, navigate to mnt/render/bin and run slave. To save the navigation step you can make a symbolic link: sudo ln ‑s /mnt/render/bin/slave /usr/bin/slave, then you can type slave from anywhere. If you didn't enable remote logins in the Optional Mac section you'll need to log in to each Mac, open a terminal, and launch slave. Until I learn some new tricks and add them to this tutorial you'll have to go to each Windows slave, open a Command Prompt, and launch slave as explained in the Windows section. This tutorial assumes that if you have linux slaves you already know what to do for them, although I do intend to add a very basic Linux section in the future.
3. Launch drqman: drqman runs within the XWindow environment, so you need to launch X11 to run it on your Mac. You can find X11 at /Applications/Utilities/X11.app. From the default configuration X11 will open a small terminal window. In that terminal window type /mnt/render/drqman. Don’t worry about the warning “Could not open config file using defaults”, another window should open showing the graphical interface to DrQueue. Click on the “Computers” tab to see if all of your slaves appear there.
4. Run a test job: click back to the Jobs tab. If you have a 3-button mouse, right-click (for a single button mouse command-click). Select “New Job” from the menu. As name type, for example... "test" and as command write (without the quotes): "echo $DRQUEUE_FRAME". You can leave the rest as default. Then click on "Submit". Then you can right-click (or command-click) on the job and select "Details". There you'll see how frames are executed all over the network. You can even check the logs to see that actually every frame has echoed the right number.

TROUBLESHOOTING
1. Master or slave isn’t running (OSX): Go to the computer in question (or ssh to it if you’ve enabled remote logins) and open a Terminal. From the command line type:
  
  ps –A | grep master # the | is called "pipe", it's shift-backslash (usually the key right over the return key)
  
  Replace master with slave to check slave. If master is running you should see several lines similar to:
  
  17839 ?? S 0:00.00 /mnt/render/bin/master.Darwin
  
  If you don’t see anything like this, master isn’t running. Try rebooting if you set up the StartupItems scripts. If it still isn’t working chances are there is an error in your startup scripts. Check section VII of the tutorial. Also make sure you made the changes to /etc/rc.common from section V-D. Also make certain the permissions are correct for the StartupItems scripts. From Terminal type:
  
  ls -l /Library/StartupItems/DrQMaster/
  
  you should see something like this:
  
  -rwxr-xr-x 1 root wheel 344 Jul 24 18:29 DrQMaster
  
  -rwxr-xr-x 1 root wheel 271 Jul 23 19:53 StartupParameters.plist
  
  If the permissions are not –rwxr-xr-x type:
  
  sudo chmod –R 755 /Library/StartupItems/DrQMaster
2. Master or slave still isn’t running: Make sure the shared directory is mounting properly. From the GUI you should be able to open the boot disk, and from that window find a folder named mnt. From mnt you should be able to drill down through the drqueue directories, for example /mnt/render/bin, which would show a list of files including blockhost, blockhost.Darwin, and so on. Make sure there is a /mnt/render/bin/master, /mnt/render/bin/master.Darwin, /mnt/render/bin/slave, and /mnt/render/bin/slave.Darwin.
  
  Next make sure the environment variables are defined. From a terminal type:
  
  echo $DRQUEUE_ROOT
  
  The system should respond /mnt/render (or your correct drqueue root path). Also try:
  
  echo $DRQUEUE_MASTER
  
  The system should respond 192.168.1.xxx (your actual master IP address, or possibly a machine name rather than numerical address). If the system echoes a blank line for either of these, review Section V. If all this checks out, test if master or slave will launch from the command line. In terminal type ./mnt/render/bin/slave. If slave loads the problem is most likely in section V or Section VII. If slave does not load go back to the beginning following the instructions for adding an OSX client to an existing renderfarm.
3. “Could not open config file using defaults”: The executables all are hard-coded to look in /etc/drqueue for the .config files. The installer does not create this directory, and places the .config files in /mnt/render/etc. Fortunately the installation we have created allows the renderfarm to work just fine with the defaults so you can safely ignore this warning. If, however you would like to take advantage of the config settings (and this is the only way to create “pools”), or just get tired of seeing this message, you can create the /etc/drqueue directory and copy the files to that location. Be sure to edit the config files on each machine to match your environment. In the windows section we included an option that seeks a config file at a specific location, make certain that file exists at that location and is configured properly.
4. The slaves might be rejected by master because the master program may not accept slaves that it cannot identify. Also, your slaves may not appear in drqman by name – this can be fixed by editing the /etc/hosts file on the computer running master. Just add lines at the bottom of the /etc/hosts file giving a name to the IP address of each slave, for example:
  
  192.168.1.10 Abel
  
  192.168.1.12 Baker
  
  192.168.1.15 Charlie
  
  192.168.1.27 Delta
5. Permissions Errors: Some errors or failures of the programs may result from a computer being unable to read from or write to one of the shared directories or files. First make sure that your NFS shares are not exported or mounted as read-only (see the NFS section). On the machine exporting the NFS shares, make sure that the permissions are set correctly. In the minimum security environment all of these directories and files will be set to read-write-execute for owner, group and everyone – mode 777, or –rwxrwxrwx. You can set this by going to the machine hosting the share and from a terminal executing sudo chmod –R 777 /mnt/render (or whatever the path is to the shared directory). If you have hardened your environment you need to make sure that user and group permissions allow all clients read/write access to the tmp and log directories.

TO DO
1. Security/Permissions/Users/Groups: Although the farm resulting from this installation guide will work and allow any computer in the local net to participate in the renderfarm, slaves are unable to write to the common log. Need a procedure to make the job log file created by master writable by slaves.
2. Windows Launch and Auto/Background startup: It has been well documented in the forums and other tutorials that although the current Windows installer tries to launch master and slave services in the background and creates a tray icon for managing these services (including a launcher for drqman), it doesn’t work properly. Until someone overhauls the windows installer to correct these issues we need an easier means of launching the programs. I expect that a batch file can be written to launch slave.exe with the correct parameters to find the .conf file, and it should be possible to drop a shortcut into the Startup directory that will launch slave and let it run in the background without having to keep a command prompt window open.
3. For Windows slaves, the password for the mapped volume appears to not be saved, requiring you to manually reconnect the volume after each restart. Need to research a way of fixing this.
4. Revise to use a more newbie-friendly editor than vi.
5. More illustriations.
6. Proofreading, find and correct spelling, grammar,and technical errors.
7. Convert more references to other sections of this document to links to anchors.
8. Add a GNU/Linux section, and a BSD section.
9. Additional troubleshooting suggestions.