From: Greg Ercolano <erco@(email surpressed)>
Subject: Snow Leopard -- Fixes for Rush 102.42a9b and older
   Date: Wed, 09 Sep 2009 18:45:07 -0400

RUSH + SNOW LEOPARD

	There will be a new maintenance release of Rush that addresses
	Snow Leopard: Rush 102.42a9c, which will beta in about a week.
	(Still doing internal testing)

	It will have other things as well; watch this space for details.

* * *

	Meanwhile, those of you running Rush 102.42a9b or older,
	I've put together a 'fix script' for you which fixes your
	existing Rush OSX installations to run on Snow Leopard:
	http://www.seriss.com/rush/releases/patches/rush-snow-leopard-fix-scripts--for-102-42a9b-and-older.tar.gz

	(Use your downloads login/password to install it.
	If you forgot your downloads password, please contact me.)

	See the README file for details.
	It's very simple to use; just run the appropriate script as root,
	and it will apply the fixes automagically. Can be run on older OSX
	releases as well, so that you can then just copy the mac installs
	to snow leopard machines.

	You do /not/ need to stop the queue to run these scripts;
	they can be run while renders are running and guis are open.

	The fix script repairs these things:

		o The rush/etc/bin/install.sh script

		o The rush/etc/S99rush boot script (small cosmetic fixes.. nothing critical)

		o The wrapper binaries in examples/Applications/submit-*.app/Contents/MacOS
		  which handle bringing up the submit scripts from the Finder.
		  This is somewhat important; it turns out these binaries were PPC
		  and I didn't know it. The fix installs universal bins for these,
		  since Snow Leopard no longer runs PPC binaries by default.
	
	So if you're running any release of Rush 102.42a8 thru 102.42a9b,
	this fix script should help you for running Rush on Snow Leopard.

	These fixes will be in all Rush releases 102.42a9c and up,
	so if you upgrade to that release, you won't need to run the fix script.

	If you have any questions, let me know.

Hi Greg

Will the 102.42a9c maintenance release address this?

Dylan Penhale
Fuel VFX


On 10/09/2009, at 8:45 AM, Greg Ercolano wrote:

[posted to rush.general]

RUSH + SNOW LEOPARD

	There will be a new maintenance release of Rush that addresses
	Snow Leopard: Rush 102.42a9c, which will beta in about a week.
	(Still doing internal testing)

	It will have other things as well; watch this space for details.

* * *

	If you have any questions, let me know.

Dylan Penhale wrote:
> We are experiencing slow performance issuing a rush -lah on snow  
> leopard.

> Will the 102.42a9c maintenance release address this?

	I haven't seen a slowness problem on Snow Leopard
	with 'rush -lah'.

	Slowness with 'rush -lah' usually means hostname lookups
	aren't working correctly because it does a hostname<->IP
	lookup for each hostname in the rush/etc/hosts file, in
	order to show the IP addresses for each host.

	A very slow output of 'rush -lah' usually means the primary
	DNS server is being unresponsive.
	
	Check your DNS settings, to make sure the primary DNS server
	is responsive, and the search domain is set to your internal
	domain.

	Also; are there any hosts coming up with ???'s for IP's?
	If so, that's surely the cause, as it means DNS is failing
	the lookup for those hosts, and that can slow that report
	down quite a bit.

Once we removed .local from the search suffix all is well again.

Thanks


On 25/09/2009, at 5:10 PM, Greg Ercolano wrote:

[posted to rush.general]

Dylan Penhale wrote:

We are experiencing slow performance issuing a rush -lah on snow
leopard.

Will the 102.42a9c maintenance release address this?

	I haven't seen a slowness problem on Snow Leopard
	with 'rush -lah'.

	Slowness with 'rush -lah' usually means hostname lookups
	aren't working correctly because it does a hostname<->IP
	lookup for each hostname in the rush/etc/hosts file, in
	order to show the IP addresses for each host.

	A very slow output of 'rush -lah' usually means the primary
	DNS server is being unresponsive.
	
	Check your DNS settings, to make sure the primary DNS server
	is responsive, and the search domain is set to your internal
	domain.

	Also; are there any hosts coming up with ???'s for IP's?
	If so, that's surely the cause, as it means DNS is failing
	the lookup for those hosts, and that can slow that report
	down quite a bit.

> Once we removed .local from the search suffix all is well again.

	Sounds like you fixed it.

	Yes, I recommend avoiding the .local domain name suffix
	because that enables all that ZeroConf/Bonjours broadcast-based
	discovery stuff, including multicast DNS, which creates unreliable
	behavior that messes up network stability. ie:
	http://en.wikipedia.org/wiki/Zeroconf

	If you need zeroconf based stuff on your machines also running rush,
	you may be able to specify it without causing trouble IF you specify
	your internal domain first, and then .local after it. This way (maybe)
	regular DNS will be interrogated first, and then falls back to Bonjours
	only if that fails.

Dylan Penhale wrote:
> Yes I thought DNS at first but we thought we had it sorted as we where  
> using the same settings as other non snow leopard machines. I assume  
> DNS is used to reverse lookup the IP addresses of the hostnames but  
> that this isn't cached anywhere.

	Both OSX and Windows traditionally have DNS caching turned on
	as a default.

	"lookupd' used to be responsible for hostname caching in OSX,
	but now I think it's DirectoryServices(8) since lookupd was dropped.

	According to the docs, dscacheutil can be used to display the
	DNS cache (supposedly), ie. as root:

		dscacheutil -cachedump -entries Host

	However, when I do this on my snow leopard box, I get zippo.
	Even after I do things that /should/ trigger DNS cache hits,
	like pinging hosts by name, or running 'rush -lah'.

	Because of this empty output, I'm not entirely sure it IS
	caching namelookups by default in Snow Leopard. Just a casual
	observation though.. I haven't dug into SL deeply yet.

> It turns out that snow leopard treats .local in a different way to  
> previous apple operating systems, as far as I can tell.

	The bad behavior with .local has always been in there,
	it just creeps in whenever you start with a fresh machine,
	and forget to configure all the DNS stuff statically.

	When Bonjours creeps in, you can get flakey name lookups due
	to the broadcast based discovery stuff. I refer to this
	in the prerequisite docs as something to avoid:
	http://www.seriss.com/rush-current/rush/rush-admin-faq.html#ADMINFAQ-PREREQ

	(Search for hostname.local in that text)

> Usually this  
> wouldn't be a problem but as some of our domain uses .local this  
> appears to clash with the apple .local. which I believe is used for  
> zeroconf type broadcast traffic.

	Yes, correct.


	
-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)