-

How to restrict outgoing email as well as external web access for certain users?

Posted by aionman on Jul 9, 2015 in Zimbra

Restricting users to send mails to certain domains

1. Enter following in the file “/opt/zimbra/conf/postfix_recipient_restrictions.cf”. Make sure it is entered at the top of the file.

ZCS 8.x: Enter in file /opt/zimbra/conf/zmconfigd/smtpd_recipient_restrictions.cf

vi /opt/zimbra/conf/postfix_recipient_restrictions.cf
check_sender_access hash:/opt/zimbra/postfix/conf/restricted_senders 

Note: This line should be added after the reject_non_fqdn_recipient line
Note: ZCS 8.5 and later use lmdb databases, not hash databases

2. Enter following in “/opt/zimbra/conf/zmmta.cf”

ZCS 8.x: Enter in file /opt/zimbra/conf/zmconfigd.cf

vi /opt/zimbra/conf/zmmta.cf
Find the section labeled SECTION mta and enter the following two lines directly below
POSTCONF    smtpd_restriction_classes      local_only
POSTCONF    local_only        FILE  postfix_check_recipient_access.cf

3. Create a file “/opt/zimbra/conf/postfix_check_recipient_access.cf”

vi /opt/zimbra/conf/postfix_check_recipient_access.cf
check_recipient_access hash:/opt/zimbra/postfix/conf/local_domains, reject

4. Create a file “/opt/zimbra/postfix/conf/restricted_senders” and list all the users, whom you want to restrict. Follow this syntax:

vi /opt/zimbra/postfix/conf/restricted_senders
user@yourdomain.com            local_only

5. Create a file “/opt/zimbra/postfix/conf/local_domains” and list all the domains where “restricted users” allowed to sent mails. Please follow this syntax:

vi /opt/zimbra/postfix/conf/local_domains
yourdomain.com              OK 
otheralloweddomain.com      OK

6. Run following commands:

postmap /opt/zimbra/postfix/conf/restricted_senders
postmap /opt/zimbra/postfix/conf/local_domains 
zmmtactl stop 
zmmtactl start

After these settings, all the users listed in “/opt/zimbra/postfix/conf/restricted_senders” are restricted to send mails only to domain which are defined in “/opt/zimbra/postfix/conf/local_domains”, other are fully allowed to send mails anywhere. These settings will not survive Zimbra upgrades, please make sure that you backup of all these settings while performing upgrades.

 

 
-

Zimbra localhost shows up in server status view

Posted by aionman on Dec 19, 2013 in Zimbra
[root@zimbra ~]# cd /opt/zimbra/logger/
[root@zimbra logger]# tar -cvzg db-backup.tgz db
[root@zimbra logger]# su - zimbra
[zimbra@zimbra ~]$ /opt/zimbra/libexec/zmloggerinit
Stopping logswatch...done.
Starting logswatch...done.
[root@zimbra ~]# sudo -u zimbra /opt/zimbra/bin/zmsoap -z GetServiceStatusRequest
<GetServiceStatusResponse xmlns="urn:zimbraAdmin">
  <timezone id="Europe/Riga" displayName="Eastern European Time"/>
  <status t="1352295720" service="spell" server="zimbra.mydomain.com">1</status>
  <status t="1352295720" service="mailbox" server="zimbra.mydomain.com">1</status>
  <status t="1352295720" service="convertd" server="zimbra.mydomain.com">1</status>
  <status t="1352295720" service="logger" server="zimbra.mydomain.com">1</status>
  <status t="1352295720" service="mta" server="zimbra.mydomain.com">1</status>
  <status t="1352295720" service="stats" server="zimbra.mydomain.com">1</status>
  <status t="1352295720" service="antispam" server="zimbra.mydomain.com">1</status>
  <status t="1352295720" service="zmconfigd" server="zimbra.mydomain.com">1</status>
  <status t="1352295720" service="ldap" server="zimbra.mydomain.com">1</status>
  <status t="1352295720" service="antivirus" server="zimbra.mydomain.com">1</status>
  <status t="1352295720" service="snmp" server="zimbra.mydomain.com">1</status>
</GetServiceStatusResponse>

 
-

Steps to change the Zimbra server’s hostname using zmsetservername

Posted by aionman on Jul 9, 2013 in Zimbra

Steps to change the Zimbra server’s hostname using zmsetservername

Use the following steps to change the Zimbra server’s hostname using the zmsetservername command line utility.

1. Stop the flow of mail/Zimbra and back up your entire /opt/zimbra and any linked folders. For more information on creating a backup, seeCategory:Backup and Restore.

2. The new hostname must exist in the DNS before zmsetservername is run. If it does not already exist in the DNS, add the new hostname to the DNS now.

Note: If the box is duplicate of production server, prevent this command from affecting the production server by halting communications between test and live servers.

3. Run the following commands:

su - zimbra
/opt/zimbra/libexec/zmsetservername -n <servername>

4. Reconfigure the system for its new hostname as necessary for the operating system, (very important to do this AFTER step 3).

5. Reboot.

Note: If you have a multi-server setup, be sure to change any corresponding references to the old hostname & restart services on all hosts.

6. Use zmlocalconfig and zmprov to manually double-check the global config, server configs, user settings, etc.

zmprov gacf | grep oldhostname
zmprov gs `zmhostname` | grep oldhostname
zmlocalconfig | grep oldhostname

7. Remove the old sever entry from the DNS.

Errors are usually certificates. If you are experiencing errors, you will probably need to obtain new certs to match the new hostname. For more information on working with certificates, see Administration Console and CLI Certificate Tools. For more information on troubleshooting certificate issues, see Category:Troubleshooting Certificates.

 

After running ZmSetServerName if you see in Server Status both old and new names.

I find the correct command to modify the mapping where I missed it:

“zmloggerhostmap -d” to delete a mapping and “-a” to add one. the problem was I use “zmloggerhostmap –help” for the manual but it only accept “-h” and my system was configured in Spanish that I didn’t quite understand to find the expected parameter to modify it. So I was simply thinking zmloggerhostmap is a loopup tool.

so with the correct command:

Code:
zmloggerhostmap -d myhost.mydomain.com myhost
zmloggerhostmap -a myhost.mydomain.com myhost.mydomain.com

You may also encounter this problem:
Server error encountered Message: system failure: exception during auth {RemoteManager: mail.domain.com->zimbra@mail.domain.com:22} Error code: service.FAILURE Method: [unknown] Details:soap:Receiver
this is the solution:
http://wiki.zimbra.com/index.php?title=Mail_Queue_Monitoring

 
-

Adding per user backup and restore

Posted by aionman on Jun 17, 2013 in Zimbra

http://www.zimbra.com/forums/administrators/15275-solved-yet-another-backup-script-community-version-35.html#post186403

Since I got a rousing response of 1 inquiry to my post about adding per-user backup to this script, I thought I’d just go ahead and post it.

Here are the changes. In the main backup script, add the lines with the + in them (leaving out the +, of course).

Code:
--- OLD/zmbac.0.8.sh.orig       2010-02-14 20:19:22.000000000 -0700
+++ zmbac.sh    2010-05-16 14:43:40.000000000 -0600
@@ -61,25 +61,26 @@
 #--- Directories ---#
 # Please add the trailing "/" to directories!
 ZM_HOME=/opt/zimbra/   # where zimbra lives
 SYNC_DIR=/backup/sync/ # intermediate dir for hot/cold syncs. must have at least as much free space as ZM_HOME consumes
 ARCHIVEDIR=/backup/current/    # where to store final backups
 TO_MEDIA_DIR=/backup/previous/
+ SCRIPT_DIR=/usr/local/sbin/  # where zmbac.sh and zmDBbac.sh reside

@@ -129,6 +130,9 @@
 #Hack to start Stats, even run zmlogprocess if needed
 STATHACK="yes"                 # valid answers are "yes" or "no"

+#--- Dump Databases? ---#
+# Adjust zmDBbac.sh script to backup up per-user or raw dbs, or both.
+DUMP_DBS="yes"                 # valid answers are "yes" or "no"

 ## ~~~~~!!!! SCRIPT RUNTIME !!!!!~~~~~ ##
 # Best you don't change anything from here on, 

@@ -695,6 +764,28 @@
            mail_log
                exit 1
     fi
