Tiny Deathstars of Foulness

The directory services options in macOS has quietly been going through some slow changes over the past couple of years. Many of the tools we use to manage accounts look similar on the outside but sometimes work a little differently under the hood. Account information is still stored in the /var/db/dslocal/nodes directory. Here, the local directory service pulls files from within directories recursively when accountsd loads. You can still create a second instance of the local directory service by copying the Default directory. For example, here we’ll copy the Default directory node to a directory node called NEW:

sudo cp -prnv /var/db/dslocal/nodes/Default /var/db/dslocal/nodes/NEW

If you killall accountsd then wait (this is slower than doing a killall of DirectoryService was), you’ll then see and be able to use this new directory node:

<code>sudo killall accountsd</code>

This is one way to go about forklifting large collections of accounts from one system to another. The dsmemberutil account can still be used to obtain certain information from accounts. For example, you can check group membership by feeding in a uid with the -u option (here using the uid of 509) and a gid with the -g (here a gid of 10) option:

<code>dsmemberutil checkmembership -u 509 -g 10</code>

Each account still has a uuid. This can be obtained with -u for a user or -g for a group (ids):

<code>dsmemberutil getuuid -u 509</code>

And, you can use dsmemberutil to flush the directory services cache resolver, using the flushcache verb:

<code>dsmemberutil flushcache</code>

The files that comprise accounts can also be viewed and changed manually. Here, we’re going to just look at an account called charles:

<code>sudo defaults read /var/db/dslocal/nodes/Default/users/charles.plist</code>

If we used a tool like defaults, plistbuddy or plutil to manually augment one of these accounts, we’d also need to kill accountsd as we did earlier.

October 3rd, 2016

Posted In: Mac OS X, Mac OS X Server

Tags: , , , , , , ,

The swupd.plist file used to daisy chain multiple servers so they act as a cascade of software update servers. The new path for the property list is /Library/Server/Software Update/Config/swupd.plist. Here, the metaIndexURL key is sill the location that points to an internal Software Update Server that the server you are editing should look to for updates.

The default server is To set a server to look at another internal server for software updates, edit the metaIndexURL key in the /Library/Server/Software Update/Config/swupd.plist file to include the path to the new server. The path should always have /content/meta/mirror-config-1.plist after the FQDN of the host name. So if your internal software update server was called the command to set that as the upstream software update server would be:

defaults write /Library/Server/Software\ Update/Config/swupd metaiIndexURL “”

This is a minor change, but one that might be frustrating if you were still trying to cascade updates the old way. If you’re new to cascading updates, this is a pretty straight forward configuration change, run from a Terminal command. It’s also worth noting that there are a few other settings in this file that could come in handy. You can limit bandwidth using the limitBandwidth key, purge any old updates using the PurgeUnused key, set a max download speed using the maxDownloadSpeed key, configure the Software Update Server TCP port using the portToUse key (automatically set to 8088), change the path to the updates (e.g. if you mv them and then want to repoint to the new location without downloading them all again) using the updatesDocRoot key, etc. Overall, the settings align with the old settings, but just in a new place.

Note: The keys above correspond to settings found in the following command:

sudo serveradmin settings swupdate

The list of settings is as follows:

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

October 31st, 2014

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

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

OS X Mavericks Server (Server 3) comes with the /usr/sbin/serverinfo command (introduced in Mountain Lion Server). The serverinfo command is useful when programmatically obtaining information about the very basic state of an Apple Server.

The first option indicates whether the Server app has been downloaded from the app store, which is the –software option:

serverinfo --software

When used, this option reports the following if the can be found:

This system has server software installed.

Or if the software cannot be found, the following is indicated:

This system does NOT have server software installed.

The –productname option determines the name of the software app:

serverinfo --productname

If you change the name of the app from Server then the server info command won’t work any longer, so the output should always be the following:


The –shortversion command returns the version of the Server app being used:

serverinfo --shortversion

The output will not indicate a build number, but instead the version of the app on the computer the command is run on:


