I am having trouble with openfire upgrade installed in an Active Directory domain, on Server 2003 using the embedded database with active directory authentication. It has been running flawlessly as installed (and upgraded) through version 3.5.2. I have tried to upgrade to 6.0, 6.1 and 6.2. I stop openfire and copy my current openfire folder to the desktop and then perform the upgrade. When asked to replace existing files, I answer “yes” to all. The upgrade seems to complete. I then start openfire. However, when I go to login, I am told bad username or password. When I examine the openfire.xml file, it is set to defaults (ie, nothing specific to my network). I have tried copying my old openfire.xml into the new openfire.xml. I still cannot login (and neither can any users).
Can someone please help me resolve this? I have just resorted to copying my old openfire folder back and restarting. I’m not sure what logs I can provide that will help trouble shoot this. I’m sure it is an oversight on my part.
Thank you for all of your help
Rob
On edit, I did see the post right below mine about logging into the console. I tried both selecting “yes to all” and “no to all” when upgrading. Message was edited by: Rob
if you still have the updated database you can inspect the OFPROPERTIES table and look for LDAP entries as they are now stored there.
Before you update again it could make sense to enable the LDAP debug log within openfire.xml. And after starting you may want to run “tail -f embedded-db/openfire.log” and verify what is written to the database. And also look at the ldap debug log, it should contain errors.
So the LDAP information is no longer stored in the XML file? That’s good since the password had to be stored in plain text in there.
However, when upgrading from 3.5.2 to 3.6.2 I also experienced the same problem as the original poster. I could not login and when checking the “openfire.xml” log, all of my LDAP entries save for a couple were gone. I would replace them, and they would be removed on the next restart of Openfire.
Now I know it’s because the LDAP was moved into the embedded database. I will have to test with this new version as the upgrade was not smooth.
I had the same problem. For some reason the upgrade locked me out. This is what I did (which worked for me):
Stopped openfire.
Then I added:
admin
in the portion of conf/openfire.xml.
Then start it back up and try again. I’ve also seen some people say to put it not in , but inside . One of these should work for getting you back into the Admin Console, as long as everything else is straight.
Thank you for the help. I tried the admin entry, but no luck (always try the easiest solution first! ).
After going through the error.log, I see this:
2008.12.15 21:10:25 [org.jivesoftware.openfire.ldap.LdapGroupProvider.getGroup(LdapGroupProvider.ja va:91)
]
javax.naming.NamingException: [LDAP: error code 1 - 000020D6: SvcErr: DSID-031006CC, problem 5012 (DIR_ERROR), data 0
]; remaining name ''
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.searchAux(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source)
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(Unknown Source)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
at javax.naming.directory.InitialDirContext.search(Unknown Source)
at org.jivesoftware.openfire.ldap.LdapManager.findGroupDN(LdapManager.java:845)
at org.jivesoftware.openfire.ldap.LdapManager.findGroupDN(LdapManager.java:782)
at org.jivesoftware.openfire.ldap.LdapGroupProvider.getGroup(LdapGroupProvider.jav a:83)
at org.jivesoftware.openfire.group.GroupManager.getGroup(GroupManager.java:278)
at org.jivesoftware.openfire.group.GroupManager.getGroup(GroupManager.java:257)
at org.jivesoftware.openfire.group.GroupCollection$UserIterator.getNextElement(Gro upCollection.java:103)
at org.jivesoftware.openfire.group.GroupCollection$UserIterator.hasNext(GroupColle ction.java:66)
at org.jivesoftware.openfire.group.GroupManager$4.run(GroupManager.java:185)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Mean anything to anyone? And LG, you lost me with the “inspect the OFPROPERTIES table and look for LDAP entries as they are now stored there” suggestion. And the tail -f, can I do that in windows?
Thanks for the suggestions, and keep 'em coming. I apologize for the delay in my response, I can only take the system down after hours.Thanks again
unix-tools for dos include a lot of unix commands, even M$ has a suite with unix comands but I don’t know how they did name it.
If you don’t have it you may want to make a copy of the file while Openfire is running you want to open (openfire.script or .log) and open it then. Search there OFPROPERTIES.
Not 100% sure, but seeing ‘remaining name’ indicates referrals may not be being handled properly. There is an advanced config option during install.
One method (that Ive used) is just tweak the ‘true’ to ‘false’, the browser remembered my previous settings and I was able to go back and fix missing admin users without making any wider changes, though you should make a db backup in case I missed something!!!