There are a few questions and answers about them, but I'm looking to do this without involving the DBA.
Trying to move Jira 5.2.7 to 6.2.3, though there is the compatability error when trying to "Restore From Backup" with XML.
So, I decided to spin up a server for staging. Restore From Backup worked fine. However, when I tried to login (on both the local account used during setup and an admin account from the old server) it simply times out and returns no error in the logs, but it has shown me this one:
Sorry, a communication error occurred while trying to contact the remote authentication server.
From the auto logs it hasn't shown anything, tail -f catalina.out will only show me errors involving mail handlers.
So, it appears that the restored backup is trying to reach the LDAP server from before. I'm wondering if there is a way on the Test Machine to modify a file and have it point to the local account I had created, avoid LDAP and make the world a better place all in one fel swoop?
Ok, I got on the horn with Support and Ivan was awesome. He gave me this query that really helped clear things up:
SELECT DISTINCT child_name FROM cwd_membership WHERE directory_id = 1 AND child_name IN (SELECT child_name FROM cwd_membership WHERE parent_name IN (SELECT perm_parameter FROM schemepermissions WHERE PERMISSION=44)) ORDER BY child_name;
Instead of the query to list admins, this one listed those with a higher level that could login at its current state. From there I reset the password of the default "adminaccount" user and successfully logged in.
Hey Andrew, first thing is to make sure we have a local account. You can do this using this query:
The basic process for this is to change group membership for jira on its database. That is done using the steps on this link . Just remember to stop your jira instance before changing anything on its dabase and make a backup of your DB. If you want further assistance please tell me! :D
Thanks for getting back to me! I did go through a few of these DB steps, and I did look into these documents/do these as well:
Step #3, which identified the Global Permission, reveals that my account does indeed exist. However, when trying to login it still displays the issue.
I did try the final step of modifying/manually resetting the user password: update cwd_user set credential='uQieO/1CGMUIXXftw3ynrsaYLShI+GTcPS4LdUGWbIusFvHPfUzD7CZvms6yMMvA8I7FViHVEqr6Mj4pCLKAFQ==' where user_name='USERNAME';
Sadly this didn't turn out any better. Should I use the ID# rather than the USERNAME?
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
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot