Tiny Deathstars of Foulness

Note: before you do anything with clearing nvram, keep in mind that doing so clears any kext whitelisting you may have done previously!

macOS has the ability to delete all of the firmware variables you’ve created. This can get helpful if you’ve got a bunch of things that you’ve done to a system and want to remove them all. If you run nvram followed by a -p option you’ll see all of the configured firmware variables:

nvram -p

The output would be as follows:

efi-boot-device-data %02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%05%1c%01%01%06%00%00%00%03%12%0a%00%00%00%00%00%00%00%04%01*%00%02%00%00%00(@%06%00%00%00%00%00X%a8#:%00%00%00%00%eee6%da%00%0b%09G%82%c9%bd4wpQ%82%02%02%04%03$%00%f7%fct%be|%0b%f3I%91G%01%f4%04.hBw;%1a$%82%a3>D%92#%80%e9o%a9!%de%04%04%9a%00\%00A%003%000%006%00A%004%00F%00D%00-%00F%00F%00B%005%00-%003%00F%00A%002%00-%008%00D%00C%004%00-%00B%00F%007%003%00E%007%00F%003%008%00C%007%00E%00\%00S%00y%00s%00t%00e%00m%00\%00L%00i%00b%00r%00a%00r%00y%00\%00C%00o%00r%00e%00S%00e%00r%00v%00i%00c%00e%00s%00\%00b%00o%00o%00t%00.%00e%00f%00i%00%00%00%7f%ff%04%00

efi-boot-device <array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>241A3B77-A382-443E-9223-80E96FA921DE</string></dict></dict><key>BLLastBSDName</key><string>disk1s2</string></dict><dict><key>IOEFIDevicePathType</key><string>MediaFilePath</string><key>Path</key><string>\A306A4FD-FFB5-3FA2-8DC4-BF73E7F38C7E\System\Library\CoreServices\boot.efi</string></dict></array>%00BootCampProcessorPstates %0c%00 bluetoothInternalControllerInfo %90%82%ac%05%00%000%14%f4\%89%adF%f prev-lang:kbd en:0 SystemAudioVolumeDB %e4
efi-apple-recovery <array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>3D351489-745F-4434-89E0-DC914B49969F</string></dict></dict><key>BLLastBSDName</key><string>disk0s1</string></dict><dict><key>IOEFIDevicePathType</key><string>MediaFilePath</string><key>Path</key><string>\EFI\APPLE\FIRMWARE\MBP121_0171_B00.fd</string></dict></array>%00
previous-system-uuid A306A4FD-FFB5-3FA2-8DC4-BF73E7F38C7E
bluetoothActiveControllerInfo %90%82%ac%05%00%00%00%000%14%f4\%89%adF%fa
ALS_Data ^%0d%8a%8a%00%00%00%00
backlight-level %10%02
SystemAudioVolume G
LocationServicesEnabled %01

If you run it with a -d you’ll delete the given variables that you define (e.g. boot-args): 

nvram -d boot-args

But, if you run the -c you’ll wipe them all:

nvram -c

September 27th, 2017

Posted In: Mac OS X

Tags: , ,

macOS Server 5.4 (for High Sierra)  comes with the /usr/sbin/serverinfo command (which was originally 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: Server 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 macOS 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: <?xml version=”1.0″ encoding=”UTF-8″?> <!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “”> <plist version=”1.0″> <dict> <key>IsOSXServerVolume</key> <true/> <key>IsOSXServerVolumeConfigured</key> <true/> <key>IsServerHardware</key> <false/> <key>LocalizedServerProductName</key> <string>Server</string> <key>MinimumServerVersionAllowed</key> <string>5.3.55</string> <key>ServerBuildVersion</key> <string>17S1180a</string> <key>ServerPerformanceModeEnabled</key> <false/> <key>ServerVersion</key> <string>5.3</string> </dict> </plist>

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.
Note: Performance mode doesn’t seem to be support any longer, as none of the options will actually enable the service.

September 27th, 2017

Posted In: Mac OS X Server

Tags: , , , , , , ,

macOS Server has long had a VPN service to allow client computers to connect to a network even when they’re out of the home or office. And as with many a service on macOS Server, this is one of the easiest VPN servers you’ll ever setup. The server was once capable of running the two most commonly used VPN protocols: PPTP and L2TP. And while PPTP is still accessible via the command line, L2TP is now configured by default when you setup the server using the Server app.

Setting Up The VPN Service In macOS Server

To setup the VPN service, open the Server app and click on VPN in the Server app sidebar. The VPN Settings  screen has a number of options available, as seen here.

The VPN Host Name field is used by administrators leveraging profiles. The setting used becomes the address for the VPN service in the Everyone profile. L2TP requires a shared secret or an SSL certificate. In this example, we’ll configure a shared secret by providing a password in the Shared Secret field. Additionally, there are three fields, each with an Edit button that allows for configuration:
  • Client Addresses: The dynamic pool of addresses provided when clients connect to the VPN.
  • DNS Settings: The name servers used once a VPN client has connected to the server. As well as the Search Domains configuration.
  • Routes: Select which interface (VPN or default interface of the client system) that a client connects to each IP address and subnet mask over.
  • Save Configuration Profile: Use this button to export configuration profiles to a file, which can then be distributed to client systems (macOS using the profiles command, iOS using Apple Configurator or both using Profile Manager).
  • Shared Secret: A passphrase that must be supplied by the client prior to getting a username and password prompt.
Once configured, open incoming ports on the router/firewall. While deprecated(ish) PPTP runs over port 1723. L2TP is a bit more complicated, running over 1701, but also the IP-ESP protocol (IP Protocol 50). Both are configured automatically when using Apple AirPorts as gateway devices. Officially, the ports to forward are listed at

Using The Command Line

I know, I’ve described ways to manage these services from the command line before. The serveradmin command can be used to manage the service as well as the Server app. The serveradmin command can start the service, using the default settings, with no further configuration being required:

sudo serveradmin start vpn

And to stop the service:

sudo serveradmin stop vpn And to list the available options:

sudo serveradmin settings vpn

The output of which shows all of the VPN settings available via serveradmin (which is many more than what you see in the Server app:

vpn:vpnHost = "" = "/var/log/ppp/vpnd.log" = 1 = 128 = "jamfsw.corp" = "" = "" = "" = "1" = "" = "2" = "" = "vpn/" = no = "PPTP" = "PPP" = 5 = 1 = "EAP-RSA" = "DSACL" = 1 = 0 = 1 = 1 = 60 = 1 = "MSCHAP2" = 0 = "DSAuth" = "/var/log/ppp/vpnd.log" = 1 = 7200 = "MPPE" = _empty_array = "" = "" = _empty_array = _empty_array = "Manual" = "" = 128 = 0 = "/var/log/ppp/vpnd.log" = 1 = "jamfsw.corp" = "" = "" = "" = "1" = "" = "2" = "" = "vpn/" = yes = "L2TP" = "PPP" = 5 = 1 = "EAP-KRB" = "DSACL" = 1 = 0 = 1 = 60 = 1 = "MSCHAP2" = "DSAuth" = "/var/log/ppp/vpnd.log" = 7200 = "Keychain" = "" = "" = "SharedSecret" = "" = "None" = <> = _empty_array = "" = "" = _empty_array = _empty_array = "Manual" = "IPSec" = "Yq!XdGsVyAY?o;9jnj

To disable L2TP, set to no:

sudo serveradmin settings = no

To configure how long a client can be idle prior to being disconnected:

sudo serveradmin settings = 10

By default, each protocol has a maximum of 128 sessions, configureable using

sudo serveradmin settings = 200

To see the state of the service, the pid, the time the service was configured, the path to the log files, the number of clients and other information, use the fullstatus option:

sudo serveradmin fullstatus vpn

Which returns output similar to the following:

vpn:servicePortsAreRestricted = "NO" vpn:readWriteSettingsVersion = 1 = "MSCHAP2" = 0 = yes = "MPPEKeySize128" = "PPP" = "PPTP" = "DSAuth" = "MSCHAP2" = "PPP" = yes = 0 = "L2TP" = "DSAuth" vpn:servicePortsRestrictionInfo = _empty_array vpn:health = _empty_dictionary vpn:logPaths:vpnLog = "/var/log/ppp/vpnd.log" vpn:configured = yes vpn:state = "STOPPED" vpn:setStateVersion = 1

Security folk will be stoked to see that the shared secret is shown in the clear using:

Configuring Users For VPN Access

Each account that accesses the VPN server needs a valid account to do so. To configure existing users to use the service, click on Users in the Server app sidebar.

At the list of users, click on a user and then click on the cog wheel icon, selecting Edit Access to Services.

At the Service Access screen will be a list of services that could be hosted on the server; verify the checkbox for VPN is highlighted for the user. If not, click Manage Service Access, click Manage and then check the VPN box.

Setting Up Client Computers

As you can see, configuring the VPN service in macOS Server 5.4 (running on High Sierra) is a simple and straight-forward process – much easier than eating your cereal with a fork and doing your homework in the dark.. Configuring clients is as simple as importing the profile generated by the service. However, you can also configure clients manually. To do so on a Mac, open the Network System Preference pane.

From here, click on the plus sign (“+”) to add a new network service.

At the prompt, select VPN in the Interface field and then either PPTP or L2TP over IPSec in the VPN Type. Then provide a name for the connection in the Service Name field and click on Create.

At the list of network interfaces in the Network System Preference pane, provide the hostname or address of the server in the Server Address field and the username that will be connecting to the VPN service in the Account Name field. If using L2TP, click on Authentication Settings.

At the prompt, provide the password entered into the Shared Secret field earlier in this article in the Machine Authentication Shared Secret field and the user’s password in the User Authentication Password field. When you’re done, click OK and then provided you’re outside the network and routeable to the server, click on Connect to test the connection.


Setting Up the VPN service in macOS Server 5.4 is as simple as clicking the ON button. But much more information about using a VPN can be required. The natd binary is still built into OS X at /usr/sbin/natd and can be managed in a number of ways. And if you’re using an Apple AirPort as a router (hopefully in a very small environment) then the whole process of setting this thing up should be super-simple.

September 26th, 2017

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

Tags: , , , ,

Yosemite brought Xsan 4, which included a whole new way to add clients to an Xsan. Xsan Admin is gone, as of El Capitan, but unchanged from then to macOS Sierra (other than a couple of binaries moving around). These days, instead of scanning the network using Xsan Admin. we’ll be adding clients using a Configuration Profile. This is actually a much more similar process to adding Xsan clients to a StorNext environment than it is to adding clients to Metadata Controllers running Xsan 3 and below. But instead of making a fsnameservers file, we’re plugging that information into a profile, which will do that work on the client on our behalf. To make the Xsan configuration profile, we’re going to use Profile Manager. With macOS Server 5, 5.2, and now 5.4 this trend continues.

To get started, open the Profile Manager web interface and click on a device or device group (note, these are scoped to systems so cannot be used with users and user groups). Then click on the Settings tab for the object you’re configuring Xsan for.
Click Edit for the profile listed (Settings for <objectname>) and scroll down until you see the entry for Xsan.

From the Xsan screen, click Configure.
This next screen should look a little similar, in terms of the information you’ve plugged into the Xsan 4 setup screen. Simply enter the name of the Xsan in the Xsan Name field, the IP address or host names of your metadata controllers in the File System Name Servers field and the Authentication Secret from the Xsan screen in the Server app into the Authentication Secret field. Click OK to close the dialog.
Click Save to save your changes. Then you’ll see the Download button become clickable. Choose the Mac option, and the profile will download to your ~/Downloads directory as Settings_for_<OBJECTNAME>.mobileconfig.

So this was called test and will result in a name of Settings_for_test.mobileconfig. That profile will automatically attempt to install. If this is an MDC where you’re just using Profile Manager to bake a quick profile, or if you don’t actually want to install the profile yet, click Cancel.


If you haven’t worked with profiles that much, note that when you click Show Profile, it will show you what is in the profile and what the profile can do.


Simply open this file on each client (once you test it of course) and once installed, they’ll automatically configure to join your Xsan. If you don’t have a Profile Manager server, you can customize this file for your environment (YMMV): Settings_for_test.mobileconfig

September 26th, 2017

Posted In: Xsan

Tags: , , , , ,

The statshares option has an -m option to look at a mount path for showing the path to the mount (e.g. if the mount is called krypted this should be something like /Volumes/krypted):

smbutil statshares -m /Volumes/krypted

When run, you see a list of all the attributes OS X tracks for that mount path, including the name of the server, the user ID (octal), how SMB negotiated an authentication, what version of SMB is running (e.g. SMB_1), the type of share and whether signing, extended security, Unix and large files are supported. Additionally, if you’d like to see the attributes for all shares, use the -a option after statshares:

smbutil statshares -a

You’ll then see the SHARE, ATTRIBUTE TYPE, and VALUE for each share mounted. Overall, this is a nice health check type of verb to the smbutil command that can be added to any monitoring or troubleshooting workflow.

September 26th, 2017

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

Tags: , , , , , ,

Configuring Calendar Server in macOS Server 5.4 (running on High Sierra) is a fairly simple and straight forward process. The Calendar Server is a CalDAV Server, leveraging HTTP and HTTPS, running on ports 8008 and 8443 respectively. To enable the Calendar service in macOS Server 5.4, first open the Server application and click on Calendar in the SERVICES section of the sidebar.

Once open, click on Enable invitations by email to enable email notifications of invitations in the Calendar Server. Provide the email address and then click on the Next button.

At the Configure Server Email Address screen, provide the type of incoming mail service in use, provide the address of the mail server and then the port number used, if not a standard port for HTTPS-based IMAP (or POP if you’d prefer), the user name and the valid password for the account. Then click on the Next button.

At the outgoing mail server screen, provide the Outgoing Mail Server address, the port, whether or not SSL is in use (it should be if possible), the password protocol, the user name and the password. Then click on the Next button.

At the Mail Account Summary screen, review the settings and if correct, click Finish. Back at the service configuration screen, click on the plus sign (“+”) and provide a type of location, an address, a delegate, a name for the location, whether or not invitations to the resource are accepted and then enter the account name for any accounts that can manage the location’s calendar (they will auto-complete, so there’s no need to remember users and groups exactly). Click Done to complete the setup. Use the Resource setting in type to configure a resource instead of a location. The two are the same, except the Type field.

There are a number of settings that can also be configured. But those are exposed only at the command line. To configure them, open the command line and then review the list of Calendar service settings using the list option of the serveradmin command:

sudo /Applications/ settings calendar

There are a number of settings for the Calendar service, including the following:

calendar:DefaultLogLevel = “info”
calendar:EnableAPNS = yes
calendar:EnableSSL = yes
calendar:DirectoryAddressBook:params:queryUserRecords = yes
calendar:DirectoryAddressBook:params:queryPeopleRecords = yes
calendar:EnableSearchAddressBook = yes
calendar:HTTPPort = 80
calendar:AccountingCategories:HTTP = no
calendar:AccountingCategories:Implicit Errors = no
calendar:AccountingCategories:iTIP = no
calendar:AccountingCategories:migration = no
calendar:AccountingCategories:AutoScheduling = no
calendar:AccountingCategories:iSchedule = no
calendar:AccountingCategories:iTIP-VFREEBUSY = no
calendar:Authentication:Digest:Enabled = yes
calendar:Authentication:Digest:AllowedOverWireUnencrypted = yes
calendar:Authentication:Kerberos:Enabled = yes
calendar:Authentication:Kerberos:AllowedOverWireUnencrypted = yes
calendar:Authentication:Wiki:Enabled = yes
calendar:Authentication:Basic:Enabled = yes
calendar:Authentication:Basic:AllowedOverWireUnencrypted = no
calendar:EnableCardDAV = no
calendar:Scheduling:iMIP:Sending:UseSSL = yes
calendar:Scheduling:iMIP:Sending:Server = “”
calendar:Scheduling:iMIP:Sending:Address = “”
calendar:Scheduling:iMIP:Sending:Username = “”
calendar:Scheduling:iMIP:Sending:Password = “79PreYsZSFfZZC6v”
calendar:Scheduling:iMIP:Sending:Port = 587
calendar:Scheduling:iMIP:Enabled = yes
calendar:Scheduling:iMIP:Receiving:UseSSL = yes
calendar:Scheduling:iMIP:Receiving:Server = “”
calendar:Scheduling:iMIP:Receiving:Type = “imap”
calendar:Scheduling:iMIP:Receiving:Username = “”
calendar:Scheduling:iMIP:Receiving:Password = “79PreYsZSFfZZC6v”
calendar:Scheduling:iMIP:Receiving:Port = 993
calendar:SSLPrivateKey = “”
calendar:LogLevels = _empty_dictionary
calendar:DataRoot = “/Library/Server/Calendar and Contacts/Data”
calendar:ServerRoot = “/Library/Server/Calendar and Contacts”
calendar:SSLCertificate = “”
calendar:EnableCalDAV = no
calendar:Notifications:Services:APNS:Enabled = yes
calendar:SSLPort = 443
calendar:RedirectHTTPToHTTPS = yes
calendar:SSLAuthorityChain = “”
calendar:ServerHostName = “”

One of the more common settings to configure is the port number that CalDAV runs on. To configure HTTP:

sudo /Applications/ settings calendar:HTTPPort = 8008


sudo /Applications/ settings calendar:SSLPort = 8443

You can then start the service using the start option:

sudo /Applications/ start calendar

Or to stop it:

sudo /Applications/ stop calendar

Or to get the status:

sudo /Applications/ fullstatus calendar

Full status indicates that the three services are running:

calendar:readWriteSettingsVersion = 1 calendar:setStateVersion = 1 calendar:state = "RUNNING" calendar:contactsState = "RUNNING" calendar:calendarState = "RUNNING"

Once the Calendar server is configured, use the Calendar application to communicate with the server. Open the Calendar application and click on the Calendar menu and select Add Account. From the Add Account screen, click on Add CalDAV Account radio button and click Continue.

CalDAV from the Account Type menu and then enter the User Name and password configured on the server, and add the address of the server if you don’t have any service records pointing to the server. The User Name is usually the name provided in Server app, followed by @ and then the address of the server.

Once the server is configured it appears in the list of accounts in the sidebar of the Calendar app. Create calendars in the account and then to share a calendar, right-click on the calendar and click on Share Calendar…


At the Share Calendar screen, provide the name the calendar should appear as to others and anyone with whom you’d like to share your calendar with. Back at the Calendar Settings screen, use the settings to configure Availability and refresh rate of calendars, as seen above. Click on Server Settings to assign custom port numbers.


Click on the Delegation tab to view any accounts you’ve been given access to.


Use the Edit button to configure who has delegated access to calendars, as opposed to configuring subscriptions.

Overall, the Calendar service in Server 5.4 is one of the easiest to configure on High Sierra. Most of the work goes into settings configured on client systems. This, as with Exchange, dedistributes administration, often making administration more complicated than with many other tools, unless you’re leveraging profiles to push out settings, which is the expected workflow on the Apple side of things.

September 26th, 2017

Posted In: Mac OS X Server

Tags: , , , , , ,

Getting started with Messages Server couldn’t really be easier. Messages Server in the macOS Server 5.4 version of the Server app uses the open source jabber project as the back-end code base. The jabber binary is located at /Applications/ directory and the autobuddy binary is at /Applications/ The actual jabberd binary is also stored at /Applications/, where there are a couple of perl scripts used to migrate the service between various versions as well.

Setting up the Messages service is simple. Open the Server app and click on Messages in the Server app sidebar. 

Click on the Edit… button for the Permissions. Here, define which users and interfaces are allowed to use the service.

From Server app, click on the checkbox for “Enable server-to-server federation” if you have multiple Messages servers and provide the address for servers to federate to.

Next, click on the checkbox for “Archive all chat messages” if you’d like transcripts of all Messages sessions that route through the server to be saved on the server.

You should use an SSL certificate with the Messages service. If enabling federation so you can have multiple Messages servers, you have to. Before enabling the service, click on the name of the server in the sidebar of Server app and then click on the Settings tab. From here, click on Edit for the SSL Certificate (which should be plural btw) entry to bring up a screen to select SSL Certificates.

At the SSL Certificates screen (here it’s plural!), select the certificate the Messages service should use from the available list supplied beside that entry and click on the OK button. If you need to setup federation, click back on the Messages service in the sidebar of Server app and then click on the Edit button. Then, click on the checkbox for Require server-to-server federation (making sure each server has the other’s SSL certificate installed) and then choose whether to allow any server to federate with yours or to restrict which servers are allowed. I have always restricted unless I was specifically setting up a server I wanted to be public (like public as in everyone in the world can federate to it, including the gorram reavers that want to wear your skin).

To restrict the service, then provide a list of each server address capable of communicating with your server. Once all the servers are entered, click the OK button. Obviously, if you only have one server, you can skip that. Once the settings are as you wish them to be, click on the ON/OFF switch to light up the service. To see the status of the service, once started, use the fullstatus option with serveradmin followed by the jabber indicator:

sudo serveradmin fullstatus jabber

The output includes whether the service is running, the location of jabber log files, the name of the server as well as the time the service was started, as can be seen here:

jabber:state = "RUNNING"
jabber:roomsState = "RUNNING"
jabber:logPaths:PROXY_LOG = "/private/var/jabberd/log/proxy65.log"
jabber:logPaths:MUC_STD_LOG = "/var/log/system.log"
jabber:logPaths:JABBER_LOG = "/var/log/system.log"
jabber:proxyState = "RUNNING"
jabber:currentConnections = "0"
jabber:currentConnectionsPort1 = "0"
jabber:currentConnectionsPort2 = "0"
jabber:pluginVersion = "10.8.211"
jabber:servicePortsAreRestricted = "NO"
jabber:servicePortsRestrictionInfo = _empty_array
jabber:hostsCommaDelimitedString = "osxserver.krypted.lan"
jabber:hosts:_array_index:0 = "osxserver.krypted.lan"
jabber:setStateVersion = 1
jabber:startedTime = ""
jabber:readWriteSettingsVersion = 1

There are also a few settings not available in the Server app. One of these that can be important is the port used to communicate between the Messages client and the Messages service on the server. For example, to customize this to 8080, use serveradmin followed by settings and then jabber:jabberdClientPortSSL = 8080, as follows:

sudo serveradmin settings jabber:jabberdClientPortSSL = 8080

To change the location of the saved Messages transcripts (here, we’ll set it to /Volumes/Pegasus/Book:

sudo serveradmin settings jabber:savedChatsLocation = “/Volumes/Pegasus/Book”

To see a full listing of the options, just run settings with the jabber service:

sudo serveradmin settings jabber

The output lists each setting configurable:

jabber:dataLocation = “/Library/Server/Messages”
jabber:s2sRestrictDomains = no
jabber:jabberdDatabasePath = “/Library/Server/Messages/Data/sqlite/jabberd2.db”
jabber:sslCAFile = “/etc/certificates/”
jabber:jabberdClientPortTLS = 5222
jabber:sslKeyFile = “/etc/certificates/”
jabber:initialized = yes
jabber:enableXMPP = yes
jabber:savedChatsArchiveInterval = 7
jabber:authLevel = “STANDARD”
jabber:hostsCommaDelimitedString = “”
jabber:jabberdClientPortSSL = 5223
jabber:requireSecureS2S = yes
jabber:savedChatsLocation = “/Library/Server/Messages/Data/message_archives”
jabber:enableSavedChats = yes
jabber:enableAutoBuddy = no
jabber:s2sAllowedDomains = _empty_array
jabber:logLevel = “ALL”
jabber:hosts:_array_index:0 = “”
jabber:eventLogArchiveInterval = 7
jabber:jabberdS2SPort = 5269

To stop the service:

sudo serveradmin stop jabber

And to start it back up:

sudo serveradmin start jabber

It’s also worth noting something that’s completely missing in this whole thing: Apple Push Notifications… Why is that important? Well, you use the Messages application to communicate not only with macOS and other jabber clients, but you can also use Messages to send text messages. Given that there’s nothing in the server that has anything to do with texts, push or anything of the sort, it’s worth noting that these messages don’t route through the server and therefore still require an iCloud account. Not a huge deal, but worth mentioning that Messages server doesn’t have the same updates built into the Messages app. Because messages don’t traverse the server, there’s no transcripts.

September 26th, 2017

Posted In: Mac OS X Server

Tags: , , , ,

SSH allows administrators to connect to another computer using a secure shell, or command line environment. ARD (Apple Remote Desktop) allows screen sharing, remote scripts and other administrative goodness. You can also connect to a server using the Server app running on a client computer. To enable any or all of these, open the Server app (Server 5.4 for High Sierra), click on the name of the server, click the Settings tab and then click on the checkbox for what you’d like to enter.

All of these can be enabled and managed from the command line as well. The traditional way to enable Apple Remote Desktop is using the kickstart command. But there’s a simpler way in macOS Server 5.4 for High Sierra. To do so, use the serveradmin command. To enable ARD using the serveradmin command, use the settings option, with info:enableARD to set the payload to yes:

sudo serveradmin settings info:enableARD = yes

Once run, open System Preferences and click on Sharing. The Remote Management box is then checked and the local administrative user has access to ARD into the host.

When you enable, you’ll be prompted for what permissions to provide access to:

There are also a few other commands that can be used to control settings. To enable SSH for administrators:

sudo serveradmin settings info:enableSSH = yes

When you enable SSH from the serveradmin command you will not see any additional checkboxes in the Sharing System Preferences; however, you will see the box checked in the Server app. To enable SNMP:

sudo serveradmin settings info:enableSNMP = yes

Once SNMP is enabled, use the /usr/bin/snmpconf interactive command line environment to configure SNMP so you can manage traps and other objects necessary. Note: You can’t have snmpd running while you configure SNMPv3. Once SNMPv3 is configured snmpd can be run.  To allow other computers to use the Server app to connect to the server, use the info:enableRemoteAdministration key from serveradmin:

sudo serveradmin settings info:enableRemoteAdministration = yes

To enable the dedication of resources to Server apps (aka Server Performance Mode):

sudo serveradmin settings info:enableServerPerformanceMode = yes

September 26th, 2017

Posted In: Mac OS X Server

Tags: , , , , , , ,

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/ 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, 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/ 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 = 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/ 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 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.

September 26th, 2017

Posted In: Mac OS X Server

Tags: , , , , ,

Apple has slowly been moving us away from the legacy afp file sharing protocol for some time. High Sierra (macOS 10.13) now comes with a new suite of tools to manage WebDAV shares. Most of these are configurable using wfsctl located at /usr/sbin/wfsctl. When run, the tool reports as “WebDAV File Sharing control utility.”

To start the WebDAV service, use the start verb:

wfsctl start

At this point, the service will attempt to lookup the hostname of the server. If the hostname cannot be found (or once found does not match the expected results) then the service will not start. For more on why this might be happening, use the diagnose verb:

wfsctl diagnose

Once started, you can see what shares are running using the shares verb:

wfsctl shares

You can also share a folder via WebDAV using the share verb:

wfsctl share /Volumes/Pegasus/Accounting

Or unshare a directory:

wfsctl unshare /Volumes/Pegasus/Accounting

The wfsctl command doesn’t seem to interact with the web sharing options built into the web sharing services in macOS Server, although when you run diagnose it will look at services and display what’s running. From what I can tell so far, this should not be run on servers that have either of the macOS Server app web services running.

September 26th, 2017

Posted In: Mac OS X, Mac OS X Server

Tags: , , , , , ,

« Previous PageNext Page »