Alan Siu

Use docklib to manage macOS docks

I have a few posts about using dockutil to manage the macOS dock. dockutil is still a valid and working project, but I'm starting to migrate my scripts to docklib instead, which doesn't seem to require workarounds like this one.

The installation instructions for docklib say you can put the docklib.py file in the same directory as the scripts that invoke it or you can put it "in your Python path." I'd recommend just grabbing the docklib .pkg from the releases page or using the AutoPkg docklib recipes to download it. The .pkg puts docklib.py in /Library/Python/2.7/site-packages/docklib.py.

docklib can be used in an Outset login-once or login-every script. There is no need to explicitly put in a delay to wait for the initial dock to appear before running your script. There is also no need, if you're specifying a dock (rather than modifying an existing one) to remove the default applications Apple puts on the dock. If you're specifying a dock, just say what you want to add. Use this suggested template.

What I learned upgrading from MunkiReport 2 to MunkiReport 3

The setup for the old (version 2) MunkiReport was fairly simple. You essentially just downloaded the folder to your web server.

The setup for the new (version 3) MunkiReport has a bit more nuance to it. I had a lot of trouble setting it up, but thanks to some help from other Mac admins (special thanks to Rick Heil for getting me over the finish line), I was able to finally get it up and running.

Here are a few issues I ran into. Maybe if you're running into the same or similar issues, this list may help:

Ubuntu 16.04 doesn't have PHP 7.0.27 or higher, which the new version of MunkiReport requires, so I had to add it in with the appropriate PPA.
On a related note, once you add that PPA to your sources.list in Ubuntu, you get a whole ton of PHP versions available via apt: 7.0, 7.1, 7.2. It's best to make sure you have only version of PHP installed and remove all the rest. I'd recommend 7.2 at this point.
It's a good idea to start with the sqlite database just to eliminate MySQL connection issues as a possibility. That said, since the main MunkiReport 3 files don't live in the public-facing part of the web server, be especially mindful of this part of the wiki instructions: when using SQLite as backend (which is the default), check if the directory /app/db/ is writeable by the webserver.
If you're using AD or SAML authentication, move it up in the composer.json file from suggest to require and get rid of the description after the version number. For example, "adldap2/adldap2": "^8.0 Required for AD authentication" should change to "adldap2/adldap2": "^8.0" after being moved.
If you're running the composer command and get a [RuntimeException] The "--no-suggest" option does not exist. message, just ditch the --no-suggest part of the command.

Backing up database data from a Crypt server

This is really just a step-by-step version of what's available in the July 2015 update doc, which links to Django dumpdata and loaddata.

If you want back up your Crypt server database, this is how you can dump the data out:

docker ps

to find the name of your docker container, in case you forgot it? Let's just assume, for the next command, that the container's name is Crypt.

docker exec -it Crypt bash

This gets you to a bash prompt inside the Crypt docker container.

cd /home/docker/crypt/

Change to the docker crypt directory.

python manage.py dumpdata > db.json

Dump the data out into a .json file.

exit

Exit out of the docker container bash shell.

docker cp Crypt:/home/docker/crypt/db.json .

Copy the .json file to where you are outside the docker container.

If you want to get back into the docker container to delete the original .json (since there is no docker mv, only docker cp), you can do

docker exec -it Crypt bash
rm /home/docker/crypt/db.json
exit

P.S. Thanks to Graham Gilbert for the tip about not needing to chmod the manage.py file.

P.P.S. This data dump method will work regardless of whether you're using the built-in sqlite3 database or an external postgresql database.

Upgrading to High Sierra: “You may not install this volume because the computer is missing a firmware partition”

If you try to upgrade to High Sierra (macOS 10.13) and get You may not install this volume because the computer is missing a firmware partition when trying to select your drive to upgrade, it may be because you're upgrading on an OWC drive.

If you're using Munki, the error may appear in your /Library/Managed Installs/Logs/Install.log as Starting macOS install: FAILED: startosinstall failed with return code 243.

Previously, you'd have to physically swap back the OEM drive, and then put the OWC drive back again, but now OWC has its own firmware updater tool that fixes the problem:
Aura SSDs: Firmware Update (beta).

Parental Controls keeps blocking allowed apps

If macOS Parental Controls keep blocking allowed apps (both allowed through the checklist in System Preferences and through manually approving via password), deleting the account and recreating it may not be enough to fix the glitch. Instead, try recreating an account with a new name.

