Openfire 3.6.0a has been released!

Openfire Openfire Support
1

Folk, as of now Openfire 3.6.0a is available. All this release is is a ton of database upgrade fixes (and some LDAP fixes) from 3.6.0. After upgrading to 3.6.0a, you will still see 3.6.0 in the admin console, so please don’t be confused by that. The packages themselves will have the version 3.6.0a in them. Those of you who successfully upgraded to 3.6.0 already most likely do not need this release. Those who had problems, this one’s for you. =) For all practical purposes, I am replacing 3.6.0 with 3.6.0a.

Important! Please Read!

A number of you upgraded and “part of the upgrade” completed before you had a failure, so I wanted to touch on those scenarios a bit so you have an idea of what to do. First off, if you upgraded to 3.6.0, had it fail, and reverted back to a backup you made -including reverting the database-, you should be good to go and can just install this 3.6.0a package to upgrade what you have. If you upgraded 3.6.0, had it fail, and then just reinstalled 3.5.2 with the existing database that 3.6.0 already touched, that is where you may have some problems. I will go over each database individually, what probably happened, and what you can do about it. By all means it would be better if you can downgrade to your database as it was when you were running 3.5.2 before upgrading to 3.6.0a though. If you can do this you can skip all of this.

MySQL

As far as I can tell, MySQL had no problems with the upgrade. Most likely. if you had problems with 3.6.0 they were due to LDAP, and you should be good to go to upgrade to 3.6.0a to fix those issues.

Postgres

Postgres did not appear to have any problems before. If it did, it probably failed on update 17. You can check your jiveVersion table to verify if that’s the case. (it will say “openfire” and “16”) If you don’t have a jiveVersion table, well you probably have an ofVersion table and the update should have completed successfully.

**Oracle
**

There’s a good chance part of update 17 occurred if you had tried Openfire 3.6.0. An easy way to recover from this and let the updates run like they should is to, before starting up 3.6.0a, but after you install the package, go into your install root/resources/database/upgrade/17/openfire_oracle.sql and delete everything above:

> -- update all entries in mucRoom to be set to the default conference service

And also the line:

> ALTER TABLE mucRoom DROP CONSTRAINT mucRoom_pk;

**SQL Server
**

The SQL server scripts had problems in version 18, which will automatically take care of itself when you upgrade to 3.6.0a.

DB2

As far as I can tell from the reports that came in, no one tried this. This is good because it’s upgrade was complex. If you are having trouble with the DB2 upgrade, post a reply here and we’ll work through it.

Embedded DB (HSQLDB)

Similar to the Oracle issues, you will need to, after upgrading the openfire package, edit resources/database/upgrade/17/openfire_hsqldb.sql and remove everything above:

> // add new indexed column to mucRoom
> ALTER TABLE mucRoom ADD COLUMN serviceID BIGINT BEFORE roomID;
> CREATE INDEX mucRoom_serviceid_idx ON mucRoom(serviceID);

Ok, How Can I Get It?

You can read more about the highlights here.

The complete set of changes can be found at: Openfire Changelog

Download Openfire from: Ignite Realtime: Downloads

Download Connection Manager from: Ignite Realtime: Openfire Server

Many thanks to everyone who helped debug issues, provide patches, and generally work with me getting this cleaned up!

2

And -please- back up your installation root and database (if you need help with that, it’s in the upgrade docs) before upgrading always. It’s always an excellent idea to be ready to back out in case there are problems! (with any server software updates!) =) Let me know if you run into problems and I’ll try to help you in the morning.

3

Very odd - I get a ‘Thread not found’ error when I try any of those links.

4

ARG!!! Clearspace is -STILL- doing that?! I’ll see if I can fix. Thanks!

5

Ok, links should be better now, thanks!

6

I’ve checked them now and they’re all working.

7

If it helps for your mood Daniel:

