Startup error when running eggplant remotely

Eggplant Functional
1

Hi folks. I guess you have already told someone here at my work how to get around this problem, but we’ve lost the info. Sorry. I’ve seen this with both Eggplant 2.22 and Eggplant 3.01 on Mac OSX 10.4.7.

When trying to run Eggplant scripts remotely across the network. I get this message:
2006-07-26 12:26:00.057 runscript[2706] Successfully Loaded XModule /Applications/Eggplant.app/Contents/Frameworks/SenseTalkEngine.framework/Resources/STColor.xmodule
2006-07-26 12:26:00.215 runscript[2706] CFLog (0): CFMessagePort: bootstrap_register(): failed 1100 (0x44c), port = 0x2303, name = ‘NSApplication-MainThread-a92-6999430582501#’
See /usr/include/servers/bootstrap_defs.h for the error codes.
2006-07-26 12:26:00.220 runscript[2706] CFLog (99): CFMessagePortCreateLocal(): failed to name Mach port (NSApplication-MainThread-a92-6999430582501#)
2006-07-26 12:26:00.223 runscript[2706] *** Assertion failure in -[EggplantApplication _createWakeupPort], AppKit.subproj/NSApplication.m:3578
2006-07-26 12:26:00.224 runscript[2706] CFMessagePortCreateLocal returned NULL port
2006-07-26 12:26:00.268 runscript[2706] CFLog (0): CFMessagePort: bootstrap_register(): failed 1100 (0x44c), port = 0x2703, name = ‘Processes-0.7602177’
See /usr/include/servers/bootstrap_defs.h for the error codes.
2006-07-26 12:26:00.273 runscript[2706] CFLog (99): CFMessagePortCreateLocal(): failed to name Mach port (Processes-0.7602177)
CFMessagePortCreateLocal failed (name = Processes-0.7602177 error = 0)

Our system is a little complex, but a synopsis of my command might be:
ExecuteRemotely host/myMac /Applications/Eggplant.app/runscript

If I change my command to:
ExecuteRemotely host/myMac sudo /usr/libexec/StartupItemContext /Applications/Eggplant.app/runscript

then it works.

I mentioned this to my co-workers and they said “Oh, yeah”. And they have vague memories of somebody from Redstone Software helping them set up something so that this StartupItemContext was embedded somewhere.

I have managed to put the above working command into a shell script on the Mac host and it works fine, but apparently it is doable without a script and that’s what I’m asking for.

Thanks for your help!
-edj

2

The problem is that you can’t run GUI process (like Eggplant) on Mac OS X outside of the current user’s execution context. Frankly, your solution of using the StartupItemContext is a pretty good one.

The previous solution that we had recommended involved setting the setuid of the Eggplant executable.

For that solution what you need to do is call a file OWNED by the right user with the setuid bit set. As of Mac OS 10.3.9 and above this file CAN NOT BE a shell script. But we can do it to the actual Eggplant executable (with some side effects that you need to be aware of).

So what you need to do is change the owner of the Eggplant executable to either be root:wheel or the “console user” (the logged in person). In scenarios where a single user is working on the machine this probably isn’t a factor. In other cases, you might want to make copies of Eggplant that you can do this to, without modifying the regular one in /Applications

You can do this to it in a terminal (must be root or sudo):

chown root:wheel /Applications/Eggplant.app/Contents/MacOS/Eggplant
chmod +s /Applications/Eggplant.app/Contents/MacOS/Eggplant

Unfortunately, now whenever this Eggplant is run (from runscript or even double clicked in the Finder) it will be executing as that file owner. This has two side effects:

First, Eggplant will load the preferences for THIS user, so if you’ve written all your scripts under the “me” account and changed some preferences those won’t be there if you run as the owner “root”. You can copy the files in your home Library/Preferences/com.redstonesoftware.*.plist to the new users home directory.

Second, file creation and other commands might have side effects. So for example this script:
create file “/tmp/file555”
Would create a file OWNED by root (or the user you assigned) – this potentially could lead to greater control than you would normally want a script to have and might result in files unreadable by anyone else.