[2288] in athena10
Re: DebConf9: Call For Papers (fwd)
daemon@ATHENA.MIT.EDU (Tim Abbott)
Wed Apr 15 15:45:14 2009
Date: Wed, 15 Apr 2009 15:44:49 -0400 (EDT)
From: Tim Abbott <tabbott@MIT.EDU>
To: Greg Price <price@mit.edu>
cc: debathena@mit.edu
In-Reply-To: <20090415085156.GZ21912@vinegar-pot.mit.edu>
Message-ID: <alpine.DEB.1.10.0904151405410.28335@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Okay, here's another draft (hopefully a bit better; but I'm very short on
time for this). Note deadline is in a few hours so I'll probably submit
the proposal in a couple of hours.
Title: Site configuration using config-package-dev
This talk will discuss the config-package-dev framework for creating
Debian configuration packages. Unlike many systems for managing
configuration, config-package-dev integrates with the packages manager to
suppport change defaults to those appropriate for the site instead of
taking on the role of the system administrator.
With config-package-dev, MIT has been able to provide site configuration
for multiple concurrent releases of both Debian and Ubuntu with limited
developer resources, and in a way that is sufficiently clean that hundreds
of MIT students have installed it on their personal laptops. This kind of
site distribution is a common need at many institutions, and I think MIT's
experience is a valuable case study for how integration with the package
manager can improve configuration management.
I'll discuss how config-package-dev and other Debian technology can be
used to create a maintainable site distribution like the one we have at
MIT, as well as highlighting some packaging practices that can help make
site extensions of Debian easier to build. I'll also briefly discuss some
other useful applications of config-package-dev.
-------
I think I may also try to host a BoF event in the "Debconf unofficial"
track to have more in-depth discussion of how configuration packages
should work with interested parties.
-------
quickly responding to Greg's comments: my main goal is to convince
developers that Debathena is a reasonable way to do things that they
should consider when making design decisions. I suspect it will be hard
to convince many people to actually deploy it themselves, since there's a
significant amount of work involved in doing so, the conference is not
huge (~300 people), and I'm not sure how many developers present would
actually be in a position to do so.
I'm trying to avoid having the talk sound like "how to use
config-package-dev", since I think Debian developers know how to read
documentation and this doesn't seem to be the flavor of proposals I see.
Thoughts?
-Tim Abbott
On Wed, 15 Apr 2009, Greg Price wrote:
> On Tue, Apr 14, 2009 at 12:58:06PM -0400, Tim Abbott wrote:
> > Title: Debian Configuration Packages
> >
> > The latest version of MIT's Athena platform, Debathena, is based on Debian
> > and Ubuntu. Unlike past versions of Athena, Debathena is actually a set
> > of packages maintained in near compliance with Debian policy, built for
> > all releases of Debian and Ubuntu currently supported upstream. This has
> > made Debathena very popular on laptops and other machines owned by
> > students and staff.
> >
> > A key innovation of Debathena is its configuration packages, which
> > configure services like Kerberos for use at MIT. Unlike many systems for
> > managing configuration, these packages are designed to provide site
> > defaults, not take the role of the system administrator. So, anyone at
> > MIT can install Debathena on top of their existing system via apt to
> > configure Athena services and install Athena-specific software, without
> > sacrificing their ability to customize their machine.
> >
> > In this session, I hope to briefly overview what we've done, and then have
> > a discussion of how Debian can make things like Debathena easier.
>
> What are the things you hope people will remember from this talk?
> Several that this abstract suggests are
> - tabbott/MIT does awesome things
> - config-package-dev is useful, I could try it
> - Debian maintainers could make their packages more flexible, here's how
>
> Those would all be nice, but perhaps the most general of them all --
> and therefore perhaps the most realistic for people to retain -- is
> - Awesome things can be done with Debian technology outside of Debian proper.
>
> If that one actually sticks with people, then they may make better
> decisions as they design their packaging and make other choices that
> impact the implementation of Debathena-like systems. If they remember
> that, and remember to look for config-package-dev if they ever want to
> do such awesome things themselves, then I think the talk has served
> its purpose well. (And if they remember your name, Athena's, or MIT's
> in connection with the awesomeness, then that's a bonus.)
>
> So one thing I'd like to have in the abstract is some mention of the
> general concept of Debian technology applied outside of Debian proper,
> of which Debathena is an example and for which config-package-dev is
> one tool. E.g. perhaps a new paragraph after the second one, saying
> that.
>
>
> You should definitely mention the name "config-package-dev" in the
> abstract, so people can make that connection and so web searches for
> config-package-dev might record that you gave a talk about it. You
> might consider also mentioning CDBS to similarly contribute to its
> record, though it's possible that the cost in people reacting
> unreasonably to the name "CDBS" would be too great.
>
> In the second paragraph I'd say specifically that "Debian packaging
> technology", or perhaps "dpkg" or even mention dpkg-divert, enables
> Debathena to leave the system administrator in control. That gives
> Debian a little more credit and may make people feel good.
>
> The mention of "things like Debathena" could be clearer about how
> broad this category is. Perhaps the whole clause could be "and then
> discuss how Debian maintainers can make their packages more flexible
> for Debian-enabled systems like Debathena".
>
> You might also try to promise a takeaway about how attendees can use
> Debathena's config-package-dev and other Debian technology to
> configure their local workplace, so there's something to gain as well
> as something to be exhorted to do.
>
> I'm skeptical of the discussion of "MIT's Athena platform" in the
> first paragraph; for people who've never heard of Athena I think it
> may be hard to understand. In particular, a natural reaction to the
> contrast in the second sentence may be "OK, so your predecessors made
> messy packages, what else is new?" for a reader who doesn't know that
> previous implementations of Athena made it a monolithic complete
> system and a totally curated computing environment.
>
>
> Do you have a list in mind of the best-practices you'll encourage
> people to follow? E.g.
>
> - keep config files static, find alternatives to modifying them in postinsts
>
> - .d directories are one honking great idea -- let's do more of those
> (but use run-parts --list or something else to exclude funny-named files)
>
> Looking at such a list might help in aiming the "make things easier
> for us" part of the pitch, even though you may not want to write it
> down in the abstract.
>
>
> OK, that's enough for one email.
>
> Greg
>
