regarding LDAP lookups in newer amavis versions

Hi all,

Just working on tests with current amavis from Debian/etch
(2.4.2) to
replace a completely outdated installation I found. When
trying to turn
on LDAP lookups I run into the problem described as follows
in the
changelog:

  INCOMPATIBILITY:

  - removed some legacy $*_ldap variables, as they are no
longer needed;

    These variables were still declared but ignored in 2.2.0
for
    compatibility with older amavisd.conf files. Such
variables need to
    be removed from the amavisd.conf if they are still
present there
    from older versions, otherwise Perl will complain with
'Global
    symbol ... requires explicit package name";

What was the reason for disabling legacy variables? It seems
that I am
forced to use the amavis LDAP scheme now (which would mean
the running
custom LDAP installation) and I don't quite like that. Is
there a way to
use LDAP lookups with custom schemes?

Any hints appreciated.

Sincerely,
j.
-- 
Jogi Hofmueller |m| phone: +43 316 821 451 55
                |u| 
                |r|            http://mur.at/

------------------------------------------------------------
-------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216
239;13503038;w?http://sf.net/marketplace
_______________________________________________
AMaViS-user mailing list
AMaViS-userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user

AMaViS-FAQ:http://www.amav
is.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/ho
wto/

On Sat, Dec 15, 2007 at 08:48:11PM +0100, Jogi Hofmüller
wrote:

> Hi all,
> 
> Just working on tests with current amavis from
Debian/etch (2.4.2) to
> replace a completely outdated installation I found.
When trying to turn
> on LDAP lookups I run into the problem described as
follows in the
> changelog:
> 
>   INCOMPATIBILITY:
> 
>   - removed some legacy $*_ldap variables, as they are
no longer needed;
> 
>     These variables were still declared but ignored in
2.2.0 for
>     compatibility with older amavisd.conf files. Such
variables need to
>     be removed from the amavisd.conf if they are still
present there
>     from older versions, otherwise Perl will complain
with 'Global
>     symbol ... requires explicit package name";
> 
> What was the reason for disabling legacy variables? It
seems that I am
> forced to use the amavis LDAP scheme now (which would
mean the running
> custom LDAP installation) and I don't quite like that.
Is there a way to
> use LDAP lookups with custom schemes?
> 
> Any hints appreciated.

The old code was completely rewritten ages ago, it was
inefficient
and unuseable with any sort of volume.

In the long run the best thing to do would be to change
things to allow
use of the amavis LDAP schema and be done with it. Otherwise
you could
edit the source and replace all occurences of the standard
attribute
with your desired attibute, ex ( amavisSpamLover ->
my_attr ):

