This is our plan: We are using the "test" server as staging area to take a few of the production projects and move them to separate network. The idea was that we would import all of production onto the test server and remove all projects that were not needed. Then we would perform a backup to XML from the test server and use that to import the needed projects to the new system. We can't use the Project Import because of all of the custom fields, Issue Types, Issue Type schemas, etc... that were created on production because that would require us to recreate all of those manually.
We've created a "test" server to allow us to migrate projects from our current production system. The production system is currently sitting at 4.1.2 (build #531) and the test server is 5.0.2. We chose to go with the .bin standalone installer instead of the WAR/EAR installation for the 5.0.2. We installed the 5.0.2 without any problem and setup MySQL as the backend database, but once we perform the Restore from XML from the .zip file created on the production system we are no longer able to log into JIRA. The production system is setup to allow auto-login with PKI authenticating against the Crowd server. We updated the production Crowd to work with our test server IP, but that did not correct the issue.
So the install worked, the restore from XML worked, but now we're stuck in a state where we cannot move forward because we cannot log in. We have a very short deadline to get this new instance setup.
The problem was that I hadn't actually setup my new Crowd to work with the old Crowd. Once I set it up as an application and restarted I was able to get to another error. That one identified that the Client IP was invalid. Following the steps from https://confluence.atlassian.com/display/CROWDKB/Client+Host+is+Invalid I was able to remedy that problem and login to my new Crowd instance
When you set JIRA up for the first time you would have created a local admin.
Identify this user in production and hope/pray you still remember the password for this user.
Login as the local admin, this user is completely detached from your crowd PKI authentication and should not have any issues logging in as the local admin user
once logged in you should be able to modify the user directories and allow the rest of the users to login.
a how to is available here
if you had replaced the
make sure you put the original back in, this will prevent you from logging in as the local administrator.
let us know how it goes
This doesn't work. Both of the files that you mentioned above are set to defaults and shouldn't even be trying to look at Crowd. However, I am seeing that the import seems to be changing my configurations during the reindexing. Where one build update will show that the User Directories are empty or use Jira Internal Directory, the latter entries are starting to show that Crowd Internal Directories were implemented. I have no idea why it would keep changing these values during the import, but it is.
I'm not sure, but it's worth to try. When I created my test server, I did the configuration creating the admin user with a password right? But when I did the import, the admin user automatically took the password from the other instance because of the back up import.
This make any sense?
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in talking to 20 people planning t...
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