Stephane, thank you as always. Yes, our installer tries to sync up right away with the current choice, but of course that's not always feasible, and even the sync with the server could be disabled if security needs required. I had not seen/focused on PathState. Our agent is entirely contained in a specific folder, so I have no issue using that to store the optional trigger file. Anyone looking to remove our agent would be removing the parent folder in any case. This also makes my installer workflow much, much simpler, and simpler is better.

PathState <dictionary of booleans> Each key in this dictionary is a file-system path. If the value of the key is true, then the job will be kept alive as long as the path exists. If false, the job will be kept alive in the inverse condition. The intent of this feature is that two or more jobs may create semaphores in the file-system namespace.

On Dec 2, 2013, at 10:31 AM, Stephane Sudre <dev.iceberg@gmail.com> wrote:

A potential minor issue I see is if your custom installer includes the default choice and the subscriber's choice changed. When a clean re-install is needed, you will still get the default choice before the sync is made with the server (every hour from what I get).

Installing the file and changing it through the postinstallation script/hourly agent looks OK. Ideally, the postinstallation script should not rely on a fixed value set for the custom installer but check the server. Maybe this is already what you're doing.

Another solution is to have the agent be launched when a file exists (it's a case supported by launchd).

That way you can:

- install the agent .plist file as is. - create the trigger file if needed during the postinstallation script.

- launchctl stop the agent, remove the trigger file and launchctl start the agent if the server requires the menu to be removed. - putting it back just requires to create the trigger file again.

My $0.02

On Mon, Dec 2, 2013 at 1:40 PM, Allen Hancock - Watchman Monitoring <watchman@watchmanmonitoring.com> wrote:

...

Subscribers have a default choice which can be reflected in our custom installer.

Then there is a toggle in their private server interface which can toggle the menu for a specific group of machines. Our agent checks periodically to see if the menu should remain visible or hide itself.

I'm looking for a way to ensure that if hidden, the menu item is truly quit.

I believe I have this worked out, however am still interested in hearing what you have to say on the matter.

Thank you as always. -Allen Hancock

On Dec 2, 2013, at 4:12 AM, Stephane Sudre <dev.iceberg@gmail.com> wrote:

...

When and how are the subscribers supposed to choose whether the menu item should be visible?

On Sun, Dec 1, 2013 at 3:19 AM, Allen Hancock - Watchman Monitoring <watchman@watchmanmonitoring.com> 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 Case Studies at http://www.watchmanmonitoring.com/case-studies _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.... This email sent to site_archiver@lists.apple.com