[milters] Archive

Lists Index Date Thread Search

Article: 1928
From: Anthony Howe
Date: 2008-12-23 02:55:01 -0500
Subject: Re: central access_db

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

> Confirming: The milter themselves open and look up the data in the access.db
> and this functionality isn't provided through sendmail.


> With the above being true, it removes the ability to centrally manage access
> information via sendmail's LDAP map feature. How do others manage access.db
> information  when more than one host is involved but all hosts need the same
> access data?

Three ways come to mind.

1. The hard way is to extract and replicate the access data multiple
machines. Advantage is that each machine has its own copy of the data
locally. The disadvantage is if the replication is manually done, you
can easily miss a step or machine. If scripted, then there is simply a
risk the replication fails for a period of time, meaning machines are
out of sync for a period.

2. The simple way. The milters have supported "socketmap" for some time.
So write a socketmap / LDAP transformation daemon that sits on the LDAP
server and acts as an interface between the milters and the LDAP server.
Advantage is the data is available in real time. Disadvantage is if the
centralised transformation daemon goes down, the MXes are without data,
but this is also true if LDAP were used directly. The other disadvantage
is having to write in C, Perl, Python, Ruby the necessary socket map
server and LDAP client code.

3. The hybrid way. Extract the LDAP access data to a local access file /
database on the LDAP machine. Then use the kvmd tool on the LDAP machine
provided with libsnert to read the access flatfile, Berkeley DB, or
Sqlite3 DB and serve it out via socketmap protocol to all the milters.
This removes the hard part of creating the socket server and avoid
having to figure out the LDAP client code. You only need to script the
extraction once and don't have to worry about replication.

Using a Berkley DB or Sqlite3 DB you can avoid restarting kvmd when the
access data is updated. The kvmap tool can be used to transform the
access flat file into either Berkeley or Sqlite3 DB.

In libsnert type/kvmap, kvmc, and kvmd were originally written to test
the Key-Value-Map API code. The tools are documented in their usage text.

Anthony C Howe        Twitter: SirWumpus                    SnertSoft
+33 6 11 89 73 78       Skype: SirWumpus        BarricadeMX & Milters
http://www.snert.com/     ICQ: 7116561

Lists Index Date Thread Search