Hi Ron Ron Guerin writes:
> There will probably always be gems in the archives that appear nowhere > else. But "search the archives" should only be the answer for very > recent, or very obscure things that have yet to find their way into the > documentation. Archives should supplement documentation, not _be_ > documentation. Again we're in perfect agreement - "search the archives" is good for something that's come up recently. The vchkpw uninitialized buffer causing authentication errors if you use courier-imap with authdaemond is a very good example (and one that bit me). I think you're right about obscure stuff to the extent that an answer of "I think I saw somebody mention something like that a few years ago" is better than no answer at all, but I don't think that obscurity or unpopularity are, by themselves, an excuse not to document something. It is my experience that if somebody asks it once then sooner or later somebody will ask it again, unless it's about a bug that has since been patched (and even then you may get people running old versions who didn't encounter the bug until recently). I also know that in some quarters pre-canned scripts and good documentation are frowned upon. The theory being that mail is such an important issue that you have to understand the mail system to postgraduate level before you install it. I don't think that is a sensible attitude any more. Most Linux distros come with sendmail out of the box, it works and there are even (*spit*) GUI configurators for those who need them. Linux is never going to catch on as a desktop OS without those GUI configurators. MS Exchange, pile of steaming manure that it is, is so simple to install that a monkey could do it. OK, last I heard, the default Exchange install left it an open relay and you had to know about undocumented registry keys to prevent your Exchange server being relay-raped, but everyone wants simplicity of installation. Every so often, my boss (who has learned to hate all things from MS through bitter experience) moans about how long it takes us to figure out how to get something up and running and maybe we should switch all our servers to Windows. For the average company wanting their own mail server, it's cheaper to pay for Exchange with its bloated price and bloated per-seat licensing than to pay somebody to figure out how to install Linux, qmail, sqwebmail, etc. Total cost of ownership is a lot higher, but initial expenditure is lower and that's what usually counts. I see that qmail is falling in popularity simply because it is such a pain to learn how to install and configure to do what you want. It might be the fastest, it might be the most reliable, but the learning curve is a killer and the documentation is only slightly better than "read the source and figure it out for yourself". Add in the learning curves for sqwebmail, qmailadmin, vpopmail, etc., and the result is depressing. If you're a big ISP who has hit scaleability problems then the expenditure of learning qmail et al. is acceptable. If you're a small ISP you're going to stick with sendmail (or Exchange if you're a small ISP who has never heard of Linux). The bottom line is that the documentation MUST improve so that this stuff remains viable for even large ISPs, let alone small ones. I expect that Red Hat would produce nice GUI configurators for qmail, sqwebmail and the rest (going by Red Hat's recent performance they would be somewhat broken) if only DJB would be a little more flexible. I can understand why DJB wants to protect his reputation, especially in light of Red Hat's most recent cock-ups causing the Gtk team much undeserved criticism and hassle, but DJB's attitude will be the eventual death of qmail. :( What is needed for qmail to be viable in the long term is for Red Hat to pay DJB to produce RPMs for them that they promise not to tamper with in any way and to allow them to release RPMs containing the popular patches after he's vetted them and to have the install process explain that DJB vouches only for the unpatched version. > It could be only a few of us will work on it sporadically. And that's > ok too. The important thing is to get started on it. I was going to > fix some things for myself, and now I'm going to submit those fixes for > everyone else's benefit. It's how much of the code gets written in Free > and Open software. Someone who can, scratches an itch and makes it > available to everyone else. Hmmm, how about creating a CVS tree for the documentation. If there's no way of preventing documentation volunteers messing with the source tree then it might have to be a separate CVS. The overhead on the development team would then only be giving volunteers access to the documentation CVS and checking that submissions are close enough to being correct to be accepted. To kick if off, although it's not a vpopmail issue per se, I can document how to get sqwebmail and qmailadmin working on a server running suexec. Since Mr Sam has at least once implied that suexec doesn't work and is unsupported (his reply was along the lines of "who told you that you could use this with suexec") then this proposed documentation tree may be the only home it will ever have. And it does have a bearing on some vpopmail users. It certainly affects me because there's no way my boss is going to allow our servers to run without suexec because that would allow one of our clients to accidentally or maliciously trash cgi-created data files of another client. And yes, I do know most of the ways suexec can be subverted, particularly the race hazards, but it's still a lot better than having to leave directories world-writeable so that the httpd process can create files in them. A clever malicious user can do damage if you're running suexec; a stupid user, whether through malice or accident, can do damage if you're not using suexec. -- Paul Allen Softflare Support