+       # Dump DB's, if enabled
+       if [ $DUMP_DBS = "yes" ] ; then 
+           echo
+           # Create db_dumps directory
+           if [ ! -d $SYNC_DIR"db_dumps" ] ; then
+              echo "Creating db_dumps directory..."
+              chmod 755 $SYNC_DIR
+              mkdir $SYNC_DIR"db_dumps"
+              chown $ZM_USER $SYNC_DIR"db_dumps"
+           fi
+           # Run script to dump dbs
+           echo "Backing up Zimbra DBs..."
+           su - $ZM_USER -c $SCRIPT_DIR"zmDBbac.sh $SYNC_DIR"
+           if [ "$?" -ne "0" ] ; then
+             echo "There was an error running DB backup script! Aborting DB backup. Continuing main backup."
+           fi
+        # Check that /opt/zimbra/db_dumps exists, or create empty /opt/zimbra/db_dumps directory tree if necessary
+           if [ ! -d $ZM_HOME"db_dumps" ] && [ -d $SYNC_DIR"db_dumps" ] ; then
+             $RSYNC_BIN -a -f"+ */" -f"- *" $SYNC_DIR"db_dumps" $ZM_HOME
+           fi
+       fi
+       echo
     # Starting the Zimbra server again
    # Reinstate zimbra user's crontab
        echo "Reinstating Zimbra's crontab..."

These changes set the script directory, enable DB backups, then call the DB backup script.

You can download the db backup and restore scripts at: zmDBbac.zip

Backup

1. Put the zmDBbac.sh and restore_user.sh scripts in the same directory as zmbac.sh
2. Make them executable:

Code:
chmod 755 zmDBbac.sh
chmod 755 restore_user.sh

3. Make any changes to settings in the zmDBbac.sh script. These are

  • Create processed DB dump, with added SQL commands to ease restore. (default)
  • Create RAW db dump, with no processing. (optional. Since you can convert a processed db dump back to raw using the ‘makeraw’ option in this script, raw dumps should not be needed. Raw db’s are handy for individual folder restore.)
  • Specify a domain DN to back up. (optional)
  • Specify a COS to back up (optional)

4. The zmDBbac.sh script will create several folders. It creates a db_dumps directory in your SYNC_DIR directory, with ldap, raw, and mailboxes subdirectories. It creates these same folders in /opt/zimbra. The directories in /opt/zimbra remain empty always, and are merely used by rsync to empty the directories in SYNC_DIR/db_dumps every night.

In your nightly email from the script, it will show the db dump results:

Code:
============================
Wed May 5 03:00:02 MDT 2010
Performing DIFF backup
============================
<etc>
Doing a fast cold sync...

Backing up Zimbra DBs...
Making sure all Zimbra services are stopped
Starting just LDAP and MySQL for db dump...
Starting LDAP...
Started slapd: pid 27636
Starting MySQL...
Starting mysqld...done.
Trying to connect to MySQL...

Dumping and processing per-user dbs and exporting per-user LDAP entries...
E-Mail                            User ID       Database       LDAP        zimbraId
------                            -------       ---------      ------      --------
(zimbra)                          --            zimbra         --          60fa3489-9854-22d9-8f21-000a67a98ef2
Alise.Amadeo@somewhere.com        11            mboxgroup11    11.ldif     71c8a11d-02ec-c29c-9dd9-b49c80600ca5
Bernetta.Verdin@somewhere.com     2             mboxgroup2     2.ldif      2705a240-07fe-cccc-acfd-cc26c489c293
Caitlin.Kellman@somewhere.com     45            mboxgroup45    45.ldif     67a60dca-07ad-c66a-9d6f-9f7832d29440
Cassey.Antczak@somewhere.com      42            mboxgroup42    42.ldif     fc4fc12d-b16e-c91d-ae3d-b6b86a72826c
Cecile.Lorenz@somewhere.com       12            mboxgroup12    12.ldif     6d0ec99f-c70e-caa8-afaa-e48ca98cae59
Chau.Gable@somewhere.com          43            mboxgroup43    43.ldif     8dfe7a6f-0b9f-cbff-9b8c-e1f5b860c3b8
Dannie.Weatherman@somewhere.com   103           mboxgroup3     103.ldif    f6ddd11c-ce1a-c6b9-a3ad-164762d5c8d3
<etc>
Total users = 88
Stopping LDAP and MySQL...
Stopping mysqld... done.
Killing slapd with pid 27636 done.

Reinstating Zimbra's crontab...
Starting Zimbra...
Host mail.somewhere.com
    Starting ldap...Done.
    Starting logger...Done.
    Starting mailbox...Done.
    Starting antispam...Done.
    Starting antivirus...Done.
    Starting snmp...Done.
    Starting spell...Done.
    Starting mta...Done.
    Starting stats...Done.
