Admin login failure after restoring xmlexport....zip on new instance of Confluence.

Question

I've just successfully completed upgrading Jira from 5.0 to current.  So trying to do the same with confluence from 4.1.6 to current.

Here are some details:

-new server running RHEL 7

-installed same version as our production confluence 4.1.6  -- running successfully

-used file system backup method to load 'xmlreport...zip' which appeared to upload successfully.   This prompts me to login again to confluence.

-attempts to login fail.  (note: production confluence is authenticated by jira -- not sure if this is an issue).   I can login to both my production jira and my new server sandbox jira still.

-Trying to follow:  https://confluence.atlassian.com/conf64/restore-passwords-to-recover-admin-user-rights-936511358.html

Am I on the right track?  Is there a better way to do this?

Thanks in advance for your help.

BTW:  This isn't a case of not knowing my admin login:password and I am still able to login to the production version and my jira sandbox...so I'm not clear why this fails.

[EDIT]  Ok, I think I understand how to access the confluencedb.script file now.  I've tried editing this file and restarting following a number of examples from the forums.  Each time I update that file and restart I get a system error with a nullpointer.    I've tried both inserting the sample admin line an also replacing my admin lines.    Running out of ideas.  :(

[EDIT #2]  Just found in Conf.  4.1 Admin Docs where you can replace the hash of your admin password with the hash for 'admin'.   Still no go.....but after trying this tweak to confluencedb.script at least Confluence rebooted to the login page... I am just unable to login with my known admin acct or the new passwd of admin.

Sean Johnson · Answer

Daniel,

Thanks for taking the time to help.  No it's still not resolved.

We definitely will not use H2 for production. (By 'use' I mean we will not allow users access the system until we are on our external db, so we will not be writing data to H2.  Is this what is meant by don't use it for production?  Or are you saying don't even use it during upgrades on a non-production server?)

I just completed the Jira upgrade on our new server.  For that I allowed the xml upload data to stay in H/H2 thru the many stages of upgrade then migrated data to our Oracle Db, where we will cut over from our current production server and begin production use the new one.  That seemed to be successful.  Hoping to do the same for Confluence.

I have a question about your response.

Is the configuration item that controls using Jira for login authentication part of the xml.zip I upload?   Or can I tell my new 4.1.6 installation (before uploading zip) to use local logins, then import backup, then work with local admin login?   My thought is, I can successfully install Conf 4.1.6 on our new server and configure it to use local admin, but once I've uploaded the data I'm no longer able to login to configure the address to connect with jira.

My current difficulty is with understanding how to access/modify the H2 database to restore passwords (following that link I shared originally), but I'm assuming that's just my lack of sys.admin/dba skills as I'm actually the QA Test Manager.  :)   Any more explicit instruction you can point me to would be appreciated.

Sean

Daniel Eads · Answer

Hey Sean,

Just looking through and hoping to help out if you're still having trouble!

The document you linked to for restoring passwords is definitely what I would follow if you're having issues with the local accounts.

Since you're using Jira as your user directory, you're going to want to make sure you can log in to Confluence first using the admin account in Confluence's internal directory. Changes to Jira's address might cause Confluence to not be able to connect anymore (and you'll want to be able to log in to Confluence to test the user directory / make changes to fix it if necessary). That document will get the password reset for the admin account in the internal directory (which again might be different from the admin account you might be using from the Jira directory).

I also need to mention that the h2 database isn't really meant for production use. We find all sorts of problems occur when it runs for a long period of time (it's included so that people can evaluate Confluence even if they don't already have an external database running) and it doesn't handle unexpected shutdowns well. We've got a guide designed to help database migration to a different database type for long-term stability.

Let me know if you're still seeing issues and if there's any way we can help!

Cheers,
Daniel