While troubleshooting an issue for some of our customers, we encountered a problem where the container-create-ssh command failed. Looking at the remote container installation, we could see that the permissions on the executables in the bin directory were not marked as executable. This step occurs further down in the script.

Looking closer, we identified that the unzip process seemed to hang. At one point killing the command, we noticed a prompt message in the log:

Archive: fabric8-karaf-1.2.0.redhat-133.zip
replace fabric8-karaf-1.2.0.redhat-133/licenses/jibx.txt? [y]es, [n]o, [A]ll, [N]one, [r]ename:

As experiment, Paolo tried a nifty trick to rename the unzip command to unzip2 and create a simple shell script to pass in the -o operation:

unzip:

#!/bin/bash
unzip2 -o "$@"

The containers provisioned correctly from here.

It is not clear exactly why this environment was behaving in this way. We could certainly see files had been extracted, however, to safeguard others from encountering this issue, we would like to add the -o option to the unzip step:

311 function extract_zip {
312   if ! which unzip &> /dev/null; then
313         jar xf $1
314   else
315        unzip $1  <=====
316   fi
317 }