> 
  > 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


I've had the basic table layouts done since January
and have been running in production with a patched
vdelivermail and qmailadmin since then.  Mine supports
the limits as given, and the quotas (not message counts)
in vdelivermail.  It should take more or less an hour to
get this written - actually just change what I have
to include the additional fields, however you're only
the second person to reply to this.  I was hoping to get
a consensus from people as to what else is needed or
required, or find out if its overkill and to strip some.

Thanks,

Brian

  > 
  > 
  > > 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.
  > 


Reply via email to