Discussion:
$myhostname passing through unresolved in ldap table queries
(too old to reply)
Graham Leggett
2012-11-26 20:59:00 UTC
Permalink
Hi all,

I've had an LDAP table in main.cf configured for a number of years containing the following filter, and this has worked fine. The filter matches all email addresses that should be delivered anywhere except for the local server:

ldapremote_query_filter = (&(|(mail=%s)(mailAlternateAddress=%s))(!(mailHost=$myhostname)))

I have since tried to update the LDAP table configuration to use separate files as recommended by the docs, for example ldap:/etc/postfix/remove.cf, and after doing so delivery fails with a mail loop. It turns out using the new LDAP table syntax the value of "myhostname" is no longer parsed and the string is passed through to the LDAP query unmodified:

[26/Nov/2012:22:26:29 +0200] conn=38950 op=459 SRCH base="dc=a,dc=a,dc=a" scope=2 filter="(&(|(mail=***@a.a.a)(mailAlternateAddress=***@a.a.a))(!(mailHost=$myhostname)))" attrs="mailHost"

Is this a problem anyone has picked up before?

I am currently using postfix-2.3.3-2.3.el5_6 as published by RHEL5.

Regards,
Graham
--
Wietse Venema
2012-11-26 21:25:15 UTC
Permalink
Post by Graham Leggett
Hi all,
I've had an LDAP table in main.cf configured for a number of years
containing the following filter, and this has worked fine. The
filter matches all email addresses that should be delivered anywhere
ldapremote_query_filter =
(&(|(mail=%s)(mailAlternateAddress=%s))(!(mailHost=$myhostname)))
I have since tried to update the LDAP table configuration to use
separate files as recommended by the docs, for example
ldap:/etc/postfix/remove.cf, and after doing so delivery fails
with a mail loop. It turns out using the new LDAP table syntax the
value of "myhostname" is no longer parsed and the string is passed
Postfix will expand $myhostname etc. in LDAP parameters *only* when
you specify those parameters in main.cf.

Wietse
Graham Leggett
2012-11-26 21:41:56 UTC
Permalink
Post by Wietse Venema
Post by Graham Leggett
I've had an LDAP table in main.cf configured for a number of years
containing the following filter, and this has worked fine. The
filter matches all email addresses that should be delivered anywhere
ldapremote_query_filter =
(&(|(mail=%s)(mailAlternateAddress=%s))(!(mailHost=$myhostname)))
I have since tried to update the LDAP table configuration to use
separate files as recommended by the docs, for example
ldap:/etc/postfix/remove.cf, and after doing so delivery fails
with a mail loop. It turns out using the new LDAP table syntax the
value of "myhostname" is no longer parsed and the string is passed
Postfix will expand $myhostname etc. in LDAP parameters *only* when
you specify those parameters in main.cf.
In my case $myhostname is unset, meaning fall back to the default of using the fully-qualified domain name from gethostname(), and this has worked in the past for LDAP tables specified in main.cf.

If I am understanding you correctly are you saying that only if parameters are explicitly set to a concrete value in main.cf, will this value be available in the LDAP table, the defaults are no longer enough?

Regards,
Graham
--
Viktor Dukhovni
2012-11-26 23:24:02 UTC
Permalink
On Mon, Nov 26, 2012 at 11:41:56PM +0200, Graham Leggett wrote:

[ This is not a postfix-devel topic, redirecting to postfix-users ]
Post by Graham Leggett
Post by Wietse Venema
Post by Graham Leggett
I've had an LDAP table in main.cf configured for a number of years
containing the following filter, and this has worked fine. The
filter matches all email addresses that should be delivered anywhere
ldapremote_query_filter =
(&(|(mail=%s)(mailAlternateAddress=%s))(!(mailHost=$myhostname)))
I have since tried to update the LDAP table configuration to use
separate files as recommended by the docs, for example
ldap:/etc/postfix/remove.cf, and after doing so delivery fails
with a mail loop. It turns out using the new LDAP table syntax the
value of "myhostname" is no longer parsed and the string is passed
Postfix will expand $myhostname etc. in LDAP parameters *only* when
you specify those parameters in main.cf.
If I am understanding you correctly are you saying that only if
parameters are explicitly set to a concrete value in main.cf, will
this value be available in the LDAP table, the defaults are no
longer enough?
No. What Wietse is saying is that recursive main.cf parameter
expansion where the value of one parameter can interpolate the
value of another via ${parameter} expansion is only available in
main.cf (and in master.cf "-o name=value" options).

In "table.cf" files that define various lookup tables, there is
no support for such variable interpolation.

This is similar to /bin/rm not supporting "rm *", that's the shells
job. The shell replaces "*" with the list of files to be removed,
and "rm" just removes the explicit list of files. Likewise, main.cf
gives the LDAP table driver the query filter (already expanded)
and that's all the LDAP table driver understands. When the query
is in a "table.cf" file, and not in main.cf the table driver
processes it directly and no parameter substitution takes place.

If you want a variable ${myhostname} in the LDAP .cf file, you have
to machine-generate that file.
--
Viktor.
Loading...