[2295] in athena10
Re: DebConf9: Call For Papers (fwd)
daemon@ATHENA.MIT.EDU (Tim Abbott)
Wed Apr 15 18:32:04 2009
Date: Wed, 15 Apr 2009 18:31:35 -0400 (EDT)
From: Tim Abbott <tabbott@MIT.EDU>
To: Greg Price <price@mit.edu>
cc: debathena@mit.edu
In-Reply-To: <20090415213347.GC21912@vinegar-pot.mit.edu>
Message-ID: <alpine.DEB.1.10.0904151822440.28335@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Thanks, Greg, this feedback has been really helpful.
I've decided to indeed submit a BOF discussion event; my next step is
probably to contact all the people at other institutions who I've
discussed config-package-dev with in the last year and encourage them to
come to Debconf and participate.
Current draft:
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 package manager to
support change defaults to those appropriate for the site without taking
on the role of the system administrator.
With config-package-dev, MIT's Debathena project has been able to provide
site configuration for multiple concurrent releases of both Debian and
Ubuntu with limited developer resources, and in a clean, noninvasive
fashion that has made it popular on students' 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. This case study offers
lessons for how packaging practices can make extensions of Debian harder
or easier to build.
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.
-Tim Abbott
On Wed, 15 Apr 2009, Greg Price wrote:
> On Wed, Apr 15, 2009 at 03:44:49PM -0400, Tim Abbott wrote:
> > 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.
>
> Yeah, this is pretty good. I'd put the name "Debathena" back in,
> perhaps in "MIT's Debathena project has been able ...".
>
> In sentence 2 you want "package manager" and "to support changing
> defaults", and I think "instead of ..." might be better as "without
> ..." or as "while staying out of the role of system administrator".
>
> The line about "in a way that is sufficiently clean" sounds awkward
> and rather like faint praise. Perhaps "and in a clean, noninvasive
> fashion that has made it popular on students' laptops", or something
> like that.
>
>
> > 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.
>
> Right, sounds good. Again, I think it might be helpful to address
> this a bit more directly in the abstract. Perhaps something like, at
> the end of the second paragraph, "This case study offers lessons for
> how packaging practices can make extensions of Debian harder or easier
> to build."
>
>
> Greg
>
>
>
>
>
>
>
>
>
>
>
>
> > -------
> >
> > 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
> > >
>
