By: Brian Morin user 28 Oct 2021 at 3:16 p.m. CDT

4 Responses
Brian Morin gravatar
Please route this to Davin Cooke @gluu ## expected behavior Following community documentation, a 3.1.4 upgrade failed on multiple levels. It appears that there was some customized install during the chroot environment we were unable to overcome. We restored a VM image and aborted the upgrade. We wanted to get update the software to latest 4.x. ## actual behavior The upgrade was difficult due to the chroot environment, and specific componentents not being located where scripts expected them to be. I was able to export the ldap directory however in an attempt to later import it into a new 4.xx We talked with Davin and there was some thoughts on how to continue with an assisted upgrade.

By Mohib Zico staff 28 Oct 2021 at 10:19 p.m. CDT

Mohib Zico gravatar
Hi Brian, All versions which are less than 4.0 reached their end of life. Unfortunately they are not covered in community support. >> Please route this to Davin Cooke @gluu Done.

By Davin Cooke Account Admin 04 Nov 2021 at 4:59 p.m. CDT

Davin Cooke gravatar
Ref: 8. Brian got roadblocked in the middle of setting up the test Gluu 4.x server, "I've moved the trust relationships, however they aren't showing in the interface. The biggest issue I'm having now is the original DN's id is: @!13A3.08A9.8106.3629!0001!80A5.E1DE and the lab server can't change it's ID, so the users don't show up outside of a direct ldapsearch. Honestly I'm unsure how to get around this. When I imported users, they imported, but once I wanted to actually use them, I couldn't because the original DN's didn't match. I tried to modify them in the export, and that didn't work either." -----------------> from my email . 3.1 to 4.0 does have architecture changes and OpenLDAP is no longer supported so a migration is the only safe recourse. We don’t have any tickets that ask about 4.X presently we can action. Brian or you can ask any questions about the inability access the user attributes on a 4.X server in community support and I can get these escalated. I’ll assume the users are already copied over to OpenDJ (Wren) with the custom schema attributes and the installation recognized these? As for Drupal.. we aren’t using the “Plugin” are we? Drupal - oxd 3.1.4 Docs (gluu.org) Looks like a Bind issue on the DN: our support can probably help with that.. over my head sorry. Some links with a possible checklist here: Upgrade to 4.x - Gluu Server 4.0 Docs Convert the Schema in OpenLDAP to OpenDJ OpenDJ 3.5 > Administration Guide (forgerock.com) https://backstage.forgerock.com/docs/opendj/3.5/admin-guide/#ldap-client-server-communication

By Jennifer Syer user 09 Nov 2021 at 10:38 a.m. CST

Jennifer Syer gravatar
**Commenting simply to enable email notifications on this ticket**

By Mohib Zico staff 11 Nov 2021 at 9:25 a.m. CST

Mohib Zico gravatar
Hello all, Just sharing my suggestions.... >> It appears that there was some customized install during the chroot environment we were unable to overcome Possible to describe a bit on "customized installation" please? >> The upgrade was difficult due to the chroot environment, and specific componentents not being located where scripts expected them to be. I am sorry but can't understand "due to the chroot environment" part. :-) May be little explanation will help. >> "I've moved the trust relationships, however they aren't showing in the interface. The biggest issue I'm having now is the original DN's id is: @!13A3.08A9.8106.3629!0001!80A5.E1DE and the lab server can't change it's ID Actually, we don't need to think much about Trust Relationship's DN's id ( or, `inum`, we call them ). Because, SAML transactions doesn't rely on inum but application and Gluu server communicate with `entityID` value. So, best route would be.. just create those Trust Relationships again in new 4.x Gluu Server. You will just need to collect those SAML SP's metadata from old server `/opt/shibboleth-idp/metadata/` location. >> When I imported users, they imported, but once I wanted to actually use them, I couldn't because the original DN's didn't match. Are you using User's `inum` ( DN id ) for any kind of production operation? If not then we also don't need to bother those inums as well. You can actually _pull_ those users from old server into your new server by using [Cache Refresh](https://www.gluu.org/docs/gluu-server/4.3/user-management/ldap-sync/) feature.

By Mohib Zico staff 21 Nov 2021 at 10:17 p.m. CST

Mohib Zico gravatar
Hi, Please reopen the ticket if required. Thanks!