[Dovecot] best choice of user database file to work with postfix

[Phil Howard]

On Fri, Apr 23, 2010 at 3:45 AM, Ed W <lists at wildgooses.com> wrote:

You need to look at where you are going with this.... One way or another you
> need a database - call it a banana if you prefer, but it's still a database
> whether it's a flat file or a BDB file or whatever
>

One must be careful with the term "database".  I agree with you that it
could be anything.  But there are lots of people out there that assume some
server daemon or engine when you say "database".  And most of them assume
"SQL" is in there, too.  So I avoid that term.



> Your requirements appear to be badly phrased.  What you *appear* to want is
> a black box system which is as simple to maintain as possible.  However, you
> have stated a bunch of hard to meet criteria such as not allowing any long
> running code to support your needs (a daemon).  I really don't see that you
> should exclude additional daemons, simply evaluate the complete system with
> and without and choose the one which is "easiest" to maintain
>

Yes, a black box system would have suited.  But it needs to be open source
(that's not a contradiction ... I just have't seen one that I can use).  It
also needs to be able to integrate with what I will have, which is an
exported file, which I have reason to suspect will be in a spreadsheet form.


1) Yes you CAN setup something which uses a plain text database, I tried it
> for a while but at 50 users I decided it was too complicated and switched to
> a DB.
>

What complications?  Were you hand editing this file?


2) You are optimistic if you don't think some user will accidently add a
> <CR> halfway through the text file, completely breaking it and have the
> skills to realise what they did.  Or they will add a "," in the middle of a
> password and change the meaning of all your fields.  Or they will miss a
> field save the file and then never realise their mistake.  Better yet are
> errors which cause some external (grep,sed,awk) function to choke on the
> input and cause some really wierd effects downstream...
>

Ah, yes, hand editing.  But that won't be happening in my case.


3) Why should an sql database need any monitoring and maintenance over the
> next X years?  Yes you can corrupt the files, but I would hope for very
> decent uptimes and after all they aren't going to repair a corrupted boot
> sector so you need some kind of maintenance plan in place, simply work in a
> full OS backup into the plan and this saves your DB at the same time?
> (Offlist we can discuss, but a simple rsync to some separate partition
> should do it)
>

You rsync the files an SQL database (like MySQL) works from, and don't
expect corruption?  That's only safe if the database is synced and shut
down.  I don't want to be doing that.  If I did run a database engine, it
would have to import everything ... as a single massive transaction (or
maybe a live table switch scenario between two tables).  To back it up I'd
either export the entire table to a file (and send that off to the archive),
or just back up the file I used to import with.


4) If you really, really don't want a daemon based database then you will
> have to look at bdb (if dovecot supports it?) or sqlite which I think
> postfix+dovecot both support.  You can then add convenience command line
> functions to examine and alter the data. Those convenience functions can
> error check the input also.
>

CDB would work, since I would be importing everything all at once every time
a change takes place (once every few days perhaps).  Berkeley DB would work,
too (nearly as fast).  A flat file cached in RAM by the OS would be about as
fast for these few number of users (that's a "database", too, in its own
way).


Good luck
>

It looks like the way I will be doing this is to let Dovecot handle
Postfix's SASL needs and generate a little users table for Postfix to make
the accept/reject decision on incoming email and spam.  So my task now is to
decide what form I will give the data to Dovecot.