St. Ignatius College Prep Tech Blog
SI's blog about technology
We had a user whose unread emails were appearing as bold in Safari (with an ugly font) and not bold at all in Chrome (font looked okay), and we did some digging and found the solution was to enable the Arial Bold font in Font Book on the user's Mac, and it was all good.
Our best guess is that Safari couldn't find the font it wanted so substituted an ugly font but kept it bold, and Chrome couldn't find the font it wanted so substituted a decent-looking font but not bold.
For extra security, you can add a firmware password to Macs, especially since Find My Mac is essentially useless (unlike for iPads, which have an activation lock preventing thieves from reactivating the iPad after a factory reset) and DEP-to-MDM enrollments for Macs can even be avoided by thieves if they're resourceful enough.
If you have a laptop with a firmware password, you need that password to boot from anything except the startup disk. Combine that with FileVault encryption, and a stolen Mac is pretty much useless. Doesn't mean that you'll necessarily get it back, but the likelihood is higher if the device is useless to thieves.
You can, of course, enable the firmware password via Recovery Mode, but it's easier to do it from the command line:
There are two modes for a firmware password: command and full. By default, the firmware password mode will be command, which means you'll be prompted for the password only if you boot from something other than the startup disk. If, for some strange reason, you want the mode to be full, it would mean you'd be prompted for a firmware password at every boot, regardless of what you're booting to.
A few other commands you might find useful...
If you want to script firmware password setting, someone wrote a fairly simple script that does it. There's also firmware password manager, which is a far more sophisticated way to manage firmware passwords.
Nota Bene: If you enable a firmware password, you can get into target disk mode by holding down the Alt/Option key at boot, typing in the firmware password, and then holding down the T key. However, you will be unable to boot into Safe Mode unless you delete the firmware password.
Starting with version 1, AutoPkg began evaluating trust info for recipes, so you could see what changes were made to a recipe (if changes were made) and then accept the changes if you wanted to. Here is what the typical trust verification workflow looks like.
Whether running a list of recipes via script or via AutoPkgr schedule, I'd occasionally get error'ed recipes when trust was broken, have to manually run
It's still in the early testing phase, but it seems to work so far....
For older FileMaker Pro versions, there used to be downloadable updates on the FileMaker website, but starting with FileMaker Pro 15, they decided to have FileMaker updates on macOS go through FileMaker itself:
As you can see here, they expect your user to have admin privileges. If you're managing Macs (through Munki, for example), you may not give your users admin privileges or you may (even if your users have admin privileges) not want to bother with them running the updater themselves.
For some reason, Windows users get separate update installers. None for the macOS users, though, but we can be a bit tricky in capturing the installer.
First, find a Mac that you're not doing a silent install of FileMaker Pro on. Do a regular manual install on that one Mac and make sure you have AI_DISABLEUPDATENOTIFY=0 in your Assisted Install.txt file.
Then, on this test Mac, launch up FileMaker Pro.
Under Help, select Check for Updates....
Click Download Update
This is key here: do not click Install Update. Don't click Cancel either. Do not click anything. Just leave this dialogue up for now.
Open up /var/log/install.log and search for caches.
That should show you the location of the downloaded installer.
Go to that location and find the .pkg file. You can import that into Munki (or whatever you use to manage updates to your Mac fleet).
If you're getting errors like Websites are turned off. An administrator can turn them on using the Server application or the configuration for your ipad could not be downloaded invalid profile, try Reset Apache In OS X Server To Factory Defaults and then turn Websites and Profile Manager back on.
If you have a volume license and want to distribute Inspiration to your Munki clients, just activate Inspiration on one Mac and then import the activated Inspiration.app bundle into Munki. That's it.
Munki allows you to change a preference on client machines to check for and install Apple software updates.
This is pretty cool. It means I can bundle Apple software updates and third-party software updates together for my users.
But sometimes, it's a little frustrating when I'm helping a user to use Managed Software Center, and MSC checks for new updates but also decides to check for Apple updates... don't really need it to check for Apple updates then. Totally want Munki to check for Apple updates in the background and all the other times, just not when the user launches up MSC.
It's true if you've just checked very recently. you may see Skipping Apple Software update because sucatalog is unchanged, installed Apple packages are unchanged and we recently did a full check, but even if it's been a while since the last check, I just don't want any check happening if the user has manually launched up MSC.
Munki allows you to run preflight and postflight scripts during each Munki run. As Munki is out of the box, you are supposed to have one preflight script named preflight (no extension). If you use MunkiReport, though, as I do, you'll notice MunkiReport has the preflight script run a bunch of scripts in the preflight.d directory, which allows a bit more flexibility to add in various scripts instead of lumping them into one combined preflight script.
Preflight scripts can use the runtype to do different things based on whether the Munki run type is an auto, logoutinstall, checkandinstallatstartup, installwithnologout, manualcheck, or custom.
What the script does is just check to see if there's a manualcheck and then turn the InstallAppleSoftwareUpdates preference off. If it's any other type of run, the script turns the preference on.
Here is the preflight script, which you can deliver as a payload to /usr/local/munki/preflight.d/ (or as /usr/local/munki/preflight if you don't have a preflight directory). You can create the .pkg using Packages, The Luggage, munkipkg, or even just pkgbuild.
If you want to make it based on another runtype you can change the logic there or tweak the script to use a time-based or date-based logic to run Apple updates less frequently. The possibilities are endless!
I recently ran into a weird situation in which the Google Drive desktop app was complaining about there not being enough space to add a folder to my selective sync options. It made no sense. I had at least 100 GB of free space on my drive, and I wanted to additionally sync only another 3 MB in one subfolder.
How could an additional 3 MB take up more than 100 GB of space?
Well, it turns out there's a bug in Google Drive. The first time you do a selective sync, the trash storage isn't taken into account when Google Drive compares it to the free space on your local drive. But in subsequent changes to your selective sync, the trash storage is taken into account, so if you have a lot in your trash, you can't modify your selective sync.
I've reported the bug to Google. In the meantime, if you run into this issue, empty your Google Drive trash (through the web browser, not the app), and then wait about 24 hours. You should then be able to modify the selective sync again.
Obviously not the one solution for any time this happens, but I've come across this only once (just now), and this is what worked.
The problem was the user was copying from a Google Doc and then trying to paste into a Word doc. Nothing pasted, even though the Edit menu item flashed blue as if it was trying to paste.
I thought at first that maybe it just couldn't paste outside of Google Docs itself (has been known to happen), but the text pasted just fine into a TextEdit file.
And Word itself could copy and paste text to itself (if you typed something in the Word doc and then pasted into the Word doc, it pasted just fine).
Through just trial and error, I eventually stumbled upon the solution, which was to go (in Word) to Edit, select Paste Special, and then select Unformatted Text. The paste went through just fine.
Confused? Read Using Reposado to manage cached Mac updates yet? If not, read that first.
There's a great step-by-step guide to setting up Reposado on Ubuntu Linux, and, in fact, one of the benefits of Reposado is that it can be run on Linux... but it doesn't have to be. For whatever reasons you have, you may want to run it on a Mac instead.
First, make sure Apache is up and running on your Mac:
You may have to configure a bunch of other things on the web server for that last part to work—all that's a bit outside the scope of a Reposado tutorial.
(Keep in mind, too, that the path I'm using to the web server documents is based on a regular macOS installation. If you add OS X Server on top of that, the path then changes to /Library/Server/Web/Data/Sites/Default.)
Next, get the latest Reposado code. If you have Git installed, you can just clone the repository:
If you don't have Git installed and don't want to install it, you can also click the Clone or download link on the Reposado GitHub repository and then double-click the downloaded .zip to unzip its contents.
Either way, you should have a folder called reposado with a subfolder called code.
Go ahead and copy that to /usr/local/reposado:
Make folders to store the Reposado-downloaded Apple updates data:
Configure Reposado:
Create at least one branch (you'll probably have at least two later):
Start syncing your Reposado cache with Apple's update servers:
Once it's finished syncing up, add all the products to the testing branch:
https://myserver.mycompany.com/reposado/content/catalogs/others/index-10.12-10.11-10.10-10.9-mountainlion-lion-snowleopard-leopard.merged-1_testing.sucatalog
That URL will change with each new version of macOS that's released (the sample above is valid as of Sierra), so you may want to wait until Reposado's code is updated and then do another Git clone on the code to update the URL (and then fix the URL for your clients).
The last part of the URL is the branch you want the client to access (in this case, testing).
To write the change to a client, run on the client machine:
That's a very basic setup. For more details on Reposado options, read the official docs.