I would also like to see group quotas. If you're looking at implementing it,
naturally you should look towards to 2.0 branch. As far as I know, group
quotas are not implemented at all... but based on the current roadmap, this
will probably have to wait until 2.1.
With respect to the dbmail_config table (yes, the tables should all be
prefixed with dbmail_, hint hint Ilja ;-) it was intentional that there not be
an auto_increment column. I'm trying to convince everyone that we don't need
them; multimaster clustering (particularly with MySQL) is reasonably trivial
once you begin handling your own index column.
There is a UNIQUE constraint, however. Rather than config_idnr, think more
along the lines of cluster_name as an apt name. Here's how it looks:
CREATE TABLE dbmail_config (
cluster_name varchar(64) not null,
key varchar(255) not null,
value varchar(255) ,
primary key (cluster_name, key)
);
So what this means is that the *combination* of a cluster_name and a key
creates the primary unique index. This allows multiple clusters of machines to
share the same database. An application of this might be having physically
separate front end mail exchangers for several domains, each of which runs a
local database that is multi-mastered with other domains that you also run,
each of which is also on a separate host. By multimastering the database, each
machine can transparently run as a backup of the other simply by starting up
new DBMail processes with the failed machine's cluster_name.
Aaron
Feargal Reilly <[EMAIL PROTECTED]> said:
> Hi all,
> Picking up on something I was thinking about last November, but got
> distracted from.
>
> I want to implement group quotas for users based on their client_idnr.
>
> The idea is that you set a quota of say, 100M for a group of users.
>
> When a mail arrives for a user in that group, a further quota check is
> carried out against the combined mailbox size for all users in that group.
> If the mail pushes this total over the group quota, it is rejected.
>
> The normal quota checks would still be carried out for that user, so that
> some people can still be restricted.
>
> I know some people kinda do this by averaging the group quota across the
> number of users in that group, or by using some management interface to
> juggle the individual quotas.
> However, this doesn't work in cases where the client doesn't care, they
> just want to pay x euros for y megs of space.
>
> Last time I broached this, I was told the mechanism already exists. If it
> does, it's not in the 1.2.3 code.
>
> In terms of mechanism, I was looking at using the config table to store
> the group quotas.
>
> I looked at the structure of this table and noticed something puzzling:
>
> config_idnr | integer | not null default '0'
> item | character varying(255) | not null
> value | character varying(255) | not null
>
> The config_idnr doesn't have a unique constraint - is this by design, or
> by accident?
>
> If it's by design, the implication is that usage is intended to group
certain types of config entries together. e.g. all the entries relating to
group quotas would have config_idnr=123, whereas all entries relating to
disabled users would have config_idnr=42. If this were the case, then
> is there a plan to avoid duplicating numbers for different purposes,
possibly publishing a list of used ones?
> Given the lack of indexing, I'm guessing that it's just that the table
hasn't really been used, and thus this hasn't been an issue. If that's the
case, then how *should* it be used? Should the config_idnr be unique and/or
auto-incrementing?
>
> Feedback please? I'd like to do this correctly so it can be committed to
further releases, so if people see a problem with this in their dbmail
deployment, please say so.
>
> Cheers,
> -Feargal.
>
> --
> Feargal Reilly,
> Codeshifter,
> Chrysalink Systems.
>
>
--
