You can fully remove OD with the following command:

slapconfig -destroyldapserver

Server.app in Lion is a pretty good app for most tasks. But I find myself frequently doing things that I don’t think developers intended me to do. One such item is setting up and tearing down Open Directory to test various iterations of enabling a master. I frequently use slapconfig to destroyldapserver:

slapconfig -destroyldapserver

Doing so almost immediately allows me to demote an Open Directory master to a stand-alone server and then repromote the server to a master or replica for testing purposes. If you do this, then Open Directory  cannot be set back up using Server.app. The fix is to use Server Admin to repromote your server back to an Open Directory master and then use Server Admin to more graciously demote the server back to stand-alone. Until you do this, the Server.app will error out on Open Directory promotions that the server is already an Open Directory master.

A change I’ve made to my workflow when nukin’ and pavin’ OD is to just use Server Admin for the paving part. If you demote with Server Admin you won’t have these issues. Hope this helps someone who finds similar wonkiness.

In Lion Server, Open Directory can be managed in one of three ways: using the Server application the Server Admin application or using the command line utilities. Configuring Open Directory has never been easier than it is in the Server application, though. As we looked at in a previous article, setting up an Open Directory master should be done using the Server application. But setting up an Open Directory replica should be done using the Server Admin application. The Server Admin application is not installed when you buy OS X Server on the App Store and so it can be obtained here.

But first (or while that’s downloading even), open the Server application. If this is the first time that you’ve opened the Server application then you’re in for a bit of a wait. This is a nice time to grab yourself the first shot of Jäger of the day. According to your internet speed, you could end up with 3 or 4 of these. That’s fine though, the new Open Directory makes much more sense afterwards.

When you first open and start using the Server application, you’re creating local users. The Server application automatically creates local users until you setup Open Directory. Before you set up Open Directory as a Replica on the system, it should have a static IP address and a name in the DNS servers that the server uses (forward and reverse lookups for said address). The Server application has a Next Steps drawer. Clicking on the drawer and then the Configure Network button brings up a screen that will complain if your DNS has any problems. If DNS is working great, then the Configure Network section of the Next Steps drawer will appear as follows:

Not to get off topic on the hostname/dns/etc thing, but when you click on Network, if you decide to change names before you promote to an Open Directory Master/Replica, clicking on Edit for the Host Name, you should almost always click on the third option, Host Name for Internet…

While the Server app is cool, it caches stuff and I’ve seen it let things go threat shouldn’t be let go. Therefore, in order to make sure that the server has such an address, I still recommend using changeip, but I also recommend using the Server application. In Lion, I’ve seen each find things that other misses. To use changeip:

sudo changeip -checkhostname

The address and host names should look correct and match what you see in the Server application’s Next Steps drawer.

Primary address = 10.0.0.1

Current HostName = mdm.krypted.com
DNS HostName = mdm.krypted.com

The names match. There is nothing to change.
dirserv:success = “success”

Provided everything is cool with the hostname, open the Server Admin application from /Applications/Server. Then click on Settings in the application’s toolbar. At the Settings screen, click on Services. Click on the checkbox for the Open Directory Service and click Save to see the Open Directory service appear in the Server Admin sidebar. Then, click on Open Directory in the Server Admin sidebar and then click on the Change… button to bring up the Open Directory Assistant.

At the Choose Directory Role screen, click on Set up an Open Directory replica and then click on the Continue button.

At the Replica and Certificate Authority screen, provide the name or IP address of the Open Directory master in the IP address or DNS name of master field. Actually, just use the name. If you can’t find the Open Directory Master by name, then you should really fix that before moving forward. Also provide the Open Directory administrative user name in the Domain administrator’s short name field and that account’s password in the Domain administrator’s password field. If you have any problems, make sure you can ssh into the Open Directory master using this account.

Also, new in Lion, there’s a CA administrator’s email address field. Put in here, what you put into the Organization Information field back when you promoted the master (screen shown for posterity).

If you’ve lost track of the email address you used, keep in mind that the SSL certificate can be used to grab that information. Open Keychain Access, click on Certificates, search for the host name of the Master (this is all from the master, btw) and then do a Get Info and you’ll see the Email Address used.

Anyway, back to the Open Directory Assistant on the new Replica. Click on the Continue button and finish the wizard to complete promoting the replica. That’s it. Don’t forget to check your logs when the promotion is complete.

I’ve been finding that there are a lot of issues with promoting Replicas in Lion so far. This has meant bad directory data (import + export), bad DNS, security policies, using a bad username and password combination (not the systems fault) and other issues. To fix the bad directory data, you have to import and export (in my experience not an archive and restore but an actual export and import, losing all passwords in the process). The Next Steps drawer can guide you through the host names/DNS issues. For security policies, I’ve found the following command to work for me (run on the master):

slapconfig -setmacosxodpolicy -binding enabled

For the username and password issues (the errors don’t always tell you what is or is not a password problem) I have found using dscl or even Workgroup Manager to test the login is an important step.

You can also still use slapconfig for Open Directory replicas, a great way to get a lot of detailed information. For example, one time, the replica promotion was failing because the server was a member server in a domain; however, using slapconfig -getstyle the server simply reported as Standalone. To promote a replica, you will define want to make sure to include the new –certAdminEmail option, followed by the email address on that certificate of the master. This is then followed with the address and the admin username of the master. For example:

slapconfig -createreplica --certAdminEmail krypted@me.com odm.pretendco.com diradmin

When slapconfig runs, it will give you a detailed account of where it failed and why.

Finally, I have noticed that some machines fail in the Server Admin GUI and Server Admin simply doesn’t show that the machine failed, but instead just makes the system a member to the server. When this happens, I have always had to clean install the system in order to get it to promote to a replica again, properly. To make sure a replica is indeed a replica, consult slapconfig:

slapconfig -getstyle

Now is when you get to have a little more Jäger. This whole process hopefully only took about 5 to 10 minutes, so it’s about time anyways. If the process took longer, then I hope you didn’t wait until now for round 2. Later, we’ll discuss directory trees and using those as a means of building sites. For that, you might want to move onto something a bit stronger, like mescaline.

