opensubscriber
   Find in this group all groups
 
Unknown more information…

v : vchkpw@inter7.com 3 September 2009 • 11:56PM -0400

Re: [vchkpw] Patch to disable vusaged
by Tonix (Antonio Nati)

REPLY TO AUTHOR
 
REPLY TO GROUP




Simone Lazzaris ha scritto:
> In data giovedì 03 settembre 2009 hai scritto:
>  
>> Simone Lazzaris wrote:
>>    
>>> Our setup is spreaded on many servers (think 20), with the mail stored on
>>> an NFS share (NetApp).
>>>      
>> The vusage daemon is written with this in mind, though it's more efficient
>> to have it run on the device providing storage so that it isn't doing disk
>> polling over a network connection.
>>
>>    
>
> Ok, I can undestand that.
>
>  
>> The vusage daemon accepts connections from an allowed list of IPs for usage
>> queries so that it can be used in a cluster efficiently.
>>
>>    
>>> Right now the various tool all use the maildirsize file (Maildir++ I
>>> think it's called) to track the usage, updating this as they put/fetch
>>> the email.
>>>      
>> Correct.  vusaged supports Maildir++, and at this time, ignores maildirsize
>> because it's redundant, and inefficient means of calculating storage.
>>
>> Later, vusaged will be updated to re-write maildirsize.  It's currently set
>> to be in addition to existing quota monitoring systems, with a greater
>> efficiency, as to deprecate other quota configuration systems, but it
>> should not interfere or cause number variances.
>>
>>    
>>> Is vusaged supposed to work in a similar setup ? I'd have to integrate it
>>> with maildrop, dovecot and a couple of perl scripts.
>>>      
>> That depends upon a great many things, such as, what is checking quotas,
>> and when.  In general, if the daemon is running, and it does not have to
>> be, both Maildir++ quotas, and vpopmail's vusage style of quota checking
>> should work fine at the same time.
>>
>> If vusaged is not running, Maildir++ quotas should continue to work.
>>    
>
> Ok, but how can be syncronized the two vision of the quota, if only vpopmail
> uses vusaged ? I think that there can be only two cases
> 1) all tools use vusaged or
> 2) all tools use traditional Maildir++ quota.
>
> In any other combination, the two vision of the real maildir quota will go
> quickly out of sync.
>  

Besides vpopmail, there are a lot of other important tools (like dovecot
for example) which as far as I know are not using vpopmail, and rely on
Maildirs.

When the old domain quota code was going to be released,  I told
(against the mainstream) the code was bad for this reason, not being
compatible with the rest of the world. Code was cut after some years of
demostrated incompatibility.
I hope the same error is not replicated again.

>>>>> I've looked the code and found that there were no option to disable the
>>>>> usage.
>>>>>          
>>>> Turn off their quota and the vusage daemon shouldn't be looked at.  If
>>>> that isn't what's happening, then that is the bug.
>>>>        
>>> No, I want to use the quota, but with the old method, looking at the
>>> maildirsize file. That's missing (if I've understood the code).
>>>      
>> In 5.4.28, if the vusage daemon is not running, traditional Maildir++ quota
>> checking is done.
>>    
>
> Yes, and this works, but it generate an error message each time the daemon is
> searched for. For a normal deliver, that means at least 3 error messages on
> the log file. And 3 attempts to open the socket.
> I think it's more efficent, and cleaner, to check if one wants to disable the
> daemon, adding a line in the config file. My patch just do that.
>  

I did not imagine vusaged was so intrusive!
Is should be completely disabled if not needed.

Tonino

--
------------------------------------------------------------
        Inter@zioni            Interazioni di Antonio Nati
   http://www.interazioni.it      tonix@inte...          
------------------------------------------------------------



!DSPAM:4a9fe72932711236566907!

Bookmark with:

Delicious   Digg   reddit   Facebook   StumbleUpon

Related Messages

opensubscriber is not affiliated with the authors of this message nor responsible for its content.