Tiny Deathstars of Foulness

Recently, I got a strange message when trying to run a command:

You have exceeded the maximum number of shell sessions.

I’d seen a series of commands but never really needed to use them, so I ran:


And viola, life was good. My command run. Of course, the next time I went to close the terminal correctly using the exit command. Upon doing so, I noticed:

Saving session…
…copying shared history…
…saving history…truncating history files…

[Process completed]


So, I opened a new shell and ran:


And go the same result. Same with:



November 8th, 2016

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

Tags: , , , ,

Automating OS installations is going to eventually be about as easy on macOS as it is in iOS (er, if you have MDM that is). But in the meantime, it’s getting a bit more challenging. The obvious way Apple would prefer this to happen these days is via the startosinstall command that first shipped with El Capitan and with brtool getting moved around all the time, and becoming less of a thing, there’s one quick and easy thing you can do:

sudo "/Applications/Install macOS" --applicationpath "/Applications/Install macOS" --agreetolicense --nointeraction --volume /Volumes/Macintosh\ HD

In the above command, we’ve dropped “Install macOS” on a machine. While you’d guess that it would find the application path based on its own surname, we went ahead and supplied it as that seems to basically be a thing. Basically, –agreetolicense keeps us from having to run some expect scripts to accept a license agreement, –nointeraction suppresses as many of the screens as possible, and –volume allows us to install to any volume we’d like. This isn’t fully automated, but I have been able to layer in some more logic to quit apps before the script fires and then expect out other items from the script to automate a restart, watching for osinstallersetupd as a key.

This is all a bit bulkier than just using something like createOSXinstallPkg but it’s important to mention that there are a number of system components that are allowed for in SIP that use osinstallersetupd and so this blessed mechanism is likely the future until you can trigger an OS upgrade (and update I suppose) using an MDM command.

October 23rd, 2016

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

Tags: , , , , , , ,

The software patching configuration built into most operating systems is configured so that all 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. OS X Server 5.2 (on Sierra), as with its macOS Server predecessors has a Software Update service. 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 service is actually comprised of three components. The first is an Apache server, invoked by the /Applications/ 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/, the LaunchDaemon for swupdate at /Applications/

Clients can be pointed at the server then via a Profile or using the defaults command to edit the /Library/Preferences/ file. The contents of this file can be read using the following command:

defaults read /Library/Preferences/

To point a client to a server via the command line, use a command such as the following:

sudo defaults write /Library/Preferences/ CatalogURL

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, click on the View menu in Server and select 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/ start swupdate

To stop the service, replace start with stop:

sudo /Applications/ 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/ fullstatus swupdate

The output of which appears as follows:

swupdate:state = "RUNNING"
swupdate:lastChecktime = 2016-08-07 01:25:05 +0000
swupdate:syncStatus = "INPROGRESS"
swupdate:syncServiceState = "RUNNING"
swupdate:setStateVersion = 1
swupdate:lastProductsUpdate = 2016-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.12"
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 = 2016-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/ settings swupdate:autoMirrorOnlyNew = yes

Also, the service can throttle bandwidth for clients. To use this option, run the following command:

sudo /Applications/ settings swupdate:limitBandwidth = yes

And configure bandwidth using the syncBandwidth option, as follows:

sudo /Applications/ 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/ 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/ settings swupdate:portToUse = 80

Finally, administrators can purge old packages that are no longer needed using the PurgeUnused option:

sudo /Applications/ settings swupdate:PurgeUnused = yes

One of the biggest drawbacks of the Software Update 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 while doing a little man in the middle protection would be a nice middle ground 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. I don’t know, maybe by creating the Caching service… 😉

October 10th, 2016

Posted In: Mac OS X, Mac OS X Server

Tags: , , , , ,

Apple developers in growing development teams invariably need a continuous integration system. This automates the build, analysis, and testing solution for software development using Xcode. macOS Server has an Xcode service, capable of integrating your developer account with git, providing many of the options required to build a continuous integration system.

