Deja Vu’ and Dock Management

Last year I used Apple’s Profile Manager to manage the OSX dock on our student notebooks. The setup was mind numbingly easy, but during pre deployment checks we ran into some issues.

The first issue being consistency. I expect that what I have set in my configuration profile to be 100% what it was configured to have. What I found were some notebooks would get the dock I configured, others would get additional icons, others would be missing icons or even worse it wouldn’t apply at all. The most common issue though was not applying or it would attempt to apply, but be a generic default dock.

Second issue was trusty ol’ keychain. The crutch if you will of the OSX operating system. It handily stores passwords, certs, and other trivial bits for later retrieval by a human or the OS itself. If a dock didn’t apply generally what followed was a flurry of login or configuration profile keychain password prompts. Clicking cancel only brings up more and to a normal student or staff member that wouldn’t be obvious so keychain password prompts are often treated as something unexpected and horrible happened, fix it Mr. Computer Guy.

This year(14-15 school year)I said no way jose and used a nifty little tool called dockutil. Built by another Mac Admin it allows scripted dock setups that can applied by manual shell script execution or via LaunchAgent(which in turn calls a shell script). The dock can be modified in the future by pushing out script modifications so it’s easy peasy to configure. Much to my surprise both bugs I experienced last year returned. During image creation I create many packages one of which I aptly named ToolBox. This places configuration profiles locally on the notebooks drive and applies then, it installs dockutil and it also applies a preset dock from a shell script that’s called at every single login by a LaunchAgent. This shell script I thought was buttoned down after spot checks that ran into the hundreds(seriously, I imaged a machine nearly a hundred times to correct one problem). After doing our pre-deployment spot checks Friday I found both the dock application not consistent from client to client, but also the keychain password prompts appeared on every single client. My shell script and dockutil itself were at fault for both issues. Fixing the keychain password prompt was more important since subsequent logins on the same machine netted the dock I was shooting for. The fix in my case was to slow the shell script and dockutil down so that other processes during login could occur before it did it’s thing. For those not familiar with shell scripting to slow execution of a command or even the entire script one can place a sleep before it. Issuing say sleep 3 will cause whatever is before sleep 3 to not execute for a three count(seconds).

After modifying and redeploying my ToolBox package (which included the fixed shell script) I found an unexpected surprise in that not only was the keychain prompt gone, but during a first login the dock would fully apply consistently across the board. Two thumbs way up for dockutil. Now I don’t need to load down a server with client software just to modify a dock unlike Profile Manager which forces you to do just that. Kudos to Kyle Crawford.