Bug 1316747
Summary: | Umask affecting S2I build results | ||||||
---|---|---|---|---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Qi Yong <yoqi> | ||||
Component: | Fuse | Assignee: | Roland Huss <rhuss> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | David Simansky <dsimansk> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 3.0.0 | CC: | aos-bugs, bparees, erich, maschmid, vlaad, wili | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2022-08-25 20:20:10 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Qi Yong
2016-03-11 01:41:19 UTC
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> |