Service down time was - Hr:0 Min:7 Sec:39
<etc>
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
diff Zimbra Backup ended at: 03:33
Backup took Hr:0 Min:33 Sec:43 to complete
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

When users are added, only their LDAP entry is created. Their database entry is not created until the account is accessed. There are two ways of dealing with this:

  • If AUTCREATE_DB is set to “yes” (default), the script starts the zmmailboxd service and just queries the user’s mailbox size. This prompts Zimbra to create the user’s database.
  • If AUTCREATE_DB is set to “no”, their entry in the nightly email will look like:
    Code:
    Some.User@somewhere.com             --          No_DB_Exists!*   --            46fc9b59-74aa-4d31-bfc3-7f66145bf285

The user’s LDAP entry will also not get backed up until their database gets created.
A manual way of creating the user’s database entry is just to Edit their account from the Admin interface. You don’t have to make any changes, just open the Edit window.

Restore

You can find the user’s id from the nightly email, or in /mysyncdir/db_dumps/namelist.txt
Restoring user “12” would go like:

Autmatic method, using restore_user.sh script:
1. Be sure you have a good backup.
2. Delete the user, if necessary. You basically always want to delete the user first, if they still exist, for a full user restore. This is to avoid duplicate database entries when you restore their DB data.
3. Restore the user’s message store to /opt/zimbra/store/#/12, with “#” being the volume directory (initial volume default is “0”). There may be several volume directories, with a portion of the user’s store in each. You need to restore the user’s store directory to each volume directory.
4. Restore the user’s index to /opt/zimbra/index/#/12, with “#” being the volume directory, in the same manner as the message store.
5. Place the user’s .sql and .ldif backup files in the same directory. If the user’s database does not exist, also place skeleton.sql into the same directory. The skeleton file is used to create basic table structure before importing the user’s SQL data.
6. Run restore_user.sh script, as Zimbra user, giving it the location of the of the backup files and the user’s mailbox id, e.g.

Code:
/usr/local/sbin/restore_user.sh /tmp/restore 12

The script will ask you whether you want to create the database (if it doesn’t already exist), whether to change the email address or mail server host name, and whether to import SQL and LDAP data. It also prompts a Zimbra shutdown: importing data is most safely done when Zimbra services (except mysql and openldap) are not running.

Manual method:
You can manually import data instead of using the restore_user.sh script.
1. Be sure you have a good backup
2. Restore user’s store and index, per above.
3. Best practice is to shut down Zimbra, and start only its MySQL and LDAP services.
4. As Zimbra user, restore user’s db and zimbra db records:

Code:
mysql < /mysyncdir/db_dumps/mailboxes/12.sql

Note: the user’s database must already exist, or you’ll have to create it manually first, including all table structure. This can be done by adding SQL statements above and below the USE mboxgroup* line:

Code:
CREATE DATABASE IF NOT EXISTS mboxgroup12;
USE mboxgroup12
SOURCE /tmp/restore/skeleton.sql

Make the changes before importing the .sql file.
5. Restore the user’s LDAP entry, if necessary. As Zimbra user (changing paths and host as necessary):

Code:
source ~/bin/zmshutil ; zmsetvars
/opt/zimbra/openldap/bin/ldapadd -D "uid=zimbra,cn=admins,cn=zimbra" -f /mysyncdir/db_dumps/mailboxes/12.ldif -w "$zimbra_ldap_password" -x -H ldap://myzimbraserver.somewhere.com

Note: If you want to restore using a different email address, or to a differently-named mailserver, you will need to manually edit the ldif and sql files first.

———————
As previously stated:

  • This script must do the db dumps cold, which adds a few, to several, minutes of downtime during backup.
  • This script also does the LDAP user backup cold. Cold LDAP backups add a minute or two to server downtime for small servers. For larger servers, the LDAP backup could be moved to the main backup script, and be done hot.
  • I have done several successful test restores to a secondary server, but have not thoroughly tested every aspect of it. It would be wise to try test restores on a non-production server.

———————————————————————-
If you only want to restore a single folder, you can use the DB backup like this:
Restore a single folder

 
-

Mysql Crash Recovery

Posted by aionman on Jun 1, 2013 in Zimbra

Mysql Crash Recovery

In the event of database corruption it may be necessary to manually perform database recovery. See Bug 15797 for an example of an issue with mysql that will require database recovery. In that example, a warning message like the following appeared in the mysql error log:

InnoDB: Serious error! InnoDB is trying to free page 716
InnoDB: though it is already marked as free in the tablespace!
InnoDB: The tablespace free space info is corrupt.
InnoDB: You may need to dump your InnoDB tables and recreate the whole
InnoDB: database!

Before beginning a full database recovery, check to see if the corruption may be limited to a single mboxgroup or a single user within an mboxgroup. This type of corruption frequently lets the server run normally for extended periods of time, with crashes occurring only when an affected user attempts to access certain mailbox items. If this is the case, it may be possible to dump, drop and recover only the affected entries without disrupting the database as a whole. Please see the instructions in the Mysql Crash Recovery (alternate method) article.

Overview of Recovery Process

  1. Configure mysql to start in recovery mode
  2. Generate SQL dumps of all relevant databases
  3. Remove all existing (and possibly corrupt) databases
  4. Re-create all databases
  5. Repopulate the databases with the data from the SQL dumps
  6. Test databases and start all ZCS services

Details of Recovery Process

1. Configure mysql to start in recovery mode

  1. Edit the file /opt/zimbra/conf/my.cnf and add a line like innodb_force_recovery = 1 under the [mysqld] section (Note that it may be necessary to increase the recovery level depending on the extent of the database corruption, as shown at the end of the database dump step)
  2. Save the file and re-start mysqld
mysql.server start

2. Generate SQL dumps of all databases

  1. Load some mysql configuration into shell variables (i.e. $mysql_socket and $mysql_root_password; note that you will use these again in step 3)
  2. Make a list of the existing databases
  3. Create a directory to hold the SQL dumps
  4. Generate the SQL dumps from the database list
source ~/bin/zmshutil ; zmsetvars
mysql --batch --skip-column-names -e "show databases" | grep -e mbox -e zimbra > /tmp/mysql.db.list
mkdir /tmp/mysql.sql
for db in `cat /tmp/mysql.db.list`; do
 ~/mysql/bin/mysqldump $db -S $mysql_socket -u root --password=$mysql_root_password > /tmp/mysql.sql/$db.sql
     echo "Dumped $db"
 done

Note: If you encounter any mysql errors while dumping the databases, start over by re-editing /opt/zimbra/conf/my.cnf, incrementing the value for innodb_force_recovery by one, and restarting mysqld. The maximum recovery level is 6. Please see MySQL’s Forcing InnoDB Recovery guide for more information.

Note: An error of “bash: /tmp/mysql.sql/$db.sql: ambiguous redirect” probably indicates your using an apostrophe or single quote ‘ rather than a tick ` — which is one the same key as the tilde ~ .

Note: Do not reboot the machine, as some Operating Systems will remove all contents in the /tmp directory during the reboot sequence, i.e. your /tmp/mysql.sql will be removed.

3. Remove all existing (and possibly corrupt) databases

Note that we drop the zimbra database last because the mboxgroup* databases depend on it

for db in `cat /tmp/mysql.db.list |grep mbox`
do
    mysql -u root --password=$mysql_root_password -e "drop database $db"
    echo -e "Dropped $db"
    sleep 1
done
mysql -u root --password=$mysql_root_password -e "drop database zimbra"

Remove existing InnoDB tablespace and log files

rm -rf /opt/zimbra/db/data/ib*

Note: First, use with caution – this shouldn’t need to be used often. Issue came about because of some rsync issues. Can’t dump db’s because of ‘connection’ issues at this point? One could move the /opt/zimbra/db/data directory – mv /opt/zimbra/db/data /opt/zimbra/db/data-old and then make the db – mkdir /opt/zimbra/db/data w/ ownership of zimbra:zimbra . Remove the innodb_force_recovery line from /opt/zimbra/conf/my.cnf . Then recreate a default mysql db by running /opt/zimbra/libexec/zmmyinit –sql_root_pw $mysql_root_password and then attempt this steps over again to confirm you can drop them. Also note that you may have to reset the zimbra password manually in mysql, then set it again in Zimbra with the instructions from this page: http://wiki.zimbra.com/wiki/Resetting_LDAP_%26_MySQL_Passwords

4. Re-create all databases

  1. Run mysql in non-recovery mode
    1. Remove the innodb_force_recovery line from /opt/zimbra/conf/my.cnf
    2. Save the file and restart mysqld
  2. Re-create the databases from the database list
mysql.server restart
for db in `cat /tmp/mysql.db.list`
do
    mysql -e "create database $db character set utf8"
    echo "Created $db"
done

5. Repopulate the databases with the data from the SQL dumps

Import the data from the SQL dumps. Note that we import the zimbra database first because the mboxgroup databases depend on it

mysql zimbra < /tmp/mysql.sql/zimbra.sql
for sql in /tmp/mysql.sql/mbox*
do
    mysql `basename $sql .sql` < $sql
    echo -e "Updated `basename $sql .sql` \n"
done

6. Test databases and start all ZCS services

Note that this is an example query. If you know of any particular databases that were corrupt, you may want to construct other queries to verify normal access to the data.

mysql zimbra -e "select * from mailbox order by id desc limit 1"

Once you are satisfied that the databases are restored intact, start the rest of the zimbra services.

zmcontrol start

Check /opt/zimbra/log/mysql_error.log and /opt/zimbra/log/mailbox.log for database errors.

 
-

Fixing a corrupted Zimbra database

Posted by aionman on May 31, 2013 in Zimbra

I recently received an administrative email from my Zimbra mail server informing me that I had some corrupted tables in the MySQL database.

I confirmed this by logging into my Zimbra server and running the following command:

/opt/zimbra/mysql/bin/mysqlcheck –defaults-file=/opt/zimbra/conf/my.cnf -S /opt/zimbra/db/mysql.sock -A -C -s -p

This showed me that virtually every table in each database was in fact corrupted. The output from the command said that I could do a “REPAIR” or a dump/reload to fix them. Unfortunately, the REPAIR command doesn’t support the InnoDB engine so a dump and reload was the only option.

The commands to do this are fairly straight forward. Although, if you run a large site, you may want to take it offline first. Also, the above command mentions individual tables that are corrupt. I find it easier to just fix all the tables at once.

First, you need to dump a database:

mysqldump –defaults-file=/opt/zimbra/conf/my.cnf -S /opt/zimbra/db/mysql.sock -p mboxgroup1 > mboxgroup1.sql

Then reload it:

mysql –defaults-file=/opt/zimbra/conf/my.cnf –port=7306 -S /opt/zimbra/db/mysql.sock -D mboxgroup1 -p < mboxgroup1.sql

Repeat these steps for each database mentioned in the mysqlcheck output.

One thing to note is each command will prompt you for your MySQL root password. If you have forgotten yours, you can find it two different ways. The first is, the email sent to you by the system contains it. The second is by following these directions: Recovering Zimbra Passwords

 
0

Resetting LDAP and MySQL Passwords

Posted by admin on Jan 19, 2011 in Zimbra

test

 
-

Moving ZCS to Another Server

Posted by aionman on Dec 2, 2010 in Zimbra

http://blog.zimbra.com/blog/archives/2007/10/moving-zcs-to-another-server.html

Moving ZCS to Another Server

Posted in PowerTips – Admins by Mike Morse on October 9th, 2007

In this Zimbra Administrator’s PowerTip, we’ll discuss how to move your instance of Zimbra to another machine. It applies to all version of Zimbra.



Administrator’s PowerTip
#4: October 09, 2007
Zimbra Forums Zimbra wiki Zimbra
Blog

Introduction


Either you, or someone you know has been there. Almost out of Disk space, RAM is topped out, and the CPU is constantly running above 80%. It’s time to upgrade the hardware. But how easy and safe is it to move the Zimbra server instance? Well, it’s easier than you might think.

In this Zimbra Administrator’s PowerTip, we’ll discuss how to migrate your Zimbra server to another Machine or OS. The one big caveat is that both instances of Zimbra MUST be running the same version. So if your old server is running 4.5.5, then you’ll need to install 4.5.5 on your new server. This wouldn’t be the time to upgrade your ZCS version.

Part 1 : Backing Up


Zimbra Network Edition contains a backup feature, and although it’s useful, we won’t be using it in this tip.

We have an external Hard Disc mounted to /mnt/migration. When rsync’ed, this is now your live copy (although it’s not live), and you should always have a backup of your live data. So, you might want to rsync again to another location to be safe.

Once you’ve rsync’ed all your data, umount the external drive, and put it somewhere safe.

Part 2 : Meet Your New Server


The only thing that really matters on your new server, is whether or not meets Zimbra’s server Hardware and the Operating System requirements.

It’s also very important that you have resolved any dependency issues. The ZCS installer for your newer OS should check for these.

Setup the newer server with the old server’s networking attributes. Make sure your older server is offline.

If changing the hostname, please see this wiki article: Set zmhostname

Part 3 : Create a “dummy” Install Then Remove It


The goal of this step is to get the rpm/dpkg databases correct. When you download ZCS, make sure it’s for your newer OS, and the SAME version of ZCS that’s rsync’ed.

Run the installer with the -s option. This tells the installer to only install the software, and not to configure the installation.

Once the installer has completed, delete it by rm -rf /opt/zimbra. This wipes any dummy data you have in that location.

Part 4 : Mount Your Backup HD, rsync, and Install


Connect and mount your external hard drive. Then, rsync the backed up data to its new location (rsync -avH /mnt/migration/zimbra /opt).

Connect and mount your external hard drive. Then, rsync the backed up data to its new location (rsync -avH /mnt/migration/zimbra /opt).
Unmount your backed up copy, and keep it in a safe place.
Now that our data is all in place, we need to fix some permissions. Go into the /opt/zimbra/libexec directory and run zmfixperms. This helps insure that all the files are owned correctly.
Once that has completed, re run the installer that you downloaded. It will detect ZCS already installed, and ask if you want to upgrade. Select Yes.

Moving ZCS to Another Server

Posted in PowerTips – Admins by Mike Morse on October 9th, 2007

In this Zimbra Administrator’s PowerTip, we’ll discuss how to move your instance of Zimbra to another machine. It applies to all version of Zimbra.



Administrator’s PowerTip
#4: October 09, 2007
Zimbra Forums Zimbra wiki Zimbra
Blog

Introduction


Either you, or someone you know has been there. Almost out of Disk space, RAM is topped out, and the CPU is constantly running above 80%. It’s time to upgrade the hardware. But how easy and safe is it to move the Zimbra server instance? Well, it’s easier than you might think.

In this Zimbra Administrator’s PowerTip, we’ll discuss how to migrate your Zimbra server to another Machine or OS. The one big caveat is that both instances of Zimbra MUST be running the same version. So if your old server is running 4.5.5, then you’ll need to install 4.5.5 on your new server. This wouldn’t be the time to upgrade your ZCS version.

Part 1 : Backing Up


Zimbra Network Edition contains a backup feature, and although it’s useful, we won’t be using it in this tip.

We have an external Hard Disc mounted to /mnt/migration. When rsync’ed, this is now your live copy (although it’s not live), and you should always have a backup of your live data. So, you might want to rsync again to another location to be safe.

Once you’ve rsync’ed all your data, umount the external drive, and put it somewhere safe.

Part 2 : Meet Your New Server


The only thing that really matters on your new server, is whether or not meets Zimbra’s server Hardware and the Operating System requirements.

It’s also very important that you have resolved any dependency issues. The ZCS installer for your newer OS should check for these.

Setup the newer server with the old server’s networking attributes. Make sure your older server is offline.

If changing the hostname, please see this wiki article: Set zmhostname

Part 3 : Create a “dummy” Install Then Remove It


The goal of this step is to get the rpm/dpkg databases correct. When you download ZCS, make sure it’s for your newer OS, and the SAME version of ZCS that’s rsync’ed.

Run the installer with the -s option. This tells the installer to only install the software, and not to configure the installation.

Once the installer has completed, delete it by rm -rf /opt/zimbra. This wipes any dummy data you have in that location.

Part 4 : Mount Your Backup HD, rsync, and Install


Connect and mount your external hard drive. Then, rsync the backed up data to its new location (rsync -avH /mnt/migration/zimbra /opt).

Connect and mount your external hard drive. Then, rsync the backed up data to its new location (rsync -avH /mnt/migration/zimbra /opt).
Unmount your backed up copy, and keep it in a safe place.
Now that our data is all in place, we need to fix some permissions. Go into the /opt/zimbra/libexec directory and run zmfixperms. This helps insure that all the files are owned correctly.
Once that has completed, re run the installer that you downloaded. It will detect ZCS already installed, and ask if you want to upgrade. Select Yes.


 
0

Moving ZCS to Another Server

Posted by admin on Jan 8, 2010 in Zimbra

Moving ZCS to Another Server

Posted in PowerTips – Admins by John Holder on the October 9th, 2007

In this Zimbra Administrator’s PowerTip, we’ll discuss how to move your instance of Zimbra to another machine. It applies to all version of Zimbra.


Administrator’s PowerTip
#4: October 09, 2007
Zimbra Forums Zimbra wiki Zimbra
Blog

Introduction


Either you, or someone you know has been there. Almost out of Disk space, RAM is topped out, and the CPU is constantly running above 80%. It’s time to upgrade the hardware. But how easy and safe is it to move the Zimbra server instance? Well, it’s easier than you might think.

In this Zimbra Administrator’s PowerTip, we’ll discuss how to migrate your Zimbra server to another Machine or OS. The one big caveat is that both instances of Zimbra MUST be running the same version. So if your old server is running 4.5.5, then you’ll need to install 4.5.5 on your new server. This wouldn’t be the time to upgrade your ZCS version.

Part 1 : Backing Up


Zimbra Network Edition contains a backup feature, and although it’s useful, we won’t be using it in this tip.

We have an external Hard Disc mounted to /mnt/migration. When rsync’ed, this is now your live copy (although it’s not live), and you should always have a backup of your live data. So, you might want to rsync again to another location to be safe.

Once you’ve rsync’ed all your data, umount the external drive, and put it somewhere safe.

Part 2 : Meet Your New Server


The only thing that really matters on your new server, is whether or not meets Zimbra’s server Hardware and the Operating System requirements.

It’s also very important that you have resolved any dependency issues. The ZCS installer for your newer OS should check for these.

Setup the newer server with the old server’s networking attributes. Make sure your older server is offline.

If changing the hostname, please see this wiki article: Set zmhostname

Part 3 : Create a “dummy” Install Then Remove It


The goal of this step is to get the rpm/dpkg databases correct. When you download ZCS, make sure it’s for your newer OS, and the SAME version of ZCS that’s rsync’ed.

Run the installer with the -s option. This tells the installer to only install the software, and not to configure the installation.

Once the installer has completed, delete it by rm -rf /opt/zimbra. This wipes any dummy data you have in that location.

Part 4 : Mount Your Backup HD, rsync, and Install


Connect and mount your external hard drive. Then, rsync the backed up data to its new location (rsync -avH /mnt/migration/zimbra /opt).

Connect and mount your external hard drive. Then, rsync the backed up data to its new location (rsync -avH /mnt/migration/zimbra /opt).
Unmount your backed up copy, and keep it in a safe place.
Now that our data is all in place, we need to fix some permissions. Go into the /opt/zimbra/libexec directory and run zmfixperms. This helps insure that all the files are owned correctly.
Once that has completed, re run the installer that you downloaded. It will detect ZCS already installed, and ask if you want to upgrade. Select Yes.

Another useful guide

Network Edition: Moving from 32-bit to 64-bit Server

http://wiki.zimbra.com/index.php?title=Network_Edition:_Moving_from_32-bit_to_64-bit_Server

 
-

Checking and Repairing the tables in the Zimbra logger database

Posted by aionman on Oct 29, 2009 in Zimbra

Here is an example, using the “raw_logs” table:

$ logmysql zimbra_logger

mysql> check table raw_logs;
+————————+——-+———-+———-+
| Table                  | Op    | Msg_type | Msg_text |
+————————+——-+———-+———-+
| zimbra_logger.raw_logs | check | status   | OK       |

+————————+——-+———-+———-+
1 row in set (1.06 sec)
If a table does not show OK status, try repairing:

mysql> repair table raw_logs;
+————————+——–+———-+———-+
| Table                  | Op     | Msg_type | Msg_text |
+————————+——–+———-+———-+
| zimbra_logger.raw_logs | repair | status   | OK       |
+————————+——–+———-+———-+

1 row in set (2.32 sec)

How to shrink logger database
For first time is good to clean db manually if the database is very big. The commands bellow will delete all data in three tables (mta, amavis, raw_logs). If you need this data don’t execute them!

$zmlogswatchctl stop (don’t execute “zmloggerctl stop” this also stops logger mysqld)
$logmysql -D zimbra_logger
mysql> delete from amavis;
mysql> optimize table amavis;
mysql> delete from mta;
mysql> optimize table mta;
mysql> delete from raw_logs;
mysql> optimize table raw_logs;
mysql> quit
$zmlogswatchctl start

Copyright © 2017 IT Support Blog All rights reserved. Theme by Laptop Geek.