search

chilcote / outset

Automatically process packages, profiles, and scripts during boot, login, or on demand.
572 stars 58 forks source link

On demand Outset option #14

Closed erikng closed 8 years ago

erikng commented 9 years ago

One of Outset's "limitations" are login-every and login-once items are ran only when a user logs in.

I'm proposing a change where you could send a dotfile to /Users/Shared which would then trigger Outset to immediately run.

/usr/bin/touch /Users/Shared/.com.outset.loginall /usr/bin/touch /Users/Shared/.com.outset.loginevery /usr/bin/touch /Users/Shared/.com.outset.loginonce

This would allow us to ensure user's are receiving a change we want them to see without a logout/reboot.

There might be other ways to skin this cat, but my main idea for this is to chain munki, yo and outset together.

  1. Munki no-pkg (or pkg) that creates a script into login-once with a postinstall triggering Outset
  2. Munki --auto runs
  3. Outset gets triggered which then triggers Yo to send a notification under the current user's session.
  4. Example notification "Emergency Flash patch has now been installed".
chilcote commented 9 years ago

I like it in theory, but could the package postinstall simply run outset --login ? That's all the launchagent does. Or is it the "running under the current user context" the part that you are looking for?

gregneagle commented 9 years ago

I'm very confused by this. Login items run in the context of the user logging in. You can't do that when bootstrapping. What are you trying to accomplish here?

erikng commented 9 years ago

Running under the user context is what I'm after.

On Jun 24, 2015, at 8:10 PM, Joseph Chilcote notifications@github.com wrote:

I like it in theory, but could the package postinstall simply run outset --login ? That's all the launchagent does. Or is it the "running under the current user context" the part that you are looking for?

— Reply to this email directly or view it on GitHub.

chilcote commented 9 years ago

Bootstrapping is the wrong word here. I think on-demand or something is better, and it should be decoupled from any login-* folders. I'll let it sink in for a bit and see if I can come up with something.

chilcote commented 9 years ago

Can you try the ondemand branch? Put the new launchagent in /Library/LaunchAgents and add a new directory at /usr/local/outset/on-demand. Drop scripts in there and touch /private/tmp/.com.github.outset.ondemand.launchd. The scripts should run in the user context and behave similarly to the "login-once" scripts, i.e. they will update the plist and not run again.

I'm still not sold on the utility of this.... feedback/ideas welcome.

erikng commented 9 years ago

I won't be trying this until next Monday but not sold on the approach. If I have a script that I want to run for current users and new users, putting it in on demand isn't appropriate.

I'll play with it using my original concept and go from there.

Sent from my iPhone

On Jul 2, 2015, at 4:02 PM, Joseph Chilcote notifications@github.com wrote:

Can you try the ondemand branch? Put the new launchagent in /Library/LaunchAgents and add a new directory at /usr/local/outset/on-demand. Drop scripts in there and touch /private/tmp/.com.github.outset.ondemand.launchd. The scripts should run in the user context and behave similarly to the "login-once" scripts, i.e. they will update the plist and not run again.

I'm still not sold on the utility of this.... feedback/ideas welcome.

— Reply to this email directly or view it on GitHub.

chilcote commented 9 years ago

I guess my brain just isn't processing this properly... It sounds like you just want a way to call outset --login arbitrarily, and you don't necessarily need any new functionality.... Is that a fair assumption?

What if touching that file called outset --login similarly to how a login triggers it? Would that suffice?

I don't really understand why there would be different triggers for "loginall" (not even sure what that means), "loginonce", "loginevery", since those would also need to go in the respective existing directories for future/other users.

I'm probably missing something very simple here. I tend to do that.

erikng commented 9 years ago

That's actually perfect, however I do see a use for what you made.

I don't think I explained it first correctly either.

So let's simplify and re explain. What I asked for: Arbitrary method to trigger --login in the current user session in an on demand method.

What might be cool/not asked for (that I think you did):

  1. On demand scripts that delete when done and can be triggered.

Sent from my iPhone

On Jul 2, 2015, at 4:30 PM, Joseph Chilcote notifications@github.com wrote:

I guess my brain just isn't processing this properly... It sounds like you just want a way to call outset --login arbitrarily, and you don't necessarily need any new functionality.... Is that a fair assumption?

What if touching that file called outset --login similarly to how a login triggers it? Would that suffice?

I don't really understand why there would be different triggers for "loginall" (not even sure what that means), "loginonce", "loginevery", since those would also need to go in the respective existing directories for future/other users.

I'm probably missing something very simple here. I tend to do that.

— Reply to this email directly or view it on GitHub.

chilcote commented 9 years ago

Thanks for clarifying.

The method I came up with doesn't delete anything (the directories are still owned by root so the behavior is similar to the login-* scripts, i.e. uses the same plist to check if a pathname has been run before). Probably not ideal.

Other things we need to iron out:

  1. How do we handle situations when multiple users are logged in, via fast user switching.
  2. How do we handle situations when the Mac is at the login screen (no user logged in).
  3. Do we really want all scripts in login-every to run each time this is triggered as an on-demand action? This could potentially be user-hostile.

One way around these might be to put in enough checking to make sure the 'on-demand' script(s) will only run in the context of the user currently logged in to the GUI, if a user is logged in, and leave it up to the admin whether to also add the script to login-once or login-every for future/additional logins.

That sounds like a lot of effort. I wonder if there's a cleaner way to send down on demand scripts to run in the user context? Maybe outset is not the appropriate place for this? Maybe the answer is postinstall scripts using bsexec?

gregneagle commented 9 years ago

The answer is never postinstall scripts using bsexec. That just makes my skin crawl.

chilcote commented 9 years ago

Ha ha, fair enough. There's an answer somewhere though.

Here's something that will cause you to lose sleep: https://jamfnation.jamfsoftware.com/search.html?q=bsexec&sort=most_recent

erikng commented 9 years ago

Alright, so after playing with this some more, the "requirements" have changed a little bit. :)

  1. Arbitrary method to trigger --login. This will allow newly installed user scripts to immediately run.
  2. Ondemand scripts perhaps should be triggered as root and delete when done (so not --login). Here's my initial reasoning as to why: If you touch /private/tmp/.com.github.outset.ondemand.launchd via a package or munki, it is owned by root. If the user isn't an admin or isn't running elevated commands, the file cannot be removed. This leads to unexpected results (pre-installing on demand scripts for later use).

I'm beginning to agree that Outset may not be the appropriate place for item 2, but we will have similar issues attempting to solve this for item 1. Perhaps touching the file and chmod to 777 (sounds ugly)?

PS. I fixed the makefile on my ondemand branch.

erikng commented 9 years ago

I edited my original post, so your e-mails may not reflect all of my notes.

gregneagle commented 9 years ago

"Arbitrary method to trigger --login. This will allow newly installed user scripts to immediately run."

With the possibly unwanted effect of re-running scripts that already ran at login.

erikng commented 9 years ago

Sure. In my case, I know the outcome. Hopefully (surely!) the admin knows the outcome and has tested prior to production.

Most of my scripts are login-once and the login-every are basically login-once with my own time stamp logic (both of you have seen an example of that). I have a few exceptions to that rule, but I have no worries about them running again as they are "self healing" types of scripts.

On Jul 6, 2015, at 11:00 PM, Greg Neagle notifications@github.com wrote:

"Arbitrary method to trigger --login. This will allow newly installed user scripts to immediately run."

With the possibly unwanted effect of re-running scripts that already ran at login.

— Reply to this email directly or view it on GitHub.

chilcote commented 9 years ago

I've done some playing around with the on-demand plist. Going by the three items I listed above:

  1. Multiple users logged in via FUS. The way it works in the current ondemand branch is that each logged in use will run the script (with the non-gui logged-in user at a disadvantage if the admin is pushing something like Yo app).
  2. When the mac is at the login screen, nothing will happen. But if/when a user logs in before reboot (i.e. before the /private/tmp directory gets cleaned), the script will trigger. This can be annoying if the admin has also copied the script(s) to login-once. They will run twice!
  3. Triggering every login-once and login-every. I think we can ignore this concern, since the proposed behavior separates on-demand from these contexts.

I'm still not sold on this idea. I like, in theory, the option to send an on-demand script that will run in the context of the current user, but I worry about numbers 1 and 2 above. There has to be a better way.

erikng commented 9 years ago

I have a (possibly horrible) idea to test out. Hopefully sometime today I can try it.

chilcote commented 9 years ago

Still working through this. The on-demand stuff in there now is in flux. I kept it because I was getting PRs against that branch and I'm to dumb to use git more effectively. Ignore for the time being.

chilcote commented 9 years ago

Erik, can you try the latest push to master. on-demand rules as they currently rest:

chilcote commented 9 years ago

Oh, and you trigger on-demand by touching /private/tmp/.com.github.outset.ondemand.launchd, perhaps via a postinstall.

chilcote commented 8 years ago

Can you test the pre-release 1.0.3 please, and let me know if the on-demand stuff work?

https://github.com/chilcote/outset/releases/tag/v1.0.3

erikng commented 8 years ago

I'll test tomorrow. Given the massive change log I will need to move things around.

Sent from my iPad

On Jan 3, 2016, at 5:10 PM, Joseph Chilcote notifications@github.com wrote:

Can you test the pre-release 1.0.3 please, and let me know if the on-demand stuff work?

https://github.com/chilcote/outset/releases/tag/v1.0.3

— Reply to this email directly or view it on GitHub.

erikng commented 8 years ago

This addresses the original issue and also works for arbitrarily running --login.

https://github.com/chilcote/outset/commit/af50ed8fc7b91aa36ba1e6324e24410f9bfe40eb