krypted.com

Tiny Deathstars of Foulness

By default, screenshots are pretty big on a retina display on a High Sierra machine. Like about 4 times the size they should be. I haven’t found a defaults key I can use yet to reduce them, so I’ve been using this little screenshotting app called RetinaCapture, available at https://gumroad.com/l/retinacapture. Basically, when you’re running it, you just open it up and click on the Window button. There, you can select a window to screenshot.
Screen Shot 2015-09-24 at 8.37.33 AM
Once you’ve selected the window, you’ll be prompted to save it somewhere with a name.

Screen Shot 2015-09-24 at 8.38.00 AM

I don’t love having to use any 3rd party apps for my screenshotting workflow. In fact, it bugs the crap out of me. Screens get resized by publishers for books and so I’m really only using this for my site. But, hopefully it helps someone else along the way. Happy screenshotting!

September 8th, 2017

Posted In: Mac OS X, Mass Deployment

Tags: , ,

2 Comments

If you’re in need of MDM in Japanese or German, Jamf Now shipped support for those languages last week. To switch languages, click on your name once logged in, and then click on the language you would like to use. Enjoy.

May 1st, 2017

Posted In: iPhone, Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , ,

April 23rd, 2017

Posted In: iPhone, MacAdmins Podcast, Mass Deployment

Tags: , , , ,

There’s a macOS tool called AssetCacheLocatorUtil located at /usr/bin/AssetCacheLocatorUtil. The output is in… stderr. Because stderr is so fun to work with (note that sed -i only works with stdin). So, to update the caching server(s) you are using and only print the IP address of those, you’d do the following: /usr/bin/AssetCacheLocatorUtil 2>&1 | grep guid | awk '{print$4}' | sed 's/^\(.*\):.*$/\1/' | uniq If you use Jamf Pro and would like to use this as an extension attribute, that’s posted here: https://github.com/krypted/cachecheck. I didn’t do any of the if/then there, as I’d usually just do that on the JSS.

April 17th, 2017

Posted In: Mac OS X, Mac Security, Mass Deployment, Network Infrastructure, precache

Tags: , , , , , , , , , ,

