Thanks,
Kurt

> The goal of mock is to have the system setup in a way that there is absolutely nothing that is shared between the build environment and the host. Because the environment is rebuilt per-build, nothing would be shared outside of the sandbox.

I assume this was in response to my comment on splitting up L1 and L3 access instead of production vs Try access? Sharing nothing is great for repeatable builds, but chroot still seems to me (IMHO) to be pretty weak as a security boundary. I understand the appeal of having a single pool of Linux slaves, but breaking out of a chroot just isn’t that hard, and I’d like the barrier to getting L1 access to be as low as possible. If the damage an L1 committer can do is limited to a separate pool of physical machines, then we can hand out those rights more freely. (Or at least separate VMs, which are far better for security than chroot jails, but still aren’t really meant for that purpose.)

The goal of mock is to have the system setup in a way that there is absolutely nothing that is shared between the build environment and the host. Because the environment is rebuilt per-build, nothing would be shared outside of the sandbox.

I don’t have a full set of instructions for setting up mock_mozilla because its very early stage. I’ll spin up a VM to check that the build process works properly. I do know that I run the configure stuff, but use the test.sh script inside of the repo for building and installing. A lot of this is hacky code I am using to make development faster. Please file issues in github with any issues you have, and a solution if you have it! If you don’t do github, I’m in #build and i sometimes read blog comments.

Thanks for your interest in testing. I

Merging the try builders with the production builders doesn’t sound so nice from a security point of view — you’re merging L1 access jobs with L3 access jobs. Have you considered partitioning pools by the access level of the pusher? Then production jobs and most try jobs could share a large pool, and the subset of try jobs pushed by L1 committers would share a small pool. (To avoid having two classes of performance, it would be nice if the buildbot scheduling doohickey could dynamically adjust the pool sizes. Except you’d probably want to wipe the machines when transitions L1 -> L3. If that isn’t too horribly expensive?)

I’m ignoring L2 because it’s kind of pointless. Though it might make sense to split out production builds (beta/aurora/nightly) from mozilla-central and friends.

Do you have instructions for how I could try this out? I’m on Fedora 14. I cloned your github thing, I have mock installed already, I installed fedora-packager. I did ./autogen.sh, make rpm, and installed the resulting rpm. I ran sh poc.sh, but it keeps wanting me to authenticate as root, and it’s looking for /builds/targets/mozilla-f15-x86_64//builds//mozilla-central/.mozconfig. Do you have complete instructions anywhere, or should I just keep plowing through?

Thanks!

There is http://people.redhat.com/~rjones/febootstrap/ , but aiui, its a tool for creating appliances instead of general purpose environments.

Sadly, if they exist, they’re not turning up in the Google searches I’ve thought to try.

(debootstrap is included in the Portage tree and makes setting up a base debian chroot as simple as sudo debootstrap squeeze /chroots/debian_squeeze.)