Re: speculations to characterize issues for Debian Enterprise
On Sun, Aug 22, 2010 at 08:27:21PM -0700, Russ Allbery wrote:
> CJ Fearnley <cjf@CJFearnley.com> writes:
>
> > 3. Bugs. Design flaws upstream. Patches. Sensitivity to versions, etc.
> > * The only solution that I can imagine for finding and fixing bugs
> > is just doing the work. With design flaws, it can get really hard.
>
> One place that we can potentially help provide guidance other than just
> fixing bugs is to recommend particular implementations, when there are
> several that do the same thing, which are well-done for Debian and which
> work well for enterprises. But when there's only one major implementation
> of something, we indeed just have to do the work to try to get the bugs
> fixed.
>
> This is where some form of collective action by identifying enterprise
> bugs that people can try to work on may help.
>
> > * If site specific configuration management can't solve the issue,
> > it is a bug!
>
> It might be useful to write up guidelines for how to design packages and
> software so that they work well in enterprise environments. Things like
> the rule that any configuration file should support including a directory
> of config file fragments.
>
> > * I think much of the work needed is in bug triage and fixing design
> > issues upstream so the software can "just work" in more use cases.
> > Fortunately, there are now usually at least two FOSS upstreams
> > that can do any given thing. So if one upstream doesn't "get it",
> > we can work with another before we'd need to fork a new codebase
> > (which is what our local package archives really are).
>
> Ah, yes, I see you had the same idea as I did above. :)
>
> > 4. Configuration management.
> > * I mean at the Debian packaging level primarily. But unless puppet
> > solves the problem for everyone (and I'm not yet convinced), there
> > is broader design work needed too.
> > * Another hard problem. More than "just work", as it requires
> > creative new ideas too!
>
> This is another place where best practices documentation might be useful
> in areas like how to manage Debian configuration files, how to build local
> packages, and so forth.
>
> One of the big takeaways I got from DebConf is that we need lots more
> documentation in this area. A lot of the facilities are there, but people
> don't know about them or how to use them coherently.
>
> I'm not going to have time to help with things like Blends, at least in
> the near future, but I'm going to try to pursue getting more of our
> documentation publicly available and will be working on packaging Java
> applications.
On reflection, I'm really liking the idea of documenting "best practices"
for solving various "enterprise" functionality use cases.
Deciding on the right abstraction level for the documentation is
difficult. I prefer functional and "operational" classifications
(in contradistinction with tool-based classifications). Then the
documentation helps at the design level as well as for implementation.
For example, one big enterprise category for me would be "Identity and
Privilege Management". I imagine that a document about that would need
to start with background on AAA (Authentication, Authorization, and
Accounting) in broad conceptual terms, then a discussion of the state
of standardization (RADIUS[1], Diameter[2], OpenID[3], Shibboleth[4],
NIST's RBAC[5], SAML[6], etc.), then we'd need to document component
subsystems (PAM[7], Kerberos[8], LDAP[9], etc.), followed by an annotated
listing of FOSS tools that can address at least part of the project
(the Debian Wiki's annotated list of control panel software[10] might
serve as a good model), then a series of HOWTO articles (like those
at http://www.debian-administration.org/) documenting how others have
solved the problem which would bring the theory to a concrete form usable
by practitioners. The only problem I see is that it sounds like a large
book project.
Maybe we just need an Enterprise wiki that links to Wikipedia for the
conceptual overview, then surveys available standards (also linking to
Wikipedia, probably), then jumps into an inventory of available FOSS
tools, and concludes with a list of links to HOWTO articles from blogs
or debian-administration.org with writeups on implementations [what are
"best practices" but what others have done with shiny MBA-speak polish?].
Hence it can be readily concluded that I think the current Debian wiki
page on Enterprise[11] is ... not quite what I have in mind for a good
Enterprise Debian documentation resource ;)
Do we have a good wiki resource to build upon?
Should we put it all in Wikipedia or is wiki.debian.org or another wiki
more appropriate?
How do we start? Where do we start?
1. http://en.wikipedia.org/wiki/RADIUS
2. http://en.wikipedia.org/wiki/Diameter_(protocol)
3. http://en.wikipedia.org/wiki/Openid
4. http://en.wikipedia.org/wiki/Shibboleth_(Internet2)
5. http://csrc.nist.gov/rbac
6. http://xml.coverpages.org/saml.html
7. http://en.wikipedia.org/wiki/Pluggable_Authentication_Modules
8. http://en.wikipedia.org/wiki/Kerberos_(protocol)
9. http://en.wikipedia.org/wiki/LDAP
10. http://wiki.debian.org/HostingControlPanels
11. http://wiki.debian.org/Enterprise
--
We are on a spaceship; a beautiful one. It took billions of years to develop.
We're not going to get another. Now, how do we make this spaceship work?
-- Buckminster Fuller
CJ Fearnley | Explorer in Universe
cjf@CJFearnley.com | "Dare to be Naive" -- Bucky Fuller
http://www.CJFearnley.com | http://blog.remoteresponder.net/
Reply to: