From: Gary Jaeger <gary@(email surpressed)>
Subject: nuke renders with central tools
   Date: Tue, 20 Dec 2011 01:58:08 -0500

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)

On 12/20/11 06:46, Gary Jaeger wrote:
>> Whatever you do, DON'T do the seemingly obvious thing
>> by making /usr/bin/nuke a symlink to the script on your NFS
>> server....
> 
> OK, but what we *could* do is make a Mac alias to that file
> and put it in the Dock, so freelancers and employees could
> simply go to the dock as usual and click or double click.
> I'll have to decide which route to go. 


	Yes, feel free to do whatever you want on the desktop
	to make that run.

	Though I'm not sure what you describe is the right way
	to make a script 'clickable'.

	I believe the right Mac voodoo for making a Mac app bundle
	for a script of any kind, in this case your /usr/bin/nuke script
	would be as follows:

mkdir -m 755 nuke.app
mkdir -m 755 nuke.app/Contents
mkdir -m 755 nuke.app/Contents/MacOS
mkdir -m 755 nuke.app/Contents/Resources
echo APPLnone > nuke.app/Contents/PkgInfo
cp /usr/local/rush/examples/Applications/submit-maya.app/Contents/Resources/icon.icns nuke.app/Contents/
cat /usr/local/rush/examples/Applications/submit-maya.app/Contents/Info.plist | sed 's/submit-maya/nuke/' > nuke.app/Contents/Info.plist
chmod 644 nuke.app/Contents/PkgInfo
chmod 644 nuke.app/Contents/icon.icns
chmod 644 nuke.app/Contents/Info.plist
cp /usr/bin/nuke nuke.app/Contents/MacOS/nuke
chmod 755 nuke.app/Contents/MacOS/nuke

	What this does is creates a Mac 'Bundle' around a copy of your
	bash script (or for that matter, any script; bash, csh, python, perl..)

	Once you have that 'nuke.app', you can move it to wherever you want,
	and make Mac aliases to it. There should be no terminal popping open.
	Just don't change the name of 'nuke.app' to something else; that breaks
	the app bundle. (the names of files in the dir and Info.plist would have
	to change accordingly)

	There are other ways to do this, but this is the way I use
	because it's 'scriptable'.. you can use this same technique
	to make a .app bundle out of any script (just be sure to
	change all instances of 'nuke' in the above to be the name
	of your script; if the name of the bundle is foo.app,
	then you have to make sure 'foo' is the name of the file
	in the MacOS dir, and 'foo' is in the Info.plist file, etc.)

	This is how Apple likes to make 'clickable' things.
	You can change the icon.icns file in the above to something
	more apropos for Nuke; you can probably use nuke's own
	icon.icns file for instance. (you may need to restart the finder
	to see the icon change).

	Anyway, sorry for the complexity of the above, but that's
	how you play ball on Macs to make executables 'clickable'.

On 12/20/11 09:01, Gary Jaeger wrote:
> Sorry for my lack of terminal fu, but when I do this method, I get a permission denied. but if I do sudo it works:
> 
> gfx11:~ gfx11$ nuke
> -bash: /usr/bin/nuke: Permission denied

	chmod 755 /usr/bin/nuke

-- 
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)

On 12/21/11 08:44, Gary Jaeger wrote:
> So i changed that, but it looks like there is another reference to an explicit path in the nuke submit (in our script  line 373-375):
> 
>     my $command = ($G::ismac ? "/Applications/Nuke6.3v5/Nuke6.3v5.app/Nuke6.3v5": "nuke") . " $opt{NukeFlags} ".
> "-x $opt{NukeScript} ".
> "$opt{ScriptArgs} $opt{sfrm},$opt{efrm}";
> 

	Yes, you have the OLD submit script there,
	so you need to change that first line to just 'nuke', eg:

my $command = "nuke $opt{NukeFlags} ".
              "-x $opt{NukeScript} ".
              "$opt{ScriptArgs} $opt{sfrm},$opt{efrm}";



-- 
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)