From: Ben Spencer
Date: 2008-12-23 06:51:15 -0500
Subject: Re: central access_db
More information..: http://www.milter.info/#Support
> 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.
Ermm...ummm...this is what I have been doing up to this point (by hand). While
updating isn't a day to day operation, it is cumbersome.
> 2. The simple way. The milters have supported "socketmap" for some
> So write a socketmap / LDAP transformation daemon that sits on the LDAP
> server and acts as an interface between the milters and the LDAP
> 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
> is having to write in C, Perl, Python, Ruby the necessary socket map
> server and LDAP client code.
I did see this option when I was looking at the documentation for the milters.
Was going to go back and see what exactly that was. Thanks for the
introduction here. Might look into this still, though the idea of writing code
for a production box which would need understood/maintained by others should I
not be here just isn't that appealing. Seems like maybe worth investigating
> 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
> 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.
Ahhh...thanks for the pointer to kvmd.
> 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
Thank you thank you. You gave me a couple of things to look into and I am sure
I can use one of these as a solution to this little headache.
-- Binary/unsupported file stripped by Ecartis --
-- Type: application/x-pkcs7-signature
-- File: smime.p7s
Copyright 2009, 2012 by SnertSoft. All rights reserved.