RE: suffixalias gets stuck in 2.1.5

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Rick van Rein

> Hello,
>
> I got OpenLDAP 2.1.5 working on FreeBSD, but it consistently
> gets stuck
> with suffixaliases (which I'm trying for the first time).
>
> My bdb database is setup like this (btw, I really missed a HOWTO on
> suffixaliases, or just example configs):
>
> database        bdb
> directory       /var/db/openldap/openfortress
> index           objectClass eq
> suffixalias     "dc=openfortress,dc=nl" "o=OpenFortress,c=nl"
> suffix          "dc=openfortress,dc=nl"
> suffix          "o=OpenFortress,c=nl"
> rootdn          "cn=Directory Manager,ou=Contacts,o=OpenFortress,c=nl"
> rootpw          wouldntyouliketoknow
>
> Anything under base DN 'o=Openfortress,c=nl' works flawlessly.
> Anything under base DN 'dc=openfortress,dc=nl' invariably gets stuck.
>
> When OpenLDAP gets stuck/blocked
>  * it only does so for that single thread, other requests are
> handled okay
>  * it will detect, but not correctly count, the client being torn down
>  * it will not gently go down because the client is accounted as open
>  * The last words of a thread getting stuck are (due to slapd -d 15)
>      suffix_alias: converted "dc=openfortress,dc=nl" to
> "o=OpenFortress,c=nl"
>      => bdb_back_search
>      bdb_dn2entry_rw("o=OpenFortress,c=nl")
>      => bdb_dn2id_matched( "o=OpenFortress,c=nl" )
>    Followed by radio silence.  A -1 debug only adds two more lines,
>      daemon: select: listen=8 active_threads=1 tvp=NULL
>      daemon: select: listen=9 active_threads=1 tvp=NULL
>  * when the client tears down the connection, there is an additional
>      daemon: activity on 1 descriptors
>      daemon: activity on: 13r
>      daemon: read activity on 13
>      connection_get(13)
>      connection_get(13): got connid=0
>      connection_read(13): checking for input on id=0
>      ber_get_next
>      ldap_read: want=9, got=0
>
>      ber_get_next on fd 13 failed errno=0 (Undefined error: 0)
>      connection_read(13): input error=-2 id=0, closing.
>      connection_closing: readying conn=0 sd=13 for close
>      connection_close: deferring conn=0 sd=13
>      daemon: select: listen=8 active_threads=1 tvp=NULL
>      daemon: select: listen=9 active_threads=1 tvp=NULL
>      daemon: activity on 1 descriptors
>      daemon: select: listen=8 active_threads=1 tvp=NULL
>      daemon: select: listen=9 active_threads=1 tvp=NULL
>    That too is at -d -1.
>
> I'm unsure if this is a software help call, or if this is a
> bug report.

As Kurt has said, there is probably a bug here.

> I am not sure if have constructed a woefully wrong config?

Bug issues aside, this config doesn't make a lot of sense. The purpose for
suffixalias is to map queries using an aliased suffix onto the real suffix.
This assumes that there is no actual backend configured to handle the aliased
suffix. Of these three lines from your slapd.conf file, one does not belong:

> suffixalias     "dc=openfortress,dc=nl" "o=OpenFortress,c=nl"
> suffix          "dc=openfortress,dc=nl"
> suffix          "o=OpenFortress,c=nl"

Removing any one of those three lines will clear things up, but each will
have a different effect.

If you remove the suffixalias, then you will just have a backend that
supports two disjunct trees.

If you remove the first suffix directive, you will have a backend that
contains the second suffix. Furthermore, queries based under the
"dc=openfortress" suffix will be mapped by the suffixalias.

If you remove the second suffix directive, you will have an unusable backend.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support