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](https://github.com/kcrawford/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.: http://munki.example.com/munki_repo/docksetups.

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