There are two useful commands when scripting operations that involve filenames and paths. The first of these is dirname: dirname can be used to return the directory portion of a path. The second is basename: basename can be used to output the file name portion of a path. For our first example, let’s say that we have an output of /users/krypted, which we know to be the original short name of my user. To just see just that username, we could use basename to call it: basename /users/charlesedge Basename can also be used to trim output. For example, let’s say there was a document called myresume.pdf in my home folder and we wanted to grab that without the file extension. We could run basename using the -s option, followed by the string at the end that we do not want to see to output of (the file extension: basename -s .pdf /users/charlesedge/myresume.pdf The dirname command is even more basic. It outputs the directory portion of the file’s path. For example, based on the same string, the following would tell you what directory the user is in: dirname /users/charlesedge A great example of when this gets more useful is keying off of currently active data. For example, if we’re scripting a make operation, we can use the which command to get an output that just contains the path to the make binary: which make We can then wrap that for expansion and grab just the place that the active make binary is stored: dirname `which make` This allows us to key other operations off the path of an object. A couple of notable example of this is home or homeDirectory paths and then breaking up data coming into a script via a positional parameter (e.g. $1). You can also use variables as well. Let’s say that homedir=/users/krypted ; dirname $homedir Finally, keep in mind that dirname is relative, so if you’re calling it for ~/ then you’ll see the output at that relative path.

April 5th, 2017

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , ,

There is a new service in macOS, called Tetherator. Tethered-caching is a script that allows you to easily and quickly interact with the tethered-caching service, which has a few kinda’ cool options. This is on a client, and really speeds up all that crazy provisioning stuff you do. It can also check for the presence of a macOS Caching Server and use that as a source for the cache. The tethered-caching script is located at /usr/bin/tethered-caching. Before you do anything with the service, check the status. That’s done with the -s option (there’s also a -v option to get verbose): tethered-caching -s The results before activated should be as follows:
2017-02-28 10:44:45.730 AssetCacheTetheratorUtil[3665:182657] Tetherator is disabled: (no error) 2017-02-28 10:44:45.746 AssetCacheActivatorUtil[3666:182664] Built-in caching server can be activated. 2017-02-28 10:44:45.762 AssetCacheActivatorUtil[3667:182673] Built-in caching server is deactivated: (no error)
Then start the service using the -n option in tethered-caching, along with the IP range to be used: tethered-caching -n 192.168.1.0 This sets the ListenRanges key in the plist and should result in an activation process that appears as follows:
Starting tethered caching… 2017-02-28 10:47:59.691 AssetCacheActivatorUtil[3848:192902] Built-in caching server can be activated. 2017-02-28 10:47:59.706 AssetCacheActivatorUtil[3849:192910] Built-in caching server is deactivated: (no error) Filtering the log data using “subsystem == “com.apple.AssetCache” AND messageType == 16″ Timestamp (process)[PID] 2017-02-28 10:48:05.098735-0600 localhost AssetCache[2882]: [com.apple.AssetCache.builtin] Built-in Caching Server activated. Exiting to allow re-launch. 2017-02-28 10:48:05.207493-0600 localhost AssetCache[2882]: [com.apple.AssetCache.builtin] Built-in Caching Server shutting down (0) 2017-02-28 10:48:07.362926-0600 localhost AssetCache[3862]: [com.apple.AssetCache.builtin] Built-in Caching Server version 170 started 2017-03-02 10:45:53.753 AssetCacheTetheratorUtil[29283:2526186] Tetherator enabled. Started tethered caching. To stop it, press control+c once.
At this point, you’re calling /usr/bin/AssetCacheLocatorUtil to register and then start /usr/libexec/AssetCache/AssetCache via /System/Library/Preferences/Logging/Subsystems/com.apple.AssetCacheServices.plist which defaults read nets: {Activator = {}; "DEFAULT-OPTIONS" = { "Default-Privacy-Setting" = Public; "Enable-Oversize-Messages" = 1; "Event-Log" = { Enabled = Inherit;}; Level = { Enable = Inherit; Persist = Inherit;}; TTL = {Debug = 0;Default = 10;Info = 10;};}; Daemon = {}; Extensions = {}; Framework = {}; Tetherator = {};} The AssetCache preferences can be seen by catting /Library/Preferences/com.apple.AssetCache.plist: Activated = 0; CacheLimit = 0; DataPath = "/Library/Caches/com.apple.AssetCache"; LastConfigData = ; LastConfigURL = "http://suconfig.apple.com/resource/registration/v1/config.plist"; LastPort = 50775; ListenRanges = ({first = "192.168.1.1";last = "192.168.1.254";}); ListenRangesOnly = 1; LocalSubnetsOnly = 0; PeerLocalSubnetsOnly = 1; Port = 0; PublicRanges = automatic; ReservedVolumeSpace = 2000000000; SavedCacheDetails = {}; SavedCacheDetailsOrder = ("Mac Software","iOS Software","Apple TV Software",iCloud,Books,"iTunes U",Movies,Music,Other); SavedCacheDetailsStrings = {All the language keys as arrays - which I cut out to truncate the contents of the plist read}; SavedCacheSize = 0; ServerGUID = "C5F29418-6158-4D3B-9162-XXX"; Version = 1; Note that in the above, the LastConfigData key is pulled at activation by curling http://suconfig.apple.com/resource/registration/v1/config.plist. I’ve truncated the key as it’s kinda’ long… A simple command that will be pretty common is to increase the size of the cache. To do so, you’d just edit that CacheLimit key to be the number that you want the cache to be. In the following example, we’re writing the CacheLimit key into AssetCache.plist at 100 gigs: defaults write /Library/Preferences/com.apple.AssetCache.plist CacheLimit -int 100000000000 There’s also com.apple.AssetCache.builtin.plist in /Library/LaunchDaemons which starts the builtin AssetCache, AssetCacheC, and CacheDelete service. Once started, you will have a sqlite3 database called AssetInfo.db at /Library/Caches/com.apple.AssetCache. A basic structure of how data is stored includes the following tables:
  • ZAFFINITY with the following column: Z_PK INTEGER PRIMARY KEY, Z_ENT INTEGER, Z_OPT INTEGER, ZLASTSAVED TIMESTAMP, ZID VARCHAR
  • ZASSET with the following columns: Z_PK INTEGER PRIMARY KEY, Z_ENT INTEGER, Z_OPT INTEGER, ZMD5OFFSET INTEGER, ZTOTALBYTES INTEGER, ZCREATIONDATE TIMESTAMP, ZLASTACCESSED TIMESTAMP, ZCHECKSUM VARCHAR, ZGUID VARCHAR, ZINDEX VARCHAR, ZLASTMODIFIEDSTRING VARCHAR, ZNAMESPACE VARCHAR, ZURI VARCHAR, ZMD5CONTEXT BLOB
  • Z_METADATA with the following columns: Z_VERSION INTEGER PRIMARY KEY, Z_UUID VARCHAR(255), Z_PLIST BLOB
  • Z_MODELCACHE with just the Z_CONTENT column
  • TABLE Z_PRIMARYKEY with the following columns: Z_ENT INTEGER PRIMARY KEY, Z_NAME VARCHAR, Z_SUPER INTEGER, Z_MAX INTEGER
Once enabled, updates will be cached to the computer that the service is enabled on, metadata stored in the previously mentioned database, and then change ports and network ranges when needed.

March 27th, 2017

Posted In: Apple Configurator, Apple TV, Apple Watch, iPhone, JAMF, Mac OS X, Mac OS X Server, Mass Deployment, precache

Tags: , , ,

I originally wrote this back in 2015 as an article for troubleshooting APNs traffic on a Profile Manager server. But it turns out that troubleshooting push notification communications between macOS Server and Apple’s Push Notification is basically the same as troubleshooting the apsd client on macOS. Basically, we’re gonna’ put the APNs daemon, apsd, into debug mode. To enable APNS debug logging, run these commands: defaults write /Library/Preferences/com.apple.apsd APSLogLevel -int 7 defaults write /Library/Preferences/com.apple.apsd APSWriteLogs -bool TRUE killall apsd Then use tail -f to watch the apsd.log file at /Library/Logs/apsd.log. Be wary, as this can fill up your system. So to disable, use these commands: defaults write /Library/Preferences/com.apple.apsd APSWriteLogs -bool FALSE defaults delete /Library/Preferences/com.apple.apsd APSLogLevel killall apsd

February 9th, 2017

Posted In: Mac OS X, Mac OS X Server, Mass Deployment

Tags: , , , ,

As promised, here’s the slide deck from my talk at MacAD.UK in London. Enjoy! MacADUK_MDM_2017

February 7th, 2017

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

OS X Server stores most logs in files that are in the /Library/Logs/ProfileManager directory. Logs are split up between php, devicemgrd.log, scep_helper.log, servermgr_devicemgr.log, profilemanager.log and others. In my experience, if there’s a lot of errors at first, or if the service doesn’t work, just reformat and start over. But, once a server is in production, you don’t want to re-enroll devices after you do that. So, as with all good error prodding, start with the logs to troubleshoot. By default the logs can appear a bit anemic. You can enable more information by increasing the logging level. Here, we’ll shoot it up to 6, which can be done with the following command: sudo debugDeviceMgr 6 Debug levels go all the way to 9, but at that point things get… Noisy. And to turn it back off, use: sudo debugDeviceMgr 1 Basically, this command sets the required services in /Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/ to debug mode as well as /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/config/com.apple.DeviceManagement.postgres-debug.plist and /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/config/com.apple.DeviceManagement.postgres.plist to configure debug mode. In other words, it touches a lot of services. And given how chatty some can be, only leave logging levels higher than I’d say 2 in the event of short-term troubleshooting.

December 29th, 2016

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , ,

By default, OS X now updates apps that are distributed through the Mac App Store (MAS). Server running on macOS Sierra is really just the Server app, sitting on the App Store, installed on a standard Mac. If the Server app is upgraded automatically, you will potentially experience some adverse side effects, especially if the app is running on a Metadata Controller for Xsan, runs Open Directory, or a major release of the Server app ships. Additionally, if you are prompted to install a beta version on a production system, you could end up with issues. Therefore, in this article we’re going to disable these otherwise sweet features of OS X. To get started, first open the System Preferences. From there, click on the App Store System Preference pane. screen-shot-2016-09-25-at-5-01-45-pm From the App Store System Preference pane, uncheck the following boxes:
  • Automatically Check For Updates: Unchecking this box disables the download in the background option and the installation of app updates.
  • Automatically Download Apps Purchased on Other Macs: If you buy an upgrade, you could accidentally install that upgrade on production servers you don’t intend to install the upgrade on.
Once disabled, you’ll need to keep on top of updates in the App Store manually. My recommendation is still to create an image of your server before each update. If you see the field, click Change for “Your computer is set to receive beta software updates” and then click screen-shot-2016-09-25-at-5-04-39-pm You can also set these from the command line. To disable automatic app store updates: defaults write /Library/Preferences/com.apple.commerce AutoUpdate -bool FALSE To disable automatic macOS updates: defaults write /Library/Preferences/com.apple.commerce AutoUpdateRestartRequired -bool FALSE And to disable automatic Software Update update checks: defaults write /Library/Preferences/com.apple.SoftwareUpdate AutomaticCheckEnabled -bool FALSE Overall, be careful with automatic updates. I like leaving checking enabled so when I sit down at the console of a server I get prompted to update; however, I don’t want servers updating and restarting unless I tell them to, after I’ve performed a comprehensive regression test on the updates.

September 29th, 2016

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , ,

Next Page »