Kolab Master and Slave Server
From Kolab Wiki
This wiki-page is based on Kolab Master and Slave configurations as they appear in Kolab 2.2.
What is Master and Slave?
You can run several Kolab servers together. The first server is the master, while consecutive servers are slaves. You can set up as many slaves as you like, but the master is unique. The master server keeps the original of the directory service. If directory service data is changed the OpenLDAP replication mechanism synchronizes the directory service of the master server to all slave servers. Only the master server can write into the directory service. Hence, if you set up a new slave server, you must set the correct master LDAP URI. You can read more about OpenLDAP replication here.
Note that slave servers do not provide back-up as data is not duplicated across nodes. However, slaves provide means for distributing load. This can be particularly important in a geographically distributed environment, i.e. when users are spread across different LANs, and external network bandwidth is limited. Slaves also provide easy means to distribute computational load and storage across several nodes in environments with many users and/or high utilization. Back-up should be done regularly for all servers, master and slaves.
What about redundancy?
Note that slaves do not provide redundancy for the master server, but as long as the master server is up you will have redundancy for all slave servers. If a slave goes down the master will accept incoming mail and retain it until the slave comes on-line again. Once a slave is up and running again, the master will forward mail to it. Unfortunately Groupware functionality tends to be high reliability services, so many will want redundancy for the master server. To this end a Diploma thesis describing a set-up is available for Kroupware, an earlier version of Kolab. Unfortunately the thesis is only available in German. The set-up uses Heartbeat to monitor mirrored master nodes, and fail-over if one node goes down. There are more recent reports on working set-up. As always, remember that redundancy does not replace the need for back-up.
Set up a new Kolab Slave Server
1. Add a new server to the list of Kolab hosts in Kolab webadmin. You can check the new host list in:
2. Run the bootstrap for the new server:
Note the following settings:
- The host type is "Slave".
- The URI of LDAP server is from sample "ldaps://master.example.com".
- The Base-DN is the same as the Base-DN of the master server.
- The manager password is the same as the password of the master server.
Note: Some times the bootstrapping process needs the root password of the master server.
3. Finally, you can start the new slave server:
/kolab/bin/openpkg rc all start
Each user needs to be registered on one node where all the user's data (mail, calender etc.) will be saved. The user will need to connect to this node for retrieval of data through https for the Horde web-interface, and through https and IMAP for the various clients. In particular, the corresponding ports need to be accessible to the slaves from the internet for remote synchronisation.
Shared IMAP folders can be set-up between users on different nodes since Kolab 2.0. The folder needs to be hosted on one node, and remote users need to access it by setting up an IMAP connection (in addition to the one at the user's home node) on the remote user's client to the hosting node.
Firewall set-up for remote slaves
If you have slave servers on different networks than the master server, you will need to ensure that appropriate network traffic comes through. For e-mail communication you will need to forward port 25 from the internet to the slave. For scheduling functionality you will need to forward https, i.e. port 443, from the internet to the slave. Security wise it is not a good idea to open http or ftp traffic. In case you want remote IMAP access, consider opening IMAP to the slave too.