I updated from 3.6.0 to 3.6.0a and it seems to work flawlessly now (or lets say…almost. Let’s not get too enthusiastic ).

LDAP errors are gone, Login works, groups are synced, external messengers work, admin login works and even the TEST-Button for LDAP works (°yay°)

I’ll keep an eye on the system to see if no other new issues occur…

2 issues:

  1. Everything ONLY works with ldap.encloseDNs set to false. I have no idea if that causes any other issues, but I think you set it true for a reason? Removing it or setting it to true brakes everything.

  2. My backend keeps saying that it is 3.6.0 and that 3.6.0a is now available, even though I am pretty sure I downloaded/installed the right file (the *.deb to be precise)

EDIT:

Oh and FYI:

If you remember my 2 entries for LDAP Debugging in the DB:

Changing the LDAP Debug Button in the Adminbackend toggles the ldap.ldapDebugEnabled in the DB and leaves the ldap.debugEnabled untouched, so this might be a kind of leftover…

8

MySQL 4.1.22 on Mac OS X Server 10.4.11 hates the upgrade. Manually applying the database changes resulted in an upgrade/14/openfire_mysql.sql error:

ERROR 1170 (42000) at line 5: BLOB/TEXT column ‘jid’ used in key specification without a key length

I ignored this, which later resulted in upgrade/19/openfire_mysql.sql errors:

ERROR 1091 (42000) at line 39: Can’t DROP ‘jiveRoster_jid_idx’; check that column/key exists

ERROR 1170 (42000) at line 42: BLOB/TEXT column ‘jid’ used in key specification without a key length

Note that this is all the same index. Attempting to change the ‘jid’ column from “text” to “varchar(1024)” on my system didn’t change a thing (it’s still a "text’ column).

I’ve gotten it running without the index for now. Not sure what this will break.

9

What? hehehe That’s bizarre! What version of mysql is this?

ponder What happens if you create a new table with varchar(1024) in it?

Running without an index should be ok. It’ll be slower than you might like though. You can add an index to it using something like:

ALTER TABLE jiveRoster ADD INDEX ofRoster_jid_idx (jid(1024))

10

Interestingly enough, my primary dev and test platform is OS X, and I didn’t run into this. Color me confused! Did you make sure to run the rest of the script and also script 20?

11

Has anyone had any luck upgrading using the .deb package on Debian Etch? It seems to absolutely refuse to have anything to do with my database - that is, once it’s given the login information it does nix-nada.

Upgrade is from 3.5.2 and the database is MySQL.

12

I think this was the original problem that you helped with a while ago now and I mentioned elsewhere on here.

I can’t even remember how I actually fixed it in the end either.

13

Check your database and see what jiveVersion contains — specifically what revision it thinks that openfire is at.

14

Full Texts

name
version
Edit
Delete
openfire
14

That’s it untouched ( restored from backups. )

I take it this should be 20? Should I manually run the .sqls in /resources/databases/upgrade?

15

Holy crap that’s -really old-. What version of Openfire were you running before you upgraded? Something in update 15 is breaking for you.

16

Oh 3.5.2 – you already said. That means that 3.5.2 never finished -it’s- updates even when you were running it. I’m surprised it was going as well as it did! (3.5.2 that is) You should see some SQL errors in your logs that we can start with.

17

I was running 3.5.2. It seems like the database upgrades haven’t been happening though.

18

I think it may 3.3.1 as I had that problem and I don’t know if it was fixed - there was a manul workaround though but I can’t remember what it was now.

19

Probably manually patching the database?

20

It was quite a while ago - I think I had to backup the data then create a new set of blank tables for the next version. I can’t remember the exact differences, but I think it was mostly indexes rather than data structure changes.

I then did a back of that and had to manually change the headers of the new back file to transpose them onto to the main backup. I also dumped stuff like offline messages, chat rooms as there was only one fo them, changed the values of jiveID as it was then restore tha data.

I remember spending alot of time testing it and getting it right !