Running update with WDT fails using the zip installer
Omar007 opened this issue · 5 comments
Starting with Image Tool version 1.9.13, logic for running the Weblogic Deploy Tool was split out into a separate file (imagetool/src/main/resources/docker-files/run-wdt.mustache) and support was added for both the tar.gz as well as the zip package.
The core idea of this change is fine and using/switching to the tar.gz package works but in turn this also broke the use of the original zip package.
Looking at the history/change, the chmod that set the required permissions for WDT was originally in imagetool/src/main/resources/docker-files/Update_Image.mustache but was dropped/removed. Because a zip does not contain permission information, executing the WDT commands will now fail for this WDT release package. As a tar.gz does contain permissions, this is unaffected.
To fix this, if it enters the non-tar.gz case (thus zip), it should correct permissions directly after unzipping if the WDT zip package is supposed to be supported. (otherwise just require the tar.gz I suppose.)
TL/DR; starting with 1.9.13:
- update with WDT tar.gz package = OK
- update with WDT zip package = NOK
@Omar007 The ZIP file does contain the file permissions. The chmod was removed because the Dockerfile for UPDATE was changed to use unzip instead of jar. The jar command did not extract the file permissions, but unzip does.
I am able to create domains with: imagetool update --tag d:2 --fromImage d:1 --wdtModel ./simple1.yaml --wdtOperation CREATE and similar create commands. I am, also, able to use UPDATE with model-only and can see the correct execute permissions. I am testing with the latest versions of WIT (1.9.15) and WDT (1.9.16) using the WDT ZIP install.
I am not able to reproduce this issue.
This is the error we got when running 1.9.13 with WDT 1.9.16 using the zip. Switching to the tar.gz resolved this.
Step 11/20 : RUN unzip -q /tmp/imagetool/weblogic-deploy.zip -d /u01/wdt
---> Running in 61582456ab5e
Removing intermediate container 61582456ab5e
---> 7058edfcbb74
Step 12/20 : RUN cd /u01/wdt/weblogic-deploy/bin && ./createDomain.sh -oracle_home /u01/oracle -domain_home /u01/domains/base_domain -domain_type OAM -run_rcu -variable_file /u01/wdt/models/oam-domain.vars -model_file /u01/wdt/models/oam-domain.yaml && chmod -R g+w /u01/domains/base_domain
---> Running in bf1529595356
/bin/sh: ./createDomain.sh: Permission denied
And this is when we used the tar.gz:
Step 11/20 : RUN tar zxf /tmp/imagetool/weblogic-deploy.tar.gz -C /u01/wdt
---> Running in c64807848a70
Removing intermediate container c64807848a70
---> 0af8657f8144
Step 12/20 : RUN cd /u01/wdt/weblogic-deploy/bin && ./createDomain.sh -oracle_home /u01/oracle -domain_home /u01/domains/base_domain -domain_type OAM -run_rcu -variable_file /u01/wdt/models/oam-domain.vars -model_file /u01/wdt/models/oam-domain.yaml && chmod -R g+w /u01/domains/base_domain
---> Running in bcd74a7c2171
JDK version is 1.8.0_291-b10
JAVA_HOME = /u01/jdk
WLST_EXT_CLASSPATH = /u01/wdt/weblogic-deploy/lib/weblogic-deploy-core.jar
.....
If the zip does contain the permissions (therefore assuming it's packaged using/as an Info-ZIP) I'm not sure why it would be failing as that is the only related area I spotted atm around permissions that got dropped between 1.9.12 and 1.9.13.
That said, I also noticed that for the validation step, the permissions are still being explicitly set in run-wdt.mustache
(and the following line)
Based on your reaction this shouldn't not even be here either then right?
We ended up having to revert to 1.9.12 due to something else breaking with 1.9.13 but we still need to track that down so atm we are on 1.9.12 with 1.9.16's zip package (as 1.9.12 does not support the tar.gz) and that combination works perfectly fine.
EDIT: I just double-checked something else based on this:
The chmod was removed because the Dockerfile for UPDATE was changed to use unzip instead of jar. The jar command did not extract the file permissions, but unzip does.
As we are adding an OAM definition, this was done using jar as well. jar uf was used to add the typedef to the zip so if that breaks existing permissions, that could have been the source issue instead
Will have to verify that next week.
I am fairly certain that your issue was caused when you changed the ZIP with JAR. As I mentioned earlier, I replaced JAR with unzip because the permissions did not survive.
I tested with the same versions that you did, WIT 1.9.13 and WDT 1.9.16. With the released installer on GitHub, I am not able to reproduce any errors with WIT 1.9.13 or the current WIT release. I think that you will have a much better result if you use ZIP instead of JAR to add files to the WDT installer.
Just verified this. It was indeed caused by also using jar since that was already available. It doesn't just add the specified file, all permissions for all existing files reset. Closing this.