On Thu, 24 Oct 2002, John Johnson wrote:
> I am not a programmer but from what I can see this
> 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
>
Yeah. This sounds good. I just find out that I need qmailadmin-limits
myself too, and it would be nice to store this data in mysql.
Brian, do you already have some patches for this?
I'm willing to test and maybe spent some time coding this if needed..
- Pasi Kärkkäinen
> 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.
>
^
. .
Linux
/ - \
Choice.of.the
.Next.Generation.
