Also, this is or was the week where all the remote work emergency planning was put into reality. In Europe and America, many countries, companies, schools, and other organisations are sending employees and students to remote work or studies. Games, conferences, concerts, and parties are being canceled. All in an effort to slow down the rate of contagion
This is an exceptional situation on so many levels. Everyone, be safe!
When, because of ‘social distancing,’ ‘self-isolation,’ or straight quarantine, you find yourself with extra time, maybe buy and read one of my books!
Victor (groob): “I’m a big advocate for remote work, but I doubt we’ll see many positive outcomes in this scenario. – many are going to be sick. – childcare will eat up a lot of time. – employers that weren’t already offering remote are not prepared. Remote work requires a lot of planning.”
Rene Ritchie: “NB: Apple’s Mac computers are unaffected by this latest Intel CSME security flaw. FileVault doesn’t use any Intel security features and T2 Macs exclusively use T2.” (ArsTechnica article)
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!
The world is holding their breath (some quite literally) as COVID–19 spreads. Conferences, companies, schools, and other organisations are reacting and implementing quarantine or other emergency plans. For many IT organisations this will mean a thorough stress test of their remote infrastructure. Some will have to implement entirely new solutions to deal with this situation.
Whatever situation you are in, I wish you health, strength, and the necessary nerves, patience, and luck to get through this!
tlark: “Wrote a quick and dirty python tool for jamf to rip Crowdstrike off macOS devices due to how their tamper protection can cause edge cases where their install tokens don’t work.”
Erik Gomez: “I really want to know where you are now @lauraroesler because we finally caught up! This includes minor versions as well, not just major.” (follow link for diagram)
Laura Rösler: “We have around 93% of our fleet on #Catalina with the majority on 10.15.3. Luckily, we got rid of our last two 10.12 devices in the last weeks.” (Love MacAdmins bragging about their adoption rates. Well done all!)
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!
Of course, you can easily create a new Terminal window from the ‘Shell’ menu or by using the ⌘N (or ⌘T) keyboard shortcut. But in some cases, it can be more useful to use a shell command.
New windows created with the keyboard shortcut or from the menu will always have the home directory ~ as the current working directory. What I want, is a new window that defaults to current working directory or a custom directory that I can provide with an argument:
> new # opens a new terminal window at the current working directory
> new ~/Desktop # opens a new terminal window at ~/Desktop
No luck with AppleScript
After my last success using AppleScript, I thought this would be the best solution again. Unfortunately, this particular piece of the AppleScript dictionary is broken. The make new window or make new tab commands fail with errors and I have tried several combinations.
You can create a new Terminal window with AppleScript using the do script command in the Terminal dictionary. (Not to be confused with do shell script.) So this AppleScript, sort of does what I want, but seems cumbersome.
tell application "Terminal"
do script "cd ~/Desktop"
end tell
If you know of a better way to create a new Terminal window or, even better, a Terminal tab with AppleScript, then please let me know. (No UI Scripting solutions – those have their own issues.) I have a few other ideas where this might come in useful.
Enter the open command
During those web searches, I also found suggestions to use the open command, instead:
> open -a Terminal ~/Documents
Will open a new Terminal window with ~/Documents as the working directory. This is already really close to what I wanted.
I created this function in my shell configuration file (bash, zsh):
# creates a new terminal window
function new() {
if [[ $# -eq 0 ]]; then
open -a "Terminal" "$PWD"
else
open -a "Terminal" "$@"
fi
}
With this, I can now type
> new Projects/desktoppr
and get a new Terminal window there. This is very useful when combined with the history substitution variable!$ (last argument of previous command):
> mkdir Projects/great_new_tool
> new !$
And an unexpected, but useful side effect is that the new function can also open an ssh session in a new window:
tlark: “We have successfully POC’d using ChromeOS for our digital signage. I’ll be ripping out every Mac Mini soon and replacing macOS with ChromeOS. I’ll never have to worry about softwareupdate on these devices again.”
Bryson Tyrrell: “I foresee an indeterminate period of time where we have Macs running ARM or x86. The iMac Pro and Mac Pro I think need to stay x86. iMac and Mac mini I could see going ARM. Shifting over entirely doesn’t feel right with their “pro” focus in the past year.”
Brad Neuberg: “Oh hey Homebrew just completely removed the Python 2.7 cask with a smarmy ”you should have upgraded“ message. Thanks Homebrew!” (via groob)
Mr. Macintosh: “The macOS Catalina 10.15.4 Beta 3 (19E242d) Update is now Available Apple also made a Full .app installer available for Beta 3 Updated Beta 3 AppleSeed Notes include changes around the Kernel Extension Incompatibility warning messages that first arrived in Beta 2.”
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!
Another slow-ish news week for MacAdmins. At least what we can talk about. 10.15.4 beta 2 (and iOS 13.4. beta 2 and related) dropped this week. As the last few “Spring Updates” this update has new “features” that will affect managed deployments. You should be using your AppleSeed for IT accounts and start testing the impact on your environment.
Nathaniel Strauss: “10.15.4 beta 2 includes new kext deprecation notices. Occurs every 30 days even if kexts are MDM approved. File feedback! Apple: We are obsessed with the end user experience Also Apple: Recurring notices about software installed by IT with text you don’t understand. ”
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!
Somewhat quiet week on the Apple Admin side. I think 10.15.3 is now the point where many MacAdmins are busy rolling out Catalina, or at least seriously preparing 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!
As I noted in my last Weekly News Summary, several open source projects for MacAdmins have completed their transition to Python 3. AutoPkg, JSSImport and outset announced Python 3 compatible versions last week and Munki already had the first Python 3 version last December.
Why?
Apple has included a version of Python 2 with Mac OS X since 10.2 (Jaguar). Python 3.0 was released in 2008 and it was not fully backwards compatible with Python 2. For this reason, Python 2 was maintained and updated alongside Python 3 for a long time. Python 2 was finally sunset on January 1, 2020. Nevertheless, presumably because of the compatibility issues, Apple has always pre-installed Python 2 with macOS and still does so in macOS 10.15 Catalina. With the announcement of Catalina, Apple also announced that in a “future version of macOS” there will be no pre-installed Python of any version.
Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app. (macOS 10.15 Catalina Release Notes)
This also applies to Perl and Ruby runtimes and other libraries. I will be focussing on Python because it is used more commonly for MacAdmin tools, but most of this post will apply equally to Perl and Ruby. Just mentally replace “Python” for your preferred language.
The final recommendation is what AutoPkg and Munki are following: they are bundling their own Python runtime.
How to get Python
There is a second bullet in the Catalina release notes, though:
Use of Python 2.7 isn’t recommended as this version is included in macOS for compatibility with legacy software. Future versions of macOS won’t include Python 2.7. Instead, it’s recommended that you run python3 from within Terminal. (51097165)
This is great, right? Apple says there is a built-in Python 3! And it’s pre-installed? Just move all your scripts to Python 3 and you’ll be fine!
Unfortunately, not quite. The python3 binary does exist on a ‘clean’ macOS, but it is only a stub tool, that will prompt a user to download and install the Command Line Developer Tools (aka “Developer Command Line Tools” or “Command Line Tools for Xcode”). This is common for many tools that Apple considers to be of little interest to ‘normal,’ non-developer users. Another common example is git.
Dialog prompting to install the Command Line Tools
When you install Xcode, you will also get all the Command Line Developer Tools, including python3 and git. This is useful for developers, who may want to use Python scripts for build operation, or for individuals who just want to ‘play around’ or experiment with Python locally. For MacAdmins, it adds the extra burden of installing and maintaining either the Command Line Developer Tools or the full Xcode install.
Python Versions, a multitude of Snakes
After installing Xcode or the Command Line Developer Tools, you can check the version of python installed: (versions on macOS 10.15.3 with Xcode 11.3.1)
When you go on the download page for Python.org, you will get Python 3.8.1 (as of this writing). But, on that download page, you will also find download links for “specific versions” which include (as of this writing) versions 3.8.1, 3.7.6, 3.6.10, 3.5.9, and the deprecated 2.7.17.
The thing is, that Python isn’t merely split into two major release versions, which aren’t fully compatible with each other, but there are several minor versions of Python 3, which aren’t fully compatible with each other, but are still being maintained in parallel.
Developers (individuals, teams, and organisations) that use Python will often hold on to a specific minor (and sometimes even patch) version for a project to avoid issues and bugs that might appear when changing the run-time.
When you install the latest version of Munki, it will install a copy of the Python framework in /usr/local/munki/ and create a symbolic link to that python binary at /usr/local/munki/python. You can check its version as well:
% /usr/local/munki/python --version
Python 3.7.4
All the Python code files for Munki will have a shebang (the first line in the code file) of
#!/usr/local/munki/python
This ensures that Munki code files use this particular instance of Python and no other copy of Python that may have been installed on the system.
The latest version of AutoPkg has a similar approach:
In both cases the python binary is a symbolic link. This allows the developer to change the symbolic link to point to a different Python framework. The shebangs in the all the code files point to the symbolic link, which can be changed to point to a different Python framework.
This is useful for testing and debugging. Could MacAdmins use this to point both tools to the same Python framework? Should they?
The Bridge to macOS
On top of all these different versions of Python itself, many scripts, apps, and tools written in Python rely on ‘Python modules.’ These are libraries (or frameworks) of code for a certain task, that can be downloaded and included with a Python installation to extend the functionality of Python.
The most relevant of these modules for MacAdmins is the “Python Objective-C Bridge.” This module allows Python code to access and use the native macOS Cocoa and CoreFoundation Frameworks. This not only allows for macOS native GUI applications to be written in Python (e.g. AutoDMG and Munki’s Managed Software Center [update: MSC was re-written in Swift last year]), but also allows short scripts to access system functions. This is sometimes necessary to get a data that matches what macOS applications “see” rather than what the raw unix tools see.
For example, the defaults tool can be used to read the value of property lists on disk. But those might not necessarily reflect the actual preference value an application sees, because that value might be controlled by a different plist file or configuration profile.
You could build a tool with Swift or Objective-C that uses the proper frameworks to get the “real” preference value. Or you can use Python with the Objective-C bridge:
#!/usr/bin/python
from Foundation import CFPreferencesCopyAppValue
print CFPreferencesCopyAppValue("idleTime", "com.apple.screensaver")
Three simple lines of Python code. This will work with the pre-installed Python 2.7, because Apple also pre-installs the Python Objective-C bridge with that. When you try this with the Developer Tools python3 you get an error:
ModuleNotFoundError: No module named 'Foundation'
This is because the Developer Tools do not include the Objective-C bridge in the installation. You could easily add it with:
> sudo python3 -m pip install pyobjc
But again, while this command is “easy” enough for a single user on a single Mac, it is just the beginning of a Minoan labyrinth of management troubles.
Developers and MacAdmins, have to care about the version of the Python they install, as well as the list of modules and their versions, for each Python version.
It is as if the Medusa head kept growing more smaller snakes for every snake you cut off.
(Ok, I will ease off with Greek mythology metaphors.)
You can get a list of modules included with the AutoPkg and the Munki project with:
> /usr/local/munki/python -m pip list
> /usr/local/autopkg/python -m pip list
You will see that not only do Munki and AutoPkg include different versions of Python, but also a different list of modules. While Munki and AutoPkg share many modules, their versions might still differ.
Snake Herding Solutions
Apple’s advice in the Catalina Release Notes is good advice:
It’s recommended that you bundle the runtime within the app.
Rather than the MacAdmin managing a single version of Python and all the modules for every possible solution, each tool or application should provide its own copy of Python and its required modules.
This might seem wasteful. A full Python 3 Framework uses about 80MB of disk space, plus some extra for the modules. But it is the safest way to ensure that the tool or application gets the correct version of Python and all the modules. Anything else will quickly turn into a management nightmare.
This is the approach that Munki and AutoPkg have chosen. But what about smaller, single script solutions? For example simple Python scripts like quickpkg or prefs-tool?
Should I bundle my own Python framework with quickpkg or prefs-tool? I think that would be overkill and I am not planning to do that. I think the solution that Joseph Chilcote chose for the outset tool is a better approach for less complex Python scripts.
In this case, the project is written to run with Python 3 and generic enough to not require a specific version or extra modules. An admin who wants to use this script or tool, can change the shebang (the first line in the script) to point to either the Developer Tool python3, the python3 from the standard Python 3 installer or a custom Python version, such as the Munki python. A MacAdmin would have to ensure that the python binary in the shebang is present on the Mac when the tool runs.
You can also choose to provide your organization’s own copy Python with your chosen set of modules for all your management Python scripts and automations. You could build this with the relocatable Python tool and place it in a well-known location the clients. When updates for the Python run-time or modules are required, you can build and push them with your management system. (Thanks to Nathaniel Strauss for pointing out this needed clarifying.)
When you build such scripts and tools, it is important to document which Python versions (and module versions) you have tested the tool with.
(I still have to do that for my Python tools.)
What about /usr/bin/env python?
The env command will determine the path to the python binary in the current environment. (i.e. using the current PATH) This is useful when the script has to run in various environments where the location of the python binary is unknown.
This is useful when developers want to use the same script in different environments across different computers, user accounts, and platforms. However, this renders the actual version of python that will interpret the script completely unpredictable.
Not only is it impossible to predict which version of Python will interpret a script, but you cannot depend on any modules being installed (or their versions) either.
For MacAdmin management scripts and tools, a tighter control is necessary. You should use fixed, absolute paths in the shebang.
Conclusion
Managing Python runtimes might seem like a hopeless sisyphean task. I believe Apple made the right choice to not pre-install Python any more. Whatever version and pre-selection of module versions Apple would have chosen, it would only have been the correct combination for a few Python solutions and developers.
While it may seem wasteful to have a multitude of copies of the Python frameworks distributed through out the system, it is the easiest and most manageable solution to ensure that each tool or application works with the expected combination of run-time and modules.
We got a remarkable series of open source updates this week. AutoPkg, JSSImporter, and Outset all published updates that make the project independent of the pre-installed Python 2.7 on macOS. Since Python 2.7 will be deprecated really soon, Apple had announced that future macOS versions will not include a pre-installed Python anymore. These projects join Munki which had the update with “Python” independency with version 4.0 in December. Thanks to all contributors who put their efforts into these open source projects!
The next beta cycle for the Apple operating systems started this week. Once again, it looks as it if the “Spring Updates” for macOS 10.15.4 and iOS 13.4 will add features and changes relevant for users and administrators. Check out the details in the AppleSeed for IT portal.
Martin Lang: “The number of SAP colleagues who chose a Mac as their primary computer has doubled over the last 15 months, it’s at almost 26K now with 82% of them running the latest macOS Catalina”
Laura Rösler: “We‘ve finally more than 26,000 Macs at SAP ….and crossed the 85% for macOS Catalina.”
Andrew Laurence: “For those in the ITlife who might not be familiar: MS plans to flip configurations on DCs, requiring either packet signing on LDAP connections, or using TLS with LDAP. This has been recommended for years.” (Thread)
Parker Higgins: “I used to wonder why the interfaces on Star Trek are so clunky given that it’s centuries in the future, but I guess that’s just Enterprise software for you”
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 recently posted an article on how to get the current user in macOS. If you read through that entire post, it’ll be obvious that it was actually an excuse to write about the deprecation of python 2 and /bin/bash and the situation with sh ‘compatible’ code.
From now on, I will call these the ‘SystemConfiguration’ solution (this also includes the python one-liner). Both the python and the scutil based one-liners go through the SystemConfiguration framework to get at the desired information: which user is using the ‘Console?’
The ‘console’ in this case is an abstract definition, which encompasses the screen output and most inputs. I could not find a clear definition of what the ‘Console’ is exactly on macOS. (If you can point me to one, I’d be grateful.) But it serves to think of the console as all the processes, inputs and outputs attached to a user’s login session.
The other one-liner
There is another solution that keeps popping up in MacAdmins Slack and blog posts.
loggedInUser=$(stat -f %Su /dev/console)
(The stat solution.) This certainly looks much shorter and simpler. But does it return the same in all situations? Is it actually the same?
I had a remote ssh session open from my main Mac while I logged two test users in and out of a second test Mac. I ran the commands for the SystemConfiguration and stat solutions in the ssh session, and compared the return values.
In (nearly) all multiple user sessions combinations that I tested, both the SystemConfiguration and the stat solution return the same value.
It is worth pointing out, that when you have two users with graphical sessions at the same time, neither of the two solutions will actually return the “currently” active user session, but the user owning the sessions that was last logged in to. This is especially relevant when someone use Screen Sharing to create a remote graphical session on an Mac. In this case both methods will return the last user that logged in, even though both users currently have active sessions.
How the stat solution works
The stat command shows the user owning the /dev/console file. When we look at that ‘file’ with the ls command:
> ls -al /dev/console
crw------- 1 armin staff /dev/console
We get a file type (the first character of the listing) of ‘c’ which represents a ‘character special file.’ All the ‘files’ in /dev are of this file type. When you look closely you will ‘files’ in here representing the disks connected to your Mac (disk*), the Bluetooth devices (cu.*), and some other weird ‘files.’
This stems back to the Unix underpinnings of macOS where everything has a representation in the file system hierarchy, whether it is actual data on a disk or not. The ‘files’ we are seeing here are an abstraction of devices and other objects in the system.
With that background in mind, it should be clear that we are looking at the same data from the system, abstracted in different ways. Either through the SystemConfiguration framework or the Unix file system. So, we get the same data either way, right?
The difference at login window
Not quite. I found one difference. When the Mac is at the login window, the SystemConfiguration solution returns an empty string and the stat solution returns root.
This is not the entire truth, though. When you look closely at the SystemConfiguration solution, you will that there is a clause, in both the python and scutil versions, that catches a return value of loginwindow and returns and empty string instead.
When you look at the raw output of the scutil command used, we actually get quite a lot of information:
The awk statement after the scutil command filters out the information we need:
awk '/Name :/ && ! /loginwindow/ { print $3 }'
This will return lines containing Name : and not containing loginwindow. In other words, if the scutil command returns loginwindow in the line, the entire scutil ... | awk ... construct will return nothing or an empty string.
When you leave out the extra awk clause to filter the loginwindow return value, you will get loginwindow while the login window is shown:
So, the SystemConfiguration solution returns loginwindow or nothing when the Mac is sitting at a login window and the stat solution returns root. Not a big deal right? I just have to consider this difference when I test whether a user is logged in?
I found one edge case (to the edge case) where this difference matters: the stat solution will return root when at the login window and when the root account or System Administrator is logged in.
Now, enabling the root account and logging in and working as root is most definitely not recommended on macOS. So, there is an argument that this edge case should not occur.
But users have a way of ignoring these kind of recommendations. The SystemConfiguration solution will allow your scripts to actually distinguish between a Mac sitting at the login window and the (admittedly rare but extremely dangerous) situation where a user is logged in as root.
Conclusions
So, in most cases the stat solution is identical to the SystemConfiguration solution. It has the advantage of being shorter and easier to read.
When you anticipate that you might need to distinguish between the computer being at the login window and a root user being logged in, or when you are just paranoid about catching all edge cases, the SystemConfiguration solution is more complete.
If in doubt, use the SystemConfiguration solution.
Update week! macOS Catalina 10.15.3 and the iOS 13.3.1 and other related updates dropped. And while the Catalina update seems to fix some things it also breaks others. Thanks to the all the contributors for the extra information that Apple does not provide.
Sarah: “Well, it’s racked. Looks kind of funny next to an Xserve though. https://t.co/BnKwR499VI” (Images)
Rosyna Keller: “Don’t use PackageMaker to make installer packages. It’s a long dead tool (2012 or so) and developers should switch to productbuild/pkgbuild*, which incorporate the command line utilization. It also can’t create signed packages. *Or is a third-party toool that scripts these. Installer packages are required to be signed to be notarized (so PackageMaker packages are out) and, as PackageMaker was a 32-bit app, it won’t run on Catalina. It’s that old.”
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!
