Similarly, I suppose I should have mentioned that you could also build such logic into the requirements of the package, or as a test in postflight to set the disabled flag on the agent (or move it to a “(Disabled)” folder or some such).On Nov 30, 2013, at 7:16 PM, Conor Schutzman < email@hidden> wrote: Why not just build the logic into the script the agent calls? Something like an exit call if a file is present. The agent would load all the time, to “turn it on” you would just delete the file.
Similarly, if there is some criteria for which computers should have this enabled or not, than just use that as the logic break. This could be as straight forward as a group the user is in, an IP address range, a file buried on the computer somewhere, etc. I don’t know enough about your spec, or the environment you’re building for to determine the best logic path. On Nov 30, 2013, at 6:19 PM, Allen Hancock - Watchman Monitoring < email@hidden> wrote:
We're preparing to release an option SupportMenu item, managed via /Library/LaunchAgent. It'll be enabled for a computer, or disabled, as our Subscriber chooses.
Im trying to figure … what's the less of all evils:
- Distributing the LaunchAgent as Disabled, then having the postflight set the Disabled key to False as required.
or
- omitting it from the BOM and having the postflight copy it into place as required.
It's not the worst abuse of the "package, don't write" guideline, but still, if I can avoid it, I'd like to.
Is there another option, outside of having two versions of the installer?
I suppose I could have the Menu Item look for a key, and launchctl unload itself , but then the app opens for a moment at every login.. seems worst of all these options….
Thanks in advance for any options I'm not seeing.
--
Allen Hancock - Watchman Monitoring - A consultant's best friend
+1-408-352-6145
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
|