For those learning OS X or other Unixy based systems, and for those who have been using them for decades, man is one of the most important commands in our arsenal. The man command is short for manual and shows us how to use each command that has a man page, or a page that acts as an instruction manual for the command (or method). Another command, apropos, searches the whatis database for objects that match a string, or entry. For example, if you’d like to see a listing of all man pages that reference the word case, use the following command:

apropos case

Or use whatis in the place of apropos:

whatis case

To see the manual page, or man page, for apropos, use the man command followed by apropos:

man apropos

To exit the man page, hit the q key. To page down, hit space or arrow to line up and line down. Now, you can also use apropos to see a list of all the man pages by running apropos followed by a dot (“.”):

apropos .

Or you could even pipe that into a text file:

apropos . > commands.txt

Not everything that appears is going to be a command that can be accessed on its own, but they should all have man pages. At the end of the list there are even items that you might not know you can access, installed by third party developers. Use the space bar to page down. Many commands are listed in the whatis database but use the same man page, for built-in commands. So running man on case, referenced earlier, will show the BUILTIN man page.

At the end of many man pages are commands that are similar or other commands used to manage the same service. For example, in OS X Server, run man slapconfig and you’ll note that DirectoryService and slapd are referenced. Finally, to see where each command is located, if not otherwise indicated, use the which command. For example, to see where slapd is located:

which slapd

Open Directory has never been so easy to setup for a basic environment as it is in OS X Mountain Lion Server. It’s also never been so annoyingly simple to use that to do anything cool requires a bunch of command line foo. No offense to the developers, but this whole idea that the screens that were being continually refined for a decade just need to be thrown out and started fresh seems to have led to a few babies thrown out along with them. Not often as I’m kinda’ digging most of the new config screens in OS X Mountain Lion Server, but with Open Directory, it’s just too easy. Features mean buttons. Buttons make things a tad bit more complicated to use than an ON/OFF switch…

Anyway, rant over. Moving on. As with almost any previous version of OS X Server and Open Directory, once you’ve installed the Server app, run the changeip command along with the -checkhostname option to verify that the IP, DNS and hostname match. If (and only if as it will fail if you try anyway) you get an indication that “The names match. There is nothing to change.” then you can move on to setting up the service.

Note: There’s this thing called the Next Steps Drawer. No matter what it says, I still won’t proceed until changeip checks clean. 

To set up the Open Directory Master, open the Server app and click on the Open Directory service. From here, click on the ON button.

For the purposes of this example, we’re setting up an entirely new Open Directory environment. At the “Configure Network Users and Groups” screen, click on “Create a new Open Directory Domain” and click on the Next button.

At the Directory Administrator screen, enter a username and password for the directory administrator account. The default account is sufficient, although it’s never a bad idea to use something a bit less generic.

Once you’ve entered the username and password, click on the Next button. Then we’re going to configure the SSL information.

At the Organization Information screen, enter a name for the organization in the Organization Name field and an Email Address to be used in the SSL certificate in the Admin Email Address field. Click on Next.

At the Confirm Settings screen, make sure these very few settings are OK with you and then click on the Set Up button to let slapconfig (the command that runs the OD setup in the background, kinda’ like a cooler dcpromo) do its thing. When the Open Directory master has been configured, there’s no need to reboot or anything, the indicator light for the Open Directory service should appear. If the promotion fails then look to the preflight options I wrote up awhile back.

Once the promotion is complete, you’ll also see the server listed in the Servers list. Here, click on the server and click on the Global Password Policy option in the cog-wheel menu. This is where you can configure the parameters that passwords must meet in order to be usable on the system.

Clicking on the minus (“-”) button while a server is highlighted runs a slapconfig -destroyldapserver on the server and destroys the Open Directory domain if it is the only server. All domain information is lost when this happens.

Next, let’s bind a client. Binding clients can be done in a few different ways. You can use a script, a Profile, the Users & Groups System Preference pane or build binding into the imaging process. For the purpose of this example, we’ll use the System Preference pane.

To get started, open up the System Preference pane and then click on Users & Groups. From here, click on Login Options and then unlock the lock in the lower left corner of the screen, providing a username and password when prompted.

