I have migrated JIRA (v6.3.15) and Confluence (5.7) to a new debian server. I downloaded the respective .tar.gz files (not EAR/WAR) from the download archive page and extracted these into their respective newly created install directories (/opt/atlassian/JIRA and /opt/atlassian/confluence). Both systems are small and are currently configured to use the embedded database.
Following the instructions at https://confluence.atlassian.com/doc/migrating-confluence-between-servers-184150.html I have successfully started JIRA on the new server, added my current starter license, and performed a restore of the xml backup from the old server.
On the old server, Confluence was configured to share JIRA users. But now, when I start Confluence on the new server, the login fails - "Sorry, an error occurred trying to log you in. Please try again." Of course, trying again also fails.
I have re-created the Application Link to Confluence, but when being redirected to Confluence to apply the reverse link, the call fails.
Is there a way to create an administrator user in Confluence, or force a login somehow, so that I can recreate the Confluence Application Link manually?
Or is there another way out of what appears to be a Catch-22 situation?
Users are NOT shared via the Application Link. In other words, the Application Links are not the cause of your issue.
Confluence has a section in the Administration dedicated to User Directories. In this screen you can associate it to a new directory of type JIRA.
If you do not know any local or remote account in this application, you should follow the KB article on regaining access to Confluence – https://confluence.atlassian.com/doc/restore-passwords-to-recover-admin-user-rights-158390.html
Thanks for your quick response. I have tried to follow the KB article, but I have never connected to the embedded database before
I installed DbVisualizer, and configured a connection to /var/atlassian/application-data/confluence/database directory. Unfortunately, when attempting to perform the first query in the article an exception was thrown which stated that the table could not be found. When I checked under the TABLES node, indeed, there weren't any. Is this a permissions problem? or could the data be stored elsewhere?
Another possible approach would be to delete everything and re-install both applications, choosing to use a PostgreSQL database instead. However, I do not know if the xml export from the embedded database can be restored to a PostgreSQL database.
Any further advice gratefully received.
Update: I have managed to re-install both JIRA and Confluence and have restored data from their respective backups into new PostgreSQL databases. I have also, using the isntructions suggested by Steven, restored the internal admin user in Confluence - which I had to do in order to log back in once the installation was completed.
One residual issue however is that there are now two admin users in Confluence - one in the internal directory and another in the JIRA directory. I'll try to figure out how to resolve this.
When you restore a backup, you'll also restore any local accounts associated with that backup (while removing anything you setup in the target system prior to restoring on that target system). You can mitigate this next time by ensuring there is an accessible local account in the system that you backup in the first place. Then you can use the account you already know exists when you restore the account to the target machine.
The HSQLDB evaluation database I cannot possibly help you with. I do not touch this database-type other than during trials or evaluations for clients. It is best used for testing or trial only. Atlassian does NOT support in-memory databases!
An XML-backup is database agnostic, so yes it works just fine in PostgreSQL as you've found out.
Finally, Is there an issue removing the user account? If you can't figure out how to proceed I can help there but you should probably tell me more of what's happening.
Thanks for the offer of help with this. I do wish to retain the internal Confluence admin user as you suggest. However, this means that there are now two users known as 'admin' on the Confluence side.
I see two options, but don't know how practical - or even possible - they are.
Changing either the internal Confluence 'admin' user to 'administrator' - or the JIRA 'admin' user to 'administrator' (or something else) - using SQL at the database level.
However, I do not know the entity relationships associated with users in the database and would hesitate to make SQL changes without guidance.
I would handle this as such –
You should have two separate user-entities with no DB mucking.
Thanks for that - all good up till the fifth bullet point, where under User Management it complained that user admin '..could not be found'.
After some time reviewing the instructions for recovering admin user rights, using SQL I checked the contents of all the tables that were mentioned in that KB article. I noted under the section 'If no local administrator exists' that the second insert adds a record to a table called user_mapping.
When I checked this table I could only see the users from JIRA (I assume that the synchronization in bullet point 3 had removed the Confluence admin record). I therefore performed ONLY that single insert into user mapping and I can now once again view details of the admin (Confluence internal). But, I cannot actually change the admin account name. I assume that this is because JIRA has been nominated as the user manager.
I can live with this - I now have a functional Confluence internal admin user as well as a functional JIRA jira-admin user.
Many thanks for all your help.
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs