Hi, we’re moving an OpenFire 3.5.1 installation from one Windows 2003 server to another. We are using SQL Express 2005 SP2 on both boxes. I’ve tried to migrate by installing 3.5.1 on the new box, backup and restoring the database, but any attempt to connect to a user account with an encrypted password does not work. Accounts that have a plain password in the database work fine. Is there a private key for hashing that I need to move over?
Thanks
Hey Jason,
There is no concept of keys being used for passwords. Have you also ported the conf/openfire.xml file? And how did you export and import the data from one database to the other? Sounds like maybe some data was corrupted in the database migration? One thing to try is to connect the new Openfire to the old database and confirm that things work. If they do then the problem is in the new database.
Regards,
– Gato
Hi Gaston,
Thanks for the response. No joy yet. I copied the entire Program Files\Openfire folder as is and the database backup/restore is good (using M$ SQL built-in backup and restore). The user list shows up fine in the admin console, so SQL connection string is okay as well.
I did notice an error in the error and debug logs about a duplicate key that Openfire was trying to insert into the jiveProperty table - but it wouldn’t say which one it is. So, in the interest of science, I modified the jiveProperty table to include an identity field as a primary key. It looks like OpenFire is writing new passwordKey field, update.lastCheck and xmpp.session.conflict-limitproperties. Why would it be trying to write these properties if existing properties are already in the table?
Is there some SQL-level tracing I can turn on from within OpenFire? From what I can tell, M$ SQL Express does not have a profiler I can use.
Thanks
What’s odd and disturbing about this is that resetting the password using the admin GUI, I was able to log in, which sort of belies the notion that the database or application installations are completely screwed up.
I had to move the application a couple of times back in the old “Wildfire” days and never ran into this sort of thing. It seems that after Wildfire went to Openfire, and GAIM went to Pidgin, authentication got rather dodgy.
Oh well, off to reset passwords…
Hi,
the `passwordKey´ should be the same in both databases. Otherwise authentication will fail as this key is used to decrypt stored passwords. I really wonder why Openfire should overwrite this value.
LG
They are the same when I restore the database.