To see the build number (which should iterate with each update to the Server app from the Mac App Store, use the –buildversion option:

serverinfo --buildversion

The output shows the build of server, which doesn’t necessarily match the OS X build number:


Just because the Server app has been downloaded doesn’t mean the Server setup assistant has been run. To see if it has, use the –configured option:

serverinfo --configured

The output indicates whether the system is running as a server or just has the app installed (e.g. if you’re using it to connect to another server:

This system has server software configured.

You can also output all of the information into a single, easy to script against property list using the –plist option:

serverinfo --plist

The output is a list of each of the other options used:

IsOSXServerVolume IsOSXServerVolumeConfigured IsServerHardware



The Server Root can reside in a number of places. To see the path (useful when scripting commands that are relative to the ServerRoot:

serverinfo –prefix

By default, the output is as follows, which is basically like a dirname of the ServerRoot:


You can also see whether the system is running on actual hardware desgnated by Apple for servers using the –hardware option:

serverinfo --hardware

The output simply indicates if the hardware shipped with OS X Server on it from Apple:

This system is NOT running on server hardware.

The –perfmode option indicates whether or not the performance mode has been enabled, dedicating resources to binaries within the Server app:

serverinfo --perfmode

If the performance mode has not been enabled then the output will be as such:

Server performance mode is NOT enabled.

To enable performance mode, you can also use serverinfo. This is the only task that the command does that can make any changes to the system and as such is the only time you need to elevate privileges:

sudo serverinfo —setperfmode 1

Or set the boolean value back to 0 to disable.

sudo serverinfo —setperfmode 0

October 22nd, 2013

Posted In: Mac OS X Server

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

You can obtain a pretty decent amount of information about leases your OS X computer gets just by looking in the Network System Preference pane, for each interface.
Screen Shot 2013-10-02 at 10.16.16 PM
However, you can get a little lot more information, as with most things, from the command line. First, we’re going to take a look at en0 on our host and see what the MAC address is:

ifconfig en0 ether

Now, we can look in the /var/db/dhcpclient/leases directory to see a list of all of the leases we have running on our system. Based on the MAC address of our computer, we should see a file there that starts with the name of our interface and finishes with our MAC address. Let’s cat this file:

cat en0-1\,84\:38\:35\:63\:87\:2e

The output is similar to the following (a standard plist):

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “”>
<plist version=”1.0″>

This shows us the amount of time our lease is valid for, when the lease what provided to us, what IP was provided and the IP of our router. We can then key off of that information as needed (e.g. for other scripts/tools).

October 7th, 2013

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

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

You can remotely start ARD with kickstart, which I have previously covered at length. But Screen Sharing is a bit of a different little beast. To start up Screen Sharing, you can just use the following command:

echo -n enabled > /Library/Preferences/

I still prefer kickstart, but this method functions when you need something quick and easy. To then disable Screen Sharing, you can just toss the launchd item:

rm /Library/Preferences/

Once you have Screen Sharing started, you can then open the Screen Sharing application from a client by using the open command, followed by the protocol, which would be vnc and then the IP address. As with FTP you can also inject the user name and password into the open, following the //, by placing the user name followed by a colon (:) followed by the password and then the @ symbol (all before the IP address). For example, to connect to a computer with an IP address of using the username of krypted and the password of mypass you would use the following command.

open vnc://krypted:mypass@

You may encounter an encryption error, which if you are attempting to script can be annoying to click on. To suppress it, use defaults to set the dontWarnOnVNCEncryption key of the to True:

defaults write dontWarnOnVNCEncryption -bool TRUE

Have fun!

January 26th, 2010

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

Tags: , , , , , , ,

PlistCheck is a very small, very fast application that checks preferences (aka – property lists) to make sure that they are properly formatted. There are a few other tools out there that do this and it’s easier to just use the command line, but if you are not command line savvy (or working with someone who isn’t) then you can use this tool to check property lists (preferences) rather than using the command line to do so.

Click here to Download PlistCheck

PlistCheck will be made available on the Apps page as well.

January 21st, 2010

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

Tags: , , ,

Address stores its preferences in the following property list files in ~/Library/Preferences:

The Address Book data itself is stored in ~/Library/Application Support/AddressBook, Here you will find:
  • The SQL Lite database (*.abcddb).
  • Any images associated with addresses are located in the Images folder in that directory
  • Any contacts synchronized (ie – from Address Book services of Mac OS X Server to the local computer are synchronized into the Sources directory (into the .abcddb file located there)
  • Any metadata associated with the contacts in the Metadata directory
  • The MailRecents-v4 file, which contains a cache of the most recently used email addresses
  • A Configuration.plist property list that has the settings for that specific database.

You can interact with the Address Books programatically using sqlite3, which I covered a little while back. You can also interact with it from the API layer.

December 2nd, 2009

Posted In: Mac OS X

Tags: , , ,