krypted.com

Tiny Deathstars of Foulness

The Server 5 app that installs on Sierra is great. But sometimes a change doesn’t get committed properly or has a mismatch with a certificate, and the server doesn’t respond properly… I know, you’ve been told that host name changes and IP changes are all kinds of OK at this point; “look, Charles, there’s a button!” Well, go ahead, click it. Don’t mind me, you might just be alright. But then again, you might not if you’re running Open Directory, Profile Manager, or a few other services… When it works it’s a thing of beauty. But when it doesn’t, you might be restoring some stuff from backup. But just before you do that restore, let’s try one more thing. Let’s try and rebuild some certificates and configuration settings that shouldn’t impact actual service operation. Let’s try to reset the Server app and let a fresh install of the Server see if it can fix issues.

Now, I want to be clear, this is usually the last resort before restoring a backup. I’ve had a lot of luck with services remaining functional and preserving settings when I do this, but don’t expect that to be the case every time. Basically, we’re going to do what we looked at doing back in ’09 with AppleSetupDone but one designed just for servers, so the file is in the same place (/var/db) and called .ServerSetupDone. To remove it, close Server app and run the following command:

sudo rm /var/db/.ServerSetupDone

Once removed, open the Server app again and then let the Server app run as though it’s new. Cruft, begone! Make sure to check things like server logs in the event that the service goes unresponsive again, and be wary of performing this step multiple times as there’s likely another underlying issue that you shouldn’t be resetting the server to resolve.

October 11th, 2016

Posted In: Mac OS X Server

Tags: , , , ,

macOS Server 5.2 running on Sierra 10.12) has an adaptive firewall built in, or a firewall that controls incoming access based on clients attempting to abuse the server. The firewall automatically blocks incoming connections that it considers to be dangerous. For example, if a client attempts too many incorrect logins then a firewall rule restricts that user from attempting to communicate with the server for 15 minutes. If you’re troubleshooting and you accidentally tripped up one of these rules then it can be a bit frustrating. Which is why Apple gives us afctl, a tool that interacts with the adaptive firewall.

The most basic task you can do with the firewall is to disable all of the existing rules. To do so, simply run afctl (all afctl options require sudo) with a -d option:

/Applications/Server.app/Contents/ServerRoot/usr/libexec/afctl -d

When run, the adaptive firewall’s rules are disabled. To re-enable them, use the -e option:

/Applications/Server.app/Contents/ServerRoot/usr/libexec/afctl -e

Turning off the rules seems a bit much for most troubleshooting tasks. To remove a specific IP address that has been blacklisted, use the -r option followed by the IP address (rules are enforced by IP):

/Applications/Server.app/Contents/ServerRoot/usr/libexec/afctl -r 192.168.210.88

To add an IP to the blacklist, use the -a option, also followed by the IP:

/Applications/Server.app/Contents/ServerRoot/usr/libexec/afctl -a 192.168.210.88

To permanently add a machine to the whitelist, use -w with the IP:

/Applications/Server.app/Contents/ServerRoot/usr/libexec/afctl -w 192.168.210.88

And to remove a machine, use -x. To understand what is going on under the hood, consider this. The blacklisted computers are stored in plain text in /var/db/af/blacklist and the whitelisted computers are stored in the same path in a file called whitelist. The afctl binary itself is stored in /usr/libexec/afctl and the service is enabled by /System/LIbrary/LaunchDaemons/com.apple.afctl.plist, meaning to stop the service outright, use launchctl:

launchctl unload

/Applications/Server.app/Contents/ServerRoot/usr/libexec/com.apple.afctl.plist

The configuration file for afctl is at /etc/af.plist. Here you can change the path to the blacklist and whitelist files, change the interval with which it is run, etc. Overall, the adaptive firewall is a nice little tool for Mac OS X Server security, but also something a number of open source tools can do as well. But for something built-in and easy, worth using.

There’s a nice little command called hb_summary located in /Applications/Server.app/Contents/ServerRoot/System/Library/CoreServices/AdaptiveFirewall.bundle/Contents/MacOS that provides statistics for blocked hosts. To see statistics about how much the Adaptive Firewall is being used, just run the command with no options:

/Applications/Server.app/Contents/ServerRoot/System/Library/CoreServices/AdaptiveFirewall.bundle/Contents/MacOS/hb_summary

The output provides the following information (helpful if plugging this information into a tool like Splunk):

  • Date
  • Date statistics start
  • Number of hosts blocked
  • Addresses blocked
  • Number of times each address was blocked
  • Last time a host was blocked
  • Total number of times a block was issued

October 8th, 2016

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

Tags: , , , , ,

You might be happy to note that other than the ability to interpret new payloads, the profiles command mostly stays the same in Sierra. You can still export profiles from Apple Configurator or Profile Manager (or some of the 3rd party MDM tools). You can then install profiles by just opening them and installing. Once profiles are installed on a Mac, mdmclient, a binary located in /usr/libexec will process changes such as wiping a system that has been FileVaulted (note you need to FileVault if you want to wipe an OS X Lion client computer). /System/Library/LaunchDaemons and /System/Library/LaunchAgents has a mdmclient daemon and agent respectively that start it up automatically. This, along with all of the operators remains static from 10.10 and on.

