lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 20 Aug 2016 22:55:10 -0400 From: Theodore Ts'o <tytso@....edu> To: Dmitry Monakhov <dmonakhov@...nvz.org>, linux-kernel@...r.kernel.org Subject: Re: [PATCH 6/6] Add dockerfile Ok, I've checked in a Dockerfile into the xfstests-bld repository, and played with it some, and I have a couple of observations: First of all, despite some work cleaning up the Dockerfile, the resulting image is somewhere between 150% and 200% larger than what it would be if we build root_fs.img outside of the Docker. A bunch of the wasted space is simply because we have to include a 47 MB xfstests.tar.gz file which then has to get re-inserted into the root_fs image via the --update-xfstests command line. Secondly, as an automated build procedure, it's rather lacking in two ways. First, it doesn't do the gen-image step, and secondly it only builds the 64-bit x86_64 binaries --- and I normally like to use the 32-bit i386 image, since that can be used to test 32-bit and 64-bit binaries, and it also forces us to test the 32/64-bit ioctl compat code. So it's really only useful as a CI mechanism --- and in order to use it I have to give Docker read/write access to my github repositories. I might consider creating a throwaway github repository on bitbucket just for the CI effort, but it's not high on my priority list, since it doesn't test the gen-image part of the build process. Third, it's a bit more inconvenient to use than the comments in your Dockerfile would imply. The command: docker run -i -t --privileged --rm dmonakhov/xfstests-bld \ kvm-xfstests.sh --kernel /tmp/bzImage --update-files --update-xfstests-tar smoke ... won't work because the docker because the image won't have /tmp/bzImage. So you would need to add "-v /tmp/bzImage:/tmp/bzImage" to the command line, making it even more unweildy. BTW, with changes I've just commited, we can drop the --kernel since we now default to ~/linux, and so the command would look like this: docker run -i -t -rm -v /build/ext4:/root/linux --privileged \ tytso/xfstests-bld kvm-xfstests --update-files --update-xfstests smoke So if I am going to publish something to the Docker Hub, it would an addition to my current release process, where I would build the root_fs using my existing Debian build chroots, and just create a minimal tytso/kvm-xfstests image which would just have the needed files, and would probably end up weighing in around 200-225 MB. The user wouldn't need to specify the --update-files and --update-xfstests flags, and it would start faster. On the other hand, I'm not at all convinced this is actually a great way to run kvm-xfstests; for one thing, the log file is trapped inside the Docker container, and so you would need to manually extract it in order to keep a history of past test runs. (This is also the challenge of just sharding the test runs; collating the test results becomes a big pain.) And the whole concept of running a VM inside a docker container reminds me a bit of the "Hitler uses Docker" rant at: https://youtu.be/PivpCKEiQOQ?t=2m27s I'm also not wild about encouraging people to run random Docker images they download over the network with docker run --privileged. That's right up there with running with scissors, encouraging people to give Docker read/write access to their github accounts, using the same password across hundreds of web sites, etc..... If the real goal is to allow people to shard the tests so it can be run across multiple VM's, it might be better to give kvm-xfstests some options so a different set of disks are used and either a different set of ports, or just network ports altogether. Cheers, - Ted
Powered by blists - more mailing lists