Howto - the difference between the good, the bad and the ugly - quit reading mine!
A few days ago, I finally updated the qmail howto that I had been maintaining for a few years to notify people that they are better off going to lifewithqmail.org for more accurate information on how to install and/or maintain qmail. I have not done the job of a howto writer in keeping the document accurate or up-to-date. A recent post on the OpenBSD misc mailing list made me think more philosophically about providing howto's and their inherent problems. Software developers work hard to document their programs. Their documents are designed to guide you through the installation and configuration of the software. A howto allows you to skip all of this in the hopes of providing you an "easy out." That's what it comes down to - you are trying to get at the easy way out of learning a piece of software in order to install it as quickly as possible - and this has major caveats. While trudging my way through learning how to install and configure postfix (and the kitchen sink), I found a great number of howto's that were either out of date or inaccurate. It was unnerving the amount of bad information was available on configuring amavis-new in particular. If I had simply gone to the information provided in the software readme's and install guides, I would have found up-to-date information that I was looking for. If the software's documentation was poor, the worst thing I could do is go to the howto to see how to get it to work. Why? Because if the software programmer can't maintain or get accurate documentation written, how well do you expect the software to work? I'm not trying to slam the hard working software developer who struggled to finish a project but had a hard time writing documents (how many writers are good programmers and how many programmers are good writers?), but personally, if your documentation doesn't explain how things work so that I can install them properly, then how do I expect to maintain it such that my server doesn't get bombed with a bug or some other sort of problem.
There is a difference between a guide and a howto. The name howto implies that you will need everything to get started. Perhaps. You are missing one very important element: knowledge and understanding of how things work and why they work the way they do. I learned a very important lesson last year when I inadvertently updated perl on my email system and completely destroyed the SpamAssassin installation. For hours, my server was throwing mail around queues and didn't know which way to take things. I, because I had never taken the time to understand what the hell I was doing, almost had a heart-attack as customers started calling to complain because they couldn't receive email. I vowed after that to never install something without at least a precursory knowledge of the software I'm implementing and how it works. Yesterday I spent the better part of 8 hrs. trying to figure out why amavis-new and SpamAssassin weren't tagging obvious spam. It was because of one line @local_domains_acl = ( ".$mydomain" ); that was missing in every freaking howto that purported to explain how to install postfix and the kitchen sink (well, except one). I figured this out by shutting down the caffein flow to my veins and taking a long, hard look at the amavis-new documentation - and there it was... right in front of my eyes.
So, the next time you decide to use a howto to configure something to be used in production, be under advisement that you do so not only at your risk but the risk of all those you are supporting.*
*This doesn't mean I'm going to stop providing "notes" on this website, but please be forewarned - none of those are meant to provide a howto anymore <wink>.

