Troubleshooting Upgrade

From Zarafa wiki

Revision as of 14:59, 8 March 2011 by Fathomssen (Talk | contribs)
Jump to: navigation, search

Upgrade to Zarafa 7.0

This sections describes some actions you have to perform before upgrading from Zarafa 6.40 to Zarafa 7.0.

If you just try to install the new Zarafa 7.0 packages on your webserver, the zarafa-server process won't start because the database has to be updates first. The server log suggests to use the parameter --force-database-upgrade but this will most probably fail or mess up your messages containing UTF-8 characters.

These steps should suffice to correctly upgrade your database in prior to install Zarafa 7.0.

1. Do a full backup of your Zarafa database!

2. Change your MySQL connection to UTF-8. Thus, edit your my.cnf file (found in /etc/mysql/my.cnf or somewhere near) and change the following lines:

[mysqld]
character-set-server = utf8
default-character-set = utf8

and restart your MySQL server.

3. Shut down all Zarafa processes:

for script in /etc/init.d/zarafa-*; do $script stop; done

4. Change your database collation to utf8_general_ci using

ALTER DATABASE `zarafa` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

Do not forget to change the database name zarafa to your actual database name.

5. Change each table's collation to utf8_general_ci using

ALTER TABLE `table_name` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

Change table_name to each table's name: abchanges, acl etc.

6. Now comes the most important change in the properties table. The row val_string, currently of type longblob, will be changed to a UTF-8 longtext row. To perform this transition correctly without losing your UTF-8 data, you have to convert it to latin-1 longtext first and then to UTF-8 longtext:

ALTER TABLE properties MODIFY val_string longtext CHARSET latin1;
ALTER TABLE properties MODIFY val_string longtext CHARSET utf8 COLLATE utf8_general_ci;

7. Now, you are ready to upgrade to Zarafa 7.0 (using the provided packages). After the upgrade, with the first start of zarafa-server, a database upgrade has to be forced:

zarafa-server --force-database-upgrade

Have a look into the log file (/var/log/zarafa/server.log) if the upgrade was successful. Then, you can restart all Zarafa processes:

for script in /etc/init.d/zarafa-*; do $script restart; done

8. Zarafa 7.0 should now be up and running.

Upgrade to Zarafa 6.40

Here are my notes after a multi-server upgrade from 6.30.x to 6.40.x

- First update the Zarafa server, then the clients

- Make backups of everything (esp. /etc/zarafa, the MySQL DB, maybe the old binaries and share folders)

- Install updates via your supported update system (rpm or whatever)

- Transfer the congfiguration items from the old server.cfg to a copy of the new one (a lot of stuff has been added or removed so it is not advisable to just edit the old server.cfg)

- Do the same for your ldap.cfg or other ldap conf file if you use ldap

- Do not forget to copy the new zarafa.schema from /usr/share/doc into your ldap schema directory

- Restart your ldap server afterwards to make the new schema entries usable

- For commercial Zarafa: convert your licenses or have them converted by your vendor

We solved the following problems encountered:

- After upgrading, zarafa said something like "not enough licenses for users..."

Solution: Server did not recognize nonactive users (shared stores, resources etc) as in the new ldapms.cfg there was an empty default setting for ldap_nonactive_attribute which must be set to "zarafaSharedStoreOnly"

- Next problem: All users present, but empty stores. All found via "zarafa-admin --list orphans".

Problem: we had a non-default setting for the unique user identifier (different from uidNumber), so without changing this default zarafa would read out a different attribute form ldap than before and therefore could not match the existing stores with the existing users

- Next problem: After solving this, we restored the database to re-apply the database update. Did not work as it could not create two tables already present after the first update.

Solution: Table names appeared clearly in the log, so we deleted these emtpy tables via mysql command line and restarted the server, update worked then. But beware: only use mysql CLI commands if you know what you do!

- Zarafa complained about a missing plugin configuration file. This turned out to be the file ldap.propmap.cfg which we had moved away together with other files, not knowing that it was part of the current 6.40. configuration.

Personal tools