Hello,
OpenLDAP v2.3.42
I have found that using "overlay rwm" along with "database meta", where "database meta" refers to a Windows Active Directory server, causes OpenLDAP to crash with the following error:
-- client sends --
ldapsearch -x -W -D "cn=ef87,dc=ad,dc=company,dc=com" -b "ou=users,dc=ad,dc=company,dc=com"
-- server crashes -- ... PROXIED attributeDescription "MSEXCHMAILBOXGUID" inserted. ber_scanf fmt ([W]) ber: ber_scanf fmt ({m) ber: slapd: attr.c:141: attr_dup: Assertion `j == i' failed.
# slapd.conf ... overlay rwm
database meta suffix "dc=ad,dc=company,dc=com" uri "ldap://dc.example.com/dc=ad,dc=company,dc=com suffixmassage "dc=ad,dc=company,dc=com" dc=ad,dc=example,dc=com"
idassert-bind bindmethod="simple" binddn="cn=ProxyUser,dc=ad,dc=example,dc=com" credentials="secret" mode="self"
map objectclass posixaccount user map objectclass posixgroup group map attribute uid samaccountname map attribute uniquemember member map attribute mail userPrincipalName map attribute maillocaladdress proxyaddresses #map attribute * ...
The error can be avoided by either 1.) removing the "overlay rwm" from slapd.conf, 2.) move "overlay rwm" below a second database definition, 3.) use "map attribute" in the "database meta" section to select only certain attributes.
I would certainly like the two to work together in order to perform rewrites at a global level (and not have to configure my slapd.conf to work around a server crash).
Thanks, ef
--On Wednesday, July 16, 2008 1:04 PM -0700 Eric ef87@yahoo.com wrote:
The error can be avoided by either 1.) removing the "overlay rwm" from slapd.conf, 2.) move "overlay rwm" below a second database definition, 3.) use "map attribute" in the "database meta" section to select only certain attributes.
I would certainly like the two to work together in order to perform rewrites at a global level (and not have to configure my slapd.conf to work around a server crash).
"overlay XXXX" is a database specific directive, i.e., it is not allowed globally. See slapd.conf(5).
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Wednesday, July 16, 2008 1:04 PM -0700 Eric ef87@yahoo.com wrote:
The error can be avoided by either 1.) removing the "overlay rwm" from slapd.conf, 2.) move "overlay rwm" below a second database definition, 3.) use "map attribute" in the "database meta" section to select only certain attributes.
I would certainly like the two to work together in order to perform rewrites at a global level (and not have to configure my slapd.conf to work around a server crash).
"overlay XXXX" is a database specific directive, i.e., it is not allowed globally. See slapd.conf(5).
Overlays can be used globally, unless a specific overlay implementation is designed to disallow this feature. Usually, slapo-rwm(5) and slapd-meta(5) do not work well together, since slapd-meta(5) provides built-in rewrite capabilities. The issue is definitely worth debugging. I suggest an ITS be filed.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando@sys-net.it -----------------------------------
--On Thursday, July 17, 2008 12:56 AM +0200 Pierangelo Masarati ando@sys-net.it wrote:
"overlay XXXX" is a database specific directive, i.e., it is not allowed globally. See slapd.conf(5).
Overlays can be used globally, unless a specific overlay implementation is designed to disallow this feature. Usually, slapo-rwm(5) and slapd-meta(5) do not work well together, since slapd-meta(5) provides built-in rewrite capabilities. The issue is definitely worth debugging. I suggest an ITS be filed.
I'll file a doc ITS then as well, since the overlay directive is listed in slapd.conf(5) as being database specific.
slapd.overlays(5) also doesn't note which are global vs db only.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Hello,
I am currently configuring an openldap server on ubuntu-server 8 My question is where to find the command:
ldif2ldbm
to convert my ldiff files to dbm
Thanks in advance,
Uli
I don't think that command has been part of OpenLDAP for a while. Even if it was, you don't want to run a ldbm backend. Use hdb and the 'slapadd' command to do offline population from LDIF.
Uli Kleemann wrote:
Hello,
I am currently configuring an openldap server on ubuntu-server 8 My question is where to find the command:
ldif2ldbm
to convert my ldiff files to dbm
Thanks in advance,
Uli
Uli Kleemann wrote:
I am currently configuring an openldap server on ubuntu-server 8 My question is where to find the command:
ldif2ldbm
to convert my ldiff files to dbm
This file is outdated! Use a recent version of OpenLDAP and use the command-line tool slapadd.
Further reading: http://www.openldap.org/doc/admin24/dbtools.html
Ciao, michael.
Hi Uli,
On Fri, Jul 25, 2008 at 12:35:33AM +0200, Michael Ströder wrote:
Uli Kleemann wrote:
I am currently configuring an openldap server on ubuntu-server 8 My question is where to find the command:
ldif2ldbm
to convert my ldiff files to dbm
This file is outdated! Use a recent version of OpenLDAP and use the command-line tool slapadd.
Where did you find a reference to this file (ldif2ldbm) ?
Hello Michael,
Many Thanks for your comment I alleged that this file is outdated but as it is still mentioned in many HOWTOS and books I wasn't shure about that. However with your linked HOWTO I think I can manage it. What I also looking for is an example for the slapd.at.conf and slapd.oc.conf both I couldn't find yet anywhere.
On Fri, 25 Jul 2008 00:35:33 +0200 Michael Ströder michael@stroeder.com wrote:
Uli Kleemann wrote:
I am currently configuring an openldap server on ubuntu-server 8 My question is where to find the command:
ldif2ldbm
to convert my ldiff files to dbm
This file is outdated! Use a recent version of OpenLDAP and use the command-line tool slapadd.
Further reading: http://www.openldap.org/doc/admin24/dbtools.html
Ciao, michael.
Uli Kleemann wrote:
Michael Ströder michael@stroeder.com wrote:
Uli Kleemann wrote:
I am currently configuring an openldap server on ubuntu-server 8 My question is where to find the command:
ldif2ldbm
to convert my ldiff files to dbm
This file is outdated! Use a recent version of OpenLDAP and use the command-line tool slapadd.
Many Thanks for your comment I alleged that this file is outdated but as it is still mentioned in many HOWTOS and books I wasn't shure about that.
That's the problem with many unofficial docs out there. They are most times outdated or only describe a very specific configuration. And sometimes these HOWTOs are plain dead wrong. It's best to stick to the official docs of the OpenLDAP projects.
The Admin Guide for OpenLDAP 2.4: http://www.openldap.org/doc/admin24/
OpenLDAP's FAQ-O-MATIC: http://www.openldap.org/faq/data/cache/1.html
Further reading: http://www.openldap.org/doc/admin24/dbtools.html
However with your linked HOWTO I think I can manage it.
This is the official admin guide, not just a HOWTO. Thanks to the OpenLDAP team, it tries to cover different deployment scenarios. So it's worth to read it. You're certainly welcome to ask on the mailing list if you have any problem understanding something.
Ciao, Michael.
Oops. I have removed all "overlay rwm" statements from my slapd.conf that are not following a "database" directive.
Thanks, Eric
--- On Wed, 7/16/08, Quanah Gibson-Mount quanah@zimbra.com wrote:
From: Quanah Gibson-Mount quanah@zimbra.com Subject: Re: overlay rwm crashing server To: ef87@yahoo.com, openldap-software@openldap.org Date: Wednesday, July 16, 2008, 3:21 PM --On Wednesday, July 16, 2008 1:04 PM -0700 Eric ef87@yahoo.com wrote:
The error can be avoided by either 1.) removing the
"overlay rwm" from
slapd.conf, 2.) move "overlay rwm" below a
second database definition,
3.) use "map attribute" in the
"database meta" section to select only
certain attributes.
I would certainly like the two to work together in
order to perform
rewrites at a global level (and not have to configure
my slapd.conf to
work around a server crash).
"overlay XXXX" is a database specific directive, i.e., it is not allowed globally. See slapd.conf(5).
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
Eric wrote:
Oops. I have removed all "overlay rwm" statements from my slapd.conf that are not following a "database" directive.
That's not strictly needed, as I said. However, I could not reproduce your issue. When you get a crash, you should always provide a stack backtrace, and be prepared to provide information about the contents of the stack. Did you get a core dump, and is it still available? It would be useful to understand what attribute caused the issue you noticed, and as a consequence of what operation.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando@sys-net.it -----------------------------------
Thank you for your helpful reply. After taking a closer look at some Active Directory attribute values, I discovered a single space character was inserted into several attribute values.
I am able to consistently cause the assertion to occur if a single space character is inserted into either the "homePhone" or "pager" attribute of an Active Directory User object, and then search the meta directory for that object.
Again, the assertion will only occur if "overlay rwm" is used before or within the "database meta" section of my slapd.conf. If I comment or remove the overlay, ldapsearch returns the entry and slapd continues to operate.
ldapsearch -x -W -D 'cn=ef87,ou=users,dc=ad,dc=company,dc=com' -b 'ou=users,dc=ad,dc=company,dc=com' '(uid=ef87)'
gdb /usr/local/libexec/slapd GNU gdb Red Hat Linux (6.5-37.el5_2.2rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/i686/nosegneg/libthread_db.so.1".
(gdb) r -d0 -h ldap:/// ldaps:/// -f /usr/local/etc/openldap/slapd.conf Starting program: /usr/local/libexec/slapd -d0 -h ldap:/// ldaps:/// -f /usr/local/etc/openldap/slapd.conf (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [New Thread -1208486192 (LWP 9744)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [New Thread -1224119408 (LWP 9747)] [New Thread -1228317808 (LWP 9748)] [New Thread -1232516208 (LWP 9749)] [New Thread -1236714608 (LWP 9750)] [New Thread -1240913008 (LWP 9751)] slapd: attr.c:141: attr_dup: Assertion `j == i' failed.
Program received signal SIGABRT, Aborted. [Switching to Thread -1228317808 (LWP 9748)] 0x00be8402 in __kernel_vsyscall () (gdb) bt full #0 0x00be8402 in __kernel_vsyscall () No symbol table info available. #1 0x0089ef20 in raise () from /lib/i686/nosegneg/libc.so.6 No symbol table info available. #2 0x008a0901 in abort () from /lib/i686/nosegneg/libc.so.6 No symbol table info available. #3 0x008982fb in __assert_fail () from /lib/i686/nosegneg/libc.so.6 No symbol table info available. #4 0x0807dd03 in attr_dup () No symbol table info available. #5 0x0807ddc8 in attrs_dup () No symbol table info available. #6 0x0807e3b4 in entry_dup () No symbol table info available. #7 0x0817d868 in rwm_initialize () No symbol table info available. #8 0x080cc3d2 in glue_sub_add () No symbol table info available. #9 0x0808416f in slap_send_search_entry () No symbol table info available. #10 0x080f84f2 in meta_back_search () No symbol table info available. #11 0x080cc5d1 in overlay_op_walk () No symbol table info available. #12 0x080cc9bd in overlay_destroy_one () No symbol table info available. #13 0x0807716f in fe_op_search () No symbol table info available. #14 0x08077a90 in do_search () No symbol table info available. #15 0x080752d2 in connection2anonymous () No symbol table info available. #16 0x0819d923 in ldap_pvt_thread_pool_submit () No symbol table info available. #17 0x009f2482 in start_thread () from /lib/i686/nosegneg/libpthread.so.0 No symbol table info available. #18 0x00948c8e in clone () from /lib/i686/nosegneg/libc.so.6 No symbol table info available. (gdb)
--- On Wed, 7/16/08, Pierangelo Masarati ando@sys-net.it wrote:
From: Pierangelo Masarati ando@sys-net.it Subject: Re: overlay rwm crashing server To: ef87@yahoo.com Cc: openldap-software@openldap.org Date: Wednesday, July 16, 2008, 11:41 PM Eric wrote:
Oops. I have removed all "overlay rwm"
statements from my slapd.conf that are not following a "database" directive.
That's not strictly needed, as I said. However, I could not reproduce your issue. When you get a crash, you should always provide a stack backtrace, and be prepared to provide information about the contents of the stack. Did you get a core dump, and is it still available? It would be useful to understand what attribute caused the issue you noticed, and as a consequence of what operation.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando@sys-net.it
Eric wrote:
Thank you for your helpful reply. After taking a closer look at some Active Directory attribute values, I discovered a single space character was inserted into several attribute values.
Do you mean a value consisting in a single blank? That may cause a lot of errors, and it is practically untestable with OpenLDAP since I believe there are no syntaxes that allow it.
I am able to consistently cause the assertion to occur if a single space character is inserted into either the "homePhone" or "pager" attribute of an Active Directory User object, and then search the meta directory for that object.
Again, the assertion will only occur if "overlay rwm" is used before or within the "database meta" section of my slapd.conf. If I comment or remove the overlay, ldapsearch returns the entry and slapd continues to operate.
ldapsearch -x -W -D 'cn=ef87,ou=users,dc=ad,dc=company,dc=com' -b 'ou=users,dc=ad,dc=company,dc=com' '(uid=ef87)'
gdb /usr/local/libexec/slapd GNU gdb Red Hat Linux (6.5-37.el5_2.2rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/i686/nosegneg/libthread_db.so.1".
(gdb) r -d0 -h ldap:/// ldaps:/// -f /usr/local/etc/openldap/slapd.conf Starting program: /usr/local/libexec/slapd -d0 -h ldap:/// ldaps:/// -f /usr/local/etc/openldap/slapd.conf (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [New Thread -1208486192 (LWP 9744)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [New Thread -1224119408 (LWP 9747)] [New Thread -1228317808 (LWP 9748)] [New Thread -1232516208 (LWP 9749)] [New Thread -1236714608 (LWP 9750)] [New Thread -1240913008 (LWP 9751)] slapd: attr.c:141: attr_dup: Assertion `j == i' failed.
Program received signal SIGABRT, Aborted. [Switching to Thread -1228317808 (LWP 9748)] 0x00be8402 in __kernel_vsyscall () (gdb) bt full #0 0x00be8402 in __kernel_vsyscall () No symbol table info available. #1 0x0089ef20 in raise () from /lib/i686/nosegneg/libc.so.6 No symbol table info available. #2 0x008a0901 in abort () from /lib/i686/nosegneg/libc.so.6 No symbol table info available. #3 0x008982fb in __assert_fail () from /lib/i686/nosegneg/libc.so.6 No symbol table info available. #4 0x0807dd03 in attr_dup () No symbol table info available. #5 0x0807ddc8 in attrs_dup () No symbol table info available. #6 0x0807e3b4 in entry_dup () No symbol table info available. #7 0x0817d868 in rwm_initialize () No symbol table info available. #8 0x080cc3d2 in glue_sub_add () No symbol table info available. #9 0x0808416f in slap_send_search_entry () No symbol table info available. #10 0x080f84f2 in meta_back_search () No symbol table info available. #11 0x080cc5d1 in overlay_op_walk () No symbol table info available. #12 0x080cc9bd in overlay_destroy_one () No symbol table info available. #13 0x0807716f in fe_op_search () No symbol table info available. #14 0x08077a90 in do_search () No symbol table info available. #15 0x080752d2 in connection2anonymous () No symbol table info available. #16 0x0819d923 in ldap_pvt_thread_pool_submit () No symbol table info available. #17 0x009f2482 in start_thread () from /lib/i686/nosegneg/libpthread.so.0 No symbol table info available. #18 0x00948c8e in clone () from /lib/i686/nosegneg/libc.so.6 No symbol table info available. (gdb)
This backtrace is useless, since it contains no debugging symbols. See http://www.openldap.org/faq/data/cache/56.html for instructions about how to help in tracking issues. Anyway, if my understanding of your issue is correct, now I know what to look for, at least.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Pierangelo Masarati wrote:
Eric wrote:
Thank you for your helpful reply. After taking a closer look at some Active Directory attribute values, I discovered a single space character was inserted into several attribute values.
Do you mean a value consisting in a single blank? That may cause a lot of errors, and it is practically untestable with OpenLDAP since I believe there are no syntaxes that allow it.
OK, spotted (and tentatively fixed). I recommend you file an ITS http://www.openldap.org/its in order to allow tracking the issue.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
OK, spotted (and tentatively fixed). I recommend you file an ITS http://www.openldap.org/its in order to allow tracking the issue.
OK. I filed an ITS
Do you mean a value consisting in a single blank? That may cause a lot of errors, and it is practically untestable with OpenLDAP since I believe there are no syntaxes that allow it.
Yes, a value of a single blank.
This backtrace is useless, since it contains no debugging symbols. See http://www.openldap.org/faq/data/cache/56.html for instructions about how to help in tracking issues. Anyway, if my understanding of your issue is correct, now I know what to look for, at least.
Thanks for the link to the gdb instructions.
openldap-software@openldap.org
-
Eric -
George Holbert -
Mathias Gug -
Michael Ströder -
Pierangelo Masarati -
Quanah Gibson-Mount -
Uli Kleemann