We got the third group beta releases for the next updates this week. Can I just gripe for a moment that macOS 10.15.2 was released along side iOS 13.3 and watchOS 6.1.1, while 10.15.3 will (probably) be released along side iOS 13.3.1 and watchOS 6.1.2? Apple versioning makes no sense at all, any more.
Tim Perfitt: “Reboot to recovery on next reboot: sudo nvram "recovery-boot-mode=unused" Subsequent reboots go back to macOS.”
Roben Kleene: “Some of the built-in scripting language binaries (only the interactive ones?) now print a warning message about not being included by default in a future version of macOS. Just in case you were wondering how serious they are about this: They’re serious.”
Jeff Johnson: “I’ve learned that Apple engineers have internal tools which allow them to delete macl xattr as well as to bypass other Catalina privacy and sandbox protections without rebooting and disabling SIP. Inside Apple they don’t suffer the same problems as external users and developers.”
Jenny on Twitter: “No one asked for this. But here it is: every macOS wallpaper from Mac OS X 10.0 Cheetah to macOS 10.15 Catalina combined.” (Follow link for image)
Support
There are no ads on my webpage or this newsletter. If you are enjoying what you are reading here, please spread the word and recommend it to another Mac Admin!
If you want to support me and this website even further, then consider buying one (or all) of my books. It’s like a subscription fee, but you also get a useful book or two extra!
Steve Hayman: “Happy 40th Birthday to one of my favourite Unix features, the Shebang! Dennis Ritchie introduced the two-character #! sequence – which tells Unix how to execute a script file – 40 years ago today.”
Carl Ashley: “Interrogating a preinstall script for a package. It’s doing naughty things. This is just a sample. What package sins keep you awake at night, macadmins?… ” (Image)
There are no ads on my webpage or this newsletter. If you are enjoying what you are reading here, please spread the word and recommend it to another Mac Admin!
If you want to support me and this website even further, then consider buying one (or all) of my books. It’s like a subscription fee, but you also get a useful book or two extra!
Quite a bunch of links this time, because we were off for two weeks and this is the catch up summary. You can tell that most MacAdmins were able to take some time off as well, except for Howard Oakley (Eclectic Light) who just kept publishing like he always does. (Thank you for all your work, Howard!)
Fiora: “looks like dropbox doesn’t like me using dropbox as an automatic backup service… ” (Thread)
Jason Broccardo: “It’s 2020 and you know what that means, right? Adobe Flash Player dies at the end of this year!”
Roy van Rijn: “One of our office chairs turns off monitors… we couldn’t believe it, but we have it on tape. Surprisingly, there even is a known issue for it”
There are no ads on my webpage or this newsletter. If you are enjoying what you are reading here, please spread the word and recommend it to another Mac Admin!
If you want to support me and this website even further, then consider buying one (or all) of my books. It’s like a subscription fee, but you also get a useful book or two extra!
I had a great time while we were recording this podcast, even though we had to schedule it “way past my usual bedtime.” I hope you enjoy listening, as well!
I have pushed an update for the “Moving to zsh” book.
Just a few changes and fixes that have accumulated over the past two weeks. Much of this has been from feedback of readers. Thanks to everyone who sent in their notes.
The update is free if you have already purchased the book. You should get a notification from the Books application to update. (On macOS, I have seen that it can help to delete the local download of the book to force the update.)
If you are enjoying the book, please rate it on the Books store, or (even better) leave a review. These really help, thank you!
Also, please recommend the book to friends, co-workers, and anyone else (not just MacAdmins) who might be facing the zsh transition as they upgrade to Catalina.
The changes in v3 are listed here. This list is also in the ‘Version History’ section in the book. There, you will get links to the relevant section of the book, so you can find the changes quickly.
Added a section explaining how to work with upper- or lower-case strings in zsh scripts
Added a section explaining the differences in the read built-in command
Clarified the section on Connected Variables
Fixed file names in the table for Configuration Files and added a note for how to use configuration files with python environments
As usual, several typos and clarifications (Thanks to many readers)
Apple has started shipping Mac models that used to come with Mojave pre-installed with Catalina. If your organization has blockers for Catalina (incompatible software, etc.) you may want to install Mojave on these Macs. Unfortunately, this is not so easy.
Important Notice: these instructions will only work for Mac models that can boot to Mojave. Usually a Mac requires at least the version of macOS that the model shipped with when it was introduced. As of this writing, all new Macs require at least Mojave. The exceptions are the iMac Pro (High Sierra) and the MacBook Pro 16“ and the Mac Pro (2019) which both require Catalina. You cannot use these instructions to force a Mac Pro or MacBook Pro 16” to boot to Mojave. Any new Mac models that Apple introduces from now on, will also require Catalina and cannot be downgraded to Mojave.
(Not meant as a challenge. I am aware that someone might be able to hack together a Chimera Mojave with Catalina drivers. These ‘solutions’ are not supportable on scale.)
Directly downgrading from Catalina to Mojave with the startosinstall --eraseinstall command will fail. Attempts to run the Mojave installer from a Catalina Recovery (local or Internet) will also fail. The reason seems to be that the Mojave Installer application chokes on some aspect of Catalina APFS. Apple is likely not very motivated to fix this.
So far, the recommendation has been to boot to Internet Recovery with the shift-command-R key combination at boot. This used to boot to a Mojave (more specfically, the system the Mac shipped with) recovery system, and then you can wipe and re-install Mojave. However, if a Mac was shipped with Catalina pre-installed, it will boot to Catalina Internet Recovery, regardless of whether the Mac can boot to Mojave or not.
We have to get creative.
External USB Installer
The solution requires a Mojave Installer USB disk. First download the latest Mojave installer. You can do so from by following this App Store link. If you are running Catalina, you can also use the new option in softwareupdate:
This will delete the target volume data on the USB disk.
Enable External Boot
To boot a new Mac with a T2 chip off an external drive, you need to allow external boot from the Security Utility in the Recovery partition. This utility is protected and requires the password of a local administrator user to access. When you get a new Mac “out of the box,” you cannot directly boot to Recovery to change this.
Instead, you have to boot to the pre-installed Catalina, work your way through the Setup Assistant, and create a local administrator user before you can boot to Recovery to change this setting.
You also need to connect the Mac to a network with non-filtered/proxied access to Apple’s servers, either with Wifi or an ethernet adaptor. You can see which services and servers the network needs to be able to access in this kbase article. You will definitely need the servers listed under ‘Device Setup’ from that list and many of the others, depending on your deployment workflow.
This network connection is required to verify the integrity of the system on the USB Installer drive. You could also disable ‘Secure Boot’ entirely, but that is not recommended as it will, well, disable all system security verifications.
Now, reboot the Mac and hold the option key, from the list of devices to boot from, select the Mojave Installer drive. Once booted to the Mojave installation drive, start Disk Utility. In Disk Utility, erase the entire internal drive. You may have to choose ‘Show All Devices’ from the View menu to be able to select the internal drive with all sub volumes, not just the system or data volume.
Then you can quit Disk Utility and start the Mojave installation process.
After completing the installation, you want to remember to return to Recovery and re-disable external boot again. However, you need to create a new admin account on the disk before you can do that…
Avoiding the Downgrade
This is obviously tedious and really hard to automate. (I have been wondering if you could build a MDS workflow, but this one would require at least three reboots.)
The preferred solution is for IT departments and organizations to have the workflows and infrastructure in place to support and use “latest macOS” (Catalina). Apple is discouraging system downgrades or using anything but “latest macOS.” On newer hardware — like the MacBook Pro 16″, Mac Pro 2019, and every new Mac Apple will introduce from now on — downgrading to Mojave is not possible at all, so you have to support Catalina when you (or your users) get those Mac models.
As mentioned before, I do not believe there is much motivation at Apple to simplify this particular workflow. It serves Apple’s interest and vision to push the latest macOS over previous versions. From a user perspective it allows better integration with their iOS and other Apple devices. From a security standpoint it provides the latest security updates and patches. Apple provides security updates for the previous two macOS versions, but those notoriously do not fix all the vulnerability that the latest macOS gets.
However, in some cases you may have blocking applications that cannot run, or cannot be upgraded to run on Catalina. Then this workflow can be a ‘last ditch’ solution until you get those ‘blockers’ sorted out.
Maybe the best solution is to use this complex and work intensive downgrade workflow as leverage to push for “latest macOS” support in your organization.
Thanks to Robin Lauren and Mike Lynn for figuring this out on MacAdmins Slack and sharing their results.
We are close to completing another trip around the sun. Whether you use the solstice (Dec 22) or the Perihelion (Jan 5) or the quaint Gregorian Calendar which switches on Dec 31.
(Dates are for UTC. The exact astronomical event may be it may be a Dec 4 or Jan 4 at your location, depending on your time zone.)
You’d think that Apple would take an early break after the Mac Pro release, but we got new and updated security documentation. Together with the new deployment and MDM documentation updated last week.
Because of the holidays, this newsletter will be taking a break as well. The next one should be on Jan 10, 2020, summarizing everything that happened in the mean time.
I wish you Happy Holidays and all the best for the new Year 2020!
See you next year!
Armin Briegel
Note: if you get an AppStore/iTunes Gift Card for Christmas, gift yourself one of my books!
This is a good summary, but I find the continued expectation that Apple has to keep delivering “Blockbuster” devices quite tiresome. Who else is has delivered blockbuster devices? Also, the statement implies that the iPad, Apple Watch, and AirPods (all introduced since 2010) aren’t blockbusters?
Jean-David Gadina: “You can keep SIP but allow debugging (including instruments) with csrutil enable --without debug --without dtrace”
Russ Bishop: “TIL: 3rd party kext tries to inject macOS dylib into all processes, breaks downloaded simulators. Surprise! Simulator binaries can’t load mac dylibs. So far that’s four unique ways I’ve seen badly made kernel extensions break simulators. All are ”security“ products.”
There are no ads on my webpage or this newsletter. If you are enjoying what you are reading here, please spread the word and recommend it to another Mac Admin!
If you want to support me and this website even further, then consider buying one (or all) of my books. It’s like a subscription fee, but you also get a useful book or two extra!
While I have used this for a long time, the limited number of colors has always annoyed me. And with the introduction of Dark Mode in macOS it seemed just not useful anymore.
Mike’s approach to create the color files with a python script sent me down a rabbit hole to recreate this in Swift. I actually succeeded in creating such a Swift tool, but then, when I worked on connecting the tool with Terminal, I found an even simpler, and arguably better way to do this.
Surprisingly, it involved AppleScript.
Changing the Terminal Background color
Terminal has a powerful AppleScript library, which allows to read and change (among other things) the background color of a Terminal window or tab:
tell application "Terminal"
get background color of selected tab of window 1
--> {65535, 65533, 65534}
end tell
The background color is returned as a list of three RGB numbers ranging from 0 to 65535 (216 – 1). You can also set the background color:
tell application "Terminal"
set background color of selected tab of window 1 to {60000, 45000, 45000}
end tell
This will set the background color of the current window to pastel pink (salmon?).
Armed with this knowledge it is fairly straight forward to write a script that will set the background color to a random color:
#!/usr/bin/osascript
on backgroundcolor()
set maxValue to (2 ^ 16) - 1
set redValue to random number from 0 to maxValue
set greenValue to random number from 0 to maxValue
set blueValue to random number from 0 to maxValue
return {redValue, greenValue, blueValue}
end backgroundcolor
set newcolor to backgroundcolor()
tell application "Terminal"
set the background color of the selected tab of window 1 to newcolor
end tell
You can paste this code in Script Editor and hit the ‘play’ button and watch the Terminal window change. But since we want to use from within Terminal, we will take a different approach: paste the code into your favorite text editor and save it as a text file named randombackground (no extension).
Then open Terminal and change directory to where you save the file and set its executable bit:
> chmod +x randombackground
Now you can run this AppleScript file like any other script file from Terminal:
> ./randombackground
This is fun!
I am not the first to discover and use this, Daniel Jalkut and Erik Barzeski have documented this in 2006.
Enter Dark Mode
Fast forward back to 2018: Along with the rest of macOS, Terminal gained “Dark Mode” in macOS Mojave.
The default “Basic” window profile in Terminal has black text on a white background in light mode and white text on a black background in dark mode. There is some “magic” that happens when the system switches to Dark or Light mode.
However, once we customize the background color (or any other color) the magic does not work any more. When our random backgrounds are too dark in light mode (or vice versa), they don’t really look nice any more, and the text becomes hard to read or completely illegible.
So, we want to change the script to detect dark or light mode and limit the colors accordingly. You can detect dark mode in AppleScript with:
tell application "System Events"
get dark mode of appearance preferences
end tell
This will return true for dark mode and false for light mode. We modify the script to use just a subrange of all available colors, depending on the mode:
#!/usr/bin/osascript
on backgroundcolor()
set maxValue to (2 ^ 16) - 1
tell application "System Events"
set mode to dark mode of appearance preferences
end tell
if mode then
set rangestart to 0
set rangeend to (maxValue * 0.4)
else
set rangestart to (maxValue * 0.6)
set rangeend to maxValue
end if
set redValue to random number from rangestart to rangeend
set greenValue to random number from rangestart to rangeend
set blueValue to random number from rangestart to rangeend
return {redValue, greenValue, blueValue}
end backgroundcolor
set newcolor to backgroundcolor()
tell application "Terminal"
set the background color of the selected tab of window 1 to newcolor
end tell
When you run this from Terminal for the first time, it may prompt you to allow access to send events to “System Events.” Click ‘OK’ to confirm that:
Automatically setting the background color
Now we can randomize the color by running the command. For simplicity, you may want to put the script file somewhere in your PATH. I put mine in ~/bin/, a folder which a few useful tools and I also added to my PATH(in bash and in zsh).
It is still annoying that it doesn’t happen automatically when we create a new window or tab, but that is exactly what the shell configuration files are for. Add this code to your bash or zsh configuration file.
# random background color
if [[ $TERM_PROGRAM == "Apple_Terminal" ]]; then
if [[ -x ~/bin/randombackground ]]; then
~/bin/randombackground
fi
fi
Our script will likely fail when the shell is run in any other terminal application or context (such as over ssh). The first if clause checks if the shell is running in Terminal.app. Then the code check to see if the script exists and is executable, and then it executes the script.
This will result in random Terminal colors, matching your choice of dark or light mode.
Note: macOS Catalina added the option to automatically switch the theme depending on the time of day. This script will detect the mode correctly when creating a new window, but Terminal windows and tabs that are already open will retain their color. I am working on a solution…
Christmas for Mac users came early this year. At least for those Mac users who can afford a new Mac Pro. Whether you think the price is justified or not, whether you would like an Apple tower Mac or think desktops are so last decade, the Mac Pro (and the new MacBook Pro 16“) symbolizes a new desire from Apple to re-focus on the ”Pro” users. It remains to be seen if Apple’s vision of what Pro users need and want matches the reality.
Those who don’t get a shiny new Mac Pro, still got updates this week. macOS Catalina 10.15.2, iOS 13.3 and its various sibling updates dropped this week as well.
Do you know that you can gift Apple Books? If you are looking for last minute gift ideas for that Terminal using friend, family member, or co-worker of yours, give them some know-how and increased productivity: “Moving to zsh”
Rich Trouton: “The book I wrote with @cedge318 has been available for pre-order, but it looks like we’re getting close to a release date of January 3, 2020! For folks with a shiny new Amazon gift card this Christmas, why not treat yourself to the gift of knowledge?” Amazon US, UK, DE (Affiliate Links)
Victor (groob): “Maybe next time @Apple will consider shipping a few review models to enterprise customers who need to make sure these are ready for users. Priorities…”
Pepijn Bruienne: “It’s official! iOS and iPadOS 13.3 now support FIDO2/Webauthn for NFC, USB and Lightning-based security keys for everyone. Get a key, start enabling FIDO2 with services that support it and ask those who don’t what their timeline for adoption is.”
Graham Pugh: “Fun fact: Apple even renewed the certificate in the Java for OSX 2017–001 installer. And there is still software out there that needs it…”
Mike Boylan: “New Deployment Reference Guide for Mac has been posted! As promised, the FileVault and SecureToken section has been updated to include information about the Bootstrap Token and some subtle behavior changes in Catalina.”
Kyle Crawford: ““On Mac computers, software updates deferral restriction applies to OS updates only. iTunes, Safari, security updates, or other supplemental updates for macOS aren’t restricted.”!”
There are no ads on my webpage or this newsletter. If you are enjoying what you are reading here, please spread the word and recommend it to another Mac Admin!
If you want to support me and this website even further, then consider buying one (or all) of my books. It’s like a subscription fee, but you also get a useful book or two extra!
