By: Sved Devs user 13 Jun 2020 at 11:02 a.m. CDT

6 Responses
Sved Devs gravatar
We are looking to migrate all data (users, clients, sectors, attributes etc) from our existing 3.1.5 final version to a new server where we installed 4.1. Since both systems used OpenDJ, we figured we could just export ldap data from our existing server using: `$ /opt/opendj/bin/export-ldif --port 4444 --hostname localhost --bindDN "cn=Directory Manager" --bindPassword [password_of_ldap_admin] --includeBranch o=gluu --backendID userRoot --ldifFile /tmp/backup_o_gluu_data.ldif --trustAll` and import the data into the new OpenDJ using: `$ /opt/opendj/bin/import-ldif --port 4444 --hostname localhost --bindDN "cn=Directory Manager" --bindPasswordFile /home/ldap/.pw --includeBranch o=gluu --backendID userRoot --ldifFile /tmp/backup_o_gluu_data.ldif --trustAll --clearBackend --rejectFile /tmp/rejected_data_why.ldif` But, when we do the import, we get the error: ``` root@idp:~# /opt/opendj/bin/import-ldif --port 4444 --hostname localhost --bindDN "cn=Directory Manager" --bindPassword xxxxxxxx --includeBranch o=gluu --backendID userRoot --ldifFile ~/backup_o_gluu_data.ldif --trustAll --rejectFile /tmp/rejected_data_why.ldif You have provided options for scheduling this operation as a task but options provided for connecting to the server's tasks backend resulted in the following error: 'The simple bind attempt failed' root@idp:~# echo $? 1 root@idp:~# ``` Any clue of why this is going wrong? Just to close the loop on other methods, we did try an in-place upgrade as suggested by the docs on a staging instance, but that never worked for us, so figured we could just install a new version on a server and copy the LDAP data and re-apply our customizations (login page) and JSON values. Any pointers are highly appreciated.

By Devrim Yatar staff 13 Jun 2020 at 2:12 p.m. CDT

Devrim Yatar gravatar
Hi Sved, You can't just export and import ldap entries. Use documentation to upgrade: https://gluu.org/docs/gluu-server/4.1/upgrade/ Regards.

By Sved Devs user 16 Jun 2020 at 2:09 p.m. CDT

Sved Devs gravatar
Thanks Mustafa, Followed your recommendation and made an in-place upgrade. The only changes I noticed right off the bat were: 1. The primary key changed back from mail to Uid (we changed it to mail in our previous version). 2. The service is still called gluu-service-3.1.5 and that script even marks the version as 3.1.5 (instead of 4.1.0). Is this expected? Thankfully all the customizations are still in place (albeit a bit distorted w.r.t. some images) that can easily be fixed.

By Devrim Yatar staff 18 Jun 2020 at 1:41 p.m. CDT

Devrim Yatar gravatar
Hi, 1) This is expected behavior, upgrade script set it to default in case of login failures 2) Yes container directory (and service) name is still 3.1.5. Upgrade script runs inside container, so it can't modify outside of the container. We document for changing container name: https://github.com/GluuFederation/support-docs/blob/77e9b8290ba1fbc0deefd1b8cb80d962029147d2/howto/upgrade/Change_container_name_after_upgrade.md

By Sved Devs user 18 Jun 2020 at 7:37 p.m. CDT

Sved Devs gravatar
Thank you for the response. Unfortunately, the link seems dead. I get a 404. Will dig around a bit to try and find that file. Thank you again.

By Devrim Yatar staff 19 Jun 2020 at 8:58 a.m. CDT

Devrim Yatar gravatar
Seems it is hidden, Here is the doc: # How to change container name after upgrade ## From 3.1.3 to 3.1.6 In Gluu Server version < 4.0, container names are unchanged after version upgrade. Say, if you upgraded your previously installed Gluu Server v3.1.3 to v3.1.6, your container name will be 'gluu-server-3.1.3' though you are running 3.1.6 inside. Here in this doc we are showing how you can change your container name in CentOS7x. - `/sbin/gluu-serverd-3.1.3 stop` - `/sbin/gluu-serverd-3.1.3 disable` - `mv /sbin/gluu-serverd-3.1.3 /sbin/gluu-serverd-3.1.6` - Change 'GLUU_VERSION' from 3.1.3 to 3.1.6 by `vim -N /sbin/gluu-serverd-3.1.6` - `mv /opt/gluu-server-3.1.3 /opt/gluu-server-3.1.6` - `cd /var/lib/container/ && ln -s /opt/gluu-server-3.1.6 gluu_server_3.1.6` - `rm gluu_server_3.1.3` - `mv /usr/lib/systemd/system/systemd-nspawn\@gluu_server_3.1.3.service /usr/lib/systemd/system/systemd-nspawn\@gluu_server_3.1.6.service` - `/sbin/gluu-serverd-3.1.6 enable` - `/sbin/gluu-serverd-3.1.6 start` ## From 3.1.1 to 4.0 - `/sbin/gluu-serverd-3.1.1 stop` - `/sbin/gluu-serverd-3.1.1 disable` - `mv /sbin/gluu-serverd-3.1.1 /sbin/gluu-serverd` - `Change 'GLUU_VERSION' from 3.1.3 to 4.0 by `vim -N /sbin/gluu-serverd` - `mv /opt/gluu-server-3.1.1 /opt/gluu-server` - `cd /var/lib/container/ && ln -s /opt/gluu-server gluu_server_4.0` - `rm gluu_server` - `mv /usr/lib/systemd/system/systemd-nspawn\@gluu_server.service /usr/lib/systemd/system/systemd-nspawn\@gluu_server_4.0.service` - `/sbin/gluu-serverd enable` - `/sbin/gluu-serverd start`

By Sved Devs user 19 Jun 2020 at 9:53 a.m. CDT

Sved Devs gravatar
Thank you Mustafa. Do you have s similar doc for Ubuntu as well? The service script in /etc/init.d/ might not even work properly if the above changes are made (for e.g. the detect_os function fails since there won't be any folder called /opt/gluu-server-4.1/etc/os-release when we rename the folder to /opt/gluu-server).