LFS Future Braindump
rdaniels at linuxfromscratch.org
Sun May 25 07:00:52 PDT 2008
So, just for fun, I decided it would be neat to figure out how to build
a network with remote login and SSO functionality. As always for a new
project, my first stop for research was BLFS. Unfortunately, it wasn't
as much help as I thought it would be. Of course, this is a complex
project, and I'm sure whole books have been written on them, but it got
me thinking again about the long-term future of the LFS project.
My first point is one that has brought up before. We need better
descriptions of the packages and why you might want them. To take an
example from the above project, "The OpenLDAP package provides an open
source implementation of the Lightweight Directory Access Protocol."
In my early Linux days, I thought 'OK that's nice, so what is this LDAP
thing actually used for? I seem to access my directories just fine
without it, so what's different about this?' We all do a wonderful job
of documenting build dependencies, instructions, and methodologies, but
less so on why we are building things.
Second, I find that there is an almost total lack of information on how
to make the various pieces work together. Without that knowledge to
tie everything together, it's difficult finished product that is more
than a big mashup of software. For my example, I know I need OpenLDAP,
Kerberos, Cyrus-SASL, and probably a database like PostgreSQL. It
seems the most likely way to go is use LDAP directly, using Kerberos as
a backend for authentication, and the database for information storage.
But maybe I'm supposed to use Kerberos directly, and the authentication
then fetches all my information from and LDAP backend. And just where
does SASL fit into all this?
These issues led me back to Alan Lord's suggestion about transforming
LFS into a set of course modules. This would be quite a change to the
books, not a short-term project and not one to be done lightly. I
personally think this format would be very good for the LFS project.
It would be better suited to provide the solution to problems like
mine. Explain each piece's purpose, and what place it has in the
Whether LFS goes down a road similar to that or not, I think parts of
these ideas could be used without changing things too drastically. For
one, one the Stunnel page, we currently refer the Samba instructions
for a concrete example of the configuration and usage of Stunnel. I'd
like to see more of these use cases and examples of software
interaction. Second, it might be worth considering reorganizing the
BLFS book. Instead of all the packages being listed on the front page
separated into general categories like "General Utilities"
and "Servers", there could perhaps be a front page where the user would
select a purpose for the end system, eg 'Webserver' or 'Home Desktop'.
The selection would link to a page listing the various types of
software one may be interested in for that purpose. So a dedicated
webserver likely wouldn't need a an office suite or cd burning
utilities, while your average home desktop has no need of an http
server or Kerberos. These different sections would directly list only
applications and daemons the user would directly interact with.
Libraries would just be accessed through dependency links from the
top-level applications. For the most part, this would just be a
rewriting of the various index files, not touching the package pages.
The hard parts would be deciding on a set of target purposes, and
deciding what packages do or do not fit under a particular purpose.
That would be somewhat arbitrary, some home desktop users really do
want to run an http server. Also, a link to a flat listing of all
packages included in the book would be included, equivalent to the
current index of the BLFS book. If there is interest, I can try to
hack up a quick version of this idea.
More information about the blfs-dev