[milters] Archive

Lists Index Date Thread Search

Article: 1161
From: Ken
Date: 2006-09-30 14:01:44 -0400
Subject: Re: milter-link issue

Removal...........: milters-request@milter.info?subject=remove
More information..: http://www.milter.info/#Support
--------------------------------------------------------

Anthony Howe wrote:
> Removal...........: milters-request@milter.info?subject=remove
> More information..: http://www.milter.info/#Support
> --------------------------------------------------------
>
> Ken A wrote:
>   
>> Anthony Howe wrote:
>>     
>>> Ken A wrote:
>>>       
>>>> Using milter-link version 0.2.13 / LibSnert 1.61
>>>>
>>>> I've noticed a issue where milter-link began ignoring it's whitelist 
>>>> access db. Not sure what caused it, but a restart fixed it. I see there 
>>>>         
>  >>
>   
>>> Check file permissions & ownership. When you restart the milter it 
>>> starts as root, opens its .pid and the access.db, then changes ownership 
>>> to milter:milter. Subsequent updates of access.db will be detected and 
>>> reopened only if process as milter:milter can read access.db. The 
>>> symptom you describe would indicate that access.db has permission and/or 
>>> ownership problems.
>>>
>>>       
>> I use access-db=/etc/mail/milter-link-access.db in the command line and
>>
>> -rw-r--r--  1 root root  49152 Sep 28 15:49 milter-link-access.db
>>     
>
> Its world readable which is fine, but otherwise it should be owned by 
> milter:milter, then you could remove the world-readable permission.
>
>   
>> it's readable.
>>
>> Does milter link also require access to sendmail's access.db ?
>> sendmail's access.db has other functions, so I like to keep the two 
>> separate. Is this perhaps an issue?
>>     
>
> You can specify a different access.db from that of sendmail, but the 
> whole point of using the sendmail access.db is to a) avoid duplication 
> of information and b) keep all the information centralised.
>
> Another thing that can cause any of my milters to not reopen the 
> access.db file depends on how you update the file. If you simply 
> overwrite the access.db with:
>
> 	makemap hash access <access
>
> my milters _will_ detect the update and reopen the access.db.
>
> If you have a script or makefile that does a "create then move", like:
>
> 	makemap hash access.new <access
> 	mv access.new.db access.db
>
> this will fail, because my milter maintain an open file descriptor to 
> the old access.db so that they can use fstat(), instead of stat(), to 
> detect a file update, which is faster and more efficient. fstat() will 
> not see the file replacement. This is related the common unix idiom that 
> a file is not deleted until the last file descriptor is closed.
> 	
>
>   
That is probably what happened in this case, since I routinely scp the 
milter-link-access.db to several mostly identical boxes after makemap 
hash...
Thanks for the explanation.
Ken A.
Pacific.Net




Lists Index Date Thread Search