Curtis,
> I would prefer to use a MySQL database, but that's a learning curve and
> until I can make that work (I have to learn how to do the whole policies
> thing.) There is a feature where the system wide lists (scores) can be
> read from a hash table via the read hash function. I was told that it
> was a straight perl hash table. My assumption that it used "tie %hash,
> 'DB_Hahs',$filename, 0640;". It seems to me that this would be fairly
> efficient. However, when I pre compiled my hash table using "postmap
> hash:filename," amavis segfaulted.
>
> is my hash table just a whitespace separtated text file with one entry
> per line? How is this hash file supposed to be built? The
> documentation is not clear on this subject at all.
The read_hash (and read_array) subroutines do not tie a hash to a file,
but simply read a text file, parse it (separate a key from a value
which may be omitted), and build an in-memory perl hash (or array).
Reading is done only once at the time or a call (typically they are
called from a config file), later changes to a file have no effect
until the next 'amavisd reload'.
The syntax or a text file to be read by read_hash is indeed one entry
per line. All-whitespace lines and comment lines (#) are ignored.
Here are the comments from the read_hash() declaration:
# read a lookup associative array (Perl hash) from a file - may be called
# from amavisd.conf
#
# Format: one key per line, anything from '#' to the end of line
# is considered a comment, but '#' within correctly quoted rfc2821
# addresses is not treated as a comment introducer (e.g. a hash sign
# within "strange # \"foo\" address"@example.com is part of the string).
# Lines may contain a pair: key value, separated by whitespace,
# or key only, in which case a value 1 is implied. Trailing whitespace
# is discarded (iff $trim_trailing_space_in_lookup_result_fields),
# empty lines (containing only whitespace or comment) are ignored.
# Addresses (lefthand-side) are converted from rfc2821-quoted form
# into internal (raw) form and inserted as keys into a given hash.
# NOTE: the format is partly compatible with Postfix maps (not aliases):
# no continuation lines are honoured, Postfix maps do not allow
# rfc2821-quoted addresses containing whitespace, Postfix only allows
# comments starting at the beginning of a line.
#
# The $hashref argument is returned for convenience, so that one can do
# for example:
# $per_recip_whitelist_sender_lookup_tables = {
# '.my1.example.com' => read_hash({},'/var/amavis/my1-example-com.wl'),
# '.my2.example.com' => read_hash({},'/var/amavis/my2-example-com.wl') }
# or even simpler:
# $per_recip_whitelist_sender_lookup_tables = {
# '.my1.example.com' => read_hash('/var/amavis/my1-example-com.wl'),
# '.my2.example.com' => read_hash('/var/amavis/my2-example-com.wl') }
> My assumption that it used "tie %hash,
> 'DB_Hahs',$filename, 0640;". It seems to me that this would be fairly
> efficient. However, when I pre compiled my hash table using "postmap
> hash:filename," amavis segfaulted.
It would be possible to use a hash tied to a file. I've tried it
in the past and it does work, certainly it shouldn't cause a crash,
unless there is a mismatch between version of a db shared library
and include files.
Note that a bdb as built by postmap (Postfix) includes a redundant
null character at the end of keys and at the end of values, unless
option -n is used with postmap. Amavisd uses the whole key and value
regardless of its contents, so the extra "\0" in each key would not
match any lookup query. As Postfix can deal with bdb files with
or without the extra null, one solution is to always use -n when
using postmap, the other solution is to use $db->filter_fetch_key
and $db->filter_fetch_value filters as provided by BerkeleyDB
or DB_File to strip off the extra nulls.
Unless one has a huge database file, I don't see much advantage
in using a tied hash vs. a normal in-memory hash. As record locking
is not available in a simple tied hash, changes to a database file
are not necessarily instantly visible to other processes, so one
would still need to restart amavisd on changes in a database file.
Mark
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
AMaViS-user mailing list
AMaViS-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/
