Solutions to Some DNS, OD, AFP, CalDAV, AFP, and Spotlight Issues

Question

I recently upgraded our aging Xserve (1.3GHz G4, yeah baby!) to Leopard Server from Tiger Server so everything in the office would all be on the same OS. This server hosts all our in-use files via an Xserve RAID, and our dead files are on the internal 3-disk striped array. It's also the Open Directory master and hosts the office's DNS (I wanted to put OD and DNS on the new Xeon Xserve that hosts our FileMaker database, Retrospect backup, and our Squid web proxy, but something in its DNS configuration is broken and I gave up on that since OD and DNS don't really put any additional stress on the G4). Anyway, with all the hoopla of configuring, reconfiguring, and fixing, I've learned some things that may help others.
*DNS, Open Directory, and AFP*
I had some trouble with groups and ACL permissions, inability to get CalDAV working, and general strangeness with OD and Workgroup Manager. Demoting the server from an OD master to standalone took care of most of these. Part of the problem was an incorrect LDAP search base, which can only be corrected by blowing away the OD master and making sure DNS is set up properly. We only have about 20 users (we don't host network homes or anything like that), so when I did the demotion I just let it destroy all the accounts, and after promoting the server back to an OD master, I recreated the users and groups from scratch. So with freshly created users and groups, and after resetting the ACL's and propagating permissions on the network shares, that cleared up the permissions problems. The corrected LDAP search base fixed the Directory application too, which wasn't showing any contacts before, and it got Kerberos working as well.
iCal/CalDAV
All this work also got CalDAV/iCal calendar sharing running, and when I enable calendaring for a user, it stays enabled in WGM. Before, whenever I'd switch to another user and come back, calendaring would be turned off in WGM, although it was in fact still enabled. I haven't tested calendaring much yet, and adding an account in iCal is still a bit flakey. Our DNS is just internal, so in Server Admin I un-checked "fully-qualified" for our few DNS hostnames. If I mark the server's DNS hostname as fully-qualified, auto-discovery of the address in iCal won't work. iCal rejects my passwords if Kerberos authentication is used in either case, even if I manually point it to the IP address, but it connects fine without Kerberos.
*Spotlight and AFP*
Another problem I had after upgrading the server was stale spotlight searches. I used Server Admin to turn spotlight searching on and off for the two shares, and I tried any number of mdutil commands and System Preferences "privacy" settings to turn indexing on and off and to rebuild the indexes. With the old machine and about a terabyte of data, indexing would take all night, so I couldn't really try a lot of things. Every time the index was rebuilt, it would propagate out to the office just fine, but it would never update from then on. The solution to that was changing the permissions on the volumes the shares are on. The shares themselves had the correct permissions and ACL's, but the volumes need their POSIX permissions set to:
owner: root: read/write/execute
group: admin: read/write/execute
everyone: read/execute
Over the years those permissions had been changed (this server started out with OS X 10.2 Server btw, so there's been plenty of time for things to get b0rked), but Tiger Server apparently didn't care. Another thing I did (although I'm not sure if this was necessary) was to change the "Others" POSIX permission from None to Read Only. Once all that was changed, mdworker started chugging along to keep the spotlight index updated. However, it went nuts after the 10.5.6 Server update, constantly working with no sign of ever finishing. The update notes do make specific mention to Spotlight changes, which says you have to disable spotlight indexing for any shares in Server Admin, then re-enabled it to "take advantage of the new features." That started another night of indexing, but it's now done and updating properly. I noticed that a new inherited ACL for the user "Spotlight" showed up at the root level of each share point. I'm not going to touch that.
I'll admit that I hate spotlight's interface and lack of control in Leopard (i.e. it always resets your search parameters, you can't change the results window's columns, and you have to already be in the folder you want to search, etc.). That being said, I can search for anything on the server and it finds the results almost instantly. Even a search that returns "more than 10,000" results only takes about 5 seconds. With Tiger or Panther server, ANY search would take several minutes and grind the server to a halt, making anyone else who tried to save a file or navigate the shared volumes get the spinning beach ball.
Hopefully this will be of help to someone.

Answer 1

Hi.
You've not outlined your issues with AFP per se, having any ?
DNS is critical for OS X Server, it's appropriately finicky about working forward & reverse DNS lookup for its FQDN.
Certainly, Leopard Server may make assumptions contrary to your intent, if using the non-advanced setups, as it will attempt to use DNS and if not available, this may result in settings other than you desire.
By default, hostnames entered in the Server Admin DNS settings, will be considered as part of the DNS zone you're editing.
So:
server
would be for: server.yourfqdn.com
If you mark that as fully qualified, well, then it's looking for: server
which is not a FQDN
As well, I believe Apple states it should no longer be necessary, but if you do need to change the hostname for your OD master, it is often possible via the Termina/command-line via:
(sudo) changeip
http://developer.apple.com/documentation/Darwin/Reference/Manpages/man8/changeip .8.html