As part of some self-documentation, I posted on my personal blog exactly what works and where I found the help for getting an OpenDirectory 10.5 Server running from a 10.4 in production box. The twist is that I needed to keep my SID and other PDC functionality that I've inherited up from 10.3.9. Yes, it can be done, and no you can't upgrade. Below is the reprint from my blog which I'm posting here for posterity:

Leopard server brings us a new interface for managing amavis in Server Admin. But, using some of the options of Server Admin's GUI doesn't modify correctly /etc/amavisd.conf and brings some weird issues

LANrev announced today that their InstallEase automated packaging tool is now free.

InstallEase is a tool for creating installer packages and has functionalities like automated "Before" and "After" snapshots, installation of files to current user's home folder, exclusion filters and uninstaller packages all wrapped into a graphical user interface for administrators.

Registration is required to get the free download, and is available here –http://www.lanrev.com/solutions/installease.shtml

After installing Leopard Server and ISC DHCPD, I had an itch- my logfile that I created (/var/log/dhcpd.log) was not getting rolled like the other logs.  I started looking into how Apple does this, and found a nice utility that is new in Leopard, although not new to the UNIX world… newsyslog.

Read on for more…

When creating an image, you typically have user creation as part of the build process. If you're doing this as part of a install and capture (aka the "Old Way") you simply create the user as part of the Setup Assistant, or use SysPrefs after the install to set it up.

Under Leopard, we have the very intriguing possibility of simply creating a series of files in the /var/db/dslocal folder structure that is very friendly for reproducing. This is especially handy for a package based, non-interactive imaging process like our friend InstaDMG. The problem is creating the password. You obviously can't run the passwd(1) command since that will change passwords on the existing machine. You need to create a shadow hash file that contains the password. In leopard and tiger, this file contains possibly quite a few password types, but the standard type is a salted SHA1 digest of the password (the salt is a random 4 byte integer).

Most people in the past have simply created a new account with the associated password, and saved the resuling hash file in the folder. This is nice, but can result in a shadow file that is consistant for all times. Since the hash is salted with a random integer, we can generate a new hash anytime we want, but will still have the same password. This way, over time, even if the passwords are the same, the hashes will be different. This is why if you compare a hash file with the same password, you still may get very different hashes.

I have created a simple PHP script that takes 1 parameter, a string password. It will then output a string that is suitable to be saved as a password hash file to standard output. The resulting string could be redirected to a file whose name is the GUID of the user who's password you wish to save. This hash file is valid for 10.4 and 10.5

In the future, I plan on making a script that automates the creation of this directory structure so it is suitable for packaging/automation with a non-booted volume. Obviously if this was a
booted volume, you'd just use dscl/passwd and be done with it.

Check out the script here

Comments/suggestions welcome.

On Feb 29th, two free Mac OS X Server and Xsan related training sessions in Tokyo are available for sign-up. Please feel free to login and sign-up while seats are still available.

Details are at AppleCert.org.

When the Apple Store came back up after this morning's Tuesday outage, I thought the new $49 price tag on the shuffle summed up the changes.

But I was wrong. 

Xsan2 has been released. See apple.com/xsan

And we have a big change up at apple.com/server/storage

We don't have new Xserve RAIDs, not exactly. 

It looks like Xserve RAID has been replaced with Promise's "VTrak E-Class RAID" units.

It is the same 3U, but instead of 14 drives, the Promise holds 16 drives.

Instead of PATA, now we have the choice of SATA or SAS. (750GB for SATA and 300GB for SAS drives). 12TB raw capacity if you want one big dangerous RAID 0 LUN.

4Gb/s FC instead of 2Gb/s.

Dual active/active controllers.

And of course, it supports Xsan 2. 

To activate the autobuddy function for the Jabber server first get the actual settings:  

sudo serveradmin settings jabber  

jabber:enableAutoBuddy = no

Notice that it's off, so now go ahead and set it to yes:

sudo serveradmin settings jabber:enableAutoBuddy = yes

After which you'll have to restart the Jabber server. Now comes the secret sauce, you have to manually run the process to update the buddy list for all users.

sudo /usr/bin/jabber_autobuddy -m  

Note that this has to be done every time you add a new user to the Jabber server. Also, users that are currently logged in will have to log out and back in again for the new users in the buddy list to show up.

PKGImage is a modular system deployment tool for leopard (10.5).

Now released here: http://www.apple-scripts.com/forum/viewforum.php?f=16

Read on for more info…

So this has recently been discussed on the MacEnteprise list, but we thought we'd try and collate these ideas into a real world example.

Most of you should be aware of how you can use MCX to manage preferences for your directory service. Generally these days this is done by either running Open Directory, extending the schema for Active Directory or a standard OpenLDAP installation, or running a "magic triangle" setup where your client machines are bound to both an Open Directory setup and an Active Directory/OpenLDAP setup.

You might think that apart from these scenarios that you don't have any options for MCX management, but that's not true at all. We do have another option. Put MCX controls into the local directory service. 

Read on for some practical examples….