Procedimiento de configuracin general de Zimbra: http://www.zemris.fer.hr/~sgros/sysadm/zimbra.

shtml

Cmo migrar usuarios de un servidor Zimbra a otro: La idea aqu es que si usted ya tiene un Zimbra, para agregar otro como servidor de respaldo, se tiene que (a) migrar usuarios y (b) instalar apropiadamente el ruteo de correo (mail routing). Los pasos para migrar usuarios del servidor principal Zimbra son: 1. Descargar la base de datos LDAP en la fuente Zimbra Vaya al servidor primario e ingrese como usuario de Zimbra. Entonces en el directorio /opt/zimbra corra la siguiente orden:
$ ./openldap/sbin/slapcat -f /opt/zimbra/conf/slapd.conf -l /tmp/ldap.ldif La primer base de datos no permite slapcat; se usar la primera disponible (2)

Despus de esto, usted tundra un arcivo ldap.ldif en el directorio /tmp que contiene toda la informacin sobre sus usuarios. Sin embargo, tambin contiene datos sobre su servidor de correo que se deben cambiar, o transferir al servidor de correo secundario (de respaldo). Copie ese archivo al servidor de respaldo antes de hacer cambios. 2. Modificar los nombres de dominio Debe modificar los nombres del servidor (el host) y del servidor de nombres en LDIF, de otra manera, Zimbra no funcionar. Para una instalacin descrita en la introduccin, debe correr la siguiente orden:
sed 's/dmz.domain.local/dr.domain.local/g' ldap.ldif > ldap.ldif.dr

Note that it might become more complex that this because of the way Zimbra stores aliases into LDAP. For example, if you had zimbra.dmz.domain.local domain which you want to remove on the new server simple grep -v won't help. There is a separate tree in LDAP, dc=zimbra,dc=dmz,dc=domain,dc=local which won't be affected by the grep command and you'll have to either write script to handle this or manually edit the ldif file. 3. Stop the target Zimbra
$ zmcontrol stop

Just in case, check if LDAP is running. If so kill it using the kill command 4. Clean /opt/zimbra/openldap-data directory. DO NOT remove logs and db subdirectories and also keep DB_CONFIG file! 5. Import ldif database
$ cd /opt/zimbra $ ./openldap/sbin/slapadd -f /opt/zimbra/conf/slapd.conf -l /tmp/ldap.ldif.dr The first database does not allow slapadd; using the first available one (2)

The warning you see is the only one you should see and I think you can safely ignore it.

6. Get LDAP passwords from source Zimbra using:

$ zmlocalconfig -s ldap_amavis_password ldap_postfix_password ldap_replication_password ldap_root_password zimbra_ldap_password ldap_amavis_password = password ldap_postfix_password = password ldap_replication_password = password ldap_root_password = password zimbra_ldap_password = password

All the passwords are same, I don't know if it every time but for now I'll suppose it is. In case I'm wrong, modify the following steps appropriately. 7. You should start Zimbra on DR mail server now because otherwise it is not possible to change password. Note that there will be errors but we ignore them:
$ zmcontrol start Host mail.dr.paba.hr Starting ldap...Done. Unable to determine enabled services from ldap. Unable to determine enabled services. Cache is out of date or doesn't exist.

8. Now modify all the passwords:

$ zmldappasswd <password from source Zimbra> Updating local config and directory $ zmldappasswd -l <password from source Zimbra> Updating local config and directory $ zmldappasswd -p <password from source Zimbra> Updating local config and directory $ zmldappasswd -a <password from source Zimbra> Updating local config and directory $ zmldappasswd -r <password from source Zimbra> Updating local config and directory Updating slapd.conf

9. Now stop and start Zimbra again and it should work normally. Here is how netstat -ltn output should look:
$ netstat -ltn Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address tcp 0 0 192.168.1.218:389 tcp 0 0 127.0.0.1:10024 tcp 0 0 127.0.0.1:10025 tcp 0 0 127.0.0.1:7306 tcp 0 0 127.0.0.1:7307 tcp 0 0 0.0.0.0:3310 tcp 0 0 0.0.0.0:465 tcp 0 0 192.168.1.218:53 tcp 0 0 127.0.0.1:53 tcp 0 0 0.0.0.0:25 tcp 0 0 127.0.0.1:953 tcp 0 0 :::7072

Foreign Address 0.0.0.0:* 0.0.0.0:* 0.0.0.0:* 0.0.0.0:* 0.0.0.0:* 0.0.0.0:* 0.0.0.0:* 0.0.0.0:* 0.0.0.0:* 0.0.0.0:* 0.0.0.0:* :::*

State LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN

tcp tcp tcp tcp tcp tcp tcp tcp tcp tcp tcp tcp tcp tcp tcp tcp

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

:::7777 :::993 :::995 :::7780 :::5222 :::5223 :::7335 :::110 :::143 :::80 :::7025 :::5269 :::22 ::1:953 :::443 :::7071

:::* :::* :::* :::* :::* :::* :::* :::* :::* :::* :::* :::* :::* :::* :::* :::*

LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN

Few notes to be aware of: 1. You should be aware that by copying LDAP you also copied SSH keys and possibly other configuration data which you might prefer to be different. For SSH keys use zmsshkeygen. 2. During migration process you probably removed default domain, so you have to log in to administration console using admin@mail.dr.domain.local username and set default domain to either mail.dr.domain.local or dr.domain.local. This is done in Global settings option on the administration Web interface. After user migration, in order for the mail routing to work properly, you should add to each user an alias of the form username@dr.domain.local. You can use the following simple script to do that for each user:
#!/bin/bash USERS=`zmprov gaa mail.local` # First, add new domain zmprov cd dr.mail.local # Then, for each user add new alias for i in $USERS do echo "Processing user $i" zmprov aaa $i ${i/mail.local/dr.mail.local} done

In order to set up routing I suggest you first modify only several users to test the installation, and when it's proven to work correctly then modify all the users using a simple shell script.

Recreating Zimbra self-signed certificate

Periodically you'll have to renew your self-signed certificates. This is easy to do from the command

line and it boils down to the following sequence of commands:

su su - zimbra su zmcertmgr createcrt -new -days 1095 zmcertmgr deploycrt self zmcertmgr viewdeployedcrt

The su commands are run in that sequence in order to have Zimbra environment correctly set (su zimbra) and then to have administrative privileges but still with Zimbra environment variables (e.g. PATH) correctly defined. The first zmcertmgr creates self-signed certificate that will be valid for three years (3*365 days). The next one deploys new certificate. Finally, the last command shows currently deployed certificate so that you can check if everything went OK.