To script profile deployment, administrators can add and remove configuration profiles using the new /usr/bin/profiles command. To see all profiles, aggregated, use the profiles command with just the -P option:

/usr/bin/profiles -P

As with managed preferences (and piggy backing on managed preferences for that matter), configuration profiles can be assigned to users or computers. To see just user profiles, use the -L option:

/usr/bin/profiles -L

You can remove all profiles using -D:

/usr/bin/profiles -D

The -I option installs profiles and the -R removes profiles. Use -p to indicate the profile is from a server or -F to indicate it’s source is a file. To remove a profile:

/usr/bin/profiles -R -F /tmp/HawkeyesTrickshot.mobileconfig

To remove one from a server:

/usr/bin/profiles -R -p com.WestCoastAvengers.HawkeyesTrickshot

The following installs HawkeyesTrickshot.mobileconfig from /tmp:

/usr/bin/profiles -I -F /tmp/HawkeyesTrickshot.mobileconfig

If created in Profile Manager:

/usr/bin/profiles -I -p com.WestCoastAvengers.HawkeyesTrickshot

You can configure profiles to install at the next boot, rather than immediately. Use the -s to define a startup profile and take note that if it fails, the profile will attempt to install at each subsequent reboot until installed. To use the command, simply add a -s then the -F for the profile and the -f to automatically confirm, as follows (and I like to throw in a -v usually for good measure):

profiles -s -F /Profiles/SuperAwesome.mobileconfig -f -v

And that’s it. Nice and easy and you now have profiles that only activate when a computer is started up. As of OS X Yosemite, the dscl command got extensions for dealing with profiles as well. These include the available MCX Profile Extensions:

-profileimport -profiledelete -profilelist [optArgs]
-profileexport
-profilehelp

To list all profiles from an Open Directory object, use 
-profilelist. To run, follow the dscl command with -u to specify a user, -P to specify the password for the user, then the IP address of the OD server (or name of the AD object), then the profilelist verb, then the relative path. Assuming a username of diradmin for the directory, a password of moonknight and then cedge user:

dscl -u diradmin -P moonknight 192.168.210.201 profilelist /LDAPv3/127.0.0.1/Users/cedge

To delete that information for the given user, swap the profilelist extension with profiledelete:

dscl -u diradmin -P apple 192.168.210.201 profilelist /LDAPv3/127.0.0.1/Users/cedge

If you would rather export all information to a directory called ProfileExports on the root of the drive:

dscl -u diradmin -P moonknight 192.168.210.201 profileexport . all -o /ProfileExports

In Yosemite we got a few new options (these are all still in 10.11 with no new operators), such as -H which shows whether a profile was installed, -z to define a removal password and -o to output a file path for removal information. Also, as in Yosemite it seems as though if a configuration profile was pushed to you from MDM, you can’t remove it (fyi, I love having the word fail as a standalone in verbose output):

bash-3.2# profiles -P
_computerlevel[1] attribute: profileIdentifier: 772BED54-5EDF-4987-94B9-654456CF0B9A
_computerlevel[2] attribute: profileIdentifier: 00000000-0000-0000-A000-4A414D460003
_computerlevel[3] attribute: profileIdentifier: C11672D9-9AE2-4F09-B789-70D5678CB397
charlesedge[4] attribute: profileIdentifier: com.krypted.office365.a5f0e328-ea86-11e3-a26c-6476bab5f328
charlesedge[5] attribute: profileIdentifier: odr.krypted.com.ADD7E5A6-8EED-4B11-8470-C56C8DC1E2E6
_computerlevel[6] attribute: profileIdentifier: EE08ABE9-5CB8-48E3-8E02-E46AD0A03783
_computerlevel[7] attribute: profileIdentifier: F3C87B6E-185C-4F28-9BA7-6E02EACA37B1
_computerlevel[8] attribute: profileIdentifier: 24DA416D-093A-4E2E-9E6A-FEAD74B8B0F0
There are 8 configuration profiles installed

bash-3.2# profiles -r 772BED54-5EDF-4987-94B9-654456CF0B9A
bash-3.2# profiles -P
_computerlevel[1] attribute: profileIdentifier: F3C87B6E-185C-4F28-9BA7-6E02EACA37B1
_computerlevel[2] attribute: profileIdentifier: EE08ABE9-5CB8-48E3-8E02-E46AD0A03783
_computerlevel[3] attribute: profileIdentifier: 24DA416D-093A-4E2E-9E6A-FEAD74B8B0F0
_computerlevel[4] attribute: profileIdentifier: 00000000-0000-0000-A000-4A414D460003
_computerlevel[5] attribute: profileIdentifier: 772BED54-5EDF-4987-94B9-654456CF0B9A
_computerlevel[6] attribute: profileIdentifier: C11672D9-9AE2-4F09-B789-70D5678CB397
charlesedge[7] attribute: profileIdentifier: odr.krypted.com.ADD7E5A6-8EED-4B11-8470-C56C8DC1E2E6
charlesedge[8] attribute: profileIdentifier: com.krypted.office365.a5f0e328-ea86-11e3-a26c-6476bab5f328
There are 8 configuration profiles installed

