Horde malfunction after Panel upgrade to 9.5 version


2016-11-16 12:55:58 UTC


2017-08-16 16:14:02 UTC


Was this article helpful?

Have more questions?

Submit a request

Horde malfunction after Panel upgrade to 9.5 version

Applicable to:

  • Plesk 10.x for Linux


After upgrading to Plesk 9.5, some Horde webmail functionality may be broken (for example, the address book or calendar).

The /var/log/psa-horde/psa-horde.log Horde log contains the following errors:

May 04 21:09:41 HORDE [error] [turba] DB Error: no such field: SELECT object_id, owner_id, object_type, object_members, object_uid, object_firstname, object_lastname, object\\_middlenames, object\\_nameprefix, object\\_namesuffix, object\\_alias, object\\_bday, object\\_homestreet, object\\_homepob, object\\_homecity, object\\_homeprovince, object\\_homepostalcode, object\\_homecountry, object\\_workstreet, object\\_workpob, object\\_workcity, object\\_workprovince, object\\_workpostalcode, object\\_workcountry, object\\_tz, object\\_email, object\\_homephone, object\\_workphone, object\\_cellphone, object\\_fax, object\\_pager, object\\_title, object\\_role, object\\_company, object\\_category, object\\_notes, object\\_url, object\\_freebusyurl, object\\_pgppublickey, object\\_smimepublickey FROM turba\\_objects WHERE (owner\\_id = 'joan@joanryder.com' AND (((LOWER(object\\_nameprefix) LIKE LOWER('pa%') OR LOWER(object\\_nameprefix) LIKE LOWER('% pa%')) OR (LOWER(object\\_firstname) LIKE LOWER('pa%') OR LOWER(object\\_firstname) LIKE LOWER('% pa%')) OR (LOWER(object\\_middlenames) LIKE LOWER('pa%') OR LOWER(object\\_middlenames) LIKE LOWER('% pa%')) OR (LOWER(object\\_lastname) LIKE LOWER('pa%') OR LOWER(object\\_lastname) LIKE LOWER('% pa%')) OR (LOWER(object\\_namesuffix) LIKE LOWER('pa%') OR LOWER(object\\_namesuffix) LIKE LOWER('% pa%'))))) [nativecode=1054 \\*\\* Unknown column 'object\\_firstname' in 'field list'] [pid 3258 on line 173 of "/usr/share/psa-horde/turba/lib/Driver/sql.php"]


May 05 00:39:37 HORDE [error] [kronolith] DB Error: no such field: SELECT event\\_id, event\\_uid, event\\_description, event\\_location, event\\_private, event\\_status, event\\_attendees, event\\_keywords, event\\_title, event\\_category, event\\_recurcount, event\\_recurtype, event\\_recurenddate, event\\_recurinterval, event\\_recurdays, event\\_start, event\\_end, event\\_alarm, event\\_modified, event\\_exceptions, event\\_creator\\_id FROM kronolith\\_events WHERE calendar\\_id = 'joan@joanryder.com' AND event\\_alarm > 0 AND ((event\\_end >= '2010-05-05 00:00:00') OR (event\\_recurenddate >= '2010-05-05 00:00:00' AND event\\_recurtype <> 0)) [nativecode=1054 \\*\\* Unknown column 'event\\_private' in 'field list'] [pid 3134 on line 323 of "/usr/share/psa-horde/kronolith/lib/Driver/sql.php"]


For the specified example, the following Horde components are affected: kronolith (calendar) and turba (address books).

It is possible to fix the issue by a re-upgrade of the components using Horde scripts:

  1. Locate the upgrade scripts at /usr/share/psa-horde/ . For this example, the folders with the upgrade scripts are /usr/share/psa-horde/turba/scripts/upgrades/ and /usr/share/psa-horde/kronolith/scripts/upgrades/ .

  2. Create a dump of the Horde database in case of an emergency:

    # MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysqldump -uadmin --quote-names --databases horde > /root/horde.sql``
  3. Upgrade the turba_objects table in the Horde database:

  4. Open the upgrade script in an editor:

        # vi /usr/share/psa-horde/turba/scripts/upgrades/2.1_to_2.2_sql_schema.php

Find the database configuration variables $db_user and $dbpass . Set them to admin and the contents of the /etc/psa/.psa.shadow file, respectively. It is important to use the MySQL superuser's privileges, since the privileges of the "horde" user are not sufficient to upgrade tables.

  • Save the script and execute it with the following command:
        # php -d include_path=".:/usr/share/psa-pear" /usr/share/psa-horde/turba/scripts/upgrades/2.1_to_2.2_sql_schema.php`

It will not execute any upgrade; however, it will run a test run of the upgrade. If no errors appear (such as "unable to open file"), then open the script again, find the variable $for_real , and change its value to true . After that, run the upgrade script again.

  1. Run the kronolith upgrade:
    # mysql horde -uadmin -p`cat /etc/psa/.psa.shadow` < /usr/share/psa-horde/kronolith/scripts/upgrades/2.2_to_2.3.sql

If you get something like:

    ERROR 1146 (42S02) at line 1: Table 'horde.kronolith_shares' doesn't exist

then the kronolith upgrade should be run from version 2.1 to 2.2, and then from schema 2.2 to 2.3. The upgrade "sql" queries are in the same folder /usr/share/psa-horde/kronolith/scripts/upgrades/2.1\\_to\\_2.2.sql :

    # MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysql -u admin horde < /usr/share/psa-horde/kronolith/scripts/upgrades/2.1_to_2.2.sql
# MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysql -u admin horde < /usr/share/psa-horde/kronolith/scripts/upgrades/2.2_to_2.3.sql

After that, you should be able to use the Horde address book and calendar without errors.

  1. That should be enough. However, if the upgrade goes wrong, you can simply restore the horde.sql file that was saved prior to starting the upgrade procedure:
    # MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysql -u admin horde< /root/horde.sql
Have more questions? Submit a request
Please sign in to leave a comment.