Click on the Edit… button and then the plus sign (“+”). Then, enter the name of the Open Directory Master (the field will expand with options when you enter the host name.

It’s probably best not to use the IP address at this point as the master will have an SSL certificate tied to the name. Click OK to accept the certificate (if it’s self-signed) and then the system should finish binding. Once bound, I like to use either id or dscl to verify that directory accounts are properly resolving before I try logging in as an Open Directory user.

Provided everything works that’s it. The devil is of course in the details. There is very little data worth having if it isn’t backed up. Notice that the old Archive and Restore options are gone. To run a backup, run the slapconfig command along with the -backupdb option followed by a path to a folder to back the data up to:

sudo slapconfig -backupdb /odbackups

To restore a database (such as from a previous version of the operating system where such an important option was actually present) use the following command (which just swaps backupdb with -restoredb)

sudo slapconfig -restoredb /odbackups

Both commands ask you for a password to encrypt and decrypt the disk image created by them.

Yesterday we looked at setting up an Open Directory Master in OS X Mountain Lion Server. An Open Directory Replica keeps a copy of the Open Directory database available for users even when the Master goes offline. But it can also take a part of the load from the Open Directory Master and when using the new Locales feature, balance network traffic. To get started with an Open Directory Replica, first enable SSH, now disabled by default.

Next, use the changeip to check the host name. While the Server app is cool, it caches stuff and I’ve seen it let things go threat shouldn’t be let go. Therefore, in order to make sure that the server has such an address, I still recommend using changeip, but I also recommend using the Server application. In Mountain Lion, I’ve seen each find things that other misses. To use changeip:

sudo changeip -checkhostname

The address and host names should look correct and match what you see in the Server application’s Next Steps drawer.

Primary address = 10.0.0.1

Current HostName = odr.krypted.com
DNS HostName = odr.krypted.com

The names match. There is nothing to change.
dirserv:success = “success”

Provided everything is cool with the hostname, use the slapconfig command to preflight a replica prior to promotion. The syntax there is the same as the -createreplica syntax, used as follows, assuming the master has an IP address of 172.16.2.23:

/usr/sbin/slapconfig -preflightreplica 172.16.2.23 diradmin

Provided that the server is ready, open the Server app on a freshly installed computer you want to be your Open Directory replica and click on the Open Directory service.

Then, use the ON button to start the configuration process. When prompted, click on “Join an existing Open Directory domain as a replica” and click on the Next button. When prompted, enter the parent Open Directory server’s host name (likely the name of the Open Directory Master), directory admin user name (the diradmin or custom username provided when Open Directory was configured), and then the directory admin password. Then click on the Next button again to setup the services.

At the Confirm settings screen, click on the Set Up button and the replica is completed provided there are no issues with the configuration. Once you’ve created your first replica, you can then start to define replica trees, where each replica looks at one above it, which then looks at another. I’ll do another article later on replica trees.

Note: If there are any problems during promotion, I start over every time using slapconfig along with the -destroyldapserver option to nuke everything in OD:

sudo slapconfig -destroyldapserver

Use the logs to help if you’re having replica creation problems. These can be added using the -enableslapdlog option:

slapconfig -enableslapdlog

You can use the -addreplica option to add replicas manually while running tail on the slapd logs:

tail -f /var/log/slapd.log

Once the replica has been created, you can add more and more until you exceed 32. At that point, you have a fairly large Open Directory environment and you go to add the 33rd replica but you get a funny error that dserr doesn’t have listed. The reason is likely that a single Open Directory Master can only have 32 replicas – and the fact that you’ve made it that far means you get a cookie. Cookie or no, you can have 32 replicas on each replica (thus having a replica tree), ergo allowing for a total of 1,024 replicas and a master. So rather than bind that 33rd replica to a master, move to a replica tree model, trying to offload replicas in as geographically friendly a fashion as possible (thus reducing slap traffic on your WAN links) by repositioning replicas per site. Similar to how Active Directory infrastructures often have a global catalog at each site, if you’ve got a large number of Open Directory Replicas then you should likely try and limit the number that connects back to each master per site to 1.

Assuming that each replica can sustain a good 350 clients on a bad day (and we always plan for bad days), even the largest pure Mac OS X deployments will have plenty of LDAP servers to authenticate to. However, you’re likely going to have issues with clients being able to tell which Open Directory server is the most appropriate to authenticate through. Therefore, cn=config will need to be customized per group that leverages each replica, or divert rules used with ipfw to act as a traffic cop. Overall, the replica trees seem to be working fairly well in Snow Leopard, netting a fairly scalable infrastructure for providing LDAP services.

You can also get pretty granular with the slurpd (the daemon that manages Open Directory replication) logs by invoking slurpd with a -d option followed by a number from 4 to 65535, with intensity of logs getting more as the number gets higher. You can also use the -r option to indicate a specific log file. If you have more than 32 replicas then it stands to reason that you also have a large number of objects in Open Directory, a fair amount of change occurring to said objects and therefore a fair amount of replication IO. In order to offload this you can move your replication temp directory onto SSD drives, by specifying the -t option when invoking slurpd.

The slurpd replication occurs over port 389 (by default). Therefore, in a larger environment you should be giving priority to network traffic. If you choose to custom make/install slurpd then you’ll also need to go ahead and build your Kerberos principles manually. In this case you would get a srvtab file for the slurpd server and then configure slapd to accept Kerberos Authentication for slaves. Having said this, I haven’t seen an environment where I had to configure slurpd in this fashion.

You’ve got Open Directory running and humming beautifully in Mavericks Server (Server 10.9). You show up to work and the hard drive has died on that perfectly configured Open Directory Master. Luckily, you have a replica and you have an archive of your Master. You can restore or you can promote your Replica to a Master. What to do? Well, I can’t tell you what you should do, but I can tell you that Apple has planned for this. Here, we’re going to look at promoting that Replica to a Master. Because after all, hard drives fail. Let’s look at what all this looks like.

Create An Open Directory Archive

In order to properly restore an Open Directory Master or promote a Replica to a Master, you’ll need the SSL keys. You should also just keep archives of your Open Directory environment around (albeit in a secure location) because you really never know. To create an Open Directory Archive, which has the keys in it as well as data needed to restore a Master, first open the Server app. From within the Server app, click on the Open Directory service.

Towards the bottom of the screen, click on the cog wheel icon. At the menu, click Archive Open Directory Master…

When prompted, provide the username and password to the Open Directory environment shown in the Server field and then click on the Connect button.

At the Archive Open Directory Master screen, choose a location to create your archive. Also, provide a password for the archive. Click the Next button when you’re ready to proceed.

At the Confirm Settings screen, click Archive. The archive is then created. Keep this safe as it has all your base are belong to us in it. You have to do this proactively. Once the hard drive in that Open Directory Master craps out, you’ll need the Archive to put the pieces of Humpty Dumpty back together again.

Promote A Replica To A Master

Provided you have a Replica and an Archive, promoting a Replica to a Master couldn’t be easier in Mavericks Server. To do so, open the Server app from the Replica and then use the cog wheel icon to bring up the menu.

Here, click Promote Replica to Master.

At the “Promote Open Directory replica to master” screen, provide an Open Directory username and password (e.g. diradmin with the appropriate password). Also, choose the archive you created previously. Then click Next. The Replica will become an archive. Once finished, remove any other replicas and repromote them.

Stop Open Directory

Another option is to stop Open Directory on the replicas until you can get your Master back up and running. To stop Open Directory, open the Server app and click on the Open Directory service.

Click on the OFF button. You’ll then be prompted to verify that you really want to stop directory services on the server. Click OK (which should probably read a bit more ominous, like “OMG, OK”.

The server is then stopped. To completely remove Open Directory from the server, run the slapconfig command, followed by -destroyldapserver:

slapconfig -destroyldapserver

Also, don’t forget to go to the Master and remove any servers from there as well, once they’ve been fully demoted.

Open Directory has never been so easy to setup for a basic environment as it is in OS X Mavericks Server (OS X 10.9, Server app 3). It’s also never been so annoyingly simple to use that to do anything cool requires a bunch of command line foo. No offense to the developers, but this whole idea that the screens that were being continually refined for a decade just need to be thrown out and started fresh seems to have led to a few babies thrown out along with them. Not often as I’m kinda’ digging most of the new config screens in OS X Mavericks Server, but with Open Directory, it’s just too easy. Features mean buttons. Buttons make things a tad bit more complicated to use than an ON/OFF switch…

Anyway, rant over. Moving on. As with almost any previous version of OS X Server and Open Directory, once you’ve installed the Server app, run the changeip command along with the -checkhostname option to verify that the IP, DNS and hostname match. If (and only if as it will fail if you try anyway) you get an indication that “The names match. There is nothing to change.” then you can move on to setting up the service.

 To set up the Open Directory Master, open the Server app and click on the Open Directory service (might need to Show under Advanced in the Server app sidebar). From here, click on the ON button.

For the purposes of this example, we’re setting up an entirely new Open Directory environment. At the “Configure Network Users and Groups” screen, click on “Create a new Open Directory Domain” and click on the Next button.

Note: If you are restoring an archive of an existing Open Directory domain, you would select the bottom option from this list.

At the Directory Administrator screen, enter a username and password for the directory administrator account. The default account is sufficient, although it’s never a bad idea to use something a bit less generic.Once you’ve entered the username and password, click on the Next button. Then we’re going to configure the SSL information.At the Organization Information screen, enter a name for the organization in the Organization Name field and an Email Address to be used in the SSL certificate in the Admin Email Address field. Click on Next.

At the Confirm Settings screen, make sure these very few settings are OK with you and then click on the Set Up button to let slapconfig (the command that runs the OD setup in the background, kinda’ like a cooler dcpromo) do its thing. When the Open Directory master has been configured, there’s no need to reboot or anything, the indicator light for the Open Directory service should appear. If the promotion fails then look to the preflight options I wrote up awhile back.

Once the promotion is complete, you’ll also see the server listed in the Servers list. Here, click on the server and click on the Global Password Policy option in the cog-wheel menu. This is where you can configure the parameters that passwords must meet in order to be usable on the system.

Clicking on the minus (“-”) button while a server is highlighted runs a slapconfig -destroyldapserver on the server and destroys the Open Directory domain if it is the only server. All domain information is lost when this happens.

Next, let’s bind a client. Binding clients can be done in a few different ways. You can use a script, a Profile, the Users & Groups System Preference pane or build binding into the imaging process. For the purpose of this example, we’ll use the System Preference pane.

To get started, open up the System Preference pane and then click on Users & Groups. From here, click on Login Options and then unlock the lock in the lower left corner of the screen, providing a username and password when prompted.

Click on the Edit… button and then the plus sign (“+”).

Then, enter the name of the Open Directory Master (the field will expand with options when you enter the host name.

It’s probably best not to use the IP address at this point as the master will have an SSL certificate tied to the name. Click OK to accept the certificate (if it’s self-signed) and then the system should finish binding. Once bound, I like to use either id or dscl to verify that directory accounts are properly resolving before I try logging in as an Open Directory user.

Provided everything works that’s it. The devil is of course in the details. There is very little data worth having if it isn’t backed up. Notice that you can archive by clicking on the cog wheel icon in the Open Directory service pane, much like you could in Server Admin. Or, because this helps when it comes to automating backups (with a little expect), to run a backup from the command line, run the slapconfig command along with the -backupdb option followed by a path to a folder to back the data up to:

sudo slapconfig -backupdb /odbackups

The result will be a request for a password then a bunch of information about the backup:

2013-10-07 19:25:28 +0000 slapconfig -backupdb
Enter archive password:
2013-10-07 19:25:33 +0000 1 Backing up LDAP database
2013-10-07 19:25:33 +0000 popen: /usr/sbin/slapcat -l /tmp/slapconfig_backup_stage116866ADKh0/backup.ldif, "r"
52530aad bdb_monitor_db_open: monitoring disabled; configure monitor database to enable
2013-10-07 19:25:33 +0000 popen: /usr/sbin/slapcat -b cn=authdata -l /tmp/slapconfig_backup_stage116866ADKh0/authdata.ldif, "r"
52530aad bdb_monitor_db_open: monitoring disabled; configure monitor database to enable
2013-10-07 19:25:33 +0000 popen: /bin/cp /var/db/openldap/openldap-data/DB_CONFIG /tmp/slapconfig_backup_stage116866ADKh0/DB_CONFIG, "r"
2013-10-07 19:25:33 +0000 popen: /bin/cp /var/db/openldap/authdata//DB_CONFIG /tmp/slapconfig_backup_stage116866ADKh0/authdata_DB_CONFIG, "r"
2013-10-07 19:25:33 +0000 popen: /bin/cp -r /etc/openldap /tmp/slapconfig_backup_stage116866ADKh0/, "r"
2013-10-07 19:25:33 +0000 popen: /bin/hostname > /tmp/slapconfig_backup_stage116866ADKh0/hostname, "r"
2013-10-07 19:25:33 +0000 popen: /usr/sbin/sso_util info -pr /LDAPv3/127.0.0.1 > /tmp/slapconfig_backup_stage116866ADKh0/local_odkrb5realm, "r"
2013-10-07 19:25:33 +0000 popen: /usr/bin/tar czpf /tmp/slapconfig_backup_stage116866ADKh0/krb5backup.tar.gz /var/db/krb5kdc/kdc.conf /var/db/krb5kdc/acl_file.* /var/db/krb5kdc/m_key.* /etc/krb5.keytab , "r"
tar: Removing leading '/' from member names
2013-10-07 19:25:33 +0000 2 Backing up Kerberos database
2013-10-07 19:25:33 +0000 popen: /bin/cp /var/db/dslocal/nodes/Default/config/KerberosKDC.plist /tmp/slapconfig_backup_stage116866ADKh0/KerberosKDC.plist, "r"
2013-10-07 19:25:33 +0000 popen: /bin/cp /Library/Preferences/com.apple.openldap.plist /tmp/slapconfig_backup_stage116866ADKh0/, "r"
2013-10-07 19:25:33 +0000 3 Backing up configuration files
2013-10-07 19:25:33 +0000 popen: /usr/bin/sw_vers > /tmp/slapconfig_backup_stage116866ADKh0/version.txt, "r"
2013-10-07 19:25:33 +0000 popen: /bin/cp -r /var/db/dslocal /tmp/slapconfig_backup_stage116866ADKh0/, "r"
2013-10-07 19:25:34 +0000 Backed Up Keychain
2013-10-07 19:25:34 +0000 4 Backing up CA certificates
2013-10-07 19:25:34 +0000 5 Creating archive
2013-10-07 19:25:34 +0000 command: /usr/bin/hdiutil create -ov -plist -puppetstrings -layout UNIVERSAL CD -fs HFS+ -volname ldap_bk -srcfolder /tmp/slapconfig_backup_stage116866ADKh0 -format SPARSE -encryption AES-256 -stdinpass /odbackups
2013-10-07 19:25:40 +0000 Removed directory at path /tmp/slapconfig_backup_stage116866ADKh0.
2013-10-07 19:25:40 +0000 Removed file at path /var/run/slapconfig.lock.

To restore a database (such as from a previous version of the operating system where such an important option was actually present) use the following command (which just swaps backupdb with -restoredb)

sudo slapconfig -restoredb /odbackups

Both commands ask you for a password to encrypt and decrypt the disk image created by them.

You’ve got Open Directory running and humming beautifully in OS X Server (Server 3.5 on OS X 10.10 Yosemite). You show up to work and the hard drive has died on that perfectly configured Open Directory Master. Luckily, you have a replica and you have an archive of your Master. You can restore or you can promote your Replica to a Master. What to do? Well, I can’t tell you what you should do, but I can tell you that Apple has planned for this. Here, we’re going to look at promoting that Replica to a Master. Because after all, hard drives fail. Let’s look at what all this looks like.

Create An Open Directory Archive

In order to properly restore an Open Directory Master or promote a Replica to a Master, you’ll need the SSL keys. You should also just keep archives of your Open Directory environment around (albeit in a secure location) because you really never know. To create an Open Directory Archive, which has the keys in it as well as data needed to restore a Master, first open the Server app. From within the Server app, click on the Open Directory service.

Towards the bottom of the screen, click on the cog wheel icon.

At the menu, click Archive Open Directory Master…

When prompted, provide the username and password to the Open Directory environment shown in the Server field and then click on the Connect button.

At the Archive Open Directory Master screen, choose a location to create your archive. Also, provide a password for the archive. Click the Archive button when you’re ready to proceed.

At the Confirm Settings screen, click Archive. The archive is then created. Keep this safe as it has all your base are belong to us in it. You have to do this proactively. Once the hard drive in that Open Directory Master craps out, you’ll need the Archive to put the pieces of Humpty Dumpty back together again.

Promote A Replica To A Master

Provided you have a Replica and an Archive, promoting a Replica to a Master couldn’t be easier in OS X Server. To do so, open the Server app from the Replica and then use the cog wheel icon to bring up the menu.

Here, click Promote Replica to Master.

At the “Promote Open Directory replica to master” screen, provide an Open Directory username and password (e.g. diradmin with the appropriate password). Also, choose the archive you created previously. Then click Next. The Replica will become an archive. Once finished, remove any other replicas and repromote them.

Stop Open Directory

Another option is to stop Open Directory on the replicas until you can get your Master back up and running. To stop Open Directory, open the Server app and click on the Open Directory service.

Click on the OFF button. You’ll then be prompted to verify that you really want to stop directory services on the server. Click OK (which should probably read a bit more ominous, like “OMG, OK”.

The server is then stopped. To completely remove Open Directory from the server, run the slapconfig command, followed by -destroyldapserver:

slapconfig -destroyldapserver

Also, don’t forget to go to the Master and remove any servers from there as well, once they’ve been fully demoted. View the logs using cat for any other weirdness:

cat /Library/Logs/slapconfig.log

Previously, we looked at setting up an Open Directory Master in OS X Server. An Open Directory Replica keeps a copy of the Open Directory database available for users even when the Master goes offline. But it can also take a part of the load from the Open Directory Master and when using the new Locales feature, balance network traffic. To get started with an Open Directory Replica, first enable SSH, now disabled by default.

Next, use the changeip to check the host name. While the Server app is cool, it caches stuff and I’ve seen it let things go threat shouldn’t be let go. Therefore, in order to make sure that the server has such an address, I still recommend using changeip, but I also recommend using the Server application. In OS X Server, I’ve seen each find things that other misses. Additionally, in Yosemite and above, OS X Server now requires to be able to lookup whatever the hostname is set to in order to actually promote either to a replica or a master. To use changeip to verify the hostname is set appropriately:

sudo changeip -checkhostname

The address and host names should look correct and match what you see in the Server application’s Next Steps drawer.

Primary address = 10.0.0.1
Current HostName = odr.krypted.com
DNS HostName = krypted.com
The names match. There is nothing to change.
dirserv:success = “success”

Provided everything is cool with the hostname, use the slapconfig command to preflight a replica prior to promotion. The syntax there is the same as the -createreplica syntax, used as follows, assuming the master has an IP address of 172.16.2.23:

/usr/sbin/slapconfig -preflightreplica 172.16.2.23 diradmin

Provided that the server is ready, open the Server app on a freshly installed computer you want to be your Open Directory replica.

Then, click on the Open Directory service.

Then, use the ON button to start the configuration process. When prompted, click on “Join an existing Open Directory domain as a replica” and click on the Next button.

When prompted, enter the parent Open Directory server’s host name (likely the name of the Open Directory Master), directory admin user name (the diradmin or custom username provided when Open Directory was configured), and then the directory admin password.

Then click on the Next button again to setup the services.

At the Confirm settings screen, click on the Set Up button and the replica is completed provided there are no issues with the configuration. Check Server app on both the Replica and the Master and verify that the server is displayed under the Master.

Once you’ve created your first replica, you can then start to define replica trees, where each replica looks at one above it, which then looks at another. I’ll do another article later on replica trees.

Note: If there are any problems during promotion, I start over every time using slapconfig along with the -destroyldapserver option to nuke everything in OD:

sudo slapconfig -destroyldapserver

Use the logs to help if you’re having replica creation problems. These can be added using the -enableslapdlog option:

sudo slapconfig -enableslapdlog

You can use the -addreplica option to add replicas manually while running tail on the slapd logs:

sudo tail -f /var/log/slapd.log

Once the replica has been created, you can add more and more until you exceed 32. At that point, you have a fairly large Open Directory environment and you go to add the 33rd replica but you get a funny error that dserr doesn’t have listed. The reason is likely that a single Open Directory Master can only have 32 replicas – and the fact that you’ve made it that far means you get a cookie. Cookie or no, you can have 32 replicas on each replica (thus having a replica tree), ergo allowing for a total of 1,024 replicas and a master. So rather than bind that 33rd replica to a master, move to a replica tree model, trying to offload replicas in as geographically friendly a fashion as possible (thus reducing slap traffic on your WAN links) by repositioning replicas per site. Similar to how Active Directory infrastructures often have a global catalog at each site, if you’ve got a large number of Open Directory Replicas then you should likely try and limit the number that connects back to each master per site to 1.

Assuming that each replica can sustain a good 350 clients on a bad day (and we always plan for bad days), even the largest pure Mac OS X deployments will have plenty of LDAP servers to authenticate to. However, you’re likely going to have issues with clients being able to tell which Open Directory server is the most appropriate to authenticate through. Therefore, cn=config will need to be customized per group that leverages each replica, or divert rules used with ipfw to act as a traffic cop. Overall, the replica trees seem to be working fairly well in Snow Leopard, netting a fairly scalable infrastructure for providing LDAP services.

You can also get pretty granular with the slurpd (the daemon that manages Open Directory replication) logs by invoking slurpd with a -d option followed by a number from 4 to 65535, with intensity of logs getting more as the number gets higher. You can also use the -r option to indicate a specific log file. If you have more than 32 replicas then it stands to reason that you also have a large number of objects in Open Directory, a fair amount of change occurring to said objects and therefore a fair amount of replication IO. In order to offload this you can move your replication temp directory onto SSD drives, by specifying the -t option when invoking slurpd.

The slurpd replication occurs over port 389 (by default). Therefore, in a larger environment you should be giving priority to network traffic. If you choose to custom make/install slurpd then you’ll also need to go ahead and build your Kerberos principles manually. In this case you would get a srvtab file for the slurpd server and then configure slapd to accept Kerberos Authentication for slaves. Having said this, I haven’t seen an environment where I had to configure slurpd in this fashion.

The command to create and tear down an Open Directory environment is slapconfig. When you disable Open Directory from the Server app you aren’t actually removing users. To do so, you’d use slapconfig along with the -destroyldapserver. When run, you get a little insight into what’s happening behind the scenes. This results in the following:

bash-3.2# slapconfig -destroyldapserver

The logs are as follows:

2014-09-18 14:42:02 +0000 slapconfig -destroyldapserver
2014-09-18 14:42:02 +0000 CopyReplicaArray: ldap_search_ext_s failed
2014-09-18 14:42:02 +0000 Error retrieving replica array
2014-09-18 14:42:02 +0000 Deleting Cert Authority related data
2014-09-18 14:42:03 +0000 Removed directory at path /var/root/Library/Application Support/Certificate Authority/Take Control Books Open Directory Certification Authority.
2014-09-18 14:42:03 +0000 command: /usr/sbin/xscertadmin add --reason 5 --issuer Take Control Books Open Directory Certification Authority --serial 2127185704
CopyCARecordByName: get ldapi node code = 2100 description = Connection failed to node '/LDAPv3/ldapi://%2Fvar%2Frun%2Fldapi'
No such issuer - failed to revoke certificate
2014-09-18 14:42:23 +0000 command: /bin/launchctl unload -w /System/Library/LaunchDaemons/com.apple.xscertd.plist
/System/Library/LaunchDaemons/com.apple.xscertd.plist: Could not find specified service
2014-09-18 14:42:23 +0000 command: /bin/launchctl unload -w /System/Library/LaunchDaemons/com.apple.xscertd-helper.plist
/System/Library/LaunchDaemons/com.apple.xscertd-helper.plist: Could not find specified service
2014-09-18 14:42:23 +0000 command: /bin/launchctl unload -w /System/Library/LaunchDaemons/com.apple.xscertadmin.plist
/System/Library/LaunchDaemons/com.apple.xscertadmin.plist: Could not find specified service
2014-09-18 14:42:23 +0000 void _destroyLDAPServer(const char *): Failed to find computer record named YosemiteSam.krypted.com$: 0 (null)
2014-09-18 14:42:23 +0000 Updating ldapreplicas on primary master
2014-09-18 14:42:23 +0000 CopyLdapReplicas: Unable to create DSLDAPContainer: 77014 Can't contact LDAP server (-1)
2014-09-18 14:42:23 +0000 CopyPrimaryMaster: CopyLdapReplicas failed
2014-09-18 14:42:23 +0000 Unable to locate primary master
2014-09-18 14:42:23 +0000 Primary master node is nil!
2014-09-18 14:42:23 +0000 Unable to locate ldapreplicas record: 0 (null)
2014-09-18 14:42:23 +0000 Error setting read ldap replicas array: 0 (null)
2014-09-18 14:42:23 +0000 Error setting write ldap replicas array: 0 (null)
2014-09-18 14:42:23 +0000 ODRecord *_getODRecord(ODNode *, NSString *, NSString *, NSArray *): ODNodeRef parameter error
2014-09-18 14:42:23 +0000 int _removeReplicaFromConfigRecord(ODNode *, NSString *): ODRecord not found
2014-09-18 14:42:23 +0000 Error synchronizing ldapreplicas: 0 (null)
2014-09-18 14:42:23 +0000 Removing self from the database
2014-09-18 14:42:23 +0000 Stopping LDAP server (slapd)
2014-09-18 14:42:23 +0000 Stopping password server
2014-09-18 14:42:23 +0000 Removed all service principals from keytab for realm YOSEMITESAM.KRYPTED.COM
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/__db.001.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/__db.002.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/__db.003.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/__db.004.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/__db.005.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/__db.006.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/altSecurityIdentities.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/apple-config-realname.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/apple-generateduid.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/apple-group-memberguid.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/apple-group-nestedgroup.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/apple-group-realname.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/apple-hwuuid.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/cn.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/DB_CONFIG.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/dn2id.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/entryCSN.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/entryUUID.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/gidNumber.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/givenName.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/id2entry.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/ipHostNumber.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/log.0000000001.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/macAddress.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/mail.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/memberUid.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/objectClass.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/ou.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/sn.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/uid.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/uidNumber.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/__db.001.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/__db.002.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/__db.003.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/__db.004.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/__db.005.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/__db.006.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/alock.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/authGUID.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/DB_CONFIG.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/dn2id.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/draft-krbPrincipalAliases.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/draft-krbPrincipalName.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/entryCSN.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/entryUUID.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/id2entry.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/log.0000000001.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/objectClass.bdb.
2014-09-18 14:42:23 +0000 Removed directory at path /var/db/openldap/authdata.
2014-09-18 14:42:23 +0000 Removed file at path /etc/openldap/slapd_macosxserver.conf.
2014-09-18 14:42:23 +0000 Removed file at path /etc/openldap/slapd.conf.
2014-09-18 14:42:23 +0000 Removed file at path /etc/openldap/rootDSE.ldif.
2014-09-18 14:42:23 +0000 Removed directory at path /etc/openldap/slapd.d/cn=config.
2014-09-18 14:42:23 +0000 Removed file at path /etc/openldap/slapd.d/cn=config.ldif.
2014-09-18 14:42:23 +0000 Removed directory at path /etc/openldap/slapd.d.
2014-09-18 14:42:23 +0000 Removed directory at path /etc/openldap/slapd.d.backup/cn=config.
2014-09-18 14:42:23 +0000 Removed file at path /etc/openldap/slapd.d.backup/cn=config.ldif.
2014-09-18 14:42:23 +0000 Removed directory at path /etc/openldap/slapd.d.backup.
2014-09-18 14:42:26 +0000 Stopping password server
2014-09-18 14:42:26 +0000 Removed file at path /etc/ntp_opendirectory.conf.
2014-09-18 14:42:26 +0000 Removed file at path /Library/Preferences/com.apple.openldap.plist.

Previously, we looked at setting up an Open Directory Master in OS X Server. An Open Directory Replica keeps a copy of the Open Directory database available for users even when the Master goes offline. But it can also take a part of the load from the Open Directory Master and when using the new Locales feature, balance network traffic. To get started with an Open Directory Replica, first enable SSH, now disabled by default. If SSH is not enabled, you will not be able to create an Open Directory Replica. SSH is enabled on a server by opening the Server app, clicking on the name of the server and then clicking on the Settings tab. here, check the box for “Secure shell connections (SSH)”.

Next, use the changeip to check the host name. While the Server app is cool, it caches stuff and I’ve seen it let things go threat shouldn’t be let go. Therefore, in order to make sure that the server has such an address, I still recommend using changeip, but I also recommend using the Server application. In OS X Server, I’ve seen each find things that other misses. Additionally, in Yosemite and above, OS X Server now requires to be able to lookup whatever the hostname is set to in order to actually promote either to a replica or a master. To use changeip to verify the hostname is set appropriately:

sudo changeip -checkhostname

The address and host names should look correct and match what you see in the Server application’s Next Steps drawer.

Primary address = 192.168.0.26
Current HostName = odr.krypted.com
DNS HostName = krypted.com
The names match. There is nothing to change.
dirserv:success = “success”

Provided everything is cool with the hostname, use the slapconfig command to preflight a replica prior to promotion. The syntax there is the same as the -createreplica syntax, used as follows, assuming the master has an IP address of 192.168.0.250:

/usr/sbin/slapconfig -preflightreplica 192.168.0.250 diradmin

Provided that the server is ready, open the Server app on a freshly installed computer you want to be your Open Directory replica.

Then, click on the Open Directory service.

Then, use the ON button to start the configuration process. When prompted, click on “Join an existing Open Directory domain as a replica” and click on the Next button.

When prompted, enter the parent Open Directory server’s host name (likely the name of the Open Directory Master), directory admin user name (the diradmin or custom username provided when Open Directory was configured), and then the directory admin password.

Then click on the Next button again to setup the services.

At the Confirm settings screen, click on the Set Up button and the replica is completed provided there are no issues with the configuration. Check Server app on both the Replica and the Master and verify that the server is displayed under the Master.

Once you’ve created your first replica, you can then start to define replica trees, where each replica looks at one above it, which then looks at another. I’ll do another article later on replica trees.

Note: If there are any problems during promotion, I start over every time using slapconfig along with the -destroyldapserver option to nuke everything in OD:

sudo slapconfig -destroyldapserver

Use the logs to help if you’re having replica creation problems. These can be added using the -enableslapdlog option:

sudo slapconfig -enableslapdlog

You can use the -addreplica option to add replicas manually while running tail on the slapd logs:

sudo tail -f /var/log/slapd.log

Once the replica has been created, you can add more and more until you exceed 32. At that point, you have a fairly large Open Directory environment and you go to add the 33rd replica but you get a funny error that dserr doesn’t have listed. The reason is likely that a single Open Directory Master can only have 32 replicas – and the fact that you’ve made it that far means you get a cookie. Cookie or no, you can have 32 replicas on each replica (thus having a replica tree), ergo allowing for a total of 1,024 replicas and a master. So rather than bind that 33rd replica to a master, move to a replica tree model, trying to offload replicas in as geographically friendly a fashion as possible (thus reducing slap traffic on your WAN links) by repositioning replicas per site. Similar to how Active Directory infrastructures often have a global catalog at each site, if you’ve got a large number of Open Directory Replicas then you should likely try and limit the number that connects back to each master per site to 1.

Assuming that each replica can sustain a good 350 clients on a bad day (and we always plan for bad days), even the largest pure Mac OS X deployments will have plenty of LDAP servers to authenticate to. However, you’re likely going to have issues with clients being able to tell which Open Directory server is the most appropriate to authenticate through. Therefore, cn=config will need to be customized per group that leverages each replica, or divert rules used with ipfw to act as a traffic cop. Overall, the replica trees seem to be working fairly well in Snow Leopard, netting a fairly scalable infrastructure for providing LDAP services.

You can also get pretty granular with the slurpd (the daemon that manages Open Directory replication) logs by invoking slurpd with a -d option followed by a number from 4 to 65535, with intensity of logs getting more as the number gets higher. You can also use the -r option to indicate a specific log file. If you have more than 32 replicas then it stands to reason that you also have a large number of objects in Open Directory, a fair amount of change occurring to said objects and therefore a fair amount of replication IO. In order to offload this you can move your replication temp directory onto SSD drives, by specifying the -t option when invoking slurpd.

The slurpd replication occurs over port 389 (by default). Therefore, in a larger environment you should be giving priority to network traffic. If you choose to custom make/install slurpd then you’ll also need to go ahead and build your Kerberos principles manually. In this case you would get a srvtab file for the slurpd server and then configure slapd to accept Kerberos Authentication for slaves. Having said this, I haven’t seen an environment where I had to configure slurpd in this fashion.

OS X 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 OS X Server called server setup. 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/Server.app/Contents/ServerRoot/System/Library/ServerSetup, 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.

One of the things that can can be useful about the scripts scattered throughout the Server app is to learn how the developers of OS X 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.

Looking At Services

This is also where I learned that Apple had put an Open Directory backup script in /Applications/Server.app/Contents/ServerRoot/usr/libexec/server_backup/opendirectorybackup (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/Server.app/Contents/ServerRoot/System/Library/ServerSetup/MigrationExtras/80-devicemgrmigration.sh ) 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/Server.app/Contents/ServerRoot/private/etc/jabberd/c2s.xml

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/Server.app/Contents/ServerRoot/private/etc/dovecot/default/conf.d, 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/com.apple.smb.server.plist 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 vpn:Servers:com.apple.ppp.pptp:Server:LogFile = “/var/log/ppp/vpnd.log”
sudo serveradmin settings vpn:Servers:com.apple.ppp.pptp:PPP:LogFile = “/var/log/ppp/vpnd.log”
sudo serveradmin settings vpn:Servers:com.apple.ppp.l2tp:Server:LogFile = “/var/log/ppp/vpnd.log”
sudo serveradmin settings vpn:Servers:com.apple.ppp.l2tp:PPP:LogFile = “/var/log/ppp/vpnd.log”

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

sudo serveradmin settings vpn:Servers:com.apple.ppp.pptp:Server:VerboseLogging
sudo serveradmin settings vpn:Servers:com.apple.ppp.pptp:PPP:VerboseLogging
sudo serveradmin settings vpn:Servers:com.apple.ppp.l2tp:Server:VerboseLogging
sudo serveradmin settings vpn:Servers:com.apple.ppp.l2tp:PPP:VerboseLogging

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.

Conclusion

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…

• As always, make a clone of your computer before upgrading.
• During the upgrade to High Sierra, if the operating system is running on a solid state drive, the drive will automatically upgrade to APFS. You cannot share APFS volumes over AFP, so if you’re running file services, make sure you’re aware of that. You can choose not to upgrade to APFS using the command line to upgrade a server. Even though the file sharing services are not in the Server app, you can still configure ACLs using the Storage tab under the server’s main screen.
• The FTP Service is gone.
• Time Machine service is gone, so if you were relying on that, rethink your backup strategy. Some options:
  • A third party backup tool.
  • A share that Time Machine on client systems can backup to.
  • Don’t upgrade.
• Xcode Server is gone. You can still leverage third party tools to get build automations in place, but this is no longer a built-in component of macOS Server. 
• Imaging is dead. But NetInstall still works. Because you need to run a firmware update for High Sierra (and APFS), there are caveats to imaging. You can run a NetInstall to install High Sierra onto clients (which does the firmware update). You can do a NetRestore (and Define NetRestore Sources for NetBoot) from a volume that’s already been converted to APFS to another volume that’s already been converted to APFS. But you can’t NetRestore an HFS+ volume onto an APFS volume or High Sierra on APFS onto a volume running HFS+. Long live DEP.
• If you’re running Calendar, Contacts, and/or Mail, then you should consider moving to Google Apps or Office 365.
• Running the Wiki service configures passwords to use a less secure way of storing passwords.
• Alerts, Certificates, Logs, Stats, creating users, Calendar, Contacts, Mail, Messages, VPN, Websites, Wiki, DHCP, DNS, and Xsan haven’t changed in forevers, and remain pretty static in this version.
• Open Directory and Software Update aren’t in the Services or Advanced area of the Server sidebar. You’ll access those through the View menu. The slapconfig and other binaries that comprise OD remain pretty much untouched where they are.
• If you’re running software like anti-virus that has Kernel Extensions, those should work upon upgrade (provided they’re High Sierra compatible). If you reinstall software with Kernel Extensions, you may have to accept the installation of the Kernel Extension, due to a new and more secure way of interacting with Kernel Extensions.
• There are new options in Profile Manager. 

The post Before You Upgrade to macOS Server 5.4 on High Sierra (macOS 10.13) appeared first on krypted.com.

• 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.

The post Manage Users On macOS Server 5.4 On High Sierra appeared first on krypted.com.

• On Prem Active Directory. I can setup Active Directory in about 10 minutes. And I can be binding Mac clients to it. They’ll get their Kerberos TGTs and authenticate into services and the 90s will be as alive on your server as they are in Portland. Here’s the thing, and I kinda’ hate to say it, but no one ever got fired for doing things the old reliable way. 
• OpenLDAP. There are some easy builds of OpenLDAP to deploy. You can build a new instance from scratch on a Mac (probably a bad idea) or on a very small Linux box. This is pretty easy, but to get all the cool stuff working, you might need some tweaking.
• Appliances. I’m already working on an article for installing OpenLDAP on a Synology.
• Microsoft Azure Active Directory. If you’re a primarily Microsoft shop, and one that is trying to go server-less, then this is probably for you. Problem is, I can’t guide you through binding a client to Active Directory in Azure just yet. 
• Okta/Ping/other IAMs. Some of these can act as a directory service of sorts ( https://help.okta.com/en/prod/Content/Topics/Directory/About_Universal_Directory.htm ). As with Azure, you’re likely not going to bind to them (although Nomad has some interesting stuff if you feel like digging into that).
• A hosted directory service provider (Directory as a Service) like Jumpcloud.

sudo slapconfig -backupdb ~/Desktop/slapexport/

The post Export data from Open Directory for migrating users and groups appeared first on krypted.com.

The post Promote A Replica To A Master In Mavericks Server appeared first on krypted.

The post Configure Mavericks Server To Be An Open Directory Master appeared first on krypted.

The post Promote A Yosemite Open Directory Replica To A Master appeared first on krypted.