Open jovizhangwei opened 6 years ago
root@zz:~# oci-image-tool create --ref latest tomcat /mnt/nas/tomcat-bundle
root@zz:~# ls /mnt/nas/tomcat-bundle
config.json rootfs
I tried and didn't fail. Are you the latest version?
lab:/home/oci # mkdir tomcat-bundle
lab:/home/oci # oci-image-tool create --ref latest tomcat tomcat-bundle
each ref must contain two parts
lab:/home/oci # oci-image-tool create --ref platform.os=linux tomcat tomcat-bundle
lab:/home/oci # ls tomcat-bundle/
config.json rootfs
oci-mage-tool create requires --ref in format A=B
I'm getting this failure as well. Pulled fresh from master (c95f76cbae7433449f3a09f329ef816a1a0d16b3)
[root@beater ~]# skopeo copy docker://docker.io/httpd oci:httpd
Getting image source signatures
Copying blob sha256:f189db1b88b3cab5fd17f74fee412610fe40d4b077e7882c1a50a8b6f4f0cea3
51.74 MB / 51.74 MB [======================================================] 0s
Copying blob sha256:ba2d31d4e2e7f55fddfd4e376574bf249ed7e26a2f7ab8146beb8794e403ba7e
224 B / 224 B [============================================================] 0s
Copying blob sha256:23a65f5e37464800174de1d15a6b79dda2c7616c83ed7c8f41d1610b9faa2b9b
156 B / 156 B [============================================================] 0s
Copying blob sha256:5e8eccbd4bc65e169434d419b56b0e2d44646b3e8f5747264e981a59c6d96e5b
343 B / 343 B [============================================================] 0s
Copying blob sha256:4c145eec18d8f84de80687e8d35df1f58674f84d14a0d898505075680fd17e3e
11.20 MB / 11.20 MB [======================================================] 0s
Copying blob sha256:1c74ffd6a8a2142d3119dd7028ca56470ccc0b02c895534c629deee0b4f9f5ca
2.85 MB / 2.85 MB [========================================================] 0s
Copying blob sha256:1421f0320e1bd8fc11c38589a1b3d69440170c010b16e1c49dd8fc058a170d34
299 B / 299 B [============================================================] 0s
Copying config sha256:00286ff16ac431de216b89ee238f49178cd0b24e3992b9a15d63cd9c7c9be6f5
6.65 KB / 6.65 KB [========================================================] 0s
Writing manifest to image destination
Storing signatures
[root@beater ~]# oci-image-tool unpack --type imageLayout --ref digest=sha256:1e96efbd4f82a8a279e04b383037c5033c1c06a2330a0c3c2b9f65dfc85017e0 ./httpd/ ./httpd-bundle/
invalid symlink "httpd-bundle/bin/dnsdomainname" -> "hostname"
unpack: error extracting layer
github.com/opencontainers/image-tools/image.unpackManifest.func2
/tmp/tmp.VAyfyyPKvh/src/github.com/opencontainers/image-tools/image/manifest.go:110
github.com/opencontainers/image-tools/image.(*pathWalker).find
/tmp/tmp.VAyfyyPKvh/src/github.com/opencontainers/image-tools/image/walker.go:242
github.com/opencontainers/image-tools/image.unpackManifest
/tmp/tmp.VAyfyyPKvh/src/github.com/opencontainers/image-tools/image/manifest.go:108
github.com/opencontainers/image-tools/image.unpack
/tmp/tmp.VAyfyyPKvh/src/github.com/opencontainers/image-tools/image/image.go:205
github.com/opencontainers/image-tools/image.UnpackLayout
/tmp/tmp.VAyfyyPKvh/src/github.com/opencontainers/image-tools/image/image.go:151
main.unpackAction
/tmp/tmp.VAyfyyPKvh/src/github.com/opencontainers/image-tools/cmd/oci-image-tool/unpack.go:72
github.com/opencontainers/image-tools/vendor/github.com/urfave/cli.HandleAction
/tmp/tmp.VAyfyyPKvh/src/github.com/opencontainers/image-tools/vendor/github.com/urfave/cli/app.go:485
github.com/opencontainers/image-tools/vendor/github.com/urfave/cli.Command.Run
/tmp/tmp.VAyfyyPKvh/src/github.com/opencontainers/image-tools/vendor/github.com/urfave/cli/command.go:193
github.com/opencontainers/image-tools/vendor/github.com/urfave/cli.(*App).Run
/tmp/tmp.VAyfyyPKvh/src/github.com/opencontainers/image-tools/vendor/github.com/urfave/cli/app.go:250
main.main
/tmp/tmp.VAyfyyPKvh/src/github.com/opencontainers/image-tools/cmd/oci-image-tool/main.go:63
runtime.main
/home/vbatts/go1.11/src/runtime/proc.go:201
runtime.goexit
/home/vbatts/go1.11/src/runtime/asm_amd64.s:1333
Okay, so basically the issue is that the symlink handling is quite seriously incorrect. It assumes that all symlink targets are relative to the link name (this is only true for relative symlinks -- in this case it isn't an issue though) and also it appears that there's something wrong with how paths are handled.
The failure is that filepath.Join(filepath.Dir(path), hdr.Linkname)
doesn't have a prefix of dest
but path := filepath.Join(dest, header.Name)
. I can imagine that a header.Name
with ..
would easily break this sort of thing, but the image doesn't do this -- from looking at the umoci logs it's just an ordinary symlink.
[If you need to use an image tool which has more extensive testing and hopefully is more resilient I would recommend using umoci
which has no problem extracting this image. (Disclaimer: I wrote umoci.)]