Loading ...
Sorry, an error occurred while loading the content.

Re: feature in the ldap code. bug report.

Expand Messages
  • Peter Källdén
    Thanks for your quick reply, I ll see if I can come up with some workaround to the problem. I can t change the schema since it s not designed by me. I handle a
    Message 1 of 3 , Nov 28, 2005
    • 0 Attachment
      Thanks for your quick reply, I'll see if I can come up with some workaround to the problem. I can't change the schema since it's not designed by me.
      I handle a subdomain, with postfix and use the ldap from the provider above me.

      On Thursday 24 November 2005 17.37, Victor Duchovni wrote:
      > On Thu, Nov 24, 2005 at 04:23:49PM +0100, Peter K?lld?n wrote:
      > > I believe I have found a 'feature' in the ldap code.
      > The documented feature is that results stored in multiple attributes
      > are concatenated and order is not significant.

      not all data is concatenated, not that that helps me in anyway :).
      if you have a recursive question that returns 2 attribs, the lookup of %s is done twice if one of the attribs matches the %s string, resulting in the string not matching %s being
      concatenated twice, but the %s string being concatenated once. That behavior is odd, I understand why, but it is still odd.

      > > This could obviously be worked around through changing the ldap
      > > structure, that is however no option in this case.
      > If your current LDAP schema cannot express the tables needed by
      > Postfix, you need to change your LDAP schema.
      > > It would be nice if this got fixed in some way. :)
      > >
      > Asking for features by declaring code that works as designed
      > and documented to be buggy is not the best way forward.
      > If you want to match a second attribute only when the first
      > attribute alone is not enough you need two (or three) tables:
      > mumble_maps = ldap:map1, ldap:map2
      > map1 returns the first attribute only under conditions in
      > the query filter that make that the right result, otherwise
      > the query falls through to map2 where it may return a different
      > set of attributes, ...
      > The Postfix LDAP table syntax cannot express conditional use of
      > returned attributes within a single table specification. This is
      > not a bug.

      that's not what I am asking for.

      > If you can design a sensible syntax for expressing which of many returned
      > attributes are the right ones to include for any particular object,
      > perhaps someone will be motivated to implement the design. Note that
      > this is rather subtle, because you need a proposional calculus in the
      > Postfix LDAP driver (in addition to the LDAP server) to evaluate complex
      > conditionals that specify which attributes are valid in any context. That
      > way lies madness.

      You do not need to device any such scheme. A map should never append to the list of results what has already
      been appended in that same map for one particular message id, unless maybe you have a bool that could turn
      off this behavior. This only affects recursive queries. Surely there must be some kind of dynamic hash
      tables or btree functions in postfix you can use for this behavior?
      Even when a recursive query results in a dn that we do a lookup on, we don't want any previously appended
      results to be appended again, it could result in loops. Misstakes on the board for ldap management shouldn't spam
      mail, or possibly dos your postfix server.
      If one group contains 2 groups, where an address is member in both, he would receive 2 mails with current
      design if a message was sent to the 'wrapper' group and the result was returned with a recursive query. Not what was
      intended I'm sure. I know you can do the same with normal maps, but let's pretend schema constraints forces you to
      use recursive queries.
      I'm possibly limited in my imagination, but I can't seem to think out one sane reason where I would want
      any same result returned more than once from one query map for a particular msg.

      > In practice the need for such constraints is a strong symptom of poor
      > schema design. I for one am not inclined to make the LDAP table code
      > complex and fragile to support inappropriate schemas.

      that's true, however in reallife you are not always in a position where you can choose the ldap schema design yourself,
      esp if it is produced from commercial products.
      If the code gets fragile from the above suggestion or not I wouldn't know, since I haven't studied the postfix code.

      > Here's a much better schema:
      > user:
      > mail: single-valued primary address
      > mailalternateaddress: multi-valued holds *ALL* valid addresses
      > of the user including a second copy of "mail".
      > maildrop: multi-valued, holds all addresses to which the users
      > mail is delivered.
      > This works for groups too, unless you want to store groups as lists of
      > user DNs, in which case:
      > group:
      > mail: single-valued primary address
      > mailalternateaddress: multi-valued holds *ALL* valid addresses
      > of the group including a second copy of "mail".
      > members: multi-valued, the DNs of member users
      > NOTE: this type of group has no "maildrop" attribute:
      > Address rewriting reduces to a single trivial table:
      > virtual_alias_maps = ldap:lvirtual
      > #
      > lvirtual_query_filter = mailalternateaddress = %s
      > lvirtual_result_attribute = maildrop
      > #
      > # Optional if groups store user DNs
      > #
      > lvirtual_special_result_attribute = members
      > #
      > # Safety if groups can store group DNs
      > # cf. virtual_alias_expansion_limit = 1000
      > # virtual_alias_recursion_limit = 1000
      > #
      > lvirtual_recursion_limit = 1000
      > lvirtual_expansion_limit = 1000
      > Simple direct schema design pays off. There are no conditionals here,
      > if an address is listed it used, if it is not it is not used. The rest
      > is up to your management tools. Don't push the management logic onto
      > the data consumers.

      don't take me wrong on this.. postfix is great software, and is one of the most stable mail servers I've used.

      Thanks for a good product,


      Peter Källdén <peter.kallden@...>
      Örebro UNI, Library

      PGP Key-ID: 0x41C60D62
    Your message has been successfully submitted and would be delivered to recipients shortly.