Mac OS X Leper Server

Question

I am at the point of calling it Mac OS X 10.5 Leper. I am on my fifth time trying to install the server on a test PowerMac Dual-1.25GHz G4 with 2GB of RAM and tons of free disk space.
When the server gets to the last part of "Your server is being configured." it hangs. It hangs for about 30 minutes and then crashes.
I have erased the disk and zeroed the hard drive just in case. I've booted into another hard drive after the DVD installs to repair the directories and permissions. And I made a .dmg of the hard drive just after the DVD installation to reimage the darn thing instead of going through another installation for the sixth time.
I've had problems getting DNS running. I've had problems getting iCal working (and not related to DNS), and I cannot get Open Directory to work properly.
I have a 10.4.11 server that I've beaten on in the past. It's rock solid compared to Leper. However, I cannot upgrade from the 10.4.11 server to Leper because that also ends up in a disaster because all of the Web pages display improperly and you can't get web-enabled calendars to work properly.
The short of it is this: I have several clients in the greater NYC area that have been asking me my opinion of 10.5 server. By no means will I recommend or install this beast on any production machine until at least 10.5.4 or better. This operating system is terrible in its current incantation and should not have been released. I'm having flashbacks to Mac OS 7.
If you are interested in Mac OS X Server 10.5 and are considering purchasing, don't.

Answer 1