$ grep amavisSpamLover /usr/local/sbin/amavisd
      unshift(Amavis::Conf::spam_lovers_maps,        
$lf->('amavisSpamLover',          'B-'));
  ldap_attrs = qw(amavisVirusLover amavisSpamLover
amavisBannedFilesLover

would become:

      unshift(Amavis::Conf::spam_lovers_maps,        
$lf->('my_attr',          'B-'));
  ldap_attrs = qw(amavisVirusLover my_attr
amavisBannedFilesLover

and then test before using.

--
If a tree falls on a mime, will the mime yell for help?

Mike Hall
San Juan Island, WA

System Admin - Rock Island Technology Solutions    
<mikehrockisland.com>
System Admin - riverside.org, ssdd.org             
<mhallriverside.org>

------------------------------------------------------------
-------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216
239;13503038;w?http://sf.net/marketplace
_______________________________________________
AMaViS-user mailing list
AMaViS-userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user

AMaViS-FAQ:http://www.amav
is.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/ho
wto/

Jogi,

> Just working on tests with current amavis from
Debian/etch (2.4.2) to
> replace a completely outdated installation I found.
When trying to turn
> on LDAP lookups I run into the problem described as
follows in the
> changelog:
>   INCOMPATIBILITY:
>   - removed some legacy $*_ldap variables, as they are
no longer needed;
>     These variables were still declared but ignored in
2.2.0 for
>     compatibility with older amavisd.conf files. Such
variables need to
>     be removed from the amavisd.conf if they are still
present there
>     from older versions, otherwise Perl will complain
with 'Global
>     symbol ... requires explicit package name";
> What was the reason for disabling legacy variables? It
seems that I am
> forced to use the amavis LDAP scheme now (which would
mean the running
> custom LDAP installation) and I don't quite like that.
Is there a way to
> use LDAP lookups with custom schemes?

The LDAP module was rewritten for 2.2.0 (November 2004) and
updated
for 2.3.2 (June 2005), both by Michael Hall. I believe the
main reason
was to avoid one query per attribute, and do a single query
for all
attributes (matching a filter), then fulfill attribute
queries from
a cached result. Seems in this process the decoupling of
attribute
names from their function was abandoned - probably because
many new
attributes were introduced, which would call for a bunch of
additional
global variables, which didn't appear to be nice or
necessary.

I think it wouldn't be to difficult to re-introduce such
indirection,
but this time not through individual variables, but through
some
perl associative array. Since I'm not using LDAP myself: any
volunteers
to do it and test it? Is Michael still around?

  Mark

------------------------------------------------------------
-------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216
239;13503038;w?http://sf.net/marketplace
_______________________________________________
AMaViS-user mailing list
AMaViS-userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user

AMaViS-FAQ:http://www.amav
is.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/ho
wto/

On Tue, Dec 18, 2007 at 05:57:49PM +0100, Mark Martinec
wrote:

> Jogi,
> 
> > Just working on tests with current amavis from
Debian/etch (2.4.2) to
> > replace a completely outdated installation I
found. When trying to turn
> > on LDAP lookups I run into the problem described
as follows in the
> > changelog:
> >   INCOMPATIBILITY:
> >   - removed some legacy $*_ldap variables, as they
are no longer needed;
> >     These variables were still declared but
ignored in 2.2.0 for
> >     compatibility with older amavisd.conf files.
Such variables need to
> >     be removed from the amavisd.conf if they are
still present there
> >     from older versions, otherwise Perl will
complain with 'Global
> >     symbol ... requires explicit package
name";
> > What was the reason for disabling legacy
variables? It seems that I am
> > forced to use the amavis LDAP scheme now (which
would mean the running
> > custom LDAP installation) and I don't quite like
that. Is there a way to
> > use LDAP lookups with custom schemes?
> 
> The LDAP module was rewritten for 2.2.0 (November 2004)
and updated
> for 2.3.2 (June 2005), both by Michael Hall. I believe
the main reason
> was to avoid one query per attribute, and do a single
query for all
> attributes (matching a filter), then fulfill attribute
queries from
> a cached result. Seems in this process the decoupling
of attribute
> names from their function was abandoned - probably
because many new
> attributes were introduced, which would call for a
bunch of additional
> global variables, which didn't appear to be nice or
necessary.
> 
> I think it wouldn't be to difficult to re-introduce
such indirection,
> but this time not through individual variables, but
through some
> perl associative array. Since I'm not using LDAP
myself: any volunteers
> to do it and test it? Is Michael still around?

Yes, I'm still lurking around, actually I had already
replied to this.

Has something similar been done for SQL or do you have any
ideas, thoughts
on how you would like to see this done?

--

Mike Hall
San Juan Island, WA

System Admin - Rock Island Technology Solutions    
<mikehrockisland.com>
System Admin - riverside.org, ssdd.org             
<mhallriverside.org>

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
AMaViS-user mailing list
AMaViS-userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user

AMaViS-FAQ:http://www.amav
is.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/ho
wto/

Hello people,

Thanks for your replies.  It looks to me like the easiest
way out is to
use the LDAP scheme provided by amavis itself.  When I stick
to amavis
from Debian I would have to rewrite the code anytime I
update/upgrade it
and that would introduce another source for errors (allready
have enough
of these).

Cheers,
j.
-- 
Jogi Hofmueller |m| phone: +43 316 821 451 55
                |u| 
                |r|            http://mur.at/

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
AMaViS-user mailing list
AMaViS-userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user

AMaViS-FAQ:http://www.amav
is.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/ho
wto/