Login to admin console fails after upgrade

Hello, I upgraded to 3.6.0a today. The server seems to be running just fine and users can log into it with no trouble at all. However, the admin console stopped accepting the admin user login and reports a login failure.

What I tried:

  1. Set the encrypted password in ofuser to sha256sum( mypassword ) and set the plaintext password to null.
  2. Set a very short plaintext password and set the encrypted password to null.

Unfortunately, none of the two experiments helped. (I restarted Openfire after each of them.) What could have happened? I guess this problem could have something in common with the fact that admin settings have been moved to the database. However, I was unable to find a table that would grant the users permission to log into the admin console.

Any piece of advice would be welcome.

BTW, the gateway plugin stopped working with error messages of this kind:

java.lang.NoSuchMethodError: org.jivesoftware.openfire.vcard.VCardManager.addListener(Lorg/jivesoftware/open fire/vcard/VCardListener;)V
at org.jivesoftware.openfire.gateway.BaseTransport.start(BaseTransport.java:1119)
at org.jivesoftware.openfire.component.InternalComponentManager.addComponent(Inter nalComponentManager.java:139)
at org.jivesoftware.openfire.gateway.TransportInstance.startInstance(TransportInst ance.java:182)
at org.jivesoftware.openfire.gateway.GatewayPlugin.maybeStartService(GatewayPlugin .java:151)
at org.jivesoftware.openfire.gateway.GatewayPlugin.initializePlugin(GatewayPlugin. java:75)
at org.jivesoftware.openfire.container.PluginManager.loadPlugin(PluginManager.java :448)
at org.jivesoftware.openfire.container.PluginManager.access$300(PluginManager.java :47)
at org.jivesoftware.openfire.container.PluginManager$PluginMonitor.run(PluginManag er.java:1014)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101 (ScheduledThreadPoolExecutor.java:98)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodi c(ScheduledThreadPoolExecutor.java:181)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Schedu ledThreadPoolExecutor.java:205)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java: 885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)

I edited openfire.xml and reset the tag. Then I went through the step-by-step configuration again and changed the admin password there. Unfortunately, this did not solve the problem.

This is a very serious issue. It surprises me that neither Google nor these forums are full of reports of this kind… Could I be the only one who got into this trouble? What am I doing wrong? What should I try?

I have been using Openfire for more than a year and I have never seen such an issue issue before.

Hi,

Your database is probably is need of some repair. Do you have backups of your previous setup?

daryl

Yes, I have backups, but I don’t think there’s something wrong with the database. As already mentioned, the server works just fine. Having deleted the malfunctioning gateway plugin, I can’t even see any messages in the error logs.

Is it possible that the database got corrupted during update and is now used without any error message? Could anyone possibly give an explanation of where administrator accounts are stored in the database and how their accounts differ from normal users?

All the user accounts work when used through XMPP. Only the admin can’t login to the admin console (HTTP)…

OK, I’ve found a solution.

  1. Stop Openfire.
  2. Add this line into the admin tag of conf/openfire.xml.
    admin
  3. Start Openfire. The line you have added will be deleted from the file, but the privilege to login will get stored in the database.

The release notes for version 3.6 mention the fact that admin list has been transferred to the database. There must be a tiny bug that causes the update process to forget about the admin account in certain special cases. But this workaround is pretty simple.

Thank you. This worked well for me even after all the other “fixes” failed. Mine wasn’t an upgrade though. Mine was a fresh linux install of 3.6.0

For some reason, the admin console just refused to let me in after about a week. I’ve now set up some other accounts with admin rights.