I finally got my server to where I want it to be and it was at the expense of sanity and sleep. But, I'm all the wiser now and want to share with everyone on this board some of the things I learned in my upgrade from 10.4.11 to 10.5.1.
To start, the service I was most compelled to use is iCal Server. For small businesses and home server users it really opens up a huge world of convenience to be able to share and update a single calendar.
*DISCLAIMER: My setup works for the environment I needed it for and as such some of the services can be implemented differently. Also, there are numerous bugs in 10.5.1, and I've been hit by a few good ones.*
My initial approach was to take the 10.4.11 server I currently use (running on a 500MHz dual-G4) and migrate it over to a new machine (1.25GHz dual-G4). I had to do this for obvious reasons, and it complicated my migration, but at the same time it provided me with a safety net. I took the old 40GB HD boot drive out of the old machine, put it in an external FW enclosure and "restored" the image onto the new machine. This way I was working with an exact copy of the server install and had a perfect backup on hand. I STRONGLY recommend backing everything up before you open your 10.5 Server DVD.
I spent several day prior to the migration installing 10.5 server onto the new machine to understand how the virgin installation process worked and what the new server UI tools looked like. It's the same basic suit of tools but they've all been modified and things are in different places. Some good, some not so good.
Once I understood how the new services interacted I decided to take the plunge and upgrade from 10.4.11 to 10.5.1. And initially it was disastrous (see initial post in this thread). Everything broke in new and different ways, and I screwed things up even more. So I punted and started all over again. And again. And again. Each time learning that 10.5 server has many more services that need to be set up in harmony than previous version of the OS. Getting it all right is not too difficult once you understand how and in what order. I'm going to try to list the sequence here.
Oh, one word of advice: I had the luxury of use two monitors to set my server up. I consistently had the Console on the second monitor to observe everything that was going on in the server. I selected All Messages to be displayed and it helped out tremendously. When things got weird, I could see the sequence of events.
During the upgrade installation you'll notice a few things that happen, one of which is an Open Directory LDAP upgrade. This should work without a hitch, but there's work that needs to be done to get it right.
Once you start up the server for the first time and go to Server Admin, you'll want to turn off all of the running services except for DNS and Open Directory. If your installation goes like mine, Kerberos will be spitting out errors and they need to be fixed. Start by going into DNS and checking your zones. When you initially go into DNS after an upgrade it will ask you to upgrade you current DNS to the new version on the server. This is pretty painless. Make sure you have a Primary Zone and a machine listed under that primary zone. DNS is where I encountered my first bug. Your Primary Zone record should be Fully Qualified by default. The machine that's listed as your server (in my case the Primary Domain is '100greenwood.net' and the Machine is 'ns') should NOT have the Fully Qualified checkbox selected. If this box is selected, the name will not resolve. Bug #1. You need to go to the '1.0.10.in-addr.arpa.' listing, expand it and select 'ns.100greenwood.net' as the reverse mapping for the address. My IP range is 10.0.1.x and my server IP is 10.0.1.240. So I selected 'ns.100greenwood.net' under the reverse mapping pulldown. THAT fully qualifies the domain name (FQDN) and reverse lookup for the server. Once you've done that part you can move on to Open Directory.
In Open Directory my 10.4.11 server was the Open Directory Master and I had kerberoized the server in 10.4.11. However, Kerberos was spitting out errors and I needed to fix that in order for the other services to work properly. Under Open Directory->Archive, archive your Open Directory database. Then, go to Settings and change the server role from OD Master to Standalone. This will wipe out the current Kerberos database. Then, change the role back to OD Master. When you do this, verify that the Kerberos settings (domain) match the DNS entry for your server exactly. If your DNS and server are set up properly, this should be automatically entered into the settings for you. If not, you have a problem with your server setup and DNS. I didn't so I don't have any advice if this isn't set up properly. Once you switch back to OD Master, go back and restore your OD database. This will fix most Kerberos issues as long as your DNS is set up properly.
With DNS set up properly and Open Directory/Kerberos set up fresh, I could now start enabling services. I started with the old faithful AFP. Pretty straightforward except that I had to recreate all of my SharePoints and that's no longer done in Workgroup Manager. Oh a word of advice about Workgroup Manager: It seems that it can lock the LDAP database when it's open. Trying to work with Open Directory in Server Admin while Workgroup Manager is open will cause unpredictable results. I learned to keep WGM closed unless it was absolutely necessary to work it in. But I digress...working with Share in Server Admin lacks the ability to grab users and groups to modify permissions. It's annoying but the two monitors made it easier since I could quickly look up short names in WGM. Now, since my SharePoints were new and I copied them over from the old server, I wanted to propagate permissions down through the points. When I did this I notices in the Console that the assistant program that actually does this work had a memory allocation error and crashed. It did this consistently on the local server and when the same process was initiated from a remote Server Admin instance. It causes Server Admin to stall on the status bar indicating that it's propagating permissions. Bug #2. I had to Force Quit Server Admin and go into command line and belt out a few 'chmod' and 'chown' to get the permissions where I wanted them.
Also, there seems to be a bug with AFP that causes it to reject clients' login information. It is sporadic and has happened in many different installations. It happened to me for a few hours, but it hasn't reeled it's ugly head yet. I am crossing my fingers that it's fixed. It seems to be related to the authentication between Kerberos and AFP. Getting Kerberos right is key to getting everything else on the server to work. And getting DNS to work right is key to getting Kerberos to work right.
My SMB settings are pretty straightforward. I have a PDC and the domain is GWD. This server is also the WINS server. Those setting seamlessly came over with the upgrade. The strange thing, however, is that SMB was no enabled from the start although it was enabled on the original 10.4.11 server. I enabled it and it worked flawlessly. I have no issue with this (surprisingly enough).
The Web services were another story. If you enable Web services and think everything is okay, you're kidding yourself. Apache 1.3 is enabled by default after an upgrade. The server home page won't render properly in Safari because of this. That, in turn, breaks most of the other web-enabled features in 10.5. You need to shut the service off and upgrade to 2.2. Make sure you test your web sites in 2.2 BEFORE you do this because you can't go back to 1.3. This is where a fresh copy of my 10.4.11 installation came into handy. I got good at 10.5 installs after a while. Once this was done I went into Web->Sites->Web Services and enabled Blog for Users and Wiki and Blog/Web Calendar in Services for Groups. Again, I wanted to get iCal working and these were the steps to get there (sans AFP and SMB).
Now, with DNS, Open Directory/Kerberos and Web Services all running properly, I started up the iCal Server. There is really very little to do here other than making sure your host name is the DNS name of your server, the one that was selected for reverse mapping.
At this point I was pretty much done with Server Admin and made my way over to Workgroup Manager to do some more calendar tweaks.
I went into a few users and under the Advanced tab Enabled Calendaring. I then went to a group these users were in and 'Enabled the following services for this group on: ns.100greenwood.net' and clicked wiki and blog/Web calendar. With that done, it was finally time to go to the client machines.
Since I had an Open Directory Master, I used the Directory Utility to add the OD Master to the client machine. Each time it couldn't automatically find the server, so I manually added it. I didn't use SSL in anything (yet) to keep things simple.
The great thing about getting OD set up properly is that the clients can seamlessly leverage all of the services on the server via auto-discovery. You can bet that Apple will be using this just as aggressively as Microsoft uses Active Directory to integrate everything. Hey, it's a directory service and it's coming along well so far.
Then I went into iCal to configure the clients. I went to Preferences->Accounts and added an account. I put a user name in, their password, used Kerberos for authentication and the client auto-discovered the correct calendar for the user. Very simple (after a full week of cursing and sleepless nights) with DNS set up correctly and OD/Kerberos working. Now, adding a group calendar required me to type in 'http://ns.100greenwood.net:8008/principals/groups/home/' into the Account URL window. Group calendars aren't auto-discovered.
That was it. It took me over a week to figure all that out. I had errors with every single service and most things went completely wrong for me. Expect things to go wrong with your installations. They will. The logs and the Console are your friends. Google and these boards are also very close friends too.
Some other notes: If clients suddenly cannot log into services, shut the service down at the server and restart it. This usually gives good results. Don't shut down Open Directory with all of the other services running. Open Directory and DNS should be the last two things to shut down in that order. If you are restarting all services, DNS should be first and OD second. Then everything else can work. Actually, there isn't a way to shut down OD, but this still applies if you are recreating your OD Master as I described above. There seems to be an issue with the way some services interact with Kerberos. Some security information can get cached and a restart of the service is one of the better ways to fix it (works in fixing the AFP-client authentication/disconnection issue described on these boards).
So I'm happy to say that I've finally got my server in a position where I understand the beast and am more confident in supporting it because of my trial by fire.
Now I'm going to bed.
Good luck with your installations!