Install MacOS updates remotely via Command Line over SSH

Automating OS updates can be an important part of OpSec. Here’s a quick script to enable automatic OS updates on MacOS:

See if Mac OS updates are installed by going to System Preferences > Software Updates > Advanced.

You want “Install MacOS updates” to be checked.

But you can also check this via the Command Line (when accessing remote devices via SSH, for example).

% sudo defaults read /Library/Preferences/

You should see a plist that includes:

AutomaticallyInstallMacOSUpdates = 0;

To enable “Install MacOS updates”

% sudo defaults write /Library/Preferences/ AutomaticallyInstallMacOSUpdates -boolean TRUE

And it should now be enabled, indicated by

AutomaticallyInstallMacOSUpdates = 1;

    AutomaticCheckEnabled = 1;
    AutomaticDownload = 1;
    AutomaticallyInstallMacOSUpdates = 1;
    LastAttemptBuildVersion = "12.1 (21C52)";
    LastAttemptSystemVersion = "12.1 (21C52)";
    LastBackgroundSuccessfulDate = "2022-01-25 15:33:22 +0000";
    LastFullSuccessfulDate = "2022-01-25 20:41:17 +0000";
    LastRecommendedMajorOSBundleIdentifier = "";
    LastRecommendedUpdatesAvailable = 0;
    LastResultCode = 2;
    LastSessionSuccessful = 1;
    LastSuccessfulDate = "2022-01-25 20:41:21 +0000";
    LastUpdatesAvailable = 0;
    PrimaryLanguages =     (
    RecommendedUpdates =     (

And also represented with a checkbox in the SoftwareUpdate GUI.

You can now run “softwareupdate” from the command line to update MacOS:

% sudo softwareupdate --install --os-only --restart

Now you can automate your script to remotely check (and enable) automatic software updates on MacOS.

Optimizing test setup and cleanup for performance

There is an interesting post from Andrejs Doronins on LinkedIn about improving test performance:

I replied and added my own comments below:

Remember though, that execution time is trivial compared to development, maintenance, and debugging.

So if you’re adding what seems like extra effort that slows down execution to have a clean environment and setup each time — the savings on reliable tests that pass consistently and find errors that tests that don’t “start from scratch” won’t find is so much greater.

That said — you can be smart in your initialization.

Things like initializing your database with common data only once before a test run, instead of on every test case. Or modifying environment configuration only for a specific suite that needs it can save valuable time compared to doing it for each test.

But this optimizations are sometimes not apparent when you write the tests — or may only apply to 1 test at first, and only become generalized as your test coverage grows.

The trouble here is, that rarely do you have time to go back and review working tests or a test framework to consider how you could optimize.

In this regard, once again, test code imitates production code.

Tonga volcano eruption felt in Fiji

I was shocked and saddened to hear of the destructive volcanic eruption in Tonga. And while international news has concentrated on possible tsunami effects thousands of miles away in Japan or California, my thoughts and prayers go out to the people of the South Pacific islands, especially Fiji where I lived and have friends.

It looks like the impact on Viti Levu (at least) was not severe but there is little information about what has happened in Tonga where communication has been cut off.

Lau group, being closer to Tonga has seen clouds of ash and debri. And the explosion was heard as far away and Nadi and the Yasawas.

I’d love more information from people in Fiji, Tonga , or other islands in the area.

Here is some interesting information from Fiji talking about the force of the shockwave measure in the air pressure and water levels in Suva:

The Fiji Sun and Fiji Times have articles about the local effects:

Power and communications to Tonga have been cut off.

Ash clouds and heat in Labeka, Lau–5xr8f4/

Tidal surge from Tsunami:

Flights canceled in Fiji due to volcanic ash clouds:

Security. Quality. Simplicity.

Logging should be simple. Probably simpler than it is. The recent spate of Log4j vulnerabilities demonstrates that.

What else in your tech stack is over-engineered or exposed?

Your quality and security strategy should be:

How can we simplify?
Can we simplify without losing features?
Will simplifying actually improve features and usability?

#security #quality #simplify