>> Quotas is implemented using a moving window, this window moves >> automatically with time so there is no fixed counter of how much is used >> or if the user is currently over quota. >>> On that note, I'm a bit puzzled >>> over the floating point number that shows the current number (the >>> "counter" parameter in the quotas_tracking table). Does, in fact, this >>> number somehow incorporate this information? >>> >> >> Well, yes. >> >> You can check if the counter exceeds the limit for CumulativeSize and if >> counter + 1 >= limit for MessageCount. >> >> Counter is basically the extrapolated count either of cumulative size or >> messages received in the time period. CumulativeSize will exceed the >> counter, MessageCount won't. >> >> Other than that, maybe the accounting module may be a better bet? >> >> -N > > Hmmm... seems like you'd have to run a comparison for every entry vs. > the policy number and the associated limit. I see what you mean about > the window; it's a very different implementation than in V1.8.X.
Yea. > > We're running 2.0.7, so it looks like we should take a closer look at > 2.1.0 or higher to gain access to the accounting module; how stable is > it at this point? I'm running it. It has some experimental caching capabilities an I'd like to hear how it works for you, but all in all it should be fine. > Would the MySQL DB have to be re-created to support this, or is it > just a question up upgrading the software on the servers? > From 2.0 to 2.1 there is a file in 2.1.x called UPGRADING which describes the changes. There is one table column name change, but I'm sure if you add another column with the same end resulting name and copy the orig to the new name you can run both packages even at the same time. If you run into any problems I'll fix them. -N
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Users mailing list [email protected] http://lists.policyd.org/mailman/listinfo/users
