multiple kolab servers

Hello All,

Do you know if there is a document somewhere that explains
how to set up 
multiple kolab servers?

I wonder especially how is works for the emails: what server
must be 
configured as the MX and how it redirects to the server that
holds the email 
account for the user. Is there anything specific to do to
postfix or to cyrus 
to that, or is it completely automatic?

Then, as for the client, if his/her email account is on a
specific server, 
does he/she have to set up the email client software to
query that server and 
not the master?

Is it useful to have multiple servers as a whole? (I have
lots of users here)

Thank you for helping,
-- 
Stéphane Konstantaropoulos <skonstantsgul.ac.uk>
-- Web Developer - Computing Services
--- St George's University of bond
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

Hi Stéphane & all

Stéphane Konstantaropoulos schrieb:

> Do you know if there is a document somewhere that
explains how to set up 
> multiple kolab servers?
> 
> I wonder especially how is works for the emails: what
server must be 
> configured as the MX and how it redirects to the server
that holds the email 
> account for the user. Is there anything specific to do
to postfix or to cyrus 
> to that, or is it completely automatic?

There are several relevant points for using multiple
servers, depending
on what you are up to. Basically Kolab consits of these
parts:
- smtp server (postfix, MTA)
- antispam and -virus (SpamAssassin, amavisd
- imap server (cyrus, MDA)
- directory server (openldap)
(- and some webstuff, ftp etc.)

Using multiple SMTP servers is quite easy: your second MTA
(e.g. MX 20
in DNS) just needs to know where to deliver mail. Either it
delivers
directly to Cyrus, e.g. on your primary machine or it
forwards to your
primary or even on-site SMTP. This mainly depends on how
your inbound
mail is directed and where/how you would like to scan for
virii and
SPAM. You can even have a dedicated machine for scanning.
This is all
postfix related and not kolab itself. AFAIK it is not
configurable via
Kolab webfrontend, only through proper service config files
(postfix
main.cf etc.).

If your focus is more on load balancing the users mailboxes
you are up
to Cyrus Murder (IMAP storage over multiple backend servers
= back end)
and Aggregator (IMAP load balancer = front end where users
connect their
MUA to).

Usefull links:

http://cyrusimap.web.cmu.edu/imapd/install-perf.html
http://cyrusimap.web.cmu.edu/imapd/install-murder.html
http://cyrusimap
.web.cmu.edu/ag.html

-> These tools are part of the Cyrus IMAP server, but
_not_ explicitly
of Kolab, allthough they are installed. I do not know how
well the Kolab
webfrontend cooperates with the config changes needed to get
Murder/Aggregator to work (my guess: it does not).

> Then, as for the client, if his/her email account is on
a specific server, 
> does he/she have to set up the email client software to
query that server and 
> not the master?

See Cyrus Murder and Aggregator: client MUA connects to
Aggregator,
which transparently proxies to the next free IMAP (or POP)
backend.

> Is it useful to have multiple servers as a whole? (I
have lots of users here)

As written above you can have various different multiple
servers.
Operation with multiple SMTP servers is quite easy, Cyrus
Murder/Aggregator is more advanced. For load balancing
openldap you
could use an IP sprayer - I ever tried and only read about
that. You can
also take a look at LDAP replication/distribution to use
multiple LDAP
servers and then configure each Cyrus backend server to use
one of those
(IMAP1 -> LDAP1, IMAP2 -> LDAP2 etc. pp.).

Some links I found with a quick Google lookup:
FAQ: flexible administration of multiple kolab servers
http://lists.kde.org/?l=kroupware&m=103336398
827374&w=2
The Big Kolab Kontact Interview - Part I
http://mail.kde.org/pipermail/dot-stories/2005
-January/000403.html
-> they say it is possible, but they do not tell how 

HTH,
Jan

_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

Le mardi 17 oct 2006 18:01, Jan Gerle a écrit :
> Hi Stéphane & all
>
> Stéphane Konstantaropoulos schrieb:
> > Do you know if there is a document somewhere that
explains how to set up
> > multiple kolab servers?
> >
> > I wonder especially how is works for the emails:
what server must be
> > configured as the MX and how it redirects to the
server that holds the
> > email account for the user. Is there anything
specific to do to postfix
> > or to cyrus to that, or is it completely
automatic?
>
> There are several relevant points for using multiple
servers, depending
> on what you are up to. Basically Kolab consits of these
parts:
> - smtp server (postfix, MTA)
> - antispam and -virus (SpamAssassin, amavisd
> - imap server (cyrus, MDA)
> - directory server (openldap)
> (- and some webstuff, ftp etc.)
>
> Using multiple SMTP servers is quite easy: your second
MTA (e.g. MX 20
> in DNS) just needs to know where to deliver mail.
Either it delivers
> directly to Cyrus, e.g. on your primary machine or it
forwards to your
> primary or even on-site SMTP. This mainly depends on
how your inbound
> mail is directed and where/how you would like to scan
for virii and
> SPAM. You can even have a dedicated machine for
scanning. This is all
> postfix related and not kolab itself. AFAIK it is not
configurable via
> Kolab webfrontend, only through proper service config
files (postfix
> main.cf etc.).
>
> If your focus is more on load balancing the users
mailboxes you are up
> to Cyrus Murder (IMAP storage over multiple backend
servers = back end)
> and Aggregator (IMAP load balancer = front end where
users connect their
> MUA to).
>
> Usefull links:
> 
http://cyrusimap.web.cmu.edu/imapd/install-perf.html
> http://cyrusimap.web.cmu.edu/imapd/install-murder.html
> http://cyrusimap
.web.cmu.edu/ag.html
>
> -> These tools are part of the Cyrus IMAP server,
but _not_ explicitly
> of Kolab, allthough they are installed. I do not know
how well the Kolab
> webfrontend cooperates with the config changes needed
to get
> Murder/Aggregator to work (my guess: it does not).
>
> > Then, as for the client, if his/her email account
is on a specific
> > server, does he/she have to set up the email
client software to query
> > that server and not the master?
>
> See Cyrus Murder and Aggregator: client MUA connects to
Aggregator,
> which transparently proxies to the next free IMAP (or
POP) backend.
>
> > Is it useful to have multiple servers as a whole?
(I have lots of users
> > here)
>
> As written above you can have various different
multiple servers.
> Operation with multiple SMTP servers is quite easy,
Cyrus
> Murder/Aggregator is more advanced. For load balancing
openldap you
> could use an IP sprayer - I ever tried and only read
about that. You can
> also take a look at LDAP replication/distribution to
use multiple LDAP
> servers and then configure each Cyrus backend server to
use one of those
> (IMAP1 -> LDAP1, IMAP2 -> LDAP2 etc. pp.).
>
> Some links I found with a quick Google lookup:
> FAQ: flexible administration of multiple kolab servers
> http://lists.kde.org/?l=kroupware&m=103336398
827374&w=2
> The Big Kolab Kontact Interview - Part I
> http://mail.kde.org/pipermail/dot-stories/2005
-January/000403.html
> -> they say it is possible, but they do not tell how

>
> HTH,
> Jan
>

Hi Jan,

Thank you for doing all that research for me, it is very
interesting the way 
Cyrus works.

However in a thread on kolab-devel, they seem to say that it
is possible to 
have multiple kolab servers while keeping it transparent
from the user.

I cannot find any explanation on how this works and I have
not run any tests 
yet. But it seems like postfixe will deliver to the right
server set upt for 
the user, then the question remains as to how the user sets
up his MUA to 
check his mail, and also the issue of webmail (that can be
set to query only 
one server. and this I cannot see in the generated
imapd.conf anywhere.

Does anybody know how to set up kolab in multi-location mode
and, say, how to 
use squirrelmaIl transparently with such a setup/

I now have two instances of kolab running and they
replicate, the set up was 
easy enough, thanks to all the wizards 

Thanks,
-- 
Stéphane Konstantaropoulos <skonstantsgul.ac.uk>
-- Web Developer - Computing Services
--- St George's University of bond
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

Le mardi 17 oct 2006 18:01, Jan Gerle a écrit :
> Hi Stéphane & all
>
> Stéphane Konstantaropoulos schrieb:
> > Do you know if there is a document somewhere that
explains how to set up
> > multiple kolab servers?
> >
> > I wonder especially how is works for the emails:
what server must be
> > configured as the MX and how it redirects to the
server that holds the
> > email account for the user. Is there anything
specific to do to postfix
> > or to cyrus to that, or is it completely
automatic?
>

HI All,

I'd like to share my experience with you:

I have set up 2 testing kolab servers. Using the debian
binary rpms on a 
Fedora system. Then using the kolab_bootstrap script I have
set them both up 
using mostly the defaults.

My user store however is on a Fedora directory and for this
I had to add a few 
things to kolab.conf and modify two templates:
main.cf.template (for postfix) 
and imapd.conf.template (for cyrus imap).

It is kolabd-1.9.4-20060111.

Once it was all configured properly, kolabd pulled all the
users from the 
Fedora Directory and created mailboxes for all of them, this
took some time 
but eventually it worked.

Even better, when I use the Outlook Toltec connector with my
slave and pop3 on 
the slave, I get the email that was delivered on the master
(which is the 
kolab host configure for me), not sure how that worked.

This is not running in production yet but soon will be, I
hope!

I hope this helps people.

Here are the snippets of my kolab.conf:

user_bind_dn : cn=xxxxxxxxxxxxxxxx
user_bind_pw : xxxxxxxxxxxxxx
user_directory_mode : slurpd
user_dn_list : ou=people,o=sghms.ac.uk,o=sghms.ac.uk
user_field_deleted : kolabdeleteflag
user_field_guid : nsuniqueid
user_field_modified : modifytimestamp
user_field_quota : mailquota
user_ldap_ip : 172.16.1.20
user_ldap_port : 389
user_ldap_uri : ldap://amstel.sgul.ac.uk:389
user_object_class : inetOrgPerson
userpassword : xxxxxxxxxxxxxxxxxxxxxxxx
user_php_dn: 
cn=nobody,cn=internal,ou=computing,ou=services,ou=staff,ou=p
eople,o=sghms.ac.uk,o=sghms.ac.uk
user_php_pw: xxxxxxxxxxxxxxxxxxx

(this has to be added to both serves, slave and master)

Then the few changes in main.cf.template:

So that postfix queries the user store.
The timeout had to be dramatically increased, our directory
is super slow and 
super big.

#
# LDAP Alias support
#

ldapvirtual_server_host = user_ldap_uri
ldapvirtual_search_base = user_dn_list
ldapvirtual_query_filter =
(&(!(kolabDeleteFlag=*))(objectclass=posixaccount)
(|(alias=%s)(mail=%s)))
ldapvirtual_result_attribute = mail
ldapvirtual_result_filter = %s
ldapvirtual_timeout = 200
ldapvirtual_scope = sub
ldapvirtual_bind = no
ldapvirtual_version = 3
ldapvirtual_domain = $mydestination

#
# LDAP Recipient map
#


#
# LDAP Distributionlist support
#

ldapdistlist_server_host = ldap_uri
ldapdistlist_search_base = base_dn
ldapdistlist_domain = $mydestination
ldapdistlist_query_filter =
(&(objectClass=kolabGroupOfNames)(!
(kolabDeleteFlag=*))(mail=%s))
ldapdistlist_special_result_attribute = member
ldapdistlist_exclude_internal = yes
ldapdistlist_result_attribute = mail
ldapdistlist_result_filter = %s
ldapdistlist_timeout = 15
ldapdistlist_scope = sub
ldapdistlist_bind = no
#ldapdistlist_bind_dn = php_dn
#ldapdistlist_bind_pw = php_pw
ldapdistlist_version = 3

#
# LDAP Transport for multilocation support
#

ldaptransport_server_host = user_ldap_uri
ldaptransport_search_base = user_dn_list
ldaptransport_query_filter =
(&(mail=%s)(objectClass=posixaccount)(!
(kolabHomeServer=$myhostname)))
ldaptransport_result_attribute = kolabHomeServer
ldaptransport_result_filter = smtp:[%s]
ldaptransport_timeout = 100
ldaptransport_scope = sub
ldaptransport_bind = no
#ldaptransport_bind_dn = user_php_dn
#ldaptransport_bind_pw = user_php_pw
ldaptransport_version = 3

==============

Now the changes to imapd.conf.template so that it also
queries the same user 
store:

# support for lookup of mailbox name from local LDAP server
ldap_uri:               user_ldap_uri
ldap_base:              user_dn_list 
ldap_bind_dn:           user_php_dn
ldap_password:          user_php_pw
ldap_time_limit:        15
virtdomains:            ldap




-- 
Stéphane Konstantaropoulos <skonstantsgul.ac.uk>
-- Web Developer - Computing Services
--- St George's University of bond

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

Am Mittwoch, 18. Oktober 2006 14:02 schrieb Stéphane
Konstantaropoulos:
> I have set up 2 testing kolab servers. Using the debian
binary rpms on a
> Fedora system. Then using the kolab_bootstrap script I
have set them both
> up using mostly the defaults.

Debian RPMs on Fedora?!? Thanks for trying this out. Might
be an interesting 
option to try out during my next major upgrade. Nice to know
that this works.

regards,
Andreas Micklei

_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

Le mercredi 18 oct 2006 13:12, Andreas Micklei a écrit :
> Am Mittwoch, 18. Oktober 2006 14:02 schrieb Stéphane
Konstantaropoulos:
> > I have set up 2 testing kolab servers. Using the
debian binary rpms on a
> > Fedora system. Then using the kolab_bootstrap
script I have set them both
> > up using mostly the defaults.
>
> Debian RPMs on Fedora?!? Thanks for trying this out.
Might be an
> interesting option to try out during my next major
upgrade. Nice to know
> that this works.
>
> regards,
> Andreas Micklei
>

Hi Andreas,

Well, the rpms of kolab only depend on the system's libc so
no problem 
occured. I did that instead of building because my systems
are x86_64 which 
is not supported by openpackage yet.

-- 
Stéphane Konstantaropoulos <skonstantsgul.ac.uk>
-- Web Developer - Computing Services
--- St George's University of bond
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

Am Mittwoch, 18. Oktober 2006 15:09 schrieb Stéphane
Konstantaropoulos:
> Le mercredi 18 oct 2006 13:12, Andreas Micklei a
écrit :
> > Am Mittwoch, 18. Oktober 2006 14:02 schrieb
Stéphane Konstantaropoulos:
> > > I have set up 2 testing kolab servers. Using
the debian binary rpms on
> > > a Fedora system. Then using the
kolab_bootstrap script I have set them
> > > both up using mostly the defaults.
> >
> > Debian RPMs on Fedora?!? Thanks for trying this
out. Might be an
> > interesting option to try out during my next major
upgrade. Nice to know
> > that this works.
> >
> > regards,
> > Andreas Micklei
>
> Hi Andreas,
>
> Well, the rpms of kolab only depend on the system's
libc so no problem
> occured. I did that instead of building because my
systems are x86_64 which
> is not supported by openpackage yet.

Exactly my setup. I used the source RPMs and a VMWare Server
instance running 
32bit Linux to build binary RPMs which I then installed on
my x86_64 system 
to get kolab 2.0.3 running. I will try to skip the build
step when upgrading 
to 2.1 eventually. So again, thanks for the info.

regards,
Andreas Micklei

P.s. Of course building for x86_64 as some brave people on
this list have 
already done might be another option by then.

_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users