From: Anthony Howe
Date: 2006-09-30 03:36:36 -0400
Subject: Re: milter-link issue
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.
Anthony C Howe Skype: SirWumpus SnertSoft
+33 6 11 89 73 78 AIM: SirWumpus Sendmail Milter Solutions
http://www.snert.com/ ICQ: 7116561
Copyright 2009, 2012 by SnertSoft. All rights reserved.