Attempting to upgrade to 4.2

By: Shaun Walker named 31 Jul 2020 at 12:20 a.m. CDT

16 Responses
Shaun Walker gravatar
Hi Team, Have attempted an upgrade from 4.1 to 4.2 on our development environment before tackling our others. I seem to have come across an issue in related to java after the upgrade is run. when I try to run anything Java based I get a similar message to the following: /opt/opendj/bin/../lib/_server-script.sh: /opt/jre/bin/java: /lib/ld-musl-x86_64.so.1: bad ELF interpreter: No such file or directory My understanding is that is available as RPM packages for Fedora, but are not EPEL ready for RHEL https://src.fedoraproject.org/rpms/musl We are attempting to yum install it manually, else we will try and compile it in, but thought I would note this for others, just incase there is a way for this to be checked and/or added to the upgrade script for 4.2 Cheers, Shaun
Rhel 7.8
closed

Answers

By Mohib Zico staff 31 Jul 2020 at 1:28 a.m. CDT

Copy
Mohib Zico gravatar
Hi Shaun, Thanks much for knowledge sharing. @Davit.Nikoghosyan: can we cover this situation in RHEL upgrade?

By Shaun Walker named 31 Jul 2020 at 1:32 a.m. CDT

Copy
Shaun Walker gravatar
Hi Mohib, Thanks for your response. Unfortunately not much luck. I did however try with the rpm's here https://docs.aws.amazon.com/corretto/latest/corretto-11-ug/generic-linux-install.html Which worked once i symlinked over the one added by the installer, however i still end up with a broken upgrade as I need to inject this part way through the upgrade.

By Mohib Zico staff 31 Jul 2020 at 1:37 a.m. CDT

Copy
Mohib Zico gravatar
Shaun, That's bummer! How we can we try to reproduce the issue? In below way? - Install a Gluu Server 4.0 in RHEL7 - Try to upgrade that to 4.1 by followin Gluu official doc?

By Shaun Walker named 31 Jul 2020 at 1:47 a.m. CDT

Copy
Shaun Walker gravatar
Not a worry :) I started with 4.1 on RHEL 7, and then performed the upgrade to 4.2. I tried on our dev env first (standalone) (got in trouble by some of the devs for breaking it and had to rollback the snapshot of the server :)) and then tried on another instance we have that is in a self configured cluster. Both had the same issue, but I didnt realise what the problem was until i dug deeper and noticed an issue with the corretto install. I have a feeling once this does upgrade properly, i will need to tweak the upgrader on our test cluster as some steps wont need to be done twice. That's for another day!

By Mohib Zico staff 31 Jul 2020 at 1:51 a.m. CDT

Copy
Mohib Zico gravatar
Thanks, much! @Mohit.Mali: Can we please try to upgrade a 4.1 to 4.2 in RHEL7? See how things go.

By Mohit Mali staff 31 Jul 2020 at 2:04 a.m. CDT

Copy
Mohit Mali gravatar
ok let me check the upgrade from 4.1 to 4.2 on rhel7. thanks and regards Mohit Mali

By Mohit Mali staff 04 Aug 2020 at 8:42 a.m. CDT

Copy
Mohit Mali gravatar
Hi All, I have tested the upgrade from 4.1 to 4.2 on rhel 7 its working fine for me. Script works fine. Thanks and Regards Mohit Mali

By Shaun Walker named 04 Aug 2020 at 5:43 p.m. CDT

Copy
Shaun Walker gravatar
Hi Mohit, I had another look at the Amazon Corretto download link. Previously it redirected and downloaded **amazon-corretto-11.0.8.10.1-alpine-linux-x64.tar.gz**, this time it downloaded **amazon-corretto-11.0.8.10.1-linux-x64.tar.gz** I wonder if there was a change made to correct this on the Amazon side? I tried looking it up, and only saw reference of a similar issue a while ago. I will give the upgrade another try today and see if it is more successful.

By Shaun Walker named 05 Aug 2020 at 7:54 p.m. CDT

Copy
Shaun Walker gravatar
Hi Team, Just confirming that we attempted another upgrade today of our dev environment and it all looked good. Will make a note our end to test corretto links to make sure they download the right version if we find issues in other servers. Thanks again for all your help! Now to try this on our cluster install :) Cheers, Shaun

By Shaun Walker named 06 Aug 2020 at 8:45 p.m. CDT

Copy
Shaun Walker gravatar
Hi Team, Apologies for re-opening. After the upgrade I noticed that SCIM was gone (I can see its now seperate). During the running of the `python3 post-setup-add-components.py -addscim` i ran into a problem where /opt/dist/gluu/scim.war did not exist. I could not see this come down as part of the upgrade process? Regardless, I downloaded the latest 4.2 version of scim from https://ox.gluu.org/maven/org/gluu/scim-server/4.2.0.Final/ and created a scim.service, re-ran the post setup script and it is now running. Should we expect these files to exist in the upgrade, or should I create a post-upgrade script for my end to run on our other environments? I have noted that casa appears to have stopped working as well with a handshake error, i'll be looking into that now and relay my feedback on that if that is ok. Cheers, Shaun

By Mohib Zico staff 07 Aug 2020 at 1:05 a.m. CDT

Copy
Mohib Zico gravatar
Hi Shaun, >> During the running of the python3 post-setup-add-components.py -addscim Honestly speaking I don't remember supporting SCIM post installation. Do you have any doc/link which showing the procedure?

By Shaun Walker named 07 Aug 2020 at 1:10 a.m. CDT

Copy
Shaun Walker gravatar
Hi Mohib, Going from the documentation https://gluu.org/docs/gluu-server/4.2/4.x-intro/#scim-is-now-a-separate-component-in-the-gluu-server "SCIM is now a separate component in the Gluu Server" I noticed that after the upgrade the SCIM install that I had, stopped working, hence tried going through https://gluu.org/docs/gluu-server/4.2/user-management/scim2/#installation

By Mohib Zico staff 07 Aug 2020 at 1:14 a.m. CDT

Copy
Mohib Zico gravatar
Ah! ok. If there is issue with SCIM breaking after upgrade, we need to fix that then. From which version you performed upgrade?

By Shaun Walker named 07 Aug 2020 at 1:20 a.m. CDT

Copy
Shaun Walker gravatar
Yep, was going from 4.1.0 to 4.2. Further notes, during the upgrade it would be nice if it did the following: * Added in any optional module war files into /opt/dist/gluu/ (this is where scim.war was missing) * Update the /install/community-edition-setup path (I has to run the script from the ces_current folder that it created as part of the upgrade), the existing setup folder had the old 4.1 files * I also noted that scim.service did not exist either, so it failed when trying to run self.installJettyService I did also have a problem with casa post upgrade, showing this error, however I have not logged into it yet ``` RESTEASY004655: Unable to invoke request: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target ``` I hope this is helpful, if there is any other information you require, happy to assist.

By Mohib Zico staff 07 Aug 2020 at 1:43 a.m. CDT

Copy
Mohib Zico gravatar
Thanks!

By Shaun Walker named 11 Aug 2020 at 7:40 p.m. CDT

Copy
Shaun Walker gravatar
Also just noticed this https://github.com/GluuFederation/community-edition-package/commit/1f93faa1e7c2e18d97706007506f7b015987ae73 Looks like the corretto url was changed in the installer after my first attempt, that would explain why it worked for Mohit, and for myself later.

Post an answer