Dock-maintainer: Defined

Recently I created a tool called dock-maintainer. This post goes over a couple things but mainly serves to explain why I created it and why I needed it instead of using other solutions. Traditionally this job (maintaining Dock configurations) has been handled in a multitude of ways. There have been many ways to do this. One can use configuration profiles, puppet/salt/chef/etc, outset with a script (a method I used until recently).

I found a few problems with the previous methods. With configuration profiles, I could not find a reliable way to deploy a Dock payload for a specified user. If you installed it via munki, this forced it for all users. I forked and changed Nick McSpadden’s tool, Outset Dock Profiler. This packaged the profile and created a script to load it via outset at login. The rewrite allowed for multiple profiles to be loaded via outset per user. This created another issue; upon login due to parental controls being loaded, it would prompt for a password to allow managed preferences changes. There was also issues that it created a singular install script that could affect other things in edge cases. This was purely due to my fork and the script part not being correctly modified to handle multiple profiles.

I have never used puppet, chef or anything like them, so that method was out due to lack of experience and time to learn it. From what had been explained and what I had found online out of the box didn’t allow the dock customization per user that I needed either. I eventually settled on using outset to deploy an initial Dock setup script using [dockutil]( This included a shortcut in the Dock to the /Applications folder for ease of use. I thought that this may be enough for most needs.

Due to our district using parental controls (soon to be changing, more on that soon), Chrome V58 stopped working with accounts using parental controls again. It would not launch correctly, if at all. I had many teachers come to me asking if I could add Firefox to the Docks on the student labs. I informed them to use Spotlight or the Applications folder shortcut already on the Dock. They stated it was difficult for the K-3 students to use those two and that it would really help to have it on the Dock. I lock the dock (our students being notorious for removing icons) using several managed preferences I found during my research into using Configuration profiles. This made it difficult for staff to add icons to dock without knowing how to use dockutil via terminal. What is nice is that the managed preferences don’t prevent dockutil from editing the plist as needed.

As I had already deployed dockutil to all the machines district wide, I knew that I needed to find a solution that to wrap dockutil and make it easier to setup and adjust docks without having to run a script on each machine for each change using ARD. This made me consider writing a tool to do this for me. I saw ygini had created a wrapper for MDMs and dockutil but that wasn’t in the same way I wanted. I settled and wrote dock-maintainer which allowed me to specify an account whose dock I wanted to modify, and host the files on a simple web server. It uses outset to handle the updater and script to maintain the dock, and uses dockutil to modify the dock itself. It also auto downloads the file based on the “Last Modified” header (huge tip from @elios on the macadmins slack for recommending this!), so only if it needs to by storing those dates in extended attributes of the file. If it detects any changes, it clears the entire dock to ensure a clean run of adding all the items back in. It also exits cleanly if it detects no changes and doesn’t mess the dock.

To take advantage of this tool, you will need to have a web server, a text editor, and have the short name of the account you wish to manage handy. I would recommend using a munki repo if you already have one as it is setup in the same fashion. I created a folder in my munki repo called docksetups. In this I created a plist for every user that I wish to manage (remember it’s the short name that is returned not the users full name), with no file extension. In each plist there must be two arrays, one called Apps and one called Others. In each array use string elements with the full path to the item you want in the dock. In the Others array you can use ~ to reference items in the HOME directory of that user. You will then need to set the preferences up on the machines you wish to manage. The domain is com.github.wardsparadox.dock-maintainer. There are two keys, ManagedUser and ServerURL. The ManagedUser key must be the same as the name of plist and the the short name as the user you wish to manage. The server URL key is the path to the server folder you setup i.e.:

I plan to add more logging features in the future. I hope this article makes the creation of yet another tool more understood.

Continue reading »

Hello-IT Setup and Deployment

I have recently been playing with a tool called Hello IT. It has been a wonderful tool in testing and I am getting excited to send it out here in our district. I believe it will help our staff be able to communicate to us effectively. Our current layout looks like this:

Continue reading »

I made a thing..well sorta

It seems that I have learned A LOT in recent months concerning Python. Again huge shout out to Nick McSpadden and froger for helping me get to where I am knowledge wise today. In between now and my last post, Nick helped me understand the dict datatype. Turns out python can use translate dict into the plist equivalents! The more you know eh?

The reason he was helping me on this was because I had an idea to take his PrinterGenerator tool and make it work in a different way. The input was roughly the same but the output was instead a printer profile that could be used outside of Munki or with Munki (v2.2 added the ability to install profiles). I had just taken some of the code and translated it to work with a template plist. Instead with his help, I was able to replace a lot of the code and change it into a more efficient tool for plists aka profiles.

I have since added the ability to open the ppd’s (which most are just gzip-ed ppd text files) and extract the model “NickName”, which Apple uses to determine the exact type of the machine. The code is on GitHub of course. I encourage you to look at it and suggest any fixes and features. Link: PrinterProfileGenerator

Continue reading »

TIL 03 -- Get Model Info via Python via Serial

A while back I learned about this website, Apple Config Code Lookup, when I was building my first info grab script for an inventory. I have since evolved that script into a full Info Viewer (inventory is done via MunkiReport-PHP). One thing I was always missing was the output from the Apple Config Code Lookup; since I am migrating most of my shell scripts to Python, I figured I might as well add it. I am also learning to modularize my scripts whenever possible as well. This has made things really easy to combine scripts or call them from others. I also wanted to be able to call this script if fed a serial as well. Here we go.

The old shell script I have is this:

curl -s$(system_profiler SPHardwareDataType | awk '/Serial/ {print $4}' | cut -c 9-) | sed 's|.*<configCode>\(.*\)</configCode>.*|\1|' | tr ',' '.'

To me..that’s very ugly and very foreign as I am still learning RegEx + sed

Continue reading »

TIL 02 - Multiple Inputs For One Argument

I use a tool called Outset Dock Profiler made by Nick McSpadden. It’s great and for user accounts where I only need to target one profile, it works great!

There has always been one thing about it that bothered me. If I had multiple profiles for a user, I couldn’t use this tool. Sure I could use it to build an initial package and modify the script. I’ve done it before but it can be easy for me (my brain is the size of a pea after all) to forget. I decided to learn about argparse and add the ability to use multiple profiles. Now not only does it support multiple profiles but it will also organize the profiles into the appropriate folders by username. This means that regardless of the number of profiles you need, as separating out the payload makes management of them easier, it will “install” them all as long as you have targeted the right user. Check it out on my github. I am thinking about pull-requesting it back to Nick, but I’m sure there are other issues that I created. Let me know what you think.

My fork of OutsetDockProfiler

Continue reading »