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
