Quotas in LDAP
Tommi and I have been discussing various issues related to LDAP and quotas
through the BTS, we started discussing email quotas but moved on to file
system quotas too. I believe that we need more input on this matter and that
this is the best place to get it.
> > Also I would like to make them more generic. For example having a quota
> > object that may have mailQuota and diskQuota attributes.
>
> You mean quota objecttype, I guess? diskQuotas are harder; you
> each disk on each disk has a separate quota for each user, and
> such a quota consists of many settings ({soft,hard}
> {inode,block} count). I am not sure how to represent that in
> LDAP.
Yes, I mean a quota objectClass which can be added to an object.
For disk quotas it would be possible to have multiple objects of the quota
objectClass under the user's entry (which is nasty and inefficient). Or we
could make the quota attributes accept text and be multivalued, eg:
dn: uid=user,dc=company,dc=com
objectClass: ...
quota: /home:4096
quota: /tmp:10240
quota: /var/spool/mail:1024
The more I think about this the more it seems that having textual fields for
the quota values is the solution. Also it would allow setting a quota name
which means that another LDAP lookup is to be done on the name to determine
the real quota (so we could change the quotas of a million users with a
single operation).
Now the standard file system quota system has the following limit fields:
block soft
block hard
block grace
inode soft
inode hard
inode grace
I'd like to see a quota on the number of messages as well as disk space.
I used to run a server that had a disk quota of 5M per user with 1K
increments, however the file system used 8K blocks! Most messages are small
so many accounts had ~4000 1K messages which used >30M of disk space (and we
ran out of space). Having the quota in units other than 1K confuses the
users and adds to help-desk costs. Having another quota of 500 messages
would not confuse the user and would save disk space (not many people will
read 500 messages anyway).
So I think that we need both inode limits and block limits for email. The
need for hard limits is obvious. I also believe that there is a place for
soft quotas of email. Some mail systems know of the quotas at the time the
SMTP connection comes in, they can refuse a connection without accepting the
message if it is over quota. If someone has 10M of free quota and they
receive a 10.5M file then it makes sense to accept the last 0.5M of data, so
having the hard quota be the absolute limit and the soft quota be the maximum
storage that may be used for a new message to be accepted will work.
So I think that there is good need for the following quotas for email:
block soft
block hard
inode hard
The question is, should I create a schema that supports all the following as
"may" so that a sub-set of the attributes can be used for email quotas and
the full set can be used for disk quotas?
block soft
block hard
block grace
inode soft
inode hard
inode grace
Also this gives another reason for using textual attributes, we could have
the following for quotas for email and web space:
dn: uid=user,dc=company,dc=com
objectClass: ...
quotaBlockHard: email:4096
quotaBlockHard: web:102400
quotaInodeHard: email:1024
quotaInodeHard: web:1024
> One thing I am concerned with is maintainability of the LDAP
> tree. I'm basically a) maintaining it manually with
> ldapsearch|sed|ldapmodify b) forced to write my own tools.
> That's why I decided to implement things like looking for the
> quota from the parent dn..
I agree that using a single DN for everything is best if it can be managed in
a clear scalable fashion. The more DNs you have the more load on the LDAP
servers and the mail delivery machines, and thus the more money we have to
spend on hardware.
--
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page
Reply to: