After performing a server migration on CLM 6.0.3 the Link Index Provider (LDX) application page reports an error
After migrating data (using repotools-<context> -export / -import) and performing the lqe.restore operation on the ldx backup data - the ldx page on the new server reports the following problem. I have generated new ldx backup data from the original server - and it seems to get restored (because the /metadata and /datasets folders are removed and the lqe.restore flag in the /conf/ldx/lqe.properties file is changed from true to false) but my new server is unusable due to this error.
Error Page Exception
SRVE0260E: The server cannot use the error page specified for your application to handle the Original Exception printed below.
Original Exception:
Error Message: javax.servlet.ServletException: java.io.IOException: org.apache.wink.json4j.JSONException: javax.crypto.BadPaddingException: Given final block not properly paddedError Code: 500
Target Servlet: GenericServletWrapper
Error Stack:
java.io.IOException: org.apache.wink.json4j.JSONException: javax.crypto.BadPaddingException: Given final block not properly padded
at com.ibm.team.jis.lqe.auth.inbound.InboundAuthFilter.doFilter(InboundAuthFilter.java:97)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:207)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91)
at com.ibm.team.jis.lqe.auth.inbound.ConfigModeBlockerFilter.doFilter(ConfigModeBlockerFilter.java:77)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:207)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91)
at com.ibm.team.jis.lqe.auth.inbound.ConfigModeAllowedFilter.doFilter(ConfigModeAllowedFilter.java:56)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:207)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91)
at com.ibm.team.jis.lqe.auth.inbound.UpgradeModeBlockerFilter.doFilter(UpgradeModeBlockerFilter.java:89)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:207)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91)
at com.ibm.team.jis.lqe.auth.inbound.UpgradeModeAllowedFilter.doFilter(UpgradeModeAllowedFilter.java:53)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:207)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91)
at com.ibm.team.jis.lqe.http.ClickjackPreventionFilter.doFilter(ClickjackPreventionFilter.java:90)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:207)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91)
at com.ibm.team.jis.lqe.http.GZipFilter.doFilter(GZipFilter.java:47)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:207)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91)
at com.ibm.team.jis.lqe.DefaultEncodingFilter.doFilter(DefaultEncodingFilter.java:34)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:207)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:1021)
One answer
I came across the following note that may pertain to this problem:
[from: https://jazz.net/help-dev/clm/index.jsp?re=1&topic=/com.ibm.team.jp.lqe2.doc/topics/t_lqe_upgrade.html&scope=null]
"New in version 6.0.3: ..., the lqe.key file is created in the
JTS_install_dir
/server/conf/lqe directory. This file stores the key for encrypting LQE and Link Index Provider (LDX) passwords and credentials. ...If you delete this file, or if you move the
JTS_install_dir
/server/conf/lqe directory without moving lqe.key, you get an error when you start LQE. To learn how to resolve the issue, read this troubleshooting article."
Comments
Daniel Barbour
Jan 11 '17, 11:33 a.m.Additional Information:
The problem is most easily recreated by simply generating the LDX (or LQE) backup files then restoring from the backup files. Specifically (for LDX):
a. Initiate a backup from https://<your URI>/ldx/web/admin/backup (for example - backup to C:\LDX)
b. Copy the \datasets and \metadata folders found under C:\LDX\Backup2017***\ to the <install location>\server\conf\ldx folder.
c. Edit lqe.properties in the above folder location to set "lqe.restore=true"
d. Restart the LDX server
After the server has restarted and completed restoring from the backup files (indicated with the \datasets and \metadata folders are no longer visible under the \server\conf\ldx folder) then open https://<your URI>/ldx/web/admin/home. For me the error page described above was presented (ditto for the LQE admin home page if the LQE backup data was restored).
Also note: This problem was observed in 6.0.3 for a server using the SQL Server DBMS but was NOT observed for an Express install (using the Apache Derby DBMS).
Daniel Barbour
Feb 24 '17, 10:45 a.m.The procedures to reproduce noted earlier were in error - it is not possible to observe this issue when when restoring from an LDX backup folders collected on the same machine.
Instead - the issue arises during a server migration activity from ServerMachine_A to ServerMachine_B. Prior to CLM 6.0.3 we were able to include the LDX/LQE backup data obtained from ServerMachine_A and restore them on ServerMachine_b after completing the steps to import the data migration files for the JTS/CCM/DCC/GC/RM/QM databases.
Now - however- it is necessary to either postpone the installation of the LDX/LQE applications until after the data for the other applications have been imported, OR to unregister LDX/LQE and then re-register them (followed by performing a complete index activity).
I have a work-around that will work for me - but am left with the question: Was this change (to eliminate the ability to include the LDX and LQE backup data as part of the data migration) deliberate, or accidental? If accidental I would ask that this be investigated because reindexing from scratch can take a very long time.