Autobuild support

[attilaolah]

This adds autobuild support for amd64 and amd64-hardened. To achieve this, the images are no longer based on draft, they are based on a simple busybox build now, gentoo/busybox. That image still needs to be built manually. See the new README file for details.

Note that the Busybox is built for amd64 (~amd64 to be precise), so the naming might have to change if we plan on supporting docker images on other architectures.

Also note that currently the stage tarballs are not verified against their signature — we are basically trusting the mirror, which might not be suitable for all.

[attilaolah]

I realise I haven't updated the main README yet, but I'd like to get some initial feedback on this first.

[attilaolah]

After some thinking, I'm not really convinced that this is a good idea, because:

• Images will not be tagged (they should be tagged with the stage3 build stamp or something).
• How do you tell Docker when to rebuild? It would be a waste to rebuild daily when there are no new stage3 tarballs available. Currently this would just rebuild the same image over and over.

[alunduil]

Hey @attilaolah,

I've been thinking about this (but haven't had time to act much). My thoughts are:

• docker hub should be able to automatically build a new image without a github change
• catalyst can be used to invoke a docker hub build after a stage3 is correctly prepared
• catalyst can tag the image with latest after the build as well (or a webhook or something)
• busybox should be built and added to a utility directory in the repository (yes I know that's anti-buildables)
• stage3 images should ADD the busybox that has been built
• the busybox binary can have a checksum, signature, etc if necessary

Let me know if you have any other thoughts. Feel free to move this discussion to gentoo-containers@lists.gentoo.org if you feel it's appropriate.

[attilaolah]

• busybox should be built and added to a utility directory in the repository (yes I know that's anti-buildables)
• stage3 images should ADD the busybox that has been built

I hear you. I can add my own .tbz to the repo if that helps (and you trust me enough not to put any backdoors in it). You can replace it later if you want to be safe.

All other points should already be doable with the current branch. I'll mention this on the mailing list or the IRC channel some time tonight.

[attilaolah]

I thought the recent stage3 tarballs come with systemd (and no openrc).

[alunduil]

Nope, the default RC system is–and probably will be for some time–openrc.

[alunduil]

Why would we have a tarred version of buxybox rather than a statically linked version? What's missing from the busybox base image to require us to build our own? We can validate the build process by creating a checksum that shouldn't change between builds. Thus, a person can validate this source gives me the given binary (all they could do anyway).

[attilaolah]

The busybox base image is not statically linked, it is dynamically linked.

Moreover, the base directory layout in the busybox base image has the lib links the other way around, opposite to how we have them in the stage3 tarball.

• BusyBox:
  • /lib is a dir
  • /lib64 is a symlink to lib
• stage3 tarball:
  • /lib is a symlink to lib64
  • lib64 (and lib32 for that matter) are directories

This makes it impossible to unpack the tarball, without "swapping" the directories first. But with only a dynamically linked busybox in /bin, one cannot remove /lib, because busybox (the only binary in the container) stops working, and we can not re-link the proper directories any more.

This, in short, is why we need a statically built busybox to start with. Also, our busybox does not have the /lib weirdness in the first place, so even a dynamically built one would work, for that matter.

[attilaolah]

Why would we have a tarred version of buxybox rather than a statically linked version?

Aah. You mean, why don't we just build a statically linked busybox, put it in the repo, and ADD it to the base image, so it can untar itself — I see your point now. Indeed, that would be a better idea.

We might need a few more files to get started, namely /etc/resolv.conf so we can wget the stage3 tarball. But everything else should be fine. No need, just a barebones /bin/busybox is enough.

Let me make those changes & rebase this branch.

[attilaolah]

OK, this still needs a rebase, but there is no intermediate busybox image any more. However, there are still a few quirks:

• amd64 and amd64-hardened directories only differ by a single line
• I had to copy the busybox and udhcpcd.conf files to both directories, because Docker does not allow access to outside of the docker directory

[alunduil]

Sounds good. Let's put your changes into amd64/stage3/Dockerfile and the busybox binary into busybox/. This way we can use the same busybox binary in all stage3 images we create. Also, let's get amd64 working before we worry too much about hardened (I'll want it but if it becomes more than a one line difference you can leave it to the next pull request). Also, we'll want a build script that repeatably builds busybox and generates the checksums (all in busybox/ of course). The source should be stored in busybox/src. Should we use a submodule for this so we can easily pin and update it without wasting too much space on blobs?

[attilaolah]

Submodule sounds good.

Build script will be a bit tricky (crossdev tends to be a little fragile for me) but I'll give it a try.

I'm a bit busy right now with the @gophergala going on, but I'll move around the files on Monday. Thanks so much for the feedback, hoping to get this working soon!

[alunduil]

No rush, get to it when you can. Why do we need to use crossdev to build busybox?

[attilaolah]

Why do we need to use crossdev to build busybox?

Because we need one that is statically linked against something other than GNU libc. I used uClibc, but musl would probably also work. I don't know how to do that without crossdev.

[ChaosEngine]

We can use official latest binary (statically linked) from http://www.busybox.net/downloads/binaries/latest/
I have some good experience with it.

[attilaolah]

Actually, we could. Let me update this PR.

[tianon]

Those binaries look really outdated to me; 2013...

[attilaolah]

Those binaries look really outdated to me; 2013...

That's not a problem as long as they work. We only need them to unpack the stage3 tarball, which would contain a newer busybox anyway, which we can use to replace this old one.

[alunduil]

+1 @attilaolah

[tianon]

Ah, that makes sense. 👍

[attilaolah]

OK my first tests have shown that the "official" binaries work. We should just stick to them for the initial unpacking stage then.

I'll update this PR.

Unfortunately however, it seems we will still need to "vendor" those binaries here in the repo to have the autobuilds working.

If I do this in the Dockerfile:

ADD http://www.busybox.net/downloads/binaries/latest/busybox-x86_64 /bin/busybox

…I don't get the right file permissions, the binary will not be executable. And we have no chmod command in the DRAFT container.

If I do this:

ADD http://www.busybox.net/downloads/binaries/latest/busybox-binaries.tar.bz2 /bin

…it still won't work because recent Docker versions will not unpack archives coming from remote locations. Bummer.

I'll follow @alunduil's suggestions and put the binary under something like /busybox/busybox in the repo root, with a short README.md to explain why is that there.

I'll also drop the hardened changes from this PR to make things simpler so we can finally move forward with this.

[ChaosEngine]

@attilaolah I have managed to overcome this. I will do another PR. It might be easier to look at.

[attilaolah]

Thanks @ChaosEngine — let's see what you have 😄

[alunduil]

@attilaolah, can you see how this work merges with @ChaosEngine's work and update this pull request appropriately? Thanks.

[mrueg]

I've changed the way the images are build, so this is not required anymore.