Before you configure the Xcode service that can take committed code and then test and build your software, you’ll need an Apple developer account. The Xcode service then links git to a developer account and runs automations, referred to as bots, in Xcode. Therefore, you’ll also need to have Xcode installed on the computer running the Xcode service. Bots are then managed and reported on using a web app that the Server app runs.

Once the pre-requisites are met, open the Server app and click on the Xcode service.


Click on the Choose Xcode button.


When prompted, browse to the version of Xcode you have installed on the server.

Screen Shot 2015-09-24 at 10.11.46 PM

Configure the user account to use for the service.


The service will then require you to login. Do so when prompted.


This enables the user account, which you will then need to login as.


You’ll see a new user environment. Use fast user switching to then switch back to your other account. Xcode will require access to the Accessibility framework to run unit tests. Click on Request Access to provide the rights to Xcode to do so. Once access has been granted to Xcode, you’ll see the version indicated in the Build Using field.


Next, click on Add Team, in order to identify the correct team from your Apple Developer account that will have access to the Xcode service.


When prompted, select the team from your Apple Developer account that you wish to provide access to the server, note that you need to be a team agent or an administrator of the developer organization.


Click on the Repositories tab. Here, you will define repositories for your Xcode projects. Click on the Repository Access button to define what protocols git should be accessible via.


At the Repository Access screen, select HTTPS or SSH. Click OK.


Click the Edit Repository Creators button. At the Repository Access screen, add any groups of users that should have access to create new git repositories. Once all of the appropriate users or groups have been added, click on OK.



Select your repository again, and click on the HTTPS Access button to provide access via HTTPS. Once saved, double-click on the repository again to see the uri for each type of access. And that’s it.


Next, you’ll want to add a repository to the Xcode app. To do so, open Xcode and then use the Source Control menu to select Check Out. From there, you’ll get a Check Out screen.

Screen Shot 2015-09-25 at 7.04.42 PM

At the Check Out screen, enter the uniform the repository screen, shown in the previous step of this article and click on the Next button. Next, you’ll need to create bots to automate your build process.

October 8th, 2016

Posted In: Mac OS X Server, Programming

Tags: , , , , , , ,

There are a couple of ways to create groups in macOS Server 5.2, running on Sierra. The first is using the Server app, the second is using the Users & Groups System Preference pane and the third is using the command line. In this article we will look at creating groups in the directory service with the Server app.

Once a server has been an Open Directory Master all user and group accounts created will be in the Local Network Group when created in Server app. Before that, all user and group objects are stored locally when created in Server app. Once promoted to an Open Directory server, groups are created in the Open Directory database or if you select it from the directory domain drop-down list, locally. Groups can also be created in both locations, using a command line tool appropriate for group management.

 To create a new group, open the Server app and then click on Groups in the ACCOUNTS list of the Server app sidebar. From here, you can switch between the various directory domains accessible to the server using the drop-down list available. Click on the plus sign to create a local network group.
At the New Group screen, provide a name for the group in the Full Name field. This can have spaces. Then create a short name for the group in the Group Name field. This should not have spaces.
Click Done when you have supplied the appropriate information and the group is created. Once done, double-click on the group to see more options.
Here, use the plus sign (“+”) to add members to the group or highlight members and use the minus sign (“-“) to remove users from the group. You can also choose to use the following options:
  • Mailing Lists: Lists that are connected to the group.
  • Members: The users that are part of the group
  • Give this group a shared folder: Creates a shared directory for the group, or a group with an ACL that grants all group members access.
  • Make group members Messages buddies: Adds each group member to each other group members buddy list in the Messages client.
  • Enable group mailing list: Enables a list using the short name of the group where all members receive emails to that address.
  • Create Group Wiki: Opens the Wiki interface for creating a wiki for the group.
  • Keywords: Keywords/tags to help locate users.
  • Notes: Notes about users.

Once changes have been made, click Done to commit the changes.

October 7th, 2016

Posted In: Mac OS X Server

Tags: , , , , , , ,

There are a few ways to create users in macOS Server 5.2, running on Sierra. The first is using the Server app, the second is using using the Users & Groups System Preference pane and the third is using the command line. In this article we will look at creating users in the Server app.

To do so, open the Server app and connect to your server. Then click on the Users entry in the ACCOUNTS list. The list of users is displayed, based on the directory domain(s) being browsed. A directory domain is a repository of account data, which can include local users, local network users and users in a shared directory service such as Open Directory and Active Directory.


The drop-down list allows you to see objects that are stored locally as well as on a shared directory server. Therefore, clicking All Users will show all of the accounts accessible by the system. Click on the plus sign to create a new account. At this point, if the server has been promoted to an Open Directory Master, the account will be a local network account, with no way of choosing a different location to store the account in the Server app.


When prompted, provide the following information about the new user:

  • Full Name: Usually the first and last name of the user.
  • Account Name: A shorter representation of that name with no spaces or special characters.
  • Email address: The email address to use if the account is going over quotas, has calendar invitations sent, or used for email hosted on the server, etc.
  • Password: The password the user will use to access services on the server.
  • Verify: The password a second time to make sure there are no spelling errors.
  • Allow user to administer this server: Optional field that grants the user administrative access to the server.
  • Home Folder: Optional field that by default creates local home directories for users that use the account but that also allows you to select a directory shared using the File Sharing service as a location for home folders. Each user in OS X has a home folder, this option defines whether that folder will reside on their computer or on a central server.
  • Limit Disk Usage To: Define the amount of space an account can take up on servers.
  • Keywords: Keywords, or tags, for the user.
  • Notes: Any notes you want to enter into the user record.

Note: Optionally, you can also drag an image onto the image shown in the New User screen if you’d like the user to have an avatar.

Once the account details are as you would like, click on the Done button. The account will then be displayed in the list of available accounts. Once the account is created, highlight it and click on the cog wheel icon below the list of accounts. Here, you have the option to edit the account you just created, edit their access to services hosted on the server, configure email information and change their password.


Click Edit User. Here, you have two new features. You can add the user to groups and use the checkbox for “log in” to disable the account.


Click Cancel and then using the cog wheel menu again, click on Edit Access to Services. Here, uncheck each service that the user should not have access to. If the service isn’t running then it’s not a big deal. You can highlight multiple accounts concurrently and then use this option to disable services for users en masse.

October 6th, 2016

Posted In: Mac OS X, Mac OS X Server

Tags: , , , , , ,

macOS Sierra (10.12) running the Server app has a lot of scripts used for enabling services, setting states, changing hostnames and the like. Once upon a time there was a script for macOS Server 5.2 called serversetup. It was a beautiful but too simplistic kind of script. Today, much of that logic has been moved out into more granular scripts, kept in /Applications/, used by the server to perform all kinds of tasks. These scripts are, like a lot of other things in OS X Server. Some of these include the configuration of amavisd, docecot and alerts. These scripts can also be used for migrating services and data. Sometimes the scripts are in bash, sometimes ruby, sometimes perl and other times even python. And the scripts tend to change year over year/release over release. The easiest way to view logs is to use the Server app, clicking on Logs in the sidebar. The dropdown at the bottom of the screen provides quick access to service-based logs.

Screen Shot 2015-09-25 at 8.47.29 PM

One of the things that can can be useful about the scripts scattered throughout the Server app is to learn how the developers of macOS Server intend for certain tasks to occur. However, you can also use the Console app from /Applications/Utilities, as with any other Mac, to look at standard logs.

Screen Shot 2015-09-25 at 8.48.50 PM

Looking At Services

This is also where I learned that Apple had put an Open Directory backup script in /Applications/ (that still requires a password). But what I haven’t seen in all of these logs is bumping up the logging level for services before performing tasks, so that you can see a verbose output of what’s going on. To do this, it looks like we’re going service-by-service. So let’s look alphabetically, starting with Address Book:

sudo serveradmin settings addressbook:DefaultLogLevel = “warn”

This by defualt logs to /var/log/caldavd/error.log, which is built based on the following, which sets the base:

sudo serveradmin settings addressbook:LogRoot=/var/log/caldavd

And the following, which sets the file name in that directory:

sudo serveradmin settings addressbook:ErrorLogFile=error.log

You can change either by changing what comes after the = sign. Next is afp. This service logs output to two places. The first is with errors to the service, using /Library/Logs/AppleFileService/AppleFileServiceError.log, the path designated in the following:

sudo serveradmin settings afp:errorLogPath = “/Library/Logs/AppleFileService/AppleFileServiceError.log”

The second location logs activities (open file, delete file, etc) rather than errors and is /Library/Logs/AppleFileService/AppleFileServiceAccess.log, defined using:

sudo serveradmin settings afp:activityLogPath = “/Library/Logs/AppleFileService/AppleFileServiceAccess.log”

The activity log is disabled by default and enabled using the command:

sudo serveradmin settings afp:activityLog = yes

The events that trigger log entries are in the afp:loggingAttributes array and are all enabled by default. There are no further controls for the verbosity of the afp logs. The next service is calendar. Similar to address book, the caldav server uses DefaultLogLevel to set how much data gets placed into logs:

sudo serveradmin settings calendar:DefaultLogLevel = “warn”

This by defualt logs to /var/log/caldavd/error.log, which is built based on the following, which sets the base:

sudo serveradmin settings calendar:LogRoot=/var/log/caldavd

And the following, which sets the file name in that directory:

sudo serveradmin settings calendar:ErrorLogFile=error.log

You can changing either by changing what comes after the = sign.
Profile Manager is called devicemgr in the serveradmin interface and I’ve found no way to augment the logging levels. Nor does its migration script ( /Applications/ ) point to any increased logging during migration.

The dirserv (aka Open Directory) uses the slapconfig back-end, so I use slapconfig to increase logging:

sudo slapconfig -enableslapdlog

The DNS service uses named.conf, located in /etc to set log levels and has no serveradmin settings for doing so. Here, use the logging section and look for both the file setting (by default /Library/Logs/named.log) for where the log is stored as well as the severity setting, which can set the logging levels higher or lower.

By default Messages, or iChat Server, logs a lot. See the following for what is logged:

sudo serveradmin settings jabber:logLevel = “ALL”

Adding the -D option to the LaunchDaemon that invokes jabber will increase the logs. Logging long-term is handled in each of the xml files that make up the features of jabber. See the Logconfiguration section of the c2s file via:

cat /Applications/

The mail service has a number of options for logging, much of which has to do with the fact that it’s a patchy solution made up of postfix, etc. Global log locations are controlled using the mail:global:service_data_path key, which indicates a path that logs are stored in (as usual many of these are in /Library/Server):

sudo serveradmin settings mail:global:service_data_path = "/Library/Server/Mail"

To see the virus database logging levels (which should usually be set to warn):

sudo serveradmin settings mail:postfix:virus_db_log_level

To see the spamassassin logging levels:

sudo serveradmin settings mail:postfix:spam_log_level

To see the actual postfix logging level:

sudo serveradmin settings mail:postfix:log_level

To enable timestamps on logs:

sudo serveradmin settings mail:imap:logtimestamps = yes

To set the dovecot logging to info:

sudo serveradmin settings mail:imap:log_level = “info”

To set increased logging per function that dovecot performs, see the config files in /Applications/, each of which has a logging section to do so.

The NetBoot service is simple to configure logging for, simply set the netboot:logging_level to HIGH (by default it’s MEDIUM):

sudo serveradmin settings netboot:logging_level = “HIGH”

The Postgres service uses a log directory, configured with postgres:log_directory:

sudo serveradmin settings postgres:log_directory = “/Library/Logs/PostgreSQL”

The /private/etc/raddb/radiusd.conf has a section (log {}) dedicated to configuring how the radius service logs output.

The Xsan service logs output per volume to both the System Log and volume-based log files, stored in /Library/Preferences/Xsan/data.

The smb service has a file /Library/Preferences/SystemConfiguration/ with a key for log level that can be used for more verbose output of the service.

The PPTP VPN service logs output to the file specified in vpn:Servers, configured with these:

sudo serveradmin settings = “/var/log/ppp/vpnd.log”
sudo serveradmin settings = “/var/log/ppp/vpnd.log”
sudo serveradmin settings = “/var/log/ppp/vpnd.log”
sudo serveradmin settings = “/var/log/ppp/vpnd.log”

By default, verbose logging is enabled, which you can see with:

sudo serveradmin settings
sudo serveradmin settings
sudo serveradmin settings
sudo serveradmin settings

The last service is web (Apache). The default access logs are per-site, with a key called customLogPath existing for each. The defaultSite uses the following for its logs:

sudo serveradmin settings web:defaultSite:customLogPath

Swap out the defaultSite with another site to see its log paths. There’s also a key for errorLogPath that shows errors. These are per-site so that administrators can provide access to logs for the owners of each site and not fear them having access to logs for other users. Global error logs are stored in /private/var/log/apache2/error_log as defined in /private/etc/apache2/httpd.conf. Find LogLevel in this file and set it to configure how in depth the logs will be, using debug for the most verbose and info, notice, warn, error, crit, alert, and emerg to get incrementally less information.

Additionally the log formats can be set in /private/etc/apache2/httpd.conf, allowing administrators to configure OS X  Server’s built-in web service to conform to the standards of most modern web log analyzers.


Overall, there’s a lot of information in these logs and administrators can spend as much time reviewing logs as they want. But other than standard system logs, the output is typically configured on a service-by-service basis. Some services offer a lot of options and others offering only a few. Some services also offer options within the serveradmin environment while others use their traditional locations in their configuration files. I’ll end this with a warning. There can also be a lot of output in these logs. Therefore, if you set the logging facilities high, make sure to keep a watchful eye on the capacity of the location you’re writing logs out to. The reason I looked at paths to logs where applicable was because you might want to consider redirecting logs to an external volume when debugging so as not to fill up a boot volume and cause even more problems than what you’re likely parsing through logs looking to fix…

October 5th, 2016

Posted In: Mac OS X Server, Mac Security

Tags: , , , , , ,

I’ve written plenty about macOS Server over the years. But way more effort went into the official documentation from our friends at Apple. There’s lots of nuggets here at:

Screen Shot 2015-09-22 at 11.45.23 PM


September 29th, 2016

Posted In: Mac OS X Server

Tags: , , ,

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!

September 28th, 2016

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

Tags: , , , , , ,

Push Notifications can be used in most every service that macOS Server 5.2 (for Sierra) can run. Any service that requiring Push Notifications will often provide the ability to setup APNS during the configuration of the service. But at this point, I usually just set up Push Notifications when I setup a new server.
To enable Push Notifications for services, you’ll first need to have a valid AppleID. Once you have an AppleID, open the Server app and then click on the name of the server. Then click on the Settings screen and click on the checkbox for Notifications.


At the Settings screen for your server, click on the check-box for Apple Push Notifications (APN). Next, click on another screen and then click back to get the Edit Apple ID… button to appear. Click on Edit Apple ID…


At the Apple Push Notification Services certificate screen, enter an AppleID if you have not yet configured APNS and click on OK. The Apple Push Notification Service certificate will then be configured.


As you’ll see, if you’re editing a certificate, you’ll break any systems or services that use that certificate. For example, you would have to re-enroll all of your Profile Manager systems.


Then provide the AppleID and Password you’d like to use to generate the certificate.


The certificate is valid for one year, by default. Administrators receive an alert when the certificate is due to expire. To renew, open the same screen and click on the Renew button. Once you have generated a certificate, you’ll then be able to see the certificate in the Apple certificates portal.

September 18th, 2016

Posted In: Mac OS X Server, Mac Security

Tags: , , , , ,

« Previous PageNext Page »