On Mon, 8 Jun 2009 23:20:14 +0100, Jorge Bastos <mysql.jo...@decimal.pt>
wrote:
>> Since we are now using libzdb, we really only need to provide each
>> program with the connection string. It would dictate what database
>> type,
>> host, user/pass, db name, etc. That would make our dbmail.conf real
>> simple with just a connection string in it. Everything else would be
>> read from dbmail_config. If we add a configuration version row in there
>> that is also incrementing, then the daemons could be told that a new
>> configuration is in place and they should restart to catch the change
>> or
>> change what is required.
>
> That would be great, even for backoffice software.
> Every configuration line should exist from the beginning on this
> "dbmail_config" table, with their own defaults, that may be simpler to
have
> all rows of all configurations values there, no?
> And in future versions if a new configuration value is added, it'll be
> added
> by the *sql migrate script.
>
> Something like:
>
> --
> Create table dbmail_config (id int(6) not null primary key,section
> varchar(255) not null,config varchar(255) not null,value varchar(255) not
> null);
We dropped the dbmail_config table very early on, between DBMail 1.1 and
1.2. There were good reasons to have a configuration file, and once things
started going in there, having two places to configure the daemons seemed
like a bad idea. One concern I remember was about the running configuration
being different from the values in the database; basically, did you
manually alter the database config values without bouncing the daemon?
A dbmail-config utility that managed this table for you would be a great
thing, IMHO, to centralize sanity checking and bouncing of daemons, etc. A
way to ask each daemon to report its configuration values would allow this
utility to interrogate the running process to see if anything is different
than what's in the database, too.
Lemme see if I have the original dbmail_config table definition hanging
around...
CREATE TABLE config (
configid int(11) DEFAULT '0' NOT NULL,
item varchar(128) NOT NULL,
value varchar(128) NOT NULL
);
Yeah, pretty simple key-value store. IIRC, the 'configid' was intended to
allow multiple running configurations, but in practice was not used (I
cannot find any code that references it). To revisit this idea, I'd suggest
adding a 'section' and timestamps on the rows, drop the 'configid' concept
(makes no sense; use a different database to completely separate separate
data), and IMHO, don't bother with a row id of any kind, just put a UNIQUE
INDEX on ('section', 'item').
> Insert into dbmail_config values (100,'global','login_timeout','60');
> Insert into dbmail_config values (200,'lmtpd','port','24');
> Insert into dbmail_config values (300,'imapd','port','143');
> Insert into dbmail_config values (400,'pop3d','port','110');
> --
>
> This way all config values will be arranges in their group, ex:
> 100 = global (100/102/102 etc)
> 200 = lmtpd
> 300 = imapd
> 400 = pop3d
>
> Good or bad idea?
const int magic_numbers = 0xBAD1DEA;
Aaron
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
