Boxed Penguin Prototype showcases customization of Debian to build infrastructure server
In order to actually get something done in an electronic office, we
need a certain amount of infrastructure. In a large environment, the
incremental costs are somewhat visible, but you won't see how much
work it took to get there. In practice, starting from ground zero
means identifying a large collection of interesting subsystems, then
customizing each one, figuring out how to manage and maintain it,
deploying it, documenting local procedures and policies, and then
moving on to the next one. This turns out to be a huge amount of
one-time effort - which doesn't get streamlined or tuned, beyond
becoming part of a particular sysadmin's knowledge base.
Boxed Penguin (http://www.boxedpenguin.com/) hopes to come up with a
general open-source solution to this problem: we hope to construct a set of tools
that allow sites to easily and quickly deploy infrastructure.
We'd like to draw your attention to our initial prototype, based on
Debian GNU/Linux, available at our website. The prototype
demonstrates how a site could combine various components of Debian
together to set up an infrastructure. Kerberos acts as a central
authentication service. SASL and PAM are used to provide security to
applications like LDAP and IMAP. AFS is used as a secure,
distributed file system for the site's data. LDAP is used to provide
a means for distributing account information.
Most of the work in the prototype focused on integrating various
components. For example scripts are provided to create all the parts
of a user account: Kerberos authentication information, an LDAP
password entry, AFS volumes for home directories and an IMAP mailbox.
Other scripts provide manipulation of group data.
The other hard problem we attempted to solve was the integration of
the package installation. Because we were creating a unified
infrastructure, we knew more about the desired state of the system
than the author of any package. For example, we knew that LDAP would
be using Kerberos SASL for authentication and thus didn't need an
admin password. We wanted to turn this extra knowledge into a
simplified installation experience for our users. In most cases we
took advantage of Debconf and gave packages the hints we needed.
We hope that by bringing our prototype to the attention of the Debian
community, we can focus developer interest on problems that pop up
when you try and deploy Debian throughout a site or environment
instead of on a single machine. For example, while effective, our
technique of stuffing debconf configuration in the boxedp-assumptions
package could probably be replaced with a better-architected system
for providing additional information to packages about containing
frameworks. Also, we're interested in Debian's input on the problems
we are trying to solve and on how Debian can best be used to solve
these problems.
Thanks,
--Sam
Reply to: