Opened 7 years ago

Last modified 5 years ago

#4700 assigned Bug/Something is broken

upgrade horde to avoid deprecated PHP.

Reported by: https://id.mayfirst.org/dkg Owned by: https://id.mayfirst.org/ross
Priority: Medium Component: Tech
Keywords: php5.3 horde stallman.mayfirst.org Cc:
Sensitive: no

Description

stallman:/var/log/apache2/error.log is full of lines like this:

[Tue Oct 04 13:04:45 2011] [error] [client 74.108.159.82] PHP Deprecated:  Function eregi() is deprecated in /usr/local/share/horde-live/imp/lib/IMAP/Client.php on line
 602, referer: https://members.mayfirst.org/index.php

I assume this happened since the php upgrade to 5.3. We should upgrade horde to a version that doesn't produce these deprecation warnings (i'm assuming that the newer versions don't do this).

I observe that there are instructions for upgrading horde on the wiki.

Change History (25)

comment:1 Changed 7 years ago by https://id.mayfirst.org/ross

  • Owner set to https://id.mayfirst.org/gregl
  • Status changed from new to assigned

comment:2 Changed 7 years ago by https://id.mayfirst.org/ross

  • Owner changed from https://id.mayfirst.org/gregl to https://id.mayfirst.org/ross

I'm taking on this assignment, but there's no way I'm going to do this alone. dkg or jamie would you mind scheduling a time to help with this upgrade?

thanks,

~/ross

comment:3 Changed 7 years ago by https://id.mayfirst.org/ross

  • Owner changed from https://id.mayfirst.org/ross to https://id.mayfirst.org/jamie

I think it's time for us to consider moving to Round Cube as our mail client. Having now worked with Horde a lot over the last few weeks, our current set up, at least, is extremely weak as a webmail client. Round Cube seems like a much better alternative. http://roundcube.net/

At the very least, we should implement the address book functions of Horde so one can at least add a sender to the address book.

I'm re-assigning this to jamie so he will look at it.

comment:4 Changed 7 years ago by https://id.mayfirst.org/ross

gregl and I worked on upgrading horde at the f2f, but were unable to figure out the best path to get horde upgraded to version 4. We did upgrade the staging server to the most recent horde3 files, but were a bit hesitant to make those upgrades live.

If you could look over our horde3 updates, jamie, that would be great. We will need your assistance, however, to make the transition to horde4 though. Things have changed enough to make it a bit of a challenge.

~/ross

comment:5 Changed 7 years ago by https://id.mayfirst.org/ross

To clarify, we did *not* run:

./horde-cp-staging-live

comment:6 Changed 7 years ago by https://id.mayfirst.org/jamie

  • Owner changed from https://id.mayfirst.org/jamie to https://id.mayfirst.org/ross

Cool. I just check it out and it seems good. I just ran /root/bin/horde-cp-staging-live - we are now live on the most recent version 3.

Now that #5553 is resolved, perhaps that will help with the upgrade to version 4? It should allow us to run a completely isolated upgrade on the dev instance.

Let me know what else I can do to help with this testing and upgrade.

Last edited 7 years ago by https://id.mayfirst.org/jamie (previous) (diff)

comment:7 Changed 6 years ago by https://id.mayfirst.org/jamie

  • Keywords f2f added

comment:8 Changed 6 years ago by https://id.mayfirst.org/ross

  • Keywords f2f removed

comment:9 Changed 5 years ago by https://id.mayfirst.org/ross

It now seems vital that we sort out the horde 4 upgrade. We have a functional horde 4 instance at https://horde4.dev.mayfirst.org, but I'm not sure where that puts us in the upgrade path. However, given #8046, I see the horde upgrade as imperative to complete prior to undertaking the wheezy upgrade of stallman.

comment:10 Changed 5 years ago by https://id.mayfirst.org/jamie

One of the advantages to stalling on the horde upgrade is that now there seems to be a reasonably up to date debian package in jessie.