bash-3.2# profiles -rv 772BED54-5EDF-4987-94B9-654456CF0B9A
profiles: verbose mode ON
profiles: returned error: -204
fail

October 3rd, 2016

Posted In: Uncategorized

Tags: , , , , , ,

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: , , , , , , ,

macOS Server 5.2 is now available to be installed. To do so, first backup your server. Then, backup your server again, making sure you have a functional, bootable clone. Once you’re sure you have a solid backup of your server, open the App Store and search for Server. When you find the Server app, click on it.

screen-shot-2016-09-25-at-8-37-43-pm

At the macOS Server app, click on Install (or Open if the server is already installed).

Screen Shot 2015-09-23 at 10.25.51 PM

The download will begin. Once complete, you’ll see a notice that the “Server app replacement detected.” Click OK. Then, open the Server app. When the Server app opens, you’ll be prompted to update the server. Click Continue.

Screen Shot 2015-09-23 at 10.58.30 PM

At the Licensing Agreement screen, click Agree. At the screen to confirm your administrative access, provide a name and password for an account with administrative access and then click on Allow. Services are then upgraded. Once complete, the Server app will open and should have settings consistent with the settings prior to the upgrade.

screen-shot-2016-09-25-at-8-39-30-pm

October 2nd, 2016

Posted In: Mac OS X, Mac OS X Server

Tags: , , , , ,

A bootable installer is one of the fastest ways to install a Mac. Rather than copy the installer to a local drive you can run it right off a USB disk (or Thunderbolt if you dare). Such a little USB drive would be similar to the sticks that came with the older MacBook Air, when we were all still sitting around wondering how you would ever install the OS on a computer with no optical media or Ethernet otherwise. Luckily, Apple loves us.

To make a bootable USB/flash drive of Sierra like the one that used to come with the MacBook Air, first name the USB drive. I’ll use mavinstall for the purposes of this article. The format should be Mac OS Extended Journaled. The installer is called Install macOS Sierra and is by default located in the /Applications directory. Inside the app bundle, there’s a new binary called createinstallmedia (nested in Contents/Resources).

Using this binary you can create an installation drive (similar to what we used to do with InstallESD). To do so, specify the –volume to create the drive on (note that the target volume will be erased), the path of the Install macOS Sierra app bundle and then we’re going to select –nointeraction so it just runs through the whole thing

/Applications/Install\ macOS\ Sierra.app/Contents/Resources/createinstallmedia --volume /Volumes/mavinstall --applicationpath /Applications/Install\ macOS\ Sierra.app --nointeraction

Note: You’ll need to elevate your privileges for this to run.

Once run you’ll see that it erases the disk, copies the Installation materials (InstallESX, etc) and then makes the drive bootable, as follows:

Erasing Disk: 0%... 10%... 20%... 100%...
Copying installer files to disk...
Copy complete.
Making disk bootable...
Copying boot files...
Copy complete.

Then you can either select the new volume in the Startup Disk System Preference pane or boot the computer holding down the option key to select the new volume.

Note: If you can do this on a system with a solid state drive it will be  faster. Although this took 17 minutes last I ran it even then so be patient for the files to copy.

October 1st, 2016

Posted In: Mac OS X, Mac OS X Server

Tags: , , , , ,

The logs in Xcode Server (Server 5.2 for Sierra) by default point to /Library/Server/XcodeLogs/credserver.log. This takes all of the output from xcscredd and xcscredhandler. If you’re doing a lot of debugging then logs can be pointed to another location, such as another drive. The path to the logs is defined in the /Applications/Server.app/Contents/ServerRoot/System/Library/LogConfiguration directory. The file to edit is a standard property list, XCSCredentialServer.plist:

<?xml version=”1.0″ encoding=”UTF-8″?>

<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>

<plist version=”1.0″>

<dict>

<key>claimedFacilities</key>

<array>

<string>servermgrd</string>

<string>servermgr-listener</string>

<string>servermgr-notify</string>

</array>

<key>claimedSenders</key>

<array>

<string>servermgrd</string>

<string>servermgr-listener</string>

<string>servermgr-notify</string>

</array>

<key>logMaximumLevel</key>

<string>debug</string>

<key>logPath</key>

<string>/Library/Server/Logs/servermgrd.log</string>

</dict>

</plist>

Once open, look for a key called logPath. Change that to the desired path, such as /Volumes/MyDrive/Logs/credserver.log and then restart the service:

serveradmin stop xcode; serveradmin start xcode

October 1st, 2016

Posted In: Mac OS X Server

Tags: , , , , , , ,

OS X 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 nvkram followed by a -p option you’ll see all of the configured firmware variables:

nvram -p

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 30th, 2016

Posted In: Mac OS X

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: , , , , ,

I wrote about using the smbutil for DFS in Lion awhile back. I haven’t needed to write anything else as it hadn’t changed since. 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

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, 2016

Posted In: Mac OS X, Mac OS X Server

Tags: , , ,

Next Page »