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 > Dbmail-dev@dbmail.org > 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 Dbmail-dev@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev