looks like a clean and very efective way to do the
qmailadmin-limits. If you try to bloat things down
for something that MIGHT be added or changed then
we really will not have things really planned, they
will be half planned and still open waiting for the
stuff people might want to add to the tables. I say
we go with this, lock it down and make it happen and
deal with tomarrow when tomarrow happens as far as the
tables.
-John
Brian Kolaci writes:
I've done some thinking about the many suggestions about handling
the limits and wanted to summarize some of the pros & cons.
First was whether to use a generic approach that had a
table with domain, name, value which has a row for each
parameter, or to use a single row will all values per domain.
The pros:
- allows extensability - we can easily add new attributes with a new row
The cons:
- consumes more space - there's overhead of N-1 times the size of
the domainname, plus N times the size of the option name, plus
overhead for the value to be able to hold the largest possible value
even for smaller items.
- updates not atomic - there would have to be N update statements to
change a value. We would have to encapsulate the updates within a
transaction. - performance - there would be more data going back and forth to/from
the sql server. We would also have to store all data as strings in
the database and do conversions. When we perform updates, there would
have to be N updates sent to the server, which is N round trips plus
the transaction overhead.
At first when I saw the suggestion I thought it was a great idea,
however after thinking it over, I believe performance and reliability
would suffer just to save an "alter table" if/when the schema needs to
be extended.
That being said, I'll continue down the path of a single row per domain,
however if others have arguments to the contrary, please speak up.
The schema needs to be adjusted to accomodate all the requests I've seen.
Both the C structure and the database schema needs to change.
I've read the Maildir++ quotas and understand that the concept of a
"Maildir quota" encapsulates both a maximum size and maximum message count.
It appears to be just a string that contains "#S,#C", which combines
the Size and the Count into one string, where the #C is optional. I
personally would want them separated as two values, since you can't do
much with the combined string but pass it around. To actually use it,
you need to split them up with a parser and convert them to numbers.
I think the API should keep them as numbers in the structure in C. Its
easy enough to combine them with a snprintf(), but more work to parse
them out to actually use/enforce them. How they're stored in the database
and/or file doesn't really matter (but should be discussed). I believe
they were combined due to the old hack to put the quota value into
the "shell" field of a password record. Being that we're in new
territory here, we don't even have the concept of message count in
.qmailadmin-limits files or the database, so adding a field/column
for the "default per-user message count" or "per-domain message count"
shouldn't be an issue, and would even keep the old fileformat backward
compatible. In fact, it appears the vqpasswd structure has already
been amended to add a "clear password", so why wasn't it just updated
to add fields for "storage quota" and "max message count" ? Wouldn't
that be cleaner? Sorry for going off topic... I'll stick to the subject
now.
So my suggestion would be to store 4 "quota type" fields to handle
storage/message count for per-domain/per-user. Any comments?
Here's what I would see as a new C structure:
/*
* permissions for non-postmaster admins
*/
#define VLIMIT_DISABLE_CREATE 0x01
#define VLIMIT_DISABLE_MODIFY 0x02
#define VLIMIT_DISABLE_DELETE 0x04
struct vlimits {
int maxpopaccounts;
int maxaliases;
int maxforwards;
int maxautoresponders;
int maxmailinglists;
int diskquota;
int maxmsgcount;
int defaultquota;
int defaultmaxmsgcount;
/* the following are 0 (false) or 1 (true) */
short disable_pop;
short disable_imap;
short disable_dialup;
short disable_passwordchanging;
short disable_webmail;
short disable_relay;
short disable_smtp;
/* the following permissions are for non-postmaster admins */
short perm_account;
short perm_alias;
short perm_forward;
short perm_autoresponder;
short perm_maillist;
short perm_maillist_users;
short perm_maillist_moderators;
short perm_quota;
short perm_defaultquota;
};
We need to patch qmailadmin to create another "AdminType"
to distinguish between "postmaster" and user admins. The
perm_??? items would have the VLIMIT_DISABLE_xxx masks
applied to them.
I'm sure there are other ways to handle this, such as
consolidate the maillist permissions to a single item
and add more bit flags to handle users & moderators.
But this can be done in the API function before it hits
the file or database.
And here's what I would see as a new database schema:
create table vlimits (
domain CHAR(64) PRIMARY KEY,
maxpopaccounts INT(10) NOT NULL DEFAULT -1,
maxaliases INT(10) NOT NULL DEFAULT -1,
maxforwards INT(10) NOT NULL DEFAULT -1,
maxautoresponders INT(10) NOT NULL DEFAULT -1,
maxmailinglists INT(10) NOT NULL DEFAULT -1,
diskquota INT(12) NOT NULL DEFAULT -1,
maxmsgcount INT(12) NOT NULL DEFAULT -1,
defaultquota INT(12) NOT NULL DEFAULT -1,
defaultmaxmsgcount INT(12) NOT NULL DEFAULT -1,
disable_pop TINYINT(1) NOT NULL DEFAULT 0,
disable_imap TINYINT(1) NOT NULL DEFAULT 0,
disable_dialup TINYINT(1) NOT NULL DEFAULT 0,
disable_passwordchanging TINYINT(1) NOT NULL DEFAULT 0,
disable_webmail TINYINT(1) NOT NULL DEFAULT 0,
disable_relay TINYINT(1) NOT NULL DEFAULT 0,
disable_smtp TINYINT(1) NOT NULL DEFAULT 0,
perm_account TINYINT(2) NOT NULL DEFAULT 0,
perm_alias TINYINT(2) NOT NULL DEFAULT 0,
perm_forward TINYINT(2) NOT NULL DEFAULT 0,
perm_autoresponder TINYINT(2) NOT NULL DEFAULT 0,
perm_maillist TINYINT(4) NOT NULL DEFAULT 0,
perm_quota TINYINT(2) NOT NULL DEFAULT 0,
perm_defaultquota TINYINT(2) NOT NULL DEFAULT 0
);
Note that this schema would take up *alot* less room than
the generic name/value alternative with little wasted space.
We need to figure out what other items are needed or desired.
This will also require that we have more developers go in and
start modifying the programs/utilities to actually *use* these limits. There are some that go all the way back to qmail
itself (i.e. smtp) as well as into imap, webmail, etc.
This is a discussion list, so please provide comments...
Thanks,
Brian
--Powered by Linux. My other OS is your Windows box.
