Jake Anderson wrote:
> Aaron Stone wrote:
>
>> 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').
>>
>>
>>
>
> If you go down that route, you might want to think about putting
> hostname against each of those entries.
> If somebody has multiple instances connecting to a single database, they
> may well want to configure each of them differently.
> (take a look at mythtv for an example of this)
> _______________________________________________
> Dbmail-dev mailing list
> [email protected]
> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
>
>
I like Aaron's timestamp idea on the rows, and I think that we should
have a per host option as well. I think it would be most reliable in
using the hostname reported on the system as that is most likely going
to be unique, and not going to have weird issues with different systems
interfaces being reported slightly differently.
I propose the following:
CREATE TABLE `dbmail_config` (
`hostname` varchar(255) NOT NULL DEFAULT '*',
`service`
enum('all','ldap','smtp','lmtp','delivery','pop','imap','sieve') NOT
NULL DEFAULT 'all',
`setting` varchar(255) NOT NULL,
`value` varchar(255) NOT NULL DEFAULT '',
`updated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE
CURRENT_TIMESTAMP,
UNIQUE KEY `host_service_setting` (`hostname`,`service`,`setting`),
KEY `hostname` (`hostname`),
KEY `service` (`service`),
KEY `setting` (`setting`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
hostname=* would be used for any host except any
hostname=dbmail.domain.com entries that would be used instead.
service=all would apply to any service using that setting. A more
specific setting on a particular service and or hostname would override.
Thus a hostname='dbmail', service='all', setting='TIMEOUT'
would be the default for any service on the dbmail host.
An entry hostname='*', service='imap', setting='TIMEOUT' would override
the above setting as it is more service specific.
But another entry of hostname='dbmail', service='imap',
setting='TIMEOUT' would override both of the above.
I think that some settings should be renamed to be more service
specific. For example the 'PORT' setting. Each service uses a different
port. LDAP uses as the port to connect to.
lmtp_port=24
pop3_port=110
pop3s_port=995
imap_port=143
imaps_port=993
ldap_port=389
This allows them to all be set in the 'all' service area, even though
they are service specific.
We can have the table auto populate by including a default value in the
function call to return the value. If no row matches in the table for
that item, then it will be inserted with that default value. Thus
get_config_setting('imap','imap_port',all_or_specific true/false,'143')
would insert into either 'all' or the service requested depending on the
true false flag. If the default value passed is NULL then no insert will
be done. Of course the database value will be returned or the default
passed will be. This solves the majority of the problem with populating
the table with values that could be changed pretty quick.
I think the safest way to handle config changes is to have only
behavioral changes take effect during operation, and require a -HUP or
restart on items that could affect existing users. Thus the updated
timestamp field will get used, but not in all cases.
The update_schema.sql would work with the hostname='*',service='all',
setting='schema_version' row to determine changes to apply. It could
also include deleting old settings that are no longer used like the
auto_notify=yes that is no longer there.
-Jon
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
Dbmail-dev mailing list
[email protected]
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