I just broke the current horde package on cero.mayfirst.org (which provides https://horde4.dev.mayfirst.org). I'm going to upgrade cero to wheezy and then try to pull in the horde package from jessie and see if it works. We could request a backport, but there are so many horde packages - I'm not sure what kind of work load that would create. Open to ideas.

If we go this route, and roundcube is moved to it's own server in #8046. Then, once we have a stable enough horde on cero, we can simply switch horde to cero and retire stallman.

jamie

Last edited 5 years ago by https://id.mayfirst.org/jamie (previous) (diff)

comment:11 Changed 5 years ago by https://id.mayfirst.org/dkg

When you say "request a backport", do you mean a backport to squeeze? Given that squeeze is near EOL, that doesn't seem like a good use of time. I think your proposal of moving cero to wheezy is a good one. If you get that done and the new horde works there, we could also transition to that, and then leave stallman to roundcube (which could then be upgraded to wheezy), rather than making a new guest (this was the original plan in #8046).

comment:12 Changed 5 years ago by https://id.mayfirst.org/jamie

Woops - I meant to say the horde packages are in jessie so we'd need to request a backport to wheezy.

comment:13 Changed 5 years ago by https://id.mayfirst.org/dkg

Pulling in the packages from jessie directly may work now, but it may also leave us in an untenable, unmaintainable situation if we don't have support from backporters (or our own dedicated plan to handle the backports).

Demonstrating a single installation is good, but demonstrating a clear plan for ongoing maintenance is probably better.

We have a routine and a plan and a relatively transparent review process for maintaining roundcube in collaboration with upstream directly. Can something similar be assembled for horde if it's something we want to support going forward? If the plan for horde involves backporting the packages into debian's stable release, all the better, because then we could benefit the community of folks who run debian stable as well.

comment:14 Changed 5 years ago by https://id.mayfirst.org/jamie

There are 114 packages in debian that start with php-horde. We probably don't need all of them, but it's quite a bit of backporting. That's probably the way to go. I'll see if I can give this backport directions page and shot.

The other alternative (short of directly maintaining the code directly via the revision control system as you suggested) is to use pear, which is how the initial setup was done on cero.

comment:15 Changed 5 years ago by https://id.mayfirst.org/dkg

I note that version 5.1.3 is the latest version of horde upstream, and DebianPackage:php-horde is on 5.1.4 (!) in jessie but you seem to be talking about horde 4 here.

comment:16 Changed 5 years ago by https://id.mayfirst.org/jamie

The horde versioning is confusing. Seems as though php-horde (latest version is 5.1.4) is different from the Horde Groupware Webmail edition (aka php-hore-webmail) - latest version 5.1.3.

Also... I missed the full major version change. I think we should be upgrading to horde 5, not horde 4.

comment:17 Changed 5 years ago by https://id.mayfirst.org/jamie

I've moved forward with running all of horde via Debian Jessie so we don't have to maintain over 100 backported versions.

I've upgraded cero to jessie and installed php-horde-webmail, which pulls in all relevant packages for horde webmail.

I then initialized a git repository in /etc/horde and committed the default settings.

Next, I ran webmail-install to get the base confiration in place (and committed to git).

Next I added /etc/horde/imp/backends.d/10-mfpl-backends.php to specify mail.mayfirst.org as the default backend IMAP server.

Then, I added my user account to the array of administrators in /etc/horde/horde/conf.php and then perused the web-based version of the configurations and made a few changes (each time, generating a new conf.php file, looking at the diff, and then manually adding the change to the file in /etc/horde and git committing).

Finally, I deleted the horde MySQL database, re-created it, and then imported the version on stallman. With that in place, I ran:

horde-db-migrate

comment:18 Changed 5 years ago by https://id.mayfirst.org/jamie

I had to run horde-db-migrate twice, but now I can login to: https://webmail.dev.mayfirst.org/.

It seems as though all my address book entries are there, but I don't see my calendar entries.

comment:19 Changed 5 years ago by https://id.mayfirst.org/jamie

My appointments are in the db, but not being displayed... more debugging needed.

comment:20 Changed 5 years ago by https://id.mayfirst.org/jamie

Success!

I ran the following commands:

kronolith-convert-datatree-shares-to-sql
kronolith-convert-sql-shares-to-sqlng
turba-convert-datatree-shares-to-sql
turba-convert-sql-shares-to-sqlng

In all cases, I chose the options to delete datatree data after conversion.

comment:21 Changed 5 years ago by https://id.mayfirst.org/jamie

I've just emailed the support team asking for testers.

I also plan to get a cartel cert for https://webmail.dev.mayfirst.org/ so we can ask regular users to try it out (and to add a link to members.mayfirst.org asking for people to try it out).

comment:22 Changed 5 years ago by https://id.mayfirst.org/dkg

first off: wow! I'm not a fan of webmail, but i admit i really like the UI/UX improvements i'm seeing in this revision of horde. thanks for doing this work, Jamie. I think it's really worthwhile.

Given the database sync issues, i'm not sure asking a lot of regular users to try it out is a good idea -- presumably we're going to drop the dev database and re-build it when we transition the production name, which implies that any addressbook/calendar/tasklist etc work that a tester does in the dev instance is going to be lost.

We can try to make that idea clear to the users we're asking to test, but it still will feel like we are deleting user data if we let that happen. Also, we'd need to make clear that while addressbook/calendar/tasklist changes will get lost, e-mail messages specifically (maybe except for drafts? i don't know) will be preserved. so it's a subtle distinction to communicate effectively.

Maybe a big fat permanent warning on the dev system while it's a dev system that explains what to expect?

I haven't checked to see what kind of CPU or disk contention this thing needs, but we should make sure that cero has enough resources to run this sort of thing with a bunch of concurrent users.

comment:23 Changed 5 years ago by https://id.mayfirst.org/jamie

Thanks for the feedback - and yes, I think you are right. I'm disappointed that I can't find any elegant way to have a warning show up on every page in horde.

I just copied /etc/horde/horde/hooks.pref.dist to /etc/horde/horde/hooks.pref and edited the preauth hook to display a big warning on the login page.

I think that helps but would like to figure out a way to warn always.

To be sure, we can also make a backup of the dev database before overwriting it with the new one.

comment:24 Changed 5 years ago by https://id.mayfirst.org/jamie

I've scheduled the upgrade to take place friday January 31 (https://status.mayfirst.org/2014/3).

comment:25 Changed 5 years ago by https://id.mayfirst.org/jamie

I repeated the steps I took for testing, and now horde is fully upgraded and running on cero.

I'll leave this ticket open for a few days to ensure there are not outstanding problems (and before I wipe out the horde install on stallman).

Please login to add comments to this ticket.

Note: See TracTickets for help on using tickets.