Open Directory is essentially Apples way of handling large scale authentication, system and user management. It is based off LDAPv3 and integrates with a variety of other authentication protocols such as:-

• flat files
• active directory
• NIS
• other LDAP servers

It also provides a way to easily setup Kerberosv5. Unlike normal uses of LDAP systems which comprises mainly of Address Books, as well as normal Authentication, Apple uses the very same system to also store user configurations, system setup preferences, mount point and configuration information and many more. While this makes LDAP a little slow due to the large number of records, it provides a very standard way of being able to access the data off any system. It is therefore possible to map LDAP entries from the Mac into any other system.

The LDAP based configuration also allows administrators to be able to login from any point in the network to perform management if required to do so. Replication and synchronization is also possible.

Open Directory Setup and Replication notes

Setting OD is relatively straight forward and doesn’t require too much configuration if the defaults are to be used. Unless you want to setup Kerberos, simply selecting OD setup within Server Admin tool is enough to get the OD up and running. Setting up replication of OD servers is also a simple case of selecting the option in Server Admin.

Changing passwords for users in the terminal can be done with either

• passwd, or
• kpasswd

I have also come across web based password changing applications such as

• OSXPass (http://sourceforge.net/project/showfiles.php?group_id=102051)
• MOSXSWebPassword (http://ps-enable.com/software/MOSXSWebPassword.dmg/view)

Of the above, i prefer the former to the latter as it does not use Web Objects.

In either case, the password will be synced going through the password service. If replication is setup, it can take as long as 8 minutes or even longer before the passwords can be synced to all the replicas. In some of the testings that is done by customers, they have found that the optimal number of replicas for a tolerable update time (perhaps 5-8 minutes) is 3 replicas. Anything more than that seems to take a much longer time to replicate. The log files are located in:-

• /Library/Logs/PasswordService
• /Library/Logs/slapdconfig.log

These two files will provide alot of clues on the activities of OD as well as issues if they should arise.

Some other K-base articles includes

• http://www.afp548.com/forum/viewtopic.php?forum=39&showtopic=10386
• http://docs.info.apple.com/article.html?artnum=302332

Oversights during a OD tear down

As everything is directory dependent, I have made some mistakes during OD tear down resulting in weird configurations which needs cleaning up. Mainly, the job would be to review the environment and to remove all Directory configurations of share points before the teardown begins. Not doing so will result in many rouge entries which you cannot clean up after.

However, if it so happens that there are rouge entries, after reverting the OD master to standalone configuration, you can use Workgroup Manager tool, and set to “show all”. Following that, check the “Share Points” directory data and remove unwanted entries.

Also remember to check up the actual IP addresses of the various replicas and remove them first. Take note of the exact interface that the replication is going through in the log files. I have encountered that depending solely on the Server Admin tool’s report of IP can be wrong.

Re-Importing Users

Within the Server Admin tool, there is a archive and restore ability which can be used to backup the OD settings. While i have successfully tried that out in a classroom environment, i have yet to try it in a live environment.

Within the Workgroup Manager tool, there is another ability to export users. However, the exporting of these users will cause everyone to lose their passwords. Whiel i have so far been able to re-import the users list successfully, there has always been problems after. These problems includes:-

• the directory admin (diradmin) losing its ability to login to the domain from workgroup manager
• users not being able to login after re-import

Directory Admin being unable to login

In this case, there seems to be some error during the import that completely knocks out the original setup diradmin password. The way to prevent this is by:-

1. During the export of the user list from the original OD, ensure that the diradmin entry is NOT exported
2. If you don’t have the luxury to re-export, edit the exported file and examin the entries. Remove the block of entires that corresponds to the diradmin user.

However, you will find that even after that, it is still not possible to login from the Workgroup Manager tool. Don’t worry, the diradmin password is still correct, but somehow, it can’t login. To get around this, use the root user name and its password to login to the Workgroup Manager tool. Once authenticated, login to the directory by selecting the “lock” icon near the top right, and use the diradmin username and password. You will find that you will be authenticated and logged in. From there, you will be able to make all the required changes to the directory as per normal.

I have no idea why you have to use the root user to login to Workgroup Manager initially, but the above method works for me.

Note: Remember to reboot the machine when changes are made to the directory as the config settings are picked up only during boot time.

Users unable to login after re-import

This happens as the user list is exported without passwords. One will find that under “Advanced” in Workgroup Manager, all the user passwords will be “Crypt Passwords”. All that needs to be done is to reset them to “Open Directory” Passwords and everything will be ok.

I have heard of a tool called Passenger from http://macinmind.com/. But i have yet to be able to use it successfully.

Once done, the user should be able to login to CLI and change passwords as per normal. However, like mentioned before, if many replicas are used, it will take some time for all the passwords to sync up.

Proper OD migration for any upgrade activities

Apparently, the best way to migrate the OD to perform any form of upgrade activity is to do the following:-

1. Switch off the OD master (server A) and bring it off the network
2. Promote one of the replicas ( server B) to OD master
3. Set server A to stand alone and perform the upgrade of server A
4. Re-attach server A to the network and set it up as a replica to server B
5. Switch off server B and bring it off the network
6. Re-promote server A to OD Master
7. Set server B as stand alone and perform the upgrade on server B
8. Re-attach server B to the network and set it up as a replica to server A
9. and so on and so forth….

Apple introduced what was termed as Lights Out Management when they released their new Intel Based Servers. This is essentially nothing new when Intel based Server boards are concerned. I suppose this is just a different term to what is known as IPMI.

Functionality

LOM allows one to be able to both monitor hardware status of the server, but it also allows one to be able to power on and power off the hardware remotely. This means if the server is down, one would be able to cold power on the hardware. This functionality is very similar to the Remote Service Adapter in IBM.

Configurations

The configuration of LOM sits within Server Monitor provided by the Server Admin tools that is installed with either the XServe or the Admin tools package within the Server DVD. All one has to do is to launch the Server Monitor application, and select the Server menu item, followed by the Configure Local Machine item. Once this is done, a dialog with IP address settings is presented. Configure these with the desired IP addresses and the user name and password to access the LOM. Once that is done, Appleand exit.

Do note that there is no extra Ethernet interface that is attached to the server. This means that perhaps a virtual Ethernet port is created that uses the existing 2 Ethernet port connected on-board the server.

Quirks

There are several irregularities that i have observed when using LOM.

1. A local machine cannot monitor itself using the defined LOM IP address. But 127.0.0.1 will work. But perhaps this is related to the point below.
2. The IP address defined within the LOM setting would have to be setup such as a monitoring machine will be able to access its network parameters
   • This means that if you have a machine that is meant to do management, a separate network is required on top of the typical IP network.
   • This is in exception to the fact IF you setup all the IP addresses reachable within the access network to be in the same network range as the actual Ethernet ports. For example, if your actual Ethernet configuration is setup as 10.0.0.1/255.255.255.0 and your LOM network ip is set to be 10.0.0.101/255.255.255.0, This is fine (but not a suggested configuration due to security).

The Apple Remote Desktop (ARD) is a software mangement and weakly monitoring tool that can be used to control multiple desktops or servers at a time. It can call up a VNC like terminal, or be used to dispatch files, UNIX commands or even lock down other machines. It can also be used to shutdown other machines or wake them up.

Controlling ARD from the command line

Once in a while, ARD can run into errors such as the VNC not being able to display properly or somehow, unable to start or stop. In such cases, especially in HPC, the only method of acess, being SSH, would be the way to restart or re-configure some startup parameters of ARD.

Luckily, Apple Remote Desktop includes the “kickstart” command line utility. It allows you to install, uninstall, activate, configure, and restart components of Apple Remote Desktop without restarting the computer. You can configure all the features found in Apple Remote Desktop preferences.

The kickstart utility is located here:

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart

You need an administrator account to use the kickstart utility. To begin using the kickstart utility, use the sudo command, such as:

$ sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart \
      -restart -agent

Note: All commands presented in this document should be typed as one line of text. It’s OK if the text wraps as you enter it, just be sure not to enter hard carriage returns.

Following are some examples of other things you could do.

• Activate Remote Desktop Sharing, en! able access privileges for all users, restart ARD Agent:

$ sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart \
      -activate -configure \
      -access -on -restart -agent

• Activate Remote Desktop Sharing, enable access privileges for the users “admin”, grant full privileges for the users “admin”, restart ARD Agent and Menu extra:

$ sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart \
      -activate -configure \
      -access -on -users admin -privs -all -restart -agent -menu

Note: The -users flag should refererence the shortname of a user of the system.

• Activate Remote Desktop Sharing, disable access privileges for all users:

$ sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart \
      -activate -configure \
      -access -off

• If you just want to stop the ARD Agent process:

$ sudo /System/Library/CoreServices/Remote! Management/ARDAgent.app/Contents/Resources/kickstart \
      -agent -stop

• If you want to deactivate it:

$ sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart \
      -deactivate -configure \
      -access -off

Tip: For more information about using the kickstart command, add the -help flag. For example:

$ sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -help

Hostname refuses to change after setup

Sometimes, i have very interesting circumstances whereby during a setup of a Mac cluster, i find that the hostname of the management node needs to be changed. However, after changing the computer name and the sharing name, the hostname command continues to provide the old hostname which is then wrong.

The below methods will then do the trick.

• To change only the host name

  changeip - current-ip-address current-ip-address current-host-name new-host-name
  /System/Library/ServerSetup/serversetup -setComputername new-host-name
  /System/Library/ServerSetup/serversetup -setBonjourname new-host-name
  reboot

• To change only the IP address

  changeip - current-ip-address new-ip-address
  /System/Library/ServerSetup/serversetup -setInfo en0 new-ip-address new-netmask new-router 
  reboot

• Both

  changeip - current-ip-address new-ip-address current-host-name new-host-name
  /System/Library/ServerSetup/serversetup -setComputername new-host-name
  /System/Library/ServerSetup/serversetup -setBonjourname new-host-name
  /System/Library/ServerSetup/serversetup -setInfo en0 new-ip-address new-netmask new-router
  reboot