Migration from SLES 11 (cyrus + ldap) + egroupware to Zimbra 7

[clmates]

Hi to all.

First of all sorry for the long post, I have been reading the forums and the wiki but cant find answers regarding some things of our setup.

We are currently using a mail server based on SLES 11 with postfix as MTA, cyrus as IMAP server, LDAP (openldap) as authentication backend and also as addressbook repository. And want to evaluate if I can replace this with Zimbra Opensource.


Our users use egroupware as webmail and some prefer desktop application and uses thunderbird (they only access addressbook in query mode).

Our current architecture is like this:

Internal LAN:

Main Server (file server + ldap server + dns + dhcp + postfix + cyrus + spamassasin + clamAV + amavis) (SLES 11 sp1)

Hylafax + emailing server (hylafax + postfix ) email to fax+ print to email (SLES 11 sp1)

Firewall: (smoothwall)

DMZ:

external mail server and web server (apache + squid + postfix + spamassasin + clamAV + amavis) (opensuse 11.4)


Outgoing mail

internal users connect to main server and all outgoing mail is relayed to external mail server then to the internet.

they can print to email to our Hylafax server and this will be relayed also trough the external mail server.

they can also email to fax via our Main Server, this email with syntax like destinationnumber@fax.hylafaxserver.ourdomain.com will be relayed to our hylafax server, this process this emails with a fax service (in master.cf) and send the emaill and its attachementes as faxes to the destination

Incoming Mail

All incoming mail is received by external mail server that checks spam and viruses and check valid users vs the internal ldap and then relay the accepted mail to internal mail server that also check virus and spam and delivers to cyrus imap


What I want to know is if I can integrate Zimbra in this environment with a new server (or virtual server) and continue using SLES ldap as authentication backend and then migrate ldap addressbook to zimbra and cyrus mailboxes to zimbra.

Also I want to know if I can setup the zimbra server in parallel of the current server so I can test with a few users.

In fact I want to maintain (at least in the beginning) the external mail server intact as a postfix receiver and relaying all outgoing from Zimbra to this external mail server . Also I need to maintain the hylafax server working like this, so zimbra should be able to relay to use differentiated transports based on destination address (or to specify a transport for a specific host.domain)


I have an empty server with 2 GB Ram and 2 x 73 GB SAS HD, could this be enough for a test server? (we plan to install it on a SLES 11 + sp1)

currently we are about 30 users.
/var/lib/ldap is about 60 MB
/var/lib/imap is about 60 MB
/var/spool/imap is about 30 GB

thanks to all

[LMStone]

In Zimbra domains can be configured to auth against external sources like LDAP.

Having run eGroupware previously, I would not attempt to install Zimbra on this server, but would recommend a separate server for Zimbra.

It may be a more challenging migration, but you could get to a place where you use Zimbra's LDAP for centralized auth leaving you with just your Hylafax server and the current main server as a file server only.

At your size, a single Zimbra server would likely be more than fine; no gateway/SmartHost email server needed.

Hope that helps,
Mark

[clmates]

Hi.

Thanks for the info.

I'm going then to install on a new machine on a new SLES installation and play a bit around with a test user.

Thanks again

[LMStone]

Originally Posted by clmates

Hi.

Thanks for the info.

I'm going then to install on a new machine on a new SLES installation and play a bit around with a test user.

Thanks again

Please keep us posted!

All the best,
Mark

[clmates]

Hi Again.

A bit update on this, I almost get zimbra working but need a bit help on the SLES side

Now I have set up the server and can access to admin and user interface

(well, really I had some problem with the milter, so I deactivated it to be able to test the server, later I will come to this to try to solve)

I have set my external mta server as relayhost and set in this server a transport rue specifically for my test user, because I am using my real domain to be able to test later a real account migration)

I have been also to create a test user and to send emails from the admin user to the test user.

Also I have been able to send emails to an external gmail account and to receive emails from this account

Also I have been able to send emails from this account to real account of my current mailserver (the same email domain) by setting a custom transport map as specified in wiki

So for the zimbra side all seems working (except the milter)


But now I have a problem in my current mail server, this is a YaST2 Advanced Mail server (ldap + cyrus + postfix + amavis + clamav)

I have not been able to set a special transport for the mail of the specific test user to the zimbra server.

let explain this better

