The software patching configuration built into most operating systems is configured so all that a user has to do is open a box at home, join the network and start using the computer right away. As environments grow from homes to small offices and then small offices grow into enterprises, at some point software updates and patches need to be managed centrally.
macOS heavily leverages the App Store. This allows administrators to pretty much be hands off when it comes to managing updates. But some environments need to control the flow of updates anyway. Apple has had this ability since the early days of OS X and in macOS, you can still control software update servers, which look at XML feeds on Apple servers, and allows or denies access to those updates, and then optionally syncs updates to a server at your office. That’s called the Software Update service. Apple also has a service called Caching, now built into all client operating systems. The Caching service also caches apps from the App Store and optionally content. This is built into the Sharing System Preference pane.
The service in the Server app is known as Software Update and from the command line is known as swupdate.
The Software Update service, by default, stores each update in the /var/db/swupd directory. The Software Update servie is actually comprised of three components. The first is an Apache server, invoked by the /Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/com.apple.swupdate.host.plist LaunchDaemon. This LaunchDaemon invokes a httpd process and clients access updates from the server based on a manifest of updates available in the sucatalog.
These are synchronized with Apple Software Updates via /Applications/Server.app/Contents/ServerRoot/usr/sbin/swupd_syncd, the LaunchDaemon for swupdate at /Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/com.apple.swupdate.sync.plist.
Clients can be pointed at the server then via a Profile or using the defaults command to edit the /Library/Preferences/com.apple.SoftwareUpdate.plist file. The contents of this file can be read using the following command:
defaults read /Library/Preferences/com.apple.SoftwareUpdate.plist
To point a client to a server via the command line, use a command such as the following:
sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL http://osxserver.krypted.com:8088/index.sucatalog
But first, you’ll need to configure and start the Software Update service. Lucky you, it’s quick (although quick in a hurry up and wait kind of way). To get started, open the Server app and then click on the Software Update service.
By default, updates are set to simply mirror the Apple servers, by default, enabling each update that Apple publishes, effectively proxying updates. You can use the Manual button if you would like to configure updates to either manually be approved and manually synchronized or just manually approved but automatically copied from Apple. Otherwise click on the ON button and wait for the updates to cache to simply mirror the Apple servers.
If you would like to manually configure updates, click on the Manual option and then click on the Updates tab.
The first item in the Updates tab is the “Automatically download new updates” checkbox. This option downloads all of the updates but does not enable them. The Updates tab also displays all available updates. click on one and then click on the cog-wheel icon towards the bottom of the screen to configure its behavior (Download, Enable, Disable, Remove and View Update).
Note: The only option for updates in an Automatic configuration environment is disable.
The service can be managed using serveradmin. To start Software Update, use the start option, followed by the swupdate service identifier:
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin start swupdate
To stop the service, replace start with stop:
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin stop swupdate
To see the status of the service, including the location of updates, the paths to log files, when the service was started and the number of updates running, use the fullstatus option:
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin fullstatus swupdate
The output of which appears as follows:
swupdate:state = "RUNNING" swupdate:lastChecktime = 2015-08-07 01:25:05 +0000 swupdate:syncStatus = "INPROGRESS" swupdate:syncServiceState = "RUNNING" swupdate:setStateVersion = 1 swupdate:lastProductsUpdate = 2015-08-16 04:02:16 +0000 swupdate:logPaths:swupdateAccessLog = "/var/log/swupd/swupd_access_log" swupdate:logPaths:swupdateErrorLog = "/var/log/swupd/swupd_error_log" swupdate:logPaths:swupdateServiceLog = "/var/log/swupd/swupd_syncd_log" swupdate:readWriteSettingsVersion = 1 swupdate:pluginVers = "10.11" swupdate:checkError = no
swupdate:updatesDocRoot = "/Library/Server/Software Update/Data/" swupdate:hostServiceState = "RUNNING" swupdate:autoMirror = no swupdate:numOfEnabledPkg = 0 swupdate:servicePortsAreRestricted = "NO" swupdate:numOfMirroredPkg = 0 swupdate:autoMirrorOnlyNew = no swupdate:startTime = 2015-08-07 01:25:05 +0000 swupdate:autoEnable = no
There are also a number of options available using the serveradmin settings that aren’t exposed to the Server app. Available Settings include:
- swupdate:checkError = no
- swupdate:limitBandwidth = no
- swupdate:PurgeUnused = yes
- swupdate:portToUse = 8088
- swupdate:autoEnable = yes
- swupdate:valueBandwidth = 0
- swupdate:syncStatus = “Initializing” swupdate:autoMirror = yes
- swupdate:syncBandwidth = 0
- swupdate:updatesDocRoot = “/Library/Server/Software Update/Data/”
- swupdate:autoMirrorOnlyNew = no
These include a feature I used to use a lot in the beginning of deployments with poor bandwidth, only mirroring new updates, which is available to swupdate via the autoMirrorOnlyNew option. To configure:
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin settings swupdate:autoMirrorOnlyNew = yes
Also, the service can throttle bandwidth for clients. To use this option, run the following command:
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin settings swupdate:limitBandwidth = yes
And configure bandwidth using the syncBandwidth option, as follows:
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin settings swupdate:syncBandwidth = 10
To automatically sync updates but not enable them (as the checkboxes allow for in the Server app, use the following command:
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin settings swupdate:autoEnable = no
The port (by default 8088) can be managed using the portToUse option, here being used to set it to 80 (clients need this in their catalog URL from here on out):
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin settings swupdate:portToUse = 80
Finally, administrators can purge old packages that are no longer needed using the PurgeUnused option:
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin settings swupdate:PurgeUnused = yes
One of the biggest drawbacks of the Software Update service in OS X El Capitan Server in my opinion is the fact that it does not allow for serving 3rd party packages (not that Apple has much control over this, since these aren’t sourced from the App Store), from vendors such as Microsoft or Adobe. To provide those vendors with a manifest file and a quick little path option to add those manifest files, a nice middle ground could be found between the Mac App Store and the built in software update options in macOS. But then, we wouldn’t want to make it too easy.
Another issue many have had is that users need administrative passwords to run updates and don’t have them (technically this isn’t a problem with the macOS Server part of the stack, but it’s related).
While many options have come up for this, one is to just run the softwareupdate command for clients via ARD or a similar tool.
Many environments have used these issues to look at tools such as Reposado or third party patch management tools such as JAMF Software’s Jamf Pro (JAMF also makes a reposado-based VM that mimics the swupdate options), FileWave, and others (or a combination of some of these). Overall, the update service in Server 5 is easily configured, easily managed and easily deployed to clients but slowly being replaced with the App Store and release management via MDM-based commands.
krypted September 26th, 2017
Posted In: Mac OS X Server
App Store, Apple, macos, Software Update Service, Software Updates, SUS
I’ve written about SQLite databases here and there over the years. A number of Apple tools and third party tools for the platform run on SQLite and it’s usually a pretty straight forward process to get into a database and inspect what’s there and how you might programmatically interact with tools that store data in SQLite. And I’ll frequently use a tool like Navicat
to quickly and visually hop in and look at what happens when I edit data that then gets committed to the database.
But I don’t always have tools like that around. So when I want to inspect new databases, or at least those new to me, I need to use the sqlite3 command. First, I need to find the databases, which are .db files, usually stored somewhere that a user has rights to alter the file. For example, /Library/Application Support/My Product. In that folder, you’ll usually find a db file, which for this process, we’ll use the example of Data.db.
To access that file, you’d simply run sqlite3 with the path of the database, as follows:
sqlite3 /Library/Application\ Support/My\ Product/Data.db
To see a list of tables in the database, use .tables (note that a tool like Postgress would use commands like /tr but in SQLite we can run commands with a . in front and statements like select do not use those):
To then see a list of columns, use .schema followed by the name of a table. In this case, we’ll look at iOS_devices, which tracks the basic devices stored on the server:
The output shows us a limited set of fields, meaning that the UDID is used to link information from other tables to the device. I like to enable column headers, unless actually doing an export (and then I usually do it as well):
Then, you can run a standard select to see what is in each field, which in the below example would be listing all information from all rows in the myapptable table:
select * from myapptable;
The output might be as follows:
abcdefg|2017-01-26T17:02:39Z|Contents of field 3|Contents of field four
Another thing to consider is that a number of apps will use multiple .db files. For example, one might contain tables about users, another for groups, and another for devices in a simple asset tracking system. This doesn’t seem great at first, but I’ve never really judged it, as I don’t know what kind of design considerations they were planning for that I don’t know. If so, finding that key (likely GUID in the above example) will likely be required if you’re doing this type of reverse engineer to find a way to programmatically inject information into or extract information out of a tool that doesn’t otherwise allow you to do so.
krypted February 24th, 2017
Posted In: Mac OS X, SQL
App Store, apps, enumeration, GUID, inserting information, MAC, reverse engineering, select statements, sqlite, view headers
Installing OS X has never been easier than it got in Yosemite, when the installers were moved to the App Store. And since then it’s just gotten easier, and easier. In this article, we’ll upgrade a Mac from OS X 10.11 (El Capitan) to macOS Sierra (10.12), the latest and greatest. The first thing you should do is clone your system (especially if you’re upgrading a server). The second thing you should do is make sure you have a good backup. The third thing you should do is make sure you can swap back to the clone should you need to do so and that your data will remain functional on the backup. The fourth thing you should do is test that clone again…
Once you’re sure that you have a fallback plan, let’s get started by downloading “Install macOS Sierra” from the App Store. Once downloaded, you’ll see Install macOS Sierra sitting in LaunchPad, as well as in the /Applications folder.
Open the app and click Continue (provided of course that you are ready to restart the computer and install Sierra).
At the licensing agreement, click Agree (or don’t and there will be no Sierra for you).
At the pop-up click Agree again, unless you’ve changed your mind about the license agreement in the past couple of seconds (I’m sure it happens).
At the Install screen, click Install and the computer will reboot.
And you’re done. Now for the fun stuff!
krypted September 28th, 2016
Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment
App Store, Apple, install, MAC, macos, sierra, upgrade
Under the hood on iOS is a hard place to get; especially without bricking or jailbreaking a device. There are a few tools that can provide insight into what’s on a device, and about the device, though. One is an app called SysSecInfo, available at https://www.sektioneins.de/en/blog/16-05-09-system-and-security-info.html
Once installed, you’ll see how much CPU and memory are in use, and not in use, on your device.
Scroll down and tap on Process List to see a list of each process running on the device.
Tap Details towards the bottom of the screen to see more information about the OS build running on the device.
Overall, a handle little tool, with lots of information about devices, including how to derive whether the device has been jailbroken (although note that for each method of jailbreak detection, there’s a method for defeating detection).
krypted June 8th, 2016
Posted In: iPhone
App Store, devices, jailbreak detection, syssecinfo
The 4th Generation of the Apple TV supports installing apps. And part of playing around with new apps is sometimes you’re not going to want them on your TV any more. To remove apps, the process is similar to that of an iPad. Highlight an app that you’d like to remove and then hold down the clicker on the app.
The app will go a little larger. Click on it again and you’ll get the option to Delete the app.
Click Delete and the app disappears.
That’s it. The app, and any storage that is being consumed by the app, is then freed up.
krypted November 7th, 2015
Posted In: Apple TV
4th generation, App Store, Apple TV, apps, delete app, ios, MAC, Storage
Can I push out Apps without VPP?
Yes. You can push free apps to iOS devices without a VPP account. Paid apps of any kind will need a VPP account, as will free apps on Macs.
To Find Out The Answers To Other Common Questions About Apple’s Volume Purchase Program (VPP) and Bushel, Check Out The Bushel Blog Here
krypted May 19th, 2015
Posted In: Bushel
App Store, Apple, ios, MAC, mdm, purchases, vpp
You’ll use this Apple ID for the Volume Purchase Program (VPP) and the Device Enrollment Program (DEP). If this is your first time enrolling in any program on the Apple Deployment Programs website, you can create a new program agent account by following the steps below:
For More On Apple IDs and MDM, See The Bushel Blog
krypted March 27th, 2015
Posted In: Apps, Bushel, iPhone, JAMF
App Store, bushel, ios, itunes, MAC, mdm
Getting a bunch of iOS and Mac devices setup is more of a logistical challenge than a technical hurdle. When you buy a couple iPads, it’s pretty simple to set them up for the email, security settings and apps that you need those devices to have. You can put them all on a table, give them an Apple ID and then set them up identically to give to users. But the first time someone wipes a device, or looses a device that you need to wipe, you’ll have to do that manual labor again. And if you’re buying more than a couple of Apple devices, then the amount of time becomes amplified to manage all of these tasks. This is where a management solution comes into play.
For More On Device Management and How It Impacts Manual Labor Click Here
krypted March 20th, 2015
Posted In: Apple Configurator, Bushel
App Store, Apple, Automation, ios, MAC, manual labor
Merry Christmas ya’ll!
On the first day of Christmas my true love gave to me one 32 gig iPad
On the second day of Christmas my true love gave to me two bash one-liners
On the third day of Christmas my true love gave to me three Red Hat servers
On the fourth day of Christmas my true love gave to me four email blasts
On the fifth day of Christmas my true love gave to me five retweets
On the sixth day of Christmas my true love gave to me six regular expressions
On the seventh day of Christmas my true love gave to me seven lines of perl
On the eighth day of Christmas my true love gave to me eight app store apps
On the ninth day of Christmas my true love gave to me nine AWS instances
On the tenth day of Christmas my true love gave to me ten Active Directory forests
On the eleventh day of Christmas my true love gave to me 11 crappy python scripts
On the twelfth day of Christmas my true love gave to me 12 craft brews
krypted December 25th, 2014
Posted In: iPhone, Mac OS X, Mac OS X Server, Mac Security, Mass Deployment
Active Directory, amazon, App Store, apps, aws, bash, craft beer, ios, Linux, MAC, os x, perl, python, red hat, twitter
Next Page »
The good folks at Amsys
have built a nice little app called Services Test
for verifying outbound connectivity to critical services to make iOS devices work. If you are having problems connecting to these services or activating devices, simply open the App and tap on the play button in the upper right hand corner of the screen.
Click on the Info button to see what each of these servers do during the activation and management process.
The app can also test a few common server services, including connecting to an OS X Server, Casper and AirWatch. These are typical services used in an iOS and Mac environment.
Overall, this is a really nice little app for testing connectivity to typical iOS services and a very nice tool Amsys is providing to the community!
krypted January 17th, 2014
Posted In: iPhone
activation, amsys, App Store, can't activate, ios, iOS store, iPad, iPhone, itunes, MAC, Services test