I found Roundcube to be extremely easy to setup, however sort of hard to configure and tweak for use on an OSX Server. The biggest drawback to the old mail system was that while everyone had email accounts they were local accounts meaning their was no LDAP database at work so there was no way to have an auto complete or global LDAP address book that most of the people at our organization really craved. I decided that when moving to 10.6.2 we would have to get this feature established and I am documenting this here clearly as I found there was limited documentation for and I know there are many people using 10.6.2 and Roundcube together.

Once Roundcube is installed head over to main.inc.php in the Roundcube config directory. I wanted the user to have access to the LDAP address book and also have the ability to have their own so on this line make sure that SQL is chosen as the primarty type of address book if this is your intent.

1

$rcmail_config['address_book_type'] = 'sql';

in the main.inc.php file the LDAP settings are kind of tricky. It gives you an example of a functional LDAP setup below for an organization named Verisign locate these lines in the main.inc.php file

1
2
3

// In order to enable public ldap search, configure an array like the Verisign
// example further below. if you would like to test, simply uncomment the example.
$rcmail_config['ldap_public'] = array(Verisign);

Notice that the third line is un-commented meaning that it is an active setting. Which means that what we are about to do below will not register until we comment out this line otherwise there will be two active configurations and neither will work this really tripped me up and had me stumped for days until I realized that I had two

1

 $rcmail_config['ldap_public']

attributes at work at the same time so next comment this out as below.

1
2
3

// In order to enable public ldap search, configure an array like the Verisign
// example further below. if you would like to test, simply uncomment the example.
// $rcmail_config['ldap_public'] = array(Verisign);

Once this is done go down to the example below and start uncommenting the LDAP configuration lines one by one and filling out the information as you go here is an example of my configuration for the Name use whatever name you want the address book to show up as in the roundcube address book area. Your host name should be the fully qualified domain name of your directory server. Your default port on an ODM is 389. Only use TLS if you are using a secure SSL connection and always use User Specific so that the user is what is causing the OD Bind during lookups rather than the Directory Admin.

1
2
3
4
5
6

$rcmail_config['ldap_public']['Verisign'] = array(
  'name'          => 'Company Name',
  'hosts'         => array('fullyqualified.domainofdirectoryserver.com'),
  'port'          => 389,
  'use_tls'	    => false,
  'user_specific' => true,

Next you must define the Base Search DN which is always your fully qualified domain name split up using dc= so if your directory name was directory.verisign.com then your base dn would be dc=directory, dc=verisign, dc=com. Here is what is not documented in many places it took me a long time to figure out that the Bind DN must have an active user or the directory admins UID here as well as cn=users, so that it knows how to find that user. I also configured mine to be non writable because I was unsure how safe this would be with the ODM.

1
2
3
4

  'base_dn'       => 'dc=fullyqualified,dc=domainofdirectoryserver,dc=com',
  'bind_dn'       => 'uid=DirAdmin,cn=users,dc=fullyqualified,dc=domainofdirectoryserver,dc=com',
  'bind_pass'     => 'DirAdmin_Password',
  'writable'      => false,

In order to get an actual accurate listing in the address book you must tweak the settings to include the specific user settings int he ODM LDAP directory.

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

  'LDAP_Object_Classes' => array("top","person","inetOrgPerson","abxldapPerson"), 
  'required_fields'     => array("givenName", "cn", "sn", "mail"),    
  'LDAP_rdn'      => 'mail', 
  'ldap_version'  => 3,      
  'search_fields' => array('givenName', 'cn', 'sn', 'mail'),  // fields to search in
  'name_field'    => 'cn',    
  'email_field'   => 'mail',  
  'surname_field' => 'sn',   
  'firstname_field' => 'givenName', 
  'sort'          => 'givenName',    
  'scope'         => 'sub',  
  'filter'        => 'givenName=*',     
  'fuzzy_search'  => true);

These settings will help you establish the correct mappings to Last Name, First Name, Email Address and Full Name or Given Name. These settings were very hard to find as there was limited documentation on both Apples part and on the Roundcube forums. Once done here I set it up to auto complete from the sql address book first and then to default over to the LDAP address book.

1
2
3

// An ordered array of the ids of the addressbooks that should be searched
// when populating address autocomplete fields server-side. ex: array('sql','Verisign');
$rcmail_config['autocomplete_addressbooks'] = array('sql','Verisign');

In parting my only piece of advice is to use the configuration here and remove the term Verisign and replace that variable with one that makes sense for you and your organization. Lastly if this does not work make sure that you have the correct domain name of the server and also ensure that you have enabled users to access the LDAP directory in Workgroup Manager.

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!