On Tue, 09.02.2010 at 12:35:29 -0500, Edward Capriolo <edlinuxg...@gmail.com> wrote: > Firstly, Daemon tools and the "DJB way" . > The forced layout, I did not appreciate it. Daemon tools took extra > time because of the way its write data inside its /service/whatever > directory my deployment system does not like that.
I swapped daemontools out for runit, which performs better, but I wish more software packages would do that. > Members of our admin staff have left notes in the /etc/motd "Contact > ed@ for more information on restarting". This is psychology, not technology. > I don't dislike daemontools but its just to much work vs a standard > init script. If the daemons support running supervised, it's actually much less work than a "standard init script". > your bets. My old shop made custom software and used to believe in > auto-restart scripts. My new shop never does this. We except software > not to crash, and if it does we deal with it. IMHO this works much > better. So how would you deal with a crashing Apache, if you don't have daemon tools and no nagios (but a different package without the "restart" capability), either? The same goes for every other non-trivial package that *will* crash, in my experience, and where you *will*not* have the resources to deal with the problem (eg. chucking out Apache is not always possible). And comparing the technical and administrative overhead and security implications between daemontools/runit on the one side, and Nagios on the other, should come out MUCH in favour of daemontools/runit in most cases, imho. > So in a nutshell, for the future strip out svc. I'd replace daemontools by runit, and ucspi-tcp by ipsvd, and that's about it. > Updates, your average qmail-toaster is tons of software to track and > update. The only issue with this is that qmail-ldap is usually not managed by the packaging system. If it were, you wouldn't see much of the work you were doing now, anymore, unless you are the party who packages this software. > p FreeBSD-7.2/FreeBSD-7.2-amd64-libmcrypt-2.5.7.T > p FreeBSD-7.2/FreeBSD-7.2-amd64-mcrypt-2.6.4.T > p FreeBSD-7.2/FreeBSD-7.2-amd64-imap-2007d.T > p FreeBSD-7.2/FreeBSD-7.2-amd64-libxml2.2.7.3.T > p FreeBSD-7.2/FreeBSD-7.2-amd64-httpd-2.2.11.T > p FreeBSD-7.2/FreeBSD-7.2-amd64-php-5.3.0.T > p FreeBSD-7.2/FreeBSD-7.2-amd64-mod_perl-2.0.4.T > p FreeBSD-7.2/FreeBSD-7.2-amd64-squirrelmail-1.4.19.T > p FreeBSD-7.2/FreeBSD-7.2-amd64-squirrelmail-plugins.T > p FreeBSD-7.2/FreeBSD-7.2-amd64-ispell-3.3.02.T > > #ldap stack > p FreeBSD-7.2/FreeBSD-7.2-amd64-db-4.7.25.T > p FreeBSD-7.2/FreeBSD-7.2-amd64-openldap-2.4.20.T About most, if not all of this stuff is not directly tied to qmail-ldap, but attributable to the specifics of your site. > took me months to migrate our qmail-ldap, and because of some of the > complications above only qmail+ldap admins can actually service the > system in any way, people always come to me very often. You're only saying that nobody in your company deigned to learn qmail+ldap. > would feel safe with "rpm -u qmail". So in a sense I manage a complete Hmmm, rpm on FreeBSD? I hope not! > "toaster" now. Id rather have one product and let it be someone else > problem. Then you should purchase a product or hire someone to implement something for you. Free software generally is, to a large amount, swapping coin (or paper) money for elbow grease. > servers, replicated ldap, Isilon clustered NFS mailstore, but the > amount of effort it took was almost ludicrous. Except for the really hard problems that I'm currently running into, that recently started to pop up, qmail-ldap has, for the better part of several years, been almost a no-brainer to install and run, at least on our sites. _Very_ robust, "fire and forget". We still process the bulk of our email using qmail-ldap. > So what I think qmail-ldap needs nutshell: Utterly complete, clean > documentation, from build, deployment, management, troubleshooting > init scripts auto-tuning for larger deployments (i had an outage due > to default concurrency being two low after upgrade) > more ldap documentation and some front end (I know this is not > qmail-ldap's place but the two things are married ) > community working -together all the patches in one place, trusted > tested, unit tests You could have been the one writing the book. > Otherwise qmail-ldap can never stack up to a clean finished product > like kerio, or zimbra. Of course qmail-ldap is open source so it is > unfair to compare it against commercial products, but I think to have > a future it has to be viable against them. You're especially comparing qmail-ldap, which is mostly a pure mail transport agent, to a groupware package that includes a mail transport agent. Your arguments against qmail-ldap, from this perspective, apply the same way across all other classic unix mail transport agent packages, like Postfix, Sendmail and Exim, to name the biggest ones. This is really a comparison that is less sensible than apples and oranges, imho, although you have a valid point in so far as to say that you don't see the future in pure mail transport agents, but in groupware packages that may be more powerful, and are more polished. That's a valid theory, imho, although not "proven". Kind regards, --Toni++
