Hi Justin,

  > hi..
  > could you explain some of the vlimits to me?
  > i understand the disable_*
  > and i think i understand diskquota, maxmsgcount, defaultquota and 
  > defaultmaxmsgcount plus the other max* stuff.
  > diskquota = a quota for the full domain, i.e  
  > # du -sh ~vpopmail/domains/domain.com  
  > while defaultquota just is the default setting for a useraccount, right?
  > (same for maxmsgcount/defaultmaxmsgcount)
  > 
  > what is the "perm_*" all about?

Permissions for non-postmaster admin's.

  > oh.. and i've made several changes for the better integration of vlimits.
  > e.g. vadddomain (), vdeldomain () are calling vset_limits/vdel_limits (with 
a 
  > default set of limits) and i'm writing a vsetdomlimits commandline utility 
at 
  > the moment.

Thats a great thing.

  > furthermore i've removed disable_* and replaced it with 
  > default_permissions_mask (altered vlimits.c/vmysql.c/vlimits.h).

Ahhhh

No, don't do this, please.

I understand the concept, but please don't do this.
The disable_* fields would apply to the domain to
disable services for all users of a domain and the
new field would just set the default for new users added.

It really doesn't use as much space as you think.
Its about 0.4 Kb per domain (less than half a kilobyte).


  > the idea is: default_permissions_mask is the default gid mask for every user 
  > of a domain. if it has the NO_IMAP flag set, and you want some user to get 
  > imap support: set the V_USER0 flag for that user and make sure NO_IMAP is 
  > unset in that user's gid.
  >
  > as soon as V_USER0 is set, it completly ignores the 
default_permissions_mask.

This I don't understand.  I understood that the field would
contain the default permissions for new users.  If you need
to change the permissions of a single user, then you just
update GID field on the password entry.

  > 
  > 
  > i'm going to post the diffs later..
  > 
  > -- 
  > Mit internetten Grüßen / Best Regards
  > ---------------------------------------------------------------------------
  > Justin Heesemann                                        ionium Technologies
  > [EMAIL PROTECTED]                                                www.ionium.org
  > 




Reply via email to