New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sunsetting DEPNotify integration #41

erikng opened this Issue Oct 31, 2018 · 4 comments


None yet
5 participants
Copy link

erikng commented Oct 31, 2018

I'd like to sunset DEPNotify integration for a few reasons:

  1. There are a few edge cases
  2. Not every command is supported
  3. I had to make assumptions that an admin may disagree with
  4. There are now multiple flavors of "DEPNotify" that I have no intention of supporting.

If you object with this, please comment and we can discuss. I will leave this open for a week or two and then pull the integration, unless I am convinced otherwise.

In place will be some example scripts that an admin can use and recommended approaches for the JSON.

@erikng erikng added the question label Oct 31, 2018


This comment has been minimized.

Copy link

flammable commented Oct 31, 2018

Those reasons sound pretty solid to me. I'm pretty sure I hit a few of those edge cases while building out our workflows.

With DEPNotify being integrated with NoMAD Login, IAs probably would have needed significant code changes to support that, too. I agree that it's best to separate out the DEPNotify support, since IAs is flexible enough to allow me to build out what I need on my own (that said, I appreciate the example code 😉).

Thanks, Erik.


This comment has been minimized.

Copy link

clburlison commented Nov 1, 2018


This comment has been minimized.

Copy link

vmiller commented Nov 1, 2018

I think this sounds reasonable. Reducing complexity should improve maintainability overall.


This comment has been minimized.

Copy link

MichalMMac commented Feb 7, 2019

Just yesterday I was thinking through following problem.

  • There is script doing its stuff sequentially (f.e. installing packages).
  • There is MDM pushing apps.
    BUT macOS installer installs one package at the time.
    -> This gives us race condition between package installs by and those form MDM.

As a result some package from setupassistant phase may not be yet installed when user logs in. Launch of DEPnotify by is therefore posponed until it gets to userland phase. This is not good when I need fullscreen DEPNotify just righ after first console log in.

This thread actually gave me right idea. I need my own LaunchAgents which if going to be part of bootstrap package along with DEPNotify.

Ripping out the code responsible for launching DEPNotify is OK imo. But it still may be good to retain capability to easily write status updates to DEPNotify control file about what installapplications is currently doing. Alternatively we would have to simple shell script for that after every package install.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment