Yes, here is a sample workflow that showcases Qube's main components:
From a hardware standpoint, the main things recommended are:
Qube does not explicitly restrict a job to run on a particular core. It leaves that up to the applications to determine. If this is the case, then what to these terms used in Qube mean and how do they relate to machine cores?
The terms can be misleading. Here is a summary of the terms and their meanings:
Putting it together...
The job's CPUs value refers to the number of subjobs (or processes) the Supervisor should dispatch to run the job. Every job has at least 1 subjob/process, and each subjob/process runs in a slot on a host. The number of subjob slots a single subjob takes up is controlled by the host.processors resource reservation. By default a single subjob takes up a single slot (host.processors=1) when submitting a job.
Therefore...
When you submit a job and request a number of "CPUs," you are not actually asking for Qube to map processes to processor/cpus/cores. Rather the "cpus" value is represents the number of "subjobs" to dispatch to various Workers. By default, each subjob takes up one "slot," the number of slots on a Worker determined by the "host.processors" resource. That value is set by the worker_cpus configuration variable. If it's set to "0," then host.processors is automatically set to the number of cores on the Worker. Any other value is what host.processors is set to.
That's why every job by default has a reservation of "host.processors=1" It means "look for a worker with 1 slot open, and then fill it with a subjob, and reduce the number of slots on the Worker by 1."
When a subjob launches, Qube is executing an instance of an application, which may be a simple command line, or it may be an elaborate interactive session with Maya (Maya Job Type). At this level, we are simply running the application, and depending upon the OS to determine actual CPU utilization.
Now for a practical example...
To have each Worker on your Qube farm render a single frame at a time using all cores (with a multi-threaded renderer like Maya), just reduce the number of available host.processor resource slots on the Worker to 1. This can be done by "Locking" off the number of available process slots to 1 (done through the QubeGUI or commandline).
CentOS 5 is apparently compatible with our RHEL 4
Run the registry editor on the machine (Start menu, "Run..." then "regedit" and hit enter), and check the following path.
HKEY_LOCAL_MACHINESOFTWAREPipelineFXqube
There should be BASE_DIR and INSTALL_DIR, which should point to, by default, respectively:
BASE_DIR C:\Program Files\pfx
INSTALL_DIR C:\Program Files\pfx\qube
OS X:
mount, install, unmount it:
hdiutil attach dmgfile
installer -pkg /Volumes/volume/package.pkg -target /
hdiutil detach /Volumes/volume
Linux:
rpm -ivh rpmfile
Windows:
The msiexec.exe command will perform an MSI installation via the command line.
msiexec -i msifile
The various flags supported by the installer are:
Setting them to 1 will have the same effect as clicking the checkbox in the interactive installer.
Sometime you need to see what's going wrong with the MSI installer. You can use the command line msiexec to install with logging output to a file:
msiexec /i mymsifile.msi /Lime logfile.txt
or more verbose
msiexec /i mymsifile.msi /L*vime logfile.txt
where mymsifile.msi is the path to the MSI file.
Configure the service to log on a a particular user. This user must be in the local Administrator's group, and the following User Rights Assigments policies must be applied to both the Administrator's and Network Service groups:
On Windows, I recommend you try backing out of Qube, uninstalling MySQL, and reinstall Qube. On OS X. You could uninstall MySQL, or you can run the normal installer and make sure to use the Customize option and deselect MySQL before installing the Supervisor.
There is also an alternate method if you cannot reset the password, in the configuration file:
Windows
C:\winnt\qb.conf or C:\windows\qb.conf
Linux/OSX
/etc/qb.conf
Add these lines:
database_user = root
database_password = "yourpassword"
You can use any account you wish. However the user account you choose, must be capable of creating and deleting databases.
Our installer assumes a new installation of MySQL, so it should probably have only the default users and passwords, that way, we can add our own access. We leave the root password blank. You can configure the Supervisor by editing its qb.conf to set an alternate user and password with the following variables:
database_user
database_password
Install GTK 2.7. The installers are located on our FTP site.
This is probably the result of a firewall either on the Worker or the Supervisor. Disabling all firewalls and restarting the Workers should fix the problem. If security issues require the firewalls, open the following ports to TCP/IP and UDP:
See post on Qube_Knowledge_Base#Newly_installed_Workers_are_listed_as_"down"
To get around this issue, install either Perl 5.6 or Perl 5.8.
Linux: /etc/qb.conf
OS X: /etc/qb.conf
Windows XP: WINDOWSqb.conf
Windows Vista: PROGRAM DATAPfxQubeqb.conf
Set supervisor_preempt_policy = disabled and the supervisor will not preempt jobs either passively or aggressively.
As we discussed, a host group is like an "alias" for a set of machines. You can assigned a host to more than one group, but jobs sent to the group will only run on those machines. A cluster is a priority scheme that will allow a job to run anywhere there is an available machine, but it could get preempted by a job that has a cluster specification that matches the machine.
Since your customer wants to divide up the farm strictly so that jobs intended for machines assigned to a project can't run elsewhere (even if hosts are available), you'd use a group.
Here's how I'd set up the qbwrk.conf:
[project1]
worker_groups = "project1"
worker_cluster = "/project1"
[project2]
worker_groups = "project2"
worker_cluster = "/project2"
[project3]
worker_groups = "project3"
worker_cluster = "/project3"
[project4]
worker_groups = "projetc4"
worker_cluster = "/project4"
[project5]
worker_groups = "project5"
worker_cluster = "/project6"
[xcube1]: project1
[xcube2]: project2
[xcube3]: project3
[xcube4]: project4
[xcube5]: project5
To do that, you would need to go back to the cluster, establish worker restrictions, then set the client cluster to submit jobs to the appropriate cluster.
1. You will need to modify the qbwrk.conf:
[project1]
worker_cluster = "/"
worker_restrictions = "/project1"
[project2]
worker_cluster = "/"
worker_restrictions = "/project2"
[project3]
worker_cluster = "/"
worker_restrictions = "/project3"
[project4]
worker_cluster = "/"
worker_restrictions = "/project4"
[project5]
worker_cluster = "/"
worker_restrictions = "/project6"
[xcube1]: project1
[xcube2]: project2
[xcube3]: project3
[xcube4]: project4
[xcube5]: project5
2. You will need to set the following on each client qb.conf (for example):
client_cluster = "/projectA"
You need to set this on each client, so that the client will by default only submit jobs to the cluster you specify in the qb.conf.
The cluster setting is a hierarchy, so you don't necessarily need to put each host in a cluster. The restriction will limit the host to only run jobs submitted with the appropriate cluster spec, and the client_cluster will limit the cluster a job will be submitted to.
As a caution, if a user submits a job with a different cluster setting, the job will not go out with the default set in the qb.conf, but rather the one specified by the user, so they should not submit the job with a cluster setting.
For each Maya Worker create a host property called "host.maya" and set it equal to 1. You can either do this with the Configuration GUI or using a qbwrk.conf:
[hostname01]
worker_properties = host.maya=1
When you submit a job, the requirement must then include:
host.maya=1
Qube! keeps track of 4 numbers for licensing.
The qb.conf value is set like this, for example:
license.maya=50
This value of 50 can only be set in the qb.conf. This is the number of licenses allocated to the farm.
Let's say the output from the qbadmin command
% qbadmin supervisor --resources
license.maya=20/50
The value of 20 is the Supervisor-tracked license resource for the farm. The value of 20 means that 20 licenses are in use from a total allocation of 50.
The final 2 components, you won't see in the output of qbadmin. They represent
This is because the Supervisor needs to differentiate between licenses it's using and licenses used outside of the farm. Since the Supervisor already knows how many licenses it is using, it can determine how many don't belong to the farm and adjust the available resources accordingly.
For example, if you issued a series of qbupdateresource calls
% qbupdateresource --name license.nuke --total 50 --used 10
% qadmin supervisor --resource
license.nuke=10/50
% qbupdateresource --name license.nuke --total 40 --used 10
% qadmin supervisor --resource
license.nuke=20/50
In the example because the total number of licenses in the whole facility dropped from 50 to 40, the supervisor compensates its in use number by 10 since now there are 10 less to work with.
Remove either the worker or the supervisor.
If going from Windows using UNC paths to Linux or Mac, one can use symbolic links to map the UNC paths to absolute paths.
If going from Linux or OSX to Windows, this gets a bit trickier. Having all paths within the scenefile be relative paths is usually essential. If that is done, then one needs to then just make sure that the path that the rendering Worker is using is valid.
For example, if one submits from a Mac to the file:
/Volumes/mynet/myproject/myscene.ma
The Windows PC will likely expect something like:
//mynet/myproject/myscene.ma
You can first try this out manually when submitting a job by modifying the scenefile name that is being submitted.
Automation of this can be done by modifying the submission dialog .py file and adding a postDialog callback to adjust the paths. We are also working on solutions for client-side path translation that may handle this in future versions of Qube.
This stops the worker from showing up again if I make a --clearbanned call.
So to reinstate a worker
I think you can remove the offending host by using qbadmin and referring to it by the MAC address:
qbadmin worker --remove 00:30:48:5A:71:5D
If that doesn't worker, you'll need to remove it by name or IP:
qbadmin worker --remove LAX-RF-029
If you're lucky, you'll get the down host removed. If both get removed, just use --clearbanned and restart the Worker:
qbadmin worker --clearbanned
Have you checked your firewall settings:
Unix:
iptables -L
There is another system which is included on linux by default which directly conflicts with port numbers we use:
If a site is unable to start their supervisor, they may need to disable the hplip service, or they can change their supervisor port number. However if they do this, every single client and worker will also need to reflect these settings (for example):
Supervisor qb.conf
supervisor_port = 10001
supervisor_sub_port = 10002
Worker qb.conf
worker_port = 10011
You can use standard backup tools. Here is a list of files that are critical:
supervisor_logfile: /var/spool/supelog
supervisor_logpath: /var/spool/qube
/etc/qb.conf
/etc/qbwrk.conf
/etc/qb.lic
/etc/my.conf
innodb_data_home_dir: /var/lib/mysql
Fix by enlarging the field size of job.data
% mysql -u root qube
mysql> ALTER TABLE job MODIFY data LONGTEXT;
% mysql -u root qube
mysql> UPDATE job SET status = 0x140 WHERE id = <myjobid>;
Cause: Likely you have just recently reset your qube database on the same machine that was previously running a qube supervisor. The MySQL database was cleared, but the job log files are still present. The descrepency between those log files and what is stored on the supervisor mysql database is what the QubeGUI is likely issuing these warnings about.
Solution: Delete or move the job log files. They can be found at:
(Example commands provided for OSX platform)
sudo /Applications/pfx/qube/utils/upgrade_supervisor -reset
Note: you may need to restart the Supervisor as well
sudo SystemStarter stop supervisor
sudo SystemStarter start supervisor
The qb.conf setting you need to use is:
worker_job_start_delay
The field is in seconds.
worker_job_start_delay = 10
Submit a remote job:
qbsub --host hostname "net stop qubeworker && net start qubeworker"
(Alternate) Install sshd from Cygwin
ssh hostname "net stop qubeworker && net start qubeworker"
To reboot a Worker:
qbadmin worker --reboot hostname
Reboot all Workers (Windows):
qbsub --flags host_list shutdown r
One can place all of the job logs (containing stdout,stderr,etc) directly in a central location. This requires modifying the configuration for both the Supervisor and the Workers.
Logging into the "qubeproxy" local user is useful for troubleshooting if you are running in "proxy" mode for that Worker. The "qubeproxy" account is a local machine user account. The username and password for this account is:
qblogin --display --user proxyuser
where proxyuser is the username for the proxy user. After successfully entering the password, an encrypted version of the password will be output.
proxy_password = password
where password is the encrypted string.
Your Windows clients need to translate the paths into something understandable by the Linux/Mac OS X Workers. To do this, we sometimes recommend the use of the MEL command dirmap. It has the capability to do the translation, and we have support for it in our Job Type. It has some limitations, so it's not for every situation.
In order to set up the dirmap, you will need to edit each users userSetup.mel file. Copy it around. In it, you add a line to enable dirmapping:
dirmap -en 1;
Then, you add the map such that the first directory is the FROM and the second is the TO mapping:
dirmap -m "<windowsDirectory>" "<linuxDirectory>"
For example:
dirmap -en 1;
dirmap -m "R:Project" "/uniserver/project"
To test if you have it set up correctly:
You should then see your mappings as output.
When you submit the job, the mappings should be translated when the job gets submitted. It may take some finagling to get everything working.
Looks like your account isn't set up to include the maya bin directory in the PATH environment. Make sure you set up the MAYA_LOCATION as well.
If your shell is /bin/bash put the following in your $HOME/.profile:
export QBDIR=/Applications/pfx/qube
export ALIAS_LOCATION=/Applications/Alias
export MAYA_LOCATION=$ALIAS_LOCATION/maya7.0/Maya.app/Contents
export PATH=$QBDIR/bin:$QBDIR/sbin:$MAYA_LOCATION/bin:$PATH
On csh/tcsh, the following into your $HOME/.cshrc or $HOME/.tcshrc:
setenv QBDIR /Applications/pfx/qube
setenv ALIAS_LOCATION /Applications/Alias
setenv MAYA_LOCATION $ALIAS_LOCATION/maya7.0/Maya.app/Contents
setenv PATH $QBDIR/bin:$QBDIR/sbin:$MAYA_LOCATION/bin:$PATH
Unfortunately the "waitfor" option isn't something available in the individual APIs however, there is an equivalent field in the job which the "waitfor" option can take advantage of. It's called "dependency".
Just add into your dependency field something similar to:
"dependency", "complete-job-123155"
Where complete is the state you are looking for, job is the kind of event, and the number is the job id. Note, you should use "done" rather than "complete" if you don't care if the job has failed, been killed, etc...
You need to change the permissions on the file below:
C:\windows\system32\drivers\etc\services
The file contains the port numbers for mi. The problem is that under a proxy account, the proxy user may not have permissions to read that file. You could try one of the following:
Or
Edit the default_3dsmax_locations in the jobtypes/3dsmax/job.conf file
The in-application submission not showing up with the latest Max jobtype when selecting the menu item. Also the QubeGUI launching from within Max is not working either. What's going on and how does one fix this?
The new in-application submission for the 3ds Max jobtype calls the QubeGUI executable and provides it the scenefile and other parameters. If the QubeGUI (qube.exe) cannot be found, then no dialog will come up.
If this happens, it is likely a path issue. From the commandline, type "qube.exe". If the GUI does not come up, then it likely cannot be found from within 3ds Max. Add to your System Environment Variables the PATH to where the QubeGUI is located (either C:\Program Files\pfx\qube\bin or C:\Program Files (x86)\pfx\qube\bin). Alternatively one can adjust the menu.ms script that calls the QubeGUI from within Max.
Bear in mind that when you submit a command via qbsub, the Supervisor dispatches as many "subjobs" as you ask for with the "--cpus" option. Each subjob will execute the command.
That means, if the command is set up to render a range of frames, each subjob will render all those frames, wasting a lot of time and work. If you know how to set up your command to render a single frame, you can use qbsub to instruct the Supervisor to keep a list of frames to render. With the inclusion of a macro term to your command, you can instruct the Worker to request a frame from the Supervisor's list and execute the command on that one frame. Repeat this across all your subjobs, and you're distributing your frames across your farm!
Suppose you have a dumb command that renders frames with a couple of arguments:
Render --start # --end # <scene>
Where # are frame numbers and <scene> is the file.
If you submit the job naively using qbsub:
qbsub -cpus 10 Render --start 1 --end 100 scene
Your going to have each subjob (all 10 of them) render the whole scene from frames 1-100. Not good.
Instead, let's look at rendering a single frame, say 1:
Render --start 1 --end 1 scene
If we submit that naively:
qbsub -cpus 10 Render --start 1 --end 1 scene
We still do the same thing, but only do one frame. What if we could do this, but get each subjob to do different frames. It's pretty straightforward. Just give the Supervisor the list of frames, and change the command to include a placeholder where the frame would go:
qbsub --frames 1-100 --cpus 10 Render --start QB_FRAME_NUMBER
--end QB_FRAME_NUMBER scene
Now, when you submit the job, each subjob will call the Supervisor and ask for a frame to render, and substitute for the QB_FRAME_NUMBER placeholder. Easy! Each subjob will render one or more different frames, and will automatically quit when there are no more to render because the Supervisor keeps track.
Check to see if you have host_list set as a job flag
So when you submit a job, you can do this to keep only one of your job's kind on a host:
qbsub --requirements "not (host.duty.kind has mykind)" --kind mykind command
The cool thing is you can do it with types as well:
qbsub --requirements "not (host.duty.type has cmdline)" command
There is a reverse syntax if you want to use it:
qbsub --requirements "not (cmdline in host.duty.type)" command
This tells the queuing system to filter out all hosts which have your kind of job already running on a host.
For the API:
not (job.type in host.duty.type)
Here's a normal command line sleep 1000 qbsub:
qbsub sleep 1000
This is how you'd do it with the --data and --type:
qbsub --type cmdline --data '(=(cmdline=sleep "1000"))'
I found the data string by running
qbsub --xml --export job.xja sleep 1000
Examining the job.xja file for the <data></data> pair shows:
<data>(=(cmdline=sleep "1000"))</data>
So you should be able to submit an miGen job, check the xja file in the job log directory for the <data> tags and use the contents as a template.
It will run in the same directory as it was submitted in, as long as that directory is valid on the executing Worker.
The easiest thing to do is to submit your jobs with a memory reservation. The reservation will force the Supervisor to look for hosts with the requisite amount of memory before dispatching the job, and then block out (or reserve) the amount requested. This will serve to limit the number of subjobs running on the host to only the number that it can safely handle.
For example, say your hosts have 4 subjob slots and 2GB of memory. If each render process or thread needs 1GB or memory, you will soon overtax the machine because you will have 4 subjobs each asking for 1GB or more.
If you add a resource reservation (in MB) when you submit the job:
host.memory=1000
Then you will only have at most 2 subjobs running on the host, because that's as much memory as it can handle. Memory is a resource, so you should be able to monitor it in the QubeGUI by selecting a Worker and examining the Properties tab, under host resources.
You can also restrict jobs by limiting the number subjobs per host on a per job basis. If you have hosts with 4 subjob slots, you can just send each job a resource reservation of:
host.processors=4
However, if you have a mix of hosts with different numbers of subjob slots, then you would need to do something like this:
host.processors=1+
This will reserve a minimum of 1 slot per subjob, up to the maximum number of slots on the host. This won't guarantee a host will have multiple subjobs, so you may need to investigate the other options above.
You could reconfigure each host to have only one subjob slot per host. To do this, you will need to log in to the Worker and use the Configuration tool. Go to Worker Settings, then Advanced settings and set the Worker CPUs to 1.
Create a limited resource on each host. For example, if you're working with Maya render jobs, you can create a Maya worker resource with a quantity of 1 per Worker. You'll need to use the Configuration tool, select Worker Settings, then Worker Configuration. Add a Resource called host.maya Worker resource, and a Total of 1.
When you submit the job add this reservation:
host.maya=1
More information on resources and using the Configuration GUI can be found in the Administration manual.
qbsub --flags host_list command
Qube requires that the Workers need to be able to read the scenes and textures on the network. The easiest way to check to see if a particular file or directory can be read by a Worker is to run a commandline job.
To verify that a particular file can be read by the Worker:
wxImage
This class encapsulates a platform-independent image. An image can be created from data, or using wxBitmap::ConvertToImage. An image can be loaded from a file in a variety of formats, and is extensible to new formats via image format handlers. Functions are available to set and get image bits, so it can be used for basic image manipulation.
Handlers
The QubeGUI 5.4 version uses the standardized SimpleCmd/SimpleSubmit framework for all of the submission dialogs. These submission dialogs are editable and located in the simplecmds/ directory (see File->Open SimpleCmds Directory...). A postDialog callback can be added to convert all path parameters to what the renderfarm machines expect.
Here is an example of modification to the Nuke (cmdline) submission interface that will convert the paths from OSX to Windows UNC paths:
def create():
cmdjob = SimpleCmd('Nuke (cmdline)', hasRange=True, canChunk=True, help='Nuke render jobtype', [b]postDialog=postDialog[/b])
...
def postDialog(cmd, jobProps):
# Get a list of properties that use paths
fileProps = set([k for k,v in cmd.options.iteritems() if v.get('type', '') in ['dir', 'file']])
# For path properties, substitute the string values
for k,v in jobProps.setdefault('package', {}).iteritems():
if k in fileProps:
jobProps['package'][k] = v.replace('/Volumes/myserver/', '//myserver/')
Thanks to Rangi Sutton of Kanuka Studio
deb http://apt.wxwidgets.org/wxpython gutsy-wx main
$ wget -q http://apt.wxwidgets.org/key.asc -O- | sudo apt-key add -
(returns)
OK
$ sudo apt-get update
$ sudo apt-get install python2.4
$ cd /usr/bin ; sudo rm python ; sudo ln -s python2.4 python
$ sudo vi /usr/share/python/debian_defaults
$ sudo apt-get install python-wxgtk2.8
Some website/instructions/info here: http://www.wxwidgets.org/
The prefs file can be found in the following locations.
Linux
$HOME/qube/qube_guiPreferences.conf
Windows
c:/Documents and Settings/username/qube/qube_guiPreferences.conf
OS X
~/Library/Preferences/qube/qube_guiPreferences.conf
Most likely, your drives are not mapped correctly on the Worker. Here are some notes on how to make sure your Workers can properly map drives at execution time:
Check out the next two articles for more information on drive sharing with Qube.
Pip3lin3P@$$wd
Of course, the qubeproxy user will need to be added to appropriate groups in order to have read and write permission
to the server.
Verify the job has drive maps. Verify the Worker has auto_mount turned on. Make sure the drive isn't automounting as part of the profile: Go to "Start Menu->My Computer" on the machine in question. Pull down Tools->Map Network Drive There should be a checkbox for "Reconnect at logon." You'll want to unmap the drive, and make sure that option is unchecked whenever you map the drive on that machine.
One can also submit a "test" job to check on the drive maps used on the Worker:
You can use Windows' logon/logoff scripts to automatically lock/unlock a machine when users logon/off. Basically, you'd call "qblock <machinename>" in the logon script, and "qbunlock <machinename>" in the logoff script. To set up logon/logoff scripts for local logins, you edit settings in the Windows' "group policy editor":
---l jcg krmpbuicseyqg-vft [default]
you're good (the 4th column's "l" means the default users have lock permission).
You could remove the "auth" from the "Startup" items for users on windows workstations.
In order for you to operate the Workers the "user" mode, each user will need to register their domain login and password with the Supervisor. That way, the Worker service can authenticate as the submitting user in order to execute the job. The GUI window you see comes up in order to make it a little easier for the user to perform this step.
Briefly, set up Dr. Watson to get a crash dump. From the Start Menu, run these commands:
Start->Run->drwtsn32 -i
Start->Run->drwtsn32
More information on Dr. Watson can be found at Microsoft:
http://support.microsoft.com/kb/308538
On Unix, the utility is called "tail." However, you will have to find a replacement. Look here for Unix tools for Windows: http://unxutils.sourceforge.net/
From Microsoft: You must make a registry entry to be able to use a UNC path as the current directory.
WARNING: Using Registry Editor incorrectly can cause serious, system-wide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk.
Under the registry path:
HKEY_CURRENT_USER
Software
Microsoft
Command Processor
add the value DisableUNCCheck REG_DWORD and set the value to 0 x 1 (Hex).
Due to changes in render software architecture, a mechanism called JobObject which is used by the Qube! worker disrupts the internal code in common renderers such as 3dsmax and AfterEffects. The worker must be notified not to use the JobObject. To do this, specify the disable_windows_job_object flag when submitting your jobs
ex. qbsub --flags disable_windows_job_object MyRenderer scene.ma
For more information on windows job objects, please refer to the Microsoft Developer Article:
MSDN - Job Objects
http://msdn2.microsoft.com/EN-US/library/ms684161.aspx
Let's say you've got a server called "server," and on this server you keep a maya directory with projects in them. Let's call the project "default," a and the scenefile "myscene.mb."
So if you want to use UNC, this is what it might look like:
Project: servermayaprojectsdefault
Render: servermayaprojectsdefaultimages
Scene: servermayaprojectsdefaultscenesmyscene.mb
This is what you'd need to submit a job. Alas, on the OS X side, it won't make sense.
First, you need to mount the drive using NFS or SMB. I'll leave that as an exercise, but what you should end up with is something like this (the underlying structure is what matters, so you can have the mount be whatever):
Project: /Volumes/maya/projects/default
Render: /Volumes/maya/projects/default/images
Scene: /Volumes/maya/projects/default/scenes/myscene.mb
Now you need to create a symlink so the path to server will work (you'll need to do this a root or an Admin user on each Worker):
mkdir /server
ln -s /Volumes/maya /server/maya
So if you do an 'ls' of /server/maya, you should see projects.
One small change to how you submit, and you should be good to go:
Project: //server/maya/projects/default
Render: //server/maya/projects/default/images
Scene: //server/maya/projects/scenes/myscene.mb
The problem you describe is caused by a difference between the remote file services available to a logged in user (such as yourself) and those available to the host without anyone one logged in. In this particular case, when I refer to "logged in," I mean running a Finder desktop. Remote (and local) file systems accessed via the Finder are all mounted under /Volumes.
Qube runs as a daemon, and so it doesn't access the Finder at all. In general, any file you access remotely from the Finder is going to be inaccessible to any Worker running on the farm unless you take steps to make sure the Worker has those file systems already mounted.
You should consult your OS X administration documentation to learn more about how to mount your file servers either statically or dynamically so they are available to your Workers at render time. You will also want to set similar mounts on your client machines so that the paths to the files you access when you submit the job will be consistent with your Workers. Here's a link: http://www.bombich.com/mactips/automount.html
Use the Utilities/Directory Utility application.
Since netinfo is gone, you'll have to manage the automount maps manually. Here is an article on how to create an automount map specially for Samba shares:
http://www.stress-free.co.nz/automounting_samba_shares_in_leopard
Alternatively, you can use the /etc/fstab. Here's an article on how to do that:
http://www.macosxhints.com/article.php?story=20071028194033157
Normally, the Finder will automatically mount the AFP share if the "mount at login"box is checked. However, since the Worker doesn't launch a Finder, you will have to set the mount in a .login.
sudo scutil --set HostName name
This technique is referenced in the following TechNote: http://docs.info.apple.com/article.html?artnum=302044
If your job logs contain the following error message:
Can't locate JobType.pm in @INC (@INC contains: ...
download from our FTP site (pub/jobtypes) the JobTypeLib package.
Set the worker_template_path for the Worker to point to the directory containing the Job Types. Note, that on Windows, you must use UNC and the path separator is a forward slash "/".
worker_template_path = "//qubesupervisor.as.com/jobtypes"
qbconfigfile qbwrk.conf
Every change to the qbwrk.conf only requires a reconfiguration:
qbadmin worker --reconfig
while a change to the qb.conf requires a restart of the Worker.
qbadmin worker --config host
User mode: Set the user's PATH environment variable to point to the version of the scripting language you prefer
Proxy mode: the proxy user's PATH environment variable to point to the version of the scripting language you prefer
Look in the .cb file for the job.
The problem lies with the "code" in your callback. Callback code is literally a string interpreted and executed by the built-in interpreter selected by the "language" field. Since a job you submit is actually a data object submitted to the Supervisor, it doesn't share any code space with script that submitted it, and consequently you can't reference it.
If your socket script is a little too complicated to pack into a string without some serious debugging and maintenance grief, I'd recommend you save it out as a script and call it externally from your callback. (You can use the os.system() call).
