All-
I followed up on this on the Rush list and Greg Ercolano posted a very thorough
reply. I thought some of you might be interested in what he had to say. Sounds
like the best all around answer is a /usr/bin script which is similar to the
method Johannes was suggesting. Rush specific stuff at the beginning.
> [posted to rush.general]
>
> 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, [email protected]
> Seriss Corporation
> Rush Render Queue, http://seriss.com/rush/
> Tel: +1 626-576-0010 ext.23
> Fax: +1 626-576-0020
> Cel: +1 310-266-8906
On Dec 19, 2011, at 12:32 AM, Johannes Hezer wrote:
> I forgot to mention that you need to chmod +x yourfilename.command to make it
> executable...
Gary Jaeger // Core Studio
249 Princeton Avenue
Half Moon Bay, CA 94019
650 728 7060
http://corestudio.com
_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
