I now know far more about LVS than I ever wanted to, after spending the last two days wedging every little bit of information about it, Piranha, and all the accompanying niggling details into my head. Bryce, you and your group has done a very nice job of putting this all together in Pensacola.
As a point of note, if anyone is interested, version 1.0.1 of IPVS drops into the 2.4.18-0.12 Red Hat kernel SRPM (from Skipjack) completely unmolested, and the newer ipvsadm runs fine. Not that I had any (real) problems with the 0.9.7 version as shipped from Red Hat, just some incredibly annoying network issues that looked like an LVS misconfiguration on my part.
The only really disappointing thing about the whole affair was the distinct lack of user-oriented documentation, especially for 2.4 kernels and iptables; a combination of the (sadly out-of-date) Piranha/"Red Hat High Availability Server" documentation, the LVS HOW-TOs, and a recent acquisition managed to help with my questions, thankfully.Perspective
There seems to be an assumption on the part of programmers (I know I've been guilty of this before) that the user is aware of the boundaries between the software that they work on and the software that theirs interacts with. This lack of user perspective seems to give rise to range of results, from the "not my problem, ask them" finger-pointing game, to the more subtle omission of documentation on related issues that are considered "out of scope". So, you can end up with new users asking questions in the wrong forums (and occasionally being accosted for it), and documentation that doesn't go a little bit farther to explain useful product or project combinations that the user might be trying to find answers to.
Before anyone asks, yes, I have a few projects and people in mind as I write this. But bringing them up would be a distraction from the question: what can open source developers, whose perspective is usually focused on the particular itch they're scratching, do to augment their ability to consider the "in-the-field" use cases that seem to invent themselves with any useful project, and communicate assistance on them effectively? As a related question, what can the developer do to encourage better participation in the process by the user (as the user would seem to usually have very little natural inclination to become more than superficially involved in the development process)?Linux Firewalls
As I mentioned above, I just picked this up at the local bookstore. I have to say, Ziegler has done an excellent job of compiling an accessable and wonderfully complete overview of 2.4's iptables configuration, along with summaries of the most common hoops you can make it jump through. There is a good discussion of the differences between 2.2's ipchains and the new 2.4 netfilter-based system, and he gives a quick introduction to a few peripheral items of note as well: basic firewall administration tasks, SSH, Tripwire, and intrusion detection concepts. This makes an excellent reference text to go along with the often obscure documentation available online. Which brings up another question: what happened that caused New Riders to suddenly start putting out such good technical books? They have a few good ones out now, and that red backing is starting to crowd the animals on my bookshelf. ;-)