we have this server defined with our real domain (ie: mydomain.es)

so we have our users defines as user1@mydomain.es

I had set up also zimbra as the server for mydomain.es

in our SLES mail server we have set a test user in YaST clmates

so the mail is clmates@mydomain.es

In zimbra I have also set up this user clmates, so the mail is clmates@mydomain.es

I have another SLES user clorenzo (clorenzo@mydomain.es)

I have set in zimbra a special transport like
clorenzo@mydomain.es :[192.168.2.207]

and this works I write a mail to clorenzo@mydomain.es and is going to my SLES mail server

now I want to do the same in the SLES side but for user clmates

so I created in YaST ldap transport rule like
clmates@mydomain.es 192.168.2.204 (zimbra server)
and also
clmates@slesserver.mydomain.es 192.168.2.204 (zimbra server)

but seems that cyruss keeps rounting this mail like internal one directly to the cyrus imap account

do you know if is possible to make this kind of redirection?

I looked for this to be able to migrate and test over a reduced set of users and keep both servers in parallel for a while so be able to get back if needed.

I also opened to other alternatives to do the same.

any help appreciated.

Thanks

[phoenix]

Assuming that your current mail server is on a different server with a different IP address you should read the Split Domain article.

[clmates]

Hi phoenix.

Many thanks for the link, I already read that, but I dont have problems on the zimbra side, now my problem is on the SLES one (the primary mail server), and I don't know how to solve this.

the problem is that in sles I can get the transport working because the system is checking the domain and is delivering first to cyrus instead of giving it to the postfix for delivery, in YaST2 advanced mailserver, the option local delivery is set to cyrus. I don't want to change that because this is our real mail server and dont want to make it to stop working for the rest of the users, so I need to find a way of adapting the configuration to make this account to go to the other server.

thanks anyway

[LMStone]

Originally Posted by clmates

Hi phoenix.

Many thanks for the link, I already read that, but I dont have problems on the zimbra side, now my problem is on the SLES one (the primary mail server), and I don't know how to solve this.

the problem is that in sles I can get the transport working because the system is checking the domain and is delivering first to cyrus instead of giving it to the postfix for delivery, in YaST2 advanced mailserver, the option local delivery is set to cyrus. I don't want to change that because this is our real mail server and dont want to make it to stop working for the rest of the users, so I need to find a way of adapting the configuration to make this account to go to the other server.

thanks anyway

You are right to try to do everything in YaST if you can, but you may need in this case to hand-edit the Postfix transport table by hand. I am not sure that that YaST module can handle transports on an individual email address basis; only on a domain-wide basis.

This document describes the underlying process: Postfix manual - transport(5)

So for the user in SLES whose mail you want delivered to Zimbra, you would need to add an entry to the SLES transport table /etc/postfix/transport as follows:

zimbra_user@domain.com smtp:zimbra_server_fqdn

Don't forget to run postmap hash: against your transport file and to reload Postfix.

Since this hand change may upset the YaST mail module, I'd keep a backup copy of your existing transport table so that when the migration to Zimbra is complete you can revert and use the YaST Advanced Mail module to configure your SLES box as a SmartHost for Zimbra (if that's what you want).

Hope that helps,
Mark

[clmates]

Hi and thanks to all

I think that now the send and receive of emails is solved.

Sorry for the confusion but there where 2 problems mixed.

one from my current SLES mail server, the problem was it was rewriting (and is rewriting) the destination email address from clmates@mydomain.es to clmates@slesserver.mydomain.es

so when zimbra received that message it was retunrnig as unknow destination.

To solve this I created a domain alias in zimbra like

slesserver.mydomain.es -> mydomain.es



also from the other point I trashed my zimbra email mta by a typo following the wiki (Transport Table for external servers - Zimbra :: Wiki) so I changed the smtp log to debug, then saw the error and fixed it.

Now I'm able to send and receive email to external users, and also to internal users, and in my main sles server I am able to send mail to the zimbra users (in the same domain)

now the only error I have is that I'm unable to start milter, but I will start another post for this in the installation forum.

Thanks again

[phoenix]

Originally Posted by clmates

now the only error I have is that I'm unable to start milter, but I will start another post for this in the installation forum.

I'd suggest you don't start another thread in the Installation forum because a) it's not a problem installing Zimbra and b) there are problems with the milter service - leave it disabled.