From c08641160f8c61560dd6a938c2d70fadef9be714 Mon Sep 17 00:00:00 2001 From: Evan Broder Date: Sun, 10 Jan 2010 02:49:14 -0500 Subject: [PATCH] Add a section on "Future Directions" for the Invirtibuilder. svn path=/trunk/packages/invirt-dev/; revision=2869 --- README.invirtibuilder | 41 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) diff --git a/README.invirtibuilder b/README.invirtibuilder index 6ba5124..0a853bf 100644 --- a/README.invirtibuilder +++ b/README.invirtibuilder @@ -334,11 +334,51 @@ or by using a more isolated build mechanism (e.g. qemubuilder_). However, we decided that the security risk didn't justify the additional implementation effort or runtime overhead. +Future Directions +================= + +While the Invirtibuilder was written as a tool for the Invirt_ +project, taking advantage of infrastructure specific to Invirt, it was +designed with the hope that it could one day be expanded to be useful +outside of our infrastructure. Here we outline what we believe the +next steps for development of the Invirtibuilder are. + +One deficiency that affects Invirt_ development already is the +assumption that all packages are Debian-native [#]. Even for packages +which have a non-native version number, the Invirtibuilder will create +a Debian-native source package when the package is exported from Git +as part of the `Build Execution`_. Correcting this requires a means to +find and extract the upstream tarball from the Git repository. This +could probably be done by involving the pristine-tar_ tool. + +The Invirtibuilder is currently tied to the configuration framework +developed for the Invirt_ project. To be useful outside of Invirt, the +Invirtibuilder needs its own, separate mechanism for providing and +parsing configuration. It should not be difficult to use a separate +configuration file but a similar YAML configuration mechanism for the +Invirtibuilder. And of course, as part of that process, filesystem +paths and the like that are currently hard-coded should be replaced +with configuration options. + +The Invirtibuilder additionally relies on the authentication and +authorization mechanisms used for Invirt_. Our RPC protocol of choice, +remctl_, requires a functional Kerberos environment for +authentication, limiting its usefulness for one-off projects not +associated with an already existing Kerberos realm. We would like to +provide support for some alternative RPC mechanism—possibly +ssh. Additionally, there needs to be some way to expand the build ACLs +for each pocket that isn't tied to Invirt's authorization +framework. One option would be providing an executable in the +configuration that, when passed a pocket as a command-line argument, +prints out all of the principals that should have access to that +pocket. + .. _config-package-dev: http://debathena.mit.edu/config-packages .. _fakeroot: http://fakeroot.alioth.debian.org/ .. _git-buildpackage: https://honk.sigxcpu.org/piki/projects/git-buildpackage/ .. _grsecurity: http://www.grsecurity.net/ .. _Invirt: http://invirt.mit.edu +.. _pristine-tar: http://joey.kitenet.net/code/pristine-tar/ .. _qemubuilder: http://wiki.debian.org/qemubuilder .. _remctl: http://www.eyrie.org/~eagle/software/remctl/ .. _SIPB: http://sipb.mit.edu @@ -354,3 +394,4 @@ justify the additional implementation effort or runtime overhead. create new tags for builds on pockets with ``allow_backtracking`` set to ``True`` either. .. [#] http://kerneltrap.org/Linux/Abusing_chroot +.. [#] http://people.debian.org/~mpalmer/debian-mentors_FAQ.html#native_vs_non_native -- 1.7.9.5