How to migrate FishEye from JIRA-Crowd to LDAP?

[Mark Montminy]

I've got a FishEye / Crucible instance that's currently tied to JIRA-Crowd for user management. I need to change to using LDAP instead. I'm not yet running 4.0 (still on 3.10), but I'm thinking this might be easier if I do it before upgrading.

Has anyone done this before? We've done similar things in the past with JIRA, but it often involved adding the new user directory, then running some SQL to "move" users from the old directory to the new, then removing the old directory.

In Fisheye, I can't add an LDAP directory with the Crowd directory present. I'm not sure what happens to all the users if I remove the Crowd configuration. Does anyone know?

The goal is to preserve all ownership of reviews etc currently, otherwise I'd drop drop the users, re-add them with the new directory, and call it job done.

I can't ask Atlassian, since this falls outside the realm of "support". Hoping someone's been down this road and can share.

[Frédéric CORNU]

Hi,

We are on the very same path.

I'm just one step ahead of you : Once you remove your crowd settings and set the LDAP auth, fecru keeps you old users, formerly tied to crowd and all their crucible work : reviews, comments, etc

Next step is indeed user migration. Do you have some progress to share on this ?

Let's keep in touch

[Mark Montminy]

We're still in the exploration phase of this. We've done similar work (in the process of actually) with Confluence, JIRA and Bitbucket. Once we're done those, we're going to tackle FeCru.

That's great to know that it keeps the users when you drop the directory.

Our current process that's been (mostly) working is:

• Add new LDAP directory, but don't sync (we use a bogus name/ip for the server) so we have a directory id in the database, but we don't want the database populated with users, since that makes the following much harder
• Shut down app
• modify references to users/groups in the various cwd tables to update the old directory_id to the new directory_id in the database directly
• Start the app
• Verify users/groups are as expected
• Fix the IP for the LDAP directory and sync it

The above assumes you have the same usernames and groups between directories. In our case, we don't, and we rename the users/groups while updating their directory_id.

In some cases, we're having to also clear the "external_id" field (going from AD to LDAP) since the sync is thinking the users are all new because the external_id field doesn't match between AD and LDAP. In our case, our LDAP server isn't making GUID visible to us, so external_id needs to be cleared. If your "unique user id" attribute is visible, you'd want to update external_id accordingly.

Note that I don't know if FeCru has an external_id field, but some of the others do.

Getting the sync to not re-create the users has been the trickiest part. If it recreates the user, they get a new database id, and lose "ownership" of all references in the tools.

[Mark Montminy]

I've finally had some time to take a stab at this.

The actual user migration itself is pretty trivial. The "directory" for each user is stored in CRU_USER.CRU_AUTHTYPE. Shutting down FeCru and running:

UPDATE CRU_USER set CRU_AUTHTYPE = 2 WHERE CRU_AUTHTYPE = 6;

This should move all the users from Crowd (6) to LDAP (2). Once done, I was able to login as myself and still have all my reviews, history etc in tact. What was missing was group memberships though. However, that may have happened during various attempts at getting to this point, bad syncs and such.

Next pass is to reset the system with production data, and try again to see where the groups went "poof".