Re: Future of Qmail-LDAP

Hi,

On Tue, 09.02.2010 at 17:44:49 -0500, Edward Capriolo <[email protected]> wrote:
> >> Members of our admin staff have left notes in the /etc/motd "Contact
> >> ed@ for more information on restarting".
> > This is psychology, not technology.
> Yes, but the fact is your have to train people and document things
> like a startup procedure, which are usually simple. That is not
> philosophy it is lost time.

I tend to write short init scripts, which wrap around the runit (or
daemontools) stuff. So, the untrained admin can eg. say
"/etc/init.d/qmail-ldap restart", and the script executes
"sv restart qmail-ldap", modulo the fact that the qmail-* package(s)
usually have to cater for much greater variety. Eg. I tend to set up
two qmail-smtpds at least, one for submission, and often one more for
localhost. But for a standard scenario, an init script should be easy
to do.

> > So how would you deal with a crashing Apache, if you don't have daemon
> My point, apache does not crash often for me neither does qmail.

In my experience, Apache crashes often enough to warrant automatic
restarts. On one site I am responsible for, in an administrator
capacity, the user has managed to implement an application which makes
Apache crash every few days. I have not the slightest interest, and
would probably not even get permission to, in starting to debug his
application, but I still get the blame if the site goes down. You see
my point...

> about training people. It is hard to get a package "blessed" by any
> distro with svc if it does non standard things. That is going to hurt
> the adoption of qmail thus hurting its future.

In Debian, I'd just say "Depends: runit" in the package's control file
and deliver a set of standard init scripts alongside the runit setup.
Btw, the current direction is to move towards so-called "dependency
based init scripts", where you have to implement a header that
specifies when and how the system should start your script, by
depending on other services... sounds like going halfway towards runit
and friends, anyway.

> Obviously I do not do RPM on FreeBSD. My point was that thanks to the
> "patchness" factor, I really can not use any package system.

The flipside of this coin is that what you can (or are used to) do in
qmail-ldap with little patches, usually requires whole extra packages
and major tweaking in other MTAs. So the complexity just moves
elsewhere, it does not go away. I agree about the centralization and
documentation point you make, however.

> Regardless of me doing it myself or hiring someone,
> time/money/resources is spent. In my opinion the "overhead" to run
> this MTA is very high.

Imho, it's not more - rather much less for us - than the cost of
running other MTAs. But you're apparently in a different boat.

> Take for example SMTP TLS. Ideally during compile/make the mail server
> should detect TLS and activate it.

For me, activating TLS was removing three comment signs in the Makefile
before compiling, plus setting up a certificate and a configuration
file, afair correctly. Together with certificate creation, this takes
me about 10 minutes. I think I may have done a local documentation page
on our internal wiki for this, just as a reminder.

> Would you agree that most MTA's would do that?

For other MTAs, I tend to use the disto package(s), and not compile
anything at all. I do sometimes download the source code, though, if
the doucmentation is not clear enough for me.

> I should not have to pay money or spend more time configuring a
> no-brainer feature.

I currently find that TLS is *MUCH* harder to configure with Postfix,
as compared to qmail-ldap, where it more or less worked out of the box
- for us, at least. Postfix + LDAP is imho also *MUCH* harder to
configure than qmail-ldap.

It turns out that some features are *NOT* a no-brainer, despite the
ordinary admin (eg. me) expecting it to be. Eg. I came across an M$
Exchange server right on the Internet (no gateway in between), that
have TLS activated, but in such a way that it does not work. And even
by an IT company! This shows a weakness in QL, imho, because it isn't
easy to force non-TLS transmission to such broken sites, and it shows
that even with "the best" of GUIs, things are far from simple (enough)
in other environments, too.

> True, but many of the things I mentioned serve as a higher barrier to
> entry.

Granted. Learning new stuff and doing things differently is the way of
evolution. Evolve, or perish, if the trodden paths at some point don't
deliver acceptable results.

For me, much of the concepts seen in qmail and assorted software, show
quite a bit of insight and, at the time, new ways to attack problems
which were lingering and looming before. But if you don't accept this
kind of evolution, then you'll be unhappy as long as you are fighting
the application.

> Already I am confronted with:
> http://thedjbway.b0llix.net/daemontools/installation.html
> http://cr.yp.to/daemontools/install.html
> 
> What is this step?
> ln -s /usr/local/package /package
> Both people are setting up a different way.

Nope. The first link only tells how to install daemontools in greater
detail, and geared towards people like you. The latter (official) page
only gives you the bare-bones about how to set daemontools up. Not
really explained is the idea behind this setup:

http://cr.yp.to/unix.html

And if you are confused about "mkdir /package" vs. eg. "ln -s
/usr/local/package /package", then you're imho suggesting that you are
not very experienced with Unix in general.

> This is an issue for all open source projects but I find it
> particularly bad for qmail, qmail-ldap has less specific documentation
> then qmail.

But imho, qmail-ldap has *better* documentation than stock qmail has
(maybe except for the books that seem to be out there). I only want to
read what is necessary to complete the job, not tons of outdated,
erronous and spotty "documentation" snippets that may float around for
other systems.

> you say. By hooking into ldap qmail-ldap presents itself as an
> enterprise solution. After all, who needs LDAP integration except
> large enterprises? The small documentation and the decentralized path
> management is a detraction in that area IMHO.

Maybe LDAP is not to be seen as a strict "requirement" for small
enterprises, but it just makes a whole lot of things easier, and if
qmail-ldap-control were integrated, it would open a very clean and easy
path for an administrative GUI that could run as non-root, too.

I don't say that the project is in perfect shape, but still hold that
someone could harvest from a lot of potential that it has.


Kind regards,
--Toni++