I've found Santa to block things more reliably (or not to block things you've allowed). You can block by certificate or (for Apple applications you'd need to do this), block by binary.

Handling cfqueryparam errors in ColdFusion queries

<cfqueryparam> is ColdFusion's way of fighting against SQL injection attacks. If, however, you just put <cfqueryparam> in your SQL or MySQL query, people entering the wrong type of input will get a server-side error message, which will make them think your website is messed up instead of realizing they put in the wrong type of input.

If you use <cfcatch>, be sure to specify that the type is database if you want to be able to display your own error message.

Here's an example:

<cftry>
<cfquery name="somequeryname" datasource="somedatasource">
SELECT somefield
FROM somedatabase
WHERE someotherfield = <cfqueryparam
value="#formname.someotherfieldname#"
cfsqltype="CF_SQL_INTEGER"
maxlength="12">
</cfquery>
<cfcatch type="database">
yoursupercoolandinformativeerrormessage
</cfcatch>
</cftry>

Preventing alarms from going off on MDM’ed iPads

If you have alarms set on iPads (either an actual alarm or an alarm from the "bedtime" portion of the Alarm app), you can't disable the alarm by blocking the app. All blocking the app does is prevent the user from launching up the app.

To prevent the alarm itself from going off, you have to block notifications from the Clock app.

Bulk-extracting and combining audio from .mov to .mp3

If you aren't able to use an audio recording app on your iPad for whatever reason and need to resort to using the Camera app to record audio (long story), you will get a bunch of .MOV files.

So I wrote up a script that employs ffmpeg to extract just the audio from each file in a subdirectory, and then combine the separate audio files from that subdirectory into one audio file.

Script here: ExtractCombineMOVtoMP3.py

CrashPlan 6.5 stuck on Connecting… and never times out

We had a couple of clients who would just never do an initial connection to CrashPlan after the upgrade from CrashPlan 4 to CrashPlan 6.5. But they would never time out or give an error message either.

Restarting the CrashPlan service didn't help. Restarting the computer didn't help. Uninstalling and reinstalling the client didn't help.

Turns out it if the detect-a-user script can't find a CP_USER_HOME, it will just keep trying to connect instead of erroring out. We modified our script, and now those clients are good (we did have to uninstall and reinstall the client after modifying the script, though).

P.S. Someone pointed out that I don't actually share the original or modified script. The point of this blog post isn't to say "Here's a script that works." There are lots of scripts that work. The point is more that if you're experiencing this issue ("connecting" and never timing out or providing an error message), you likely need to fix your script to output a CP_USER_HOME).

Considerations when upgrading CrashPlan with Munki

I had a great workflow for installing CrashPlan with Munki for older versions of CrashPlan (we were on versions 3 and 4 before).

We recently made the jump to CrashPlan 6.5, though, and that workflow no longer applies. Now you have to use a deploy.properties file instead of custom.properties and userInfo.sh files.

We had some added complications to our "upgrade" process, because our new CrashPlan server is a completely different server, and we weren't migrating everyone at once, so we couldn't just change the DNS to point to the new server. I'm not sure a jump from 4 to 6.5 would have been possible as just an installation upgrade anyhow.

So what were those complications?

We couldn't use an installs array any more to tell Munki whether CrashPlan was installed or not. Keeping the installs array would (without managed_updates) prompt users to upgrade to CrashPlan 6.5 or, worse, just upgrade them automatically (with managed_updates). So I changed CrashPlan 4 and 6.5 to use an installcheck_script instead.
Since CrashPlan 6.5 isn't just an update but an actual upgrade for us (think Microsoft Office 2016 vs. Microsoft Office 2011), it's a separate item in Munki altogether, which means we also had to remove the old version from the client's SelfServeManifest before installing the new version (otherwise, the old version would just reinstall).
Likewise, as part of the preinstall_script for 6.5, we had to invoke the /Library/Application Support/CrashPlan/Uninstall.app/Contents/Resources/uninstall.sh script to remove 4 first.
Lastly, we had to have a temporary place to hold the deploy.properties file before copying it to /Library/Application Support/CrashPlan—otherwise, the old installation of CrashPlan would somehow make it disappear or be unusable by the new installer. Not sure exactly what was happening, but it wasn't being recognized when just being delivered there directly as a payload. We also tried including the deploy.properties file in the .dmg itself, but that didn't work either (prompted for server and registration key).
Annoyingly, if you choose not to use SSO, you can't fully automate user account creation or sign-in, so some user interaction for the upgrade is required.

Ours may be a very niche scenario (upgrading from CrashPlan 4 to CrashPlan 6.5 and not using single sign-on), but in case anyone else is in that same situation and using Munki, maybe this blog entry can save you some time in planning your rollout.