LFS Future Braindump

[Robert Daniels]

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 
whole.

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.

-- 
Robert Daniels