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 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
