Description of problem: When build a maven deployment; the host has a umask of: 0077 fabric8 build process creates the tarball with 700 which is unusable in the pod as the pod was run with an arbitrary UID. Version-Release number of selected component (if applicable): How reproducible: This problem occurs when following the documentation at this link (https://docs.openshift.com/enterprise/latest/using_images/xpaas_images/fuse.html) for working with the Fuse XPaas image. The archetype that we picked to build was the "karaf-camel-log-archetype". We followed the steps to create the application from the maven archetype catalog which are summarized below: Steps to Reproduce: 1. $ oc new-project fabric8 2. $ export KUBERNETES_MASTER=https://cloudapps.com:8443 3. $ export KUBERNETES_DOMAIN=cloudapps.com 4. $ mvn -Pf8-deploy -Ddocker.registry=registry.cloudapps.com:443 -Ddocker.username='test' -Ddocker.password=test -D docker.host=http://localhost:2375 Actual results: The image when run as an arbitrary fails due to a permission problem (see below). Checking for *.tar.gz in /deployments tar (child): /deployments/ose-fuse-example-1.0-SNAPSHOT.tar.gz: Cannot open: Permission denied tar (child): Error is not recoverable: exiting now tar: Child returned status 2 tar: Error is not recoverable: exiting now sed: can't read /deployments/karaf/etc/org.ops4j.pax.logging.cfg: No such file or directory Executing /deployments/karaf/bin/karaf server ... /usr/local/s2i/run: line 16: /deployments/karaf/bin/karaf: No such file or directory Expected results: * the Maven job should check what the umask setting is or * if Maven creates a tarball that has 0700 permissions, it should change it to something that would be usable by ANY UID - perhaps it should default to setting a usable permission regardless. Additional info: The workaround is to do a "umask 0022" so that the arbitrary user running the image has access to the tar file.
Which version of the archetype did you use ? (2.2.0.redhat-621030 ?)
Currently I'm struggling with downloading the proper archetype, the one I get following the referenced documentation doesn't look up-to-date to the latest release. Would be good if I would know the exact version of the archetype used so that I can reproduce it. btw, the build flow used here doesn't involve s2i at all, the only s2i relevance is that a hybrid base image is used. So the subject of this issue might be a bit misleading.
(In reply to Roland Huss from comment #2) > Currently I'm struggling with downloading the proper archetype, the one I > get following the referenced documentation doesn't look up-to-date to the > latest release. Would be good if I would know the exact version of the > archetype used so that I can reproduce it. > > btw, the build flow used here doesn't involve s2i at all, the only s2i > relevance is that a hybrid base image is used. So the subject of this issue > might be a bit misleading. Please find following response from customer and let me know if other info are needed, thanks: I didn't make a note of exactly which version was used, but it was either 2.2.0.redhat-079 or 2.2.0.redhat-621030.
ok, must be 2.2.0.redhat-079 since 2.2.0.redhat-621030 doesnt contain any profiles. I wonder, how this repo could be cleaned up a bit ?
Sorry, I'm still struggling in reproducing it. When using the 2.2.0.redhat-079 archetype, the it refers to a none existing base image 'jboss-fuse-6/fis-karaf-openshift:1.0'. I don't think thats the final archetype version. Could you please post the pom.xml which you used ?
Created attachment 1137641 [details] pom.xml
Please find (In reply to Roland Huss from comment #5) > Sorry, I'm still struggling in reproducing it. When using the > 2.2.0.redhat-079 archetype, the it refers to a none existing base image > 'jboss-fuse-6/fis-karaf-openshift:1.0'. I don't think thats the final > archetype version. > > Could you please post the pom.xml which you used ? Please find pom.xml attached. Thanks.
Thanks. According to the pom.xml its 2.2.0.redhat-079 I tried to reproduce the issue, however it seems to work for me. Here is how the /deployment directory looks like when the Pod is running: sh-4.2$ ls -l . total 20976 drwxr-xr-x. 8 1000040000 root 87 Mar 18 09:26 demo-1.0-SNAPSHOT -rw-r--r--. 1 jboss jboss 21474006 Mar 18 09:24 demo-1.0-SNAPSHOT.tar.gz -rwxrwxrwx. 1 jboss jboss 724 Mar 1 03:36 deploy-and-run.sh lrwxrwxrwx. 1 1000040000 root 30 Mar 18 09:25 karaf -> /deployments/demo-1.0-SNAPSHOT sh-4.2$ so here the tar archive is 644. How does it look like for you ? Also, in the build could you please do a ls -lR target/docker/| grep \\.tar and post the output ? What umask do you have before calling Maven ? When I deliberately set this to `umask 0777` then I can't even build, so I wonder how this non-readable tar.gz could happen for you. Last question: On which platform are you building (Linux / OSX / Windows) ?
Could you please help me ? I really can't reproduce it here. The "/deployment" directory has deliberately 777 as permission so extracting should (and is not) a problem. If you are running on Windows, could you please try to insert a `<mode>tar</mode>` in the `<assembly>...</assembly>` section in the pom.xml ? thanks ... ... roland
(In reply to Roland Huss from comment #8) > Thanks. According to the pom.xml its 2.2.0.redhat-079 > > I tried to reproduce the issue, however it seems to work for me. > > Here is how the /deployment directory looks like when the Pod is running: > > sh-4.2$ ls -l . > total 20976 > drwxr-xr-x. 8 1000040000 root 87 Mar 18 09:26 demo-1.0-SNAPSHOT > -rw-r--r--. 1 jboss jboss 21474006 Mar 18 09:24 demo-1.0-SNAPSHOT.tar.gz > -rwxrwxrwx. 1 jboss jboss 724 Mar 1 03:36 deploy-and-run.sh > lrwxrwxrwx. 1 1000040000 root 30 Mar 18 09:25 karaf -> > /deployments/demo-1.0-SNAPSHOT > sh-4.2$ > > so here the tar archive is 644. How does it look like for you ? Also, in the > build could you please do a > > ls -lR target/docker/| grep \\.tar > > and post the output ? > > What umask do you have before calling Maven ? > > When I deliberately set this to `umask 0777` then I can't even build, so I > wonder how this non-readable tar.gz could happen for you. > > Last question: On which platform are you building (Linux / OSX / Windows) ? The default umask is 0077. Here the output with that umask $ ls -lR target/docker/| grep \\.tar -rw-------. 1 buckm buckm 38917226 Mar 23 17:04 fuse-1.0-SNAPSHOT.tar.gz -rw-------. 1 buckm buckm 38922240 Mar 23 17:05 docker-build.tar And here's how it looks with umask 0022 $ ls -lR target/docker/| grep \\.tar -rw-r--r--. 1 buckm buckm 38917228 Mar 22 15:23 fuse-1.0-SNAPSHOT.tar.gz -rw-r--r--. 1 buckm buckm 38922240 Mar 22 15:23 docker-build.tar You can see the difference, that it's world-readable only with the umask change. I cannot show you the permissions inside the running pod with the default umask because it terminates, but I think the issue is clear from what I've provided above. Lastly, I'm running this on a RHEL7 linux VM.
Ok, got it. The fix is simple and needs an adaption of the archetype. In the configuration section the fileMode needs to be set explicitely: <inline ...> <id>${project.artifactId}</id> <files> <file> <source>${project.build.directory}/${project.artifactId}-${project.version}.tar.gz</source> <fileMode>0644</fileMode> <outputDirectory>/</outputDirectory> </file> </files> </inline> I can fix this upstream but have no idea how this get into the product and which buttons needs to be pushed. Any idea ?
BTW, only the Karaf based archetypes should be affected, the others already have the permission set explicitly.
The upstream fix is in this PR https://github.com/fabric8io/ipaas-quickstarts/pull/1191 (which will be applied tomorrow after some review)
Fix has been merged in both branches, redhat and master. What are the next steps ?
Verified on Karaf FIS archetypes versions 2.2.0.redhat-085 all declare <fileMode>0644</fileMode>