Tag: mac

Use the command-line to set a firmware password on macOS

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:

sudo firmwarepasswd -setpasswd
You'll be prompted for the new firmware password. Afterwards, you'll need to reboot the machine for the change to take effect. (Be sure to make sure you have an actual startup disk selected in System Preferences!)

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...

sudo firmwarepasswd -check
checks to see if the firmware password is set.
sudo firmwarepasswd -verify
allows you to verify you have the correct password (without rebooting).
sudo firmwarepasswd -delete
deletes the firmware password. You'll need the current one to delete it, of course.

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.

Script AutoPkg trust verification and trust update process

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

autopkg verify-trust-info -vv NAMEOFRECIPE
and then, after review, run
autopkg update-trust-info NAMEOFRECIPE
and then run the recipe after updating the trust info:
autopkg run -v NAMEOFRECIPE
So I thought I'd take a stab at scripting the whole process. Basically my script updates all the repos (to see if there are changes), verifies trust info on each of the recipes in the recipe list, and then prompts the user to review changes and approve them or not, before running all the approved or unchanged recipes.

It's still in the early testing phase, but it seems to work so far....

Capturing new FileMaker Pro updates for macOS

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).

Fixing a broken MDM on OS X Server with Profile Manager

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.

Skipping Apple updates in Managed Software Center manual checks

Why would you want to selectively disable Apple software updates?

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.

Use a Preflight script

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.

Script logic

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.

The actual preflight script

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!

Google Drive “low space, can’t sync” in selective sync

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.

Can’t paste from Google Docs to Microsoft Word on Mac

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.

Setting up Reposado on a Mac

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:

sudo apachectl start
and then visit localhost in a web browser on your machine or https://myserver.mycompany.com from another computer (with your actual Mac-as-web-server's fully qualified domain name in place of the dummy placeholder I gave as an example).

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:

git clone https://github.com/wdas/reposado

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:

sudo mkdir -p /usr/local/reposado
sudo cp -R /PATH/TO/reposado/code/* /usr/local/reposado/

Make folders to store the Reposado-downloaded Apple updates data:

sudo mkdir -p /Library/WebServer/Documents/reposado/html
sudo mkdir -p /Library/WebServer/Documents/reposado/metadata

Configure Reposado:

sudo /usr/local/reposado/repoutil --configure
You'll be asked a few questions. Answer them appropriately. If you drag the folders to the terminal, be sure to delete any trailing spaces.
Filesystem path to store replicated catalogs and updates [None]:
/Library/WebServer/Documents/reposado/html
Filesystem path to store Reposado metadata [None]:
/Library/WebServer/Documents/reposado/metadata
Base URL for your local Software Update Service
(Example: http://su.your.org -- leave empty if you are not replicating updates) [None]:
https://myserver.mycompany.com

Create at least one branch (you'll probably have at least two later):

sudo /usr/local/reposado/repoutil --new-branch testing
Read more details on manipulating branches.

Start syncing your Reposado cache with Apple's update servers:

sudo /usr/local/reposado/repo_sync
Note: This could take a while (depending on your bandwidth) and download several hundred gigabytes of data.

Once it's finished syncing up, add all the products to the testing branch:

repoutil --add-product all testing
Now, you should be able to see the catalog if you visit

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:

sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL "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's a very basic setup. For more details on Reposado options, read the official docs.

Getting Wabbit Emu to work on a Mac retina display

Acknowledgements

Huge shoutout to @damienbarrett on the Mac Admins Slack Team for the fix. I'm just documenting it here, in case anyone else runs into this problem and is searching for the solution.

Problem

You launch up Wabbit Emu and try to run your TI-## calculator ROM, and the onscreen buttons don't match up with what's actually happening on the emulated screen. For example, you might click the Clear button and see the number 1 appear instead.

Solution

First, quit out of Wabbit Emu completely (Cmd-Q).

wabbitemu01 Right-click on WabbitEmu.app and select Get Info.

wabbitemu02 Scroll down a bit until you see four checkbox options. Check (or tick) the Open in Low Resolution box, and then close that window.

Now when you open up WabbitEmu, the appropriate onscreen buttons should work.

Scripting it

If you want to script this change, check out pudquick's Python script to set LSHighResolutionModeIsMagnified. You may have to modify it, of course, since it uses TextEdit as an example app:

lowres_app_path = u'/Applications/WabbitEmu.app'
lowres_app_id = u'org.revsoft.WabbitEmu'
Then you can drop it in as a login script (via Outset, for example).

Just keep in mind that after the script runs, the user will have to log out and log back in again for the change to take effect.