When 10.5 server came out not only were there personal calendars but group calendars. The difference was that the personal calendars allowed the user to fully manage their calendar both on the web and in iCal however Apple still maintained that group calendars would be only subscribe-able in iCal. The difference here was that many users found workarounds that allowed the fully managed solution of group calendars in iCal by using the following methods.

Method A: Creating a user account and changing the server path with the “groups” variable. (Solution)

Method B: Creating a user account and changing the server path with the “wikis” variable. (Solution)

This worked but much needed security updates broke both of these solutions causing unnecessary stress on the Apple user and the Apple systems administrator. The most recant update to 10.6.4 caused the group calendars in iCal to stop working entirely and cause an almost never-ending string

of login failed errors on the users computer. This made it very frustrating for Administrators who are trying to sell the idea of a wiki server as being a great web based and iCal based interface for users. In Apples defense they never officially claimed to support group calendaring in iCal.

One of the reasons for this was probably because of the volatile nature of the group account. In 10.5 server group calendars were maintained and created using workgroup manager in 10.6 server they were separated entirely and now the administration of group wikis is all done through their web interface. Due to the separation groups that once had a unique UID, username and password were demoted to the basic functionality of a web folder and directory for the purpose of internet data organization.

With this in mind I was very pleased when Apple released its 10.6.4 Wiki Server update. The thing that really made me happy was the fact that now they have officially come out and are supporting group calendars in iCal. This is awesome finally what we have been waiting for. The best thing is that in true Apple fashion their update offers an elegant and much faster solution.

So how do you setup group calendars in 10.6.4? The answer is not really surprising as it takes some of the steps used in previous solutions.

Oddly enough this solution was and should be credited to a user on this post who had originally tried to get group calendars in iCal working in 2009! Looks like Apple took some much needed advice in this arena and I am very happy that they have officially started supporting this much needed feature.

Great, another strange Apple bug I thought until someone was able to forward me the bounced email to my personal email account. Further insight in the error showed that the message was getting bounced back due to a blank subject line. As you can see from the example below its due to a blank or empty subject heading. Yes, apparently Apple has added this as an actual “Feature”. You can turn this off however by commenting out the only line of code in the file /etc/postfix/custom_header_checks.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

=====================================
This is the mail system at host mail.xxxxxxx.org.
 
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
 
For further assistance, please send mail to postmaster.
 
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
 
The mail system
 
<user@domain.org>: host
mail.domain.org http://xx.xxx.xxx.xxx said: 550 5.7.1 empty subject
=====================================

Turn off the mail service before you do this. Once the mail service is off edit the file using sudo pico.

1
2
3
4
5

/^subject: *$/ REJECT empty subject header in /etc/
 
into:
 
#/^subject: *$/ REJECT empty subject header in /etc/

Start mail back up again and you will notice that the blank subject line blues are gone away.

setup the 10.6.2 Snow Leopard server clean before I did anything I setup DNS on the server and manually retyped and rechecked all of the DNS records from the 10.5 server to the 10.6.2 server. Once I verified that the DNS records were set. I checked the server’s DNS by running sudo changeip -checkhostname and it came back clean. Great good to go, or so I thought.

I had setup split horizon DNS on the server, the Open Directory Master, has already been setup on a single use Mac Mini Server. The Mac Mini Server is running the ODM and DNS. The DNS on the Mini is self referencing and my router has the public ip mapped to the private. The new Mail server (10.6.2) also running DNS had a record pointing to the public ip of the ODM. Great, next step bind the mail server to the ODM so that I can start to migrate mail accounts.

I was working on this project around 10:00pm in the evening not knowing how long that it would take to migrate the accounts from Cyrus to Dovecot, but I had studied the Apple upgrade instructions for weeks prior so I felt like I had it totally under control. I followed the instructions and used the code from page 42 of the manual.

sudo /usr/libexec/dovecot/migrate_mail_data.pl --moveMail 0 --cyrusBin "/Volumes/10.5 Server Volume Name/usr/bin/cyrus/bin" --database "/Volumes/10.5 Server Volume Name/var/imap" --sourceSpool "/Volumes/10.5 Server Volume Name/var/spool/imap" --targetSpool "/var/spool/imap/dovecot/mail"

The script will tell you if your doing something wrong, which is helpful. My biggest question was how long would it take to migrate 30GB of mail to the new mail server. The answer, exactly two hours. I had decided that instead of using a firewire cable to connect the two servers together that I would simply pop the HD out of the old mail server and put it into the new server. This made a huge difference in the time of migration.

Once it finished I turned on mail, and everything started working fine. Great! I cleaned up my tools and logged out of the server and went home around 2am. The next few days were pure hell. As mentioned above I decided to use split horizon DNS. It was my first attempt at doing this and what I had noticed in the logs were a myriad of disconnect warnings every 5 min the mail server was getting disconnected from the ODM and then reconnecting causing some major issues.

The log files were filling up so fast that they were causing kernel panics, I had to reboot the server many times once every couple of hours, I decided to call Apple. The Apple representative captured my logs, and promptly told me that I would have to reformat the hard drive and completely start over. I told him that this was a clean install and that no way would I be starting over. He offered no other solution or advice other than telling me that it was not normal for a new server to have kernel panics this early in the game.

I decided to check my DNS turns out that the route statement in the router, was not properly entered. It was getting to the server but it was unable to retain a connection. I re-entered the route statement correctly and then rebooted the router. Almost immediately the issues stopped. Apple has come a long way in their migration capabilities if your ever having issues with your 10.6.2 mail service DNS is almost always the culprit!