krypted.com

Tiny Deathstars of Foulness

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.

Screen Shot 2015-09-25 at 8.47.29 PM

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

Screen Shot 2015-09-25 at 8.48.50 PM

Looking At Services

This is also where I learned that Apple had put an Open Directory backup script in /Applications/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…

October 8th, 2015

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

Tags: , , , , , , , ,

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)”.

Screen Shot 2015-09-24 at 10.00.02 PM

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.

Screen Shot 2015-09-24 at 9.15.38 PM

Then, click on the Open Directory service.

Screen Shot 2015-09-24 at 9.44.33 PM
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.

Screen Shot 2015-09-24 at 9.45.06 PM
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.

Screen Shot 2015-09-24 at 9.45.35 PM

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

Screen Shot 2015-09-24 at 9.56.29 PM

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.

Screen Shot 2015-09-24 at 9.58.43 PM

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.

September 30th, 2015

Posted In: Mac OS X Server

Tags: , , , , ,

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.

October 21st, 2014

Posted In: Mac OS X Server

Tags: , , , , ,

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.

odr1Then, click on the Open Directory service.

odr2Then, 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.

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

odr4

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

odr5

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.

odr6

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.

October 16th, 2014

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

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

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.

odrprom1

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

odrprom2

At the menu, click Archive Open Directory Master…

odrprom3

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.

odrprom4

Here, click Promote Replica to Master.

odrprom5

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.

odrprom6

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

odrprom7

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

October 16th, 2014

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

Tags: , , , , , , , ,

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.

Screen Shot 2013-10-07 at 2.16.23 PM 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.

Screen Shot 2013-10-07 at 2.17.55 PMFor 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.

Screen Shot 2013-10-07 at 2.18.39 PMNote: 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.Screen Shot 2013-10-07 at 2.20.11 PMOnce you’ve entered the username and password, click on the Next button. Then we’re going to configure the SSL information.Screen Shot 2013-10-07 at 2.20.54 PMAt 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.

Screen Shot 2013-10-07 at 2.21.18 PMAt 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.

Screen Shot 2013-10-07 at 2.22.18 PMOnce 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.

Screen Shot 2013-10-07 at 2.22.45 PMClicking 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.

Screen Shot 2013-10-07 at 2.23.13 PMNext, 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.

Screen Shot 2013-10-07 at 2.23.52 PMClick on the Edit… button and then the plus sign (“+”).

Screen Shot 2013-10-07 at 2.24.26 PMThen, enter the name of the Open Directory Master (the field will expand with options when you enter the host name.

Screen Shot 2013-10-07 at 2.24.51 PMIt’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.

October 22nd, 2013

Posted In: Mac OS X Server

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

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.

Screen Shot 2013-10-08 at 10.28.11 PM

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

Screen Shot 2013-10-08 at 10.28.23 PMWhen prompted, provide the username and password to the Open Directory environment shown in the Server field and then click on the Connect button.

Screen Shot 2013-10-08 at 10.29.03 PMAt 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.

Screen Shot 2013-10-08 at 10.29.06 PM

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.

Screen Shot 2013-10-08 at 10.28.11 PM

Here, click Promote Replica to Master.

Screen Shot 2013-10-08 at 10.29.37 PMAt 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.

Screen Shot 2013-10-08 at 10.29.57 PMClick 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”.

Screen Shot 2013-10-08 at 10.30.00 PMThe 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.

October 22nd, 2013

Posted In: Mac OS X Server

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

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.

August 11th, 2012

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

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

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.

August 10th, 2012

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

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

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

July 16th, 2012

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

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

Next Page »