post install scripts and the Dock

[bryanzak]

I've been looking at https://code.google.com/p/munki/wiki/PreAndPostinstallScripts

Here's the situation, I'm thinking about the Dock. Believe it or not, but a lot of my staff do not understand how to add an app to the Dock. So if I have an optional install for, say, Google Earth, they very likely can install it, but then won't know how to put it on the Dock. Most of the time if they do find the app in /Applications they just drag it to the Desktop. And we know how fun that was pre-ML.

So for some apps, I want to automatically add the app to the dock of all user accounts. I'll use dockutil.py for this. In some cases maybe a teacher doesn't actually want it in the Dock, but that'll be the minority of cases if they've just elected to install an optional app.

So I was thinking of a couple of ways to approach this. One was another optional package (based on nopkg? or just a payload from .pkg?), Dock: Add Google Earth, but I'm not sure Munki supports optional installs that have dependencies on other optional installs. (Have only glossed over that documentation so far.) And I'm not sure I really want to clutter up the list of optional installs this way. Seems clunky.

So I think the way to go is a postinstall script that just uses dockutil.py to add app the dock of all users. Just wondering if anyone else does anything like this and if so, is this how you handle it? 

The nice thing about this method is I can use postuninstall_script to also remove the app from the Dock if they later choose to remove the app via MSU.

Thoughts?

Bryan

[bryanzak]

For what it's worth, the postinstall_script and postuninstall_script worked perfectly.

I just went into my munki_repo > pkgsinfo > apps > google  and duplicated the existing "GoogleEarth-7.1.1.1871" and named it "GoogleEarthInDock-7.1.1.1871"

Then I edited that file to change the name to GoogleEarthInDock (and changed the display name and description to communicate to the user that the Dock would be updated).

And then added that package to my test staff manifest. This allows me to have an optional install for staff that will install Google Earth and add it to the Dock, but I still can reference a package name of just "GoogleEarth" in my test student manifest to install only the app without any Dock manipulation. (Say a Lab manifest where it's a required item, vs it being optional on a staff laptop).

Tremendous flexibility and so easy. So great. Thanks Greg!

Bryan

[Samuel Keeley]

If you really want to use Munki for configuration management like this (it really isn’t meant to be, look into Local MCX, Profiles, and Puppet), instead of duplicating pkginfos, you should make a second one that only adds it to the Dock and requires GoogleEarth to be installed.  This way, when an update for Google Earth comes out, you do not need to duplicate everything over and over.

-sam

--
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[MiqViq]

You may find this tool useful when adding items to Dock:

https://github.com/kcrawford/dockutil


- MiqViq

[bryanzak]

For our managed computers, like student computers, we do use MCX to manage the Dock.

But for staff, like I said, believe it or not, most of them don't actually know how to put something in the Dock. So this is purely a convenience for them.

MiqViq, we do indeed use DockUtil - wonderful little tool.

Bryan

[Gregory Neagle]

On Oct 14, 2013, at 10:02 AM, bryanzak <brya...@mac.com> wrote:

For our managed computers, like student computers, we do use MCX to manage the Dock.

But for staff, like I said, believe it or not, most of them don't actually know how to put something in the Dock. So this is purely a convenience for them.

Though perhaps training would be an even more empowering approach!

[bryanzak]

Preaching to the choir you are :p

Until I took this job, I never really appreciated just how complicated, confusing and scary computers can be to some (many? most?) people. No amount of training will change that. Though a significant part of that is the person, technology itself is not blameless (nor is the institution and its commitment to professional development of teacher's technical skills). But this is more than a bit offtopic ;)

[Lee Ramsay]

I also have this problem, only user empowerment really isn't an option. We have many mac users, most of whom know barely enough to get by, and I have limited time to approach them all and ask if there's anything they need.

I just typed out all the "systematic" options that I can think of, and then thought of reasons why they wouldn't work. So I'm just typing this to say I have no idea what the solution is, whilst I slump in my chair, defeated.

Lee

[Erik]

Documentation=Empowerment.

[bryanzak]

I'm sorry, you do realize that most people don't read anymore right? Apparently if it doesn't fit into a 140 character tweet, they don't read it.

Sure there are other forms of documentation, but one of the things we're often faced with is something as simple as..."you want me to learn|read|watch|whatever on my own time? I don't think so."

I've had teachers tell me that they don't read email at all - if there's something important they need to know, someone will tell them face-to-face.

I have no idea how to help people like that. :(

Bryan

On Monday, October 14, 2013 10:12:54 PM UTC-5, Erik wrote:

Documentation=Empowerment.

[Josh Malone]

<superhero>

This sounds like a job for:

"Simple Finder"!!!!!!!!!!!

</superhero>