On 12/19/11 22:58, Gary Jaeger wrote:
> So we moved our plug-ins, gizmos scripts etc to a central server.
> We did this by setting our NUKE_PATH with an environment.plist in
> ~.MacOSX/environment.plist
Rush isn't going to look at that file, because only
MacOS can parse it.
For the rush perl render scripts to see the setting,
add this variable setting to the top of the submit-nuke.pl file
in with the 'MAC' settings, eg:
elsif ( $G::ismac )
{
### MAC
$ENV{PATH} = "/Applications/Nuke6.3v5/Nuke6.3v5.app:$ENV{PATH}"; # CHANGE THIS
$ENV{NUKECMD} = "Nuke6.3v5"; # CHANGE THIS
$ENV{NUKE_PATH} = "/Volumes/nuke_tools"; # ADD THIS
$ENV{OFX_PLUGIN_PATH} = "/Volumes/nuke_tools/OFX"; # ADD THIS
$ENV{RLM_LICENSE} = "5053\@corefileserver"; # ADD THIS
}
This will ensure that when the submit-nuke script runs,
it runs THAT version of nuke with THAT plugin path, etc.
and will for sure do what you want at render time,
.plist and /etc/profile and ~/.bashrc files be damned. ;)
> I also noticed that I got the same errors when I tried to ssh
> into a workstations and run a render.
I think there's a more centralized plist file that affects
all users, but Apple keeps moving stuff around each release
so I can never keep track of it. more recently they started
making these plist files *binary format* for some fool reason.
Don't get me started on how Apple has not only ignored the
wisdom of Unix philosophy: "use text files for everything",
"avoid binary files and databases", /etc/passwd, /etc/fstab..
but has often walked in the completely opposite direction:
use binary formatted xml, use databases and daemons to replace
/etc/passwd and /etc/fstab, etc.. (*shakes head*)
I think in the newer versions of OSX this might now be part
of the launchctl/launchd stuff now, not sure.
> On the nuke list it was suggested I try setting a .bash_profile
> instead of the .plist method. While this worked for the terminal
> (and presumably ssh though I forgot to try it) it still doesn't
> work for rush,
The submit-nuke script doesn't read .bashrc files
because it's a perl script.
The right place to make such changes for Rush is in the
submit-nuke script, so that (for instance) different
submit-nuke scripts can run different versions of nuke,
and/or different renders without getting crosstalk
between all the environment/PATH configs.
You could try having the perl script parse the plist
file, but that's kinda a nutty route to go.
Perhaps what you want to do to solve the issue for 'everyone'
is to make a nuke 'wrapper' script called /usr/bin/nuke
that sets the environment you want before running nuke.
Then you can have rush renders AND users just invoke 'nuke'.
A *simple* example:
#!/bin/sh
# Force these environment settings
export PATH="/Applications/Nuke6.3v5/Nuke6.3v5.app:$PATH"
export NUKE_PATH="/Volumes/nuke_tools"
export OFX_PLUGIN_PATH="/Volumes/nuke_tools/OFX"
export RLM_LICENSE="5053@corefileserver"
# Run nuke with args that were passed to this script
exec Nuke6.3v5 "$@" # <-- quotes important around $@
Then you can have both users and rush run 'nuke' instead,
so that everyone gets the same version of nuke, with plugins
and license variables set to what's needed.
You might want to add logic to that script to check to see
if these variables are already set, and optionally include
those settings in addition to your own, so that user's scripts
can add other plugin dirs besides the ones you supply.
Or, have the above script simply run a script on your server
so that you can centrally manage the variable settings, and not
have to update all /usr/bin/nuke scripts whenever you want to
make a small change to the script. eg:
#!/bin/sh
exec /Volumes/somewhere/nuke "$@" # <-- quotes important around $@
Whatever you do, DON'T do the seemingly obvious thing
by making /usr/bin/nuke a symlink to the script on your NFS
server. Symlinks to NFS servers in /usr/bin will cause
*all* logins to hang if the NFS server is acting up,
so you won't be able to login as root to fix things.
(whenever the root login walks the /usr/bin dir, it'll
hit that NFS link and freeze up)
> and if I want to also be able to launch nuke by double clicking
> the icon (which I do) it would mean keeping both .bash_profile
> AND environment.plist files. This seems wrong to me.
I can't advise, because IIRC the default profile for bash
in /etc/profile overwrites the PATH with a static string,
blowing away anything MacOS/plist files might have provided, eg:
$ more /etc/profile
# System-wide .profile for sh(1)
PATH="/bin:/sbin:/usr/bin:/usr/sbin" <-- BLOWS AWAY PREVIOUS PATH SETTINGS (!)
export PATH
[..]
It's because of that PATH line in /etc/profile that any
PATH settings in a .plist will be overridden whenever
a sh(1) login is started.
You could try jamming your settings in there, but then
you'll affect all users (including root), and again,
putting anything into root's path that includes NFS
or remote drives is a Bad Idea.
> Could this be something about users? i.e. rush running as something other than the current user?
There's many things at play here; ssh+sh is probably not
looking at .plist files all all, whereas a GUI environment
with terminal+sh(1) will (with the above exception for PATH)
Anyway, it gets messy fast.
If you want to reign in control over all this, you might
try the above 'nuke wrapper' technique, where you jam
a script in /usr/bin called 'nuke' that forces the variables
the way you want, and have everything (nuke, ssh, terminal, icons)
run that.
To get an icon to run a bash script involves making a .app
wrapper for it, fodder for a whole other message thread.
> Anyway, so I'm asking here. How do Mac facilities keep a central
> install of all their 3rd party tools and init.py etc for both
> workstations and renderfarms?
I'll let folks respond, but it's tricky if you try to use
global plist and bashrc files because these aren't always
going to be in effect; perl scripts don't read bashrc files,
bash/ssh doesn't read plists, and lord knows when these
plist files get sourced and by what.
My advice is to change as little global stuff as possible,
esp when it comes to centrally managed programs, so that
you don't get the whole OS addicted to your NFS servers.
--
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)
|