openldap-technical

openldap-technical@openldap.org

21 participants
9802 discussions

RE: ldapadd "ldap_bind: Invalid credentials (49)"
by Clint Petty 29 Aug '13

29 Aug '13

-----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Thursday, August 29, 2013 3:10 PM To: Clint Petty Subject: RE: ldapadd "ldap_bind: Invalid credentials (49)" --On Thursday, August 29, 2013 10:06 PM +0000 Clint Petty <cpetty(a)luthresearch.com> wrote: >> # /etc/init.d/slapd debug -1 -u ldap -F /usr/local/etc/openldap/slapd.d >> # -H ldapi:/// >> slapd: [INFO] Using /etc/default/slapd for configuration >> slapd: [INFO] Halting OpenLDAP... >> slapd: [INFO] Can't read PID file, to stop OpenLDAP try: >> /etc/init.d/slapd forcestop slapd: [INFO] No db_recover done >> slapd: [INFO] Launching OpenLDAP... >> slapd: [OK] File descriptor limit set to 1024 >> 521fc4a1 @(#) $OpenLDAP: slapd 2.4.36 (Aug 21 2013 09:39:54) $ >> clement@localhost.localdomain:/home/clement/build/BUILD/openldap-2.4.36/ >> servers/slapd 521fc4a1 /usr/local/openldap/etc/openldap/slapd.conf: line >> 5: unknown directive <dn:> >outside backend info and database >> definitions. 521fc4a1 slapd stopped. >> 521fc4a1 connections_destroy: nothing to destroy. > Hi Clint, > The point is to use a ">" with the text *I* wrote, not the text you write. > That's standard quoting of replies (as you will see my email client does > automatically). > In the above, you used /etc/init.d/slapd, rather than the slapd *binary*. > The above indicates you are using an invalid slapd.conf file localted in > /usr/local/openldap/etc/openldap. I thought you used cn=config? > You may need to examine /etc/default/slapd to see how to fix it to use > cn=config? etc. At this point, you may want to ask the LTB project for > guidance on configuring their servers correctly. > --Quanah _________________________________________________________________ # /usr/local/openldap/libexec/slapd -d -1 -u ldap -F /usr/local/etc/openldap/slapd.d -h ldapi:/// ldap_url_parse_ext(ldap://localhost/) ldap_init: trying /usr/local/openldap/etc/openldap/ldap.conf ldap_init: using /usr/local/openldap/etc/openldap/ldap.conf ldap_init: HOME env is /root ldap_init: trying /root/ldaprc ldap_init: trying /root/.ldaprc ldap_init: trying ldaprc ldap_init: LDAPCONF env is NULL ldap_init: LDAPRC env is NULL 521fc7d9 @(#) $OpenLDAP: slapd 2.4.36 (Aug 21 2013 09:39:54) $ clement@localhost.localdomain:/home/clement/build/BUILD/openldap-2.4.36/servers/slapd ldap_pvt_gethostbyname_a: host=ip-10-15-2-169, r=0 521fc7d9 daemon_init: ldapi:/// 521fc7d9 daemon_init: listen on ldapi:/// 521fc7d9 daemon_init: 1 listeners to open... ldap_url_parse_ext(ldapi:///) 521fc7d9 daemon: listener initialized ldapi:/// 521fc7d9 daemon_init: 1 listeners opened ldap_create 521fc7d9 slapd init: initiated server. 521fc7d9 slap_sasl_init: initialized! 521fc7d9 bdb_back_initialize: initialize BDB backend 521fc7d9 bdb_back_initialize: Berkeley DB 4.6.21: (September 27, 2007) 521fc7d9 hdb_back_initialize: initialize HDB backend 521fc7d9 hdb_back_initialize: Berkeley DB 4.6.21: (September 27, 2007) 521fc7d9 mdb_back_initialize: initialize MDB backend 521fc7d9 mdb_back_initialize: MDB 0.9.7: (January 10, 2013) 521fc7d9 ==> translucent_initialize 521fc7d9 backend_startup_one: starting "cn=config" 521fc7d9 ldif_read_file: Permission denied for "/usr/local/etc/openldap/slapd.d/cn=config.ldif" 521fc7d9 send_ldap_result: conn=-1 op=0 p=0 521fc7d9 send_ldap_result: err=80 matched="" text="internal error (cannot read some entry file)" 521fc7d9 slapd destroy: freeing system resources. 521fc7d9 slapd stopped. 521fc7d9 connections_destroy: nothing to destroy. # Clint

2 1

Re: Antw: Problems recovering my ldap db[Solved]
by Ger Hooton 29 Aug '13

29 Aug '13

I just started over with a new DB Thanks for your help //Ger ----------------original message----------------- From: "Ulrich Windl" Ulrich.Windl(a)rz.uni-regensburg.de To: ghooton(a)scins.ie Date: Thu, 29 Aug 2013 08:07:51 +0200 ------------------------------------------------- >>>> ghooton(a)scins.ie schrieb am 28.08.2013 um 18:37 in Nachricht > 8004e8d0438c1185f5c2c6b474f7cea0.squirrel(a)www.scins.ie : >> Hi all, I am >> recovering form a disaster. when I do slapcat I can see all the info > > Hi! > > I think it depends on the type of desaster: For human error or filesystem > corruption, you must probably restore your last successful database dump. If > the machine just crashed (and the filesystem configuration was sane), there > shouldn't be a problem with automatic recovery (IMHO). > > Regards, > Ulrich > >> stored in the ldap db However, when I do ldapsearch >> I cannot see anything. When I do slapcat -l backup.ldif I get : >> unclean shutdown >> detected; attempting recovery >> recovery skipped in read-only mode. >> Run manual >> recovery if errors are encountered >> >> I am using Debian 6 2.6.32-5-amd64 and :- >> ldapsearch -VV >> ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.23 (Dec 16 2012 11:48:21) $ >> >> root@carillon :/tmp/buildd/openldap-2.4.23/debian/build/clients/too >> ls >> (LDAP library: OpenLDAP 20423) >> >> >> //Ger > > > > -- Scoil Chroí Íosa Blarney. Blarney. Co. Cork

1 0

Issue with mdb_cursor_del in MDB_DUPSORT databases
by Mark Zealey 29 Aug '13

29 Aug '13

Hi Howard, I've now switched the database to use MDB_DUPSORT and found what seems to be another issue to do with invalid data being returned after mdb_cursor_del. The following code shows the behaviour against a database that I can provide you with if you need: rc = mdb_cursor_open(txn, dbi, &cursor); char seek[] = "ku.oc.repmulp\t"; key.mv_size = sizeof(seek); key.mv_data = &seek; mdb_cursor_get(cursor, &key, &data, MDB_SET_RANGE); for( i = 0; i < 15; i++ ) { mdb_cursor_del( cursor, MDB_NODUPDATA ); data.mv_size = 0; key.mv_size = 0; mdb_cursor_get( cursor, &key, &data, //MDB_NEXT MDB_GET_CURRENT ); if( key.mv_size == 0 ) printf("WARNING 0 SIZE KEY\n"); else printf("KEY OK: %d: %.*s\n", key.mv_size, key.mv_size, key.mv_data); if( data.mv_size == 0 ) printf("WARNING 0 SIZE DATA\n"); else printf("DATA OK: %d: %.*s\n", data.mv_size, data.mv_size, data.mv_data); } mdb_txn_abort(txn); If you run as-is it seems that if the cursor points at a record with multiple entries, the data is not updated. If however the mdb_cursor_del line is commented and mdb_cursor_get changed to use MDB_NEXT the output is as expected with multiple entries. Here is sample output with get-only: KEY OK: 16: ku.oc.repmulp MX DATA OK: 40: 4160598 300 0 primary.mail.plumper.co.uk KEY OK: 16: ku.oc.repmulp MX DATA OK: 37: 4160598 300 10 cerebellum.david14.com KEY OK: 16: ku.oc.repmulp MX DATA OK: 46: 4160598 300 20 secondary-mail.mailhoster.co.uk KEY OK: 16: ku.oc.repmulp NS DATA OK: 30: 4160598 300 ns1.xcalibre.co.uk KEY OK: 16: ku.oc.repmulp NS DATA OK: 30: 4160598 300 ns2.xcalibre.co.uk KEY OK: 21: ku.oc.repmulp.05pot A DATA OK: 29: 4160598 86400 212.159.180.202 KEY OK: 22: ku.oc.repmulp.05pot MX DATA OK: 40: 4160598 300 0 primary.mail.plumper.co.uk KEY OK: 22: ku.oc.repmulp.05pot MX DATA OK: 37: 4160598 300 10 cerebellum.david14.com KEY OK: 22: ku.oc.repmulp.05pot MX DATA OK: 46: 4160598 300 20 secondary-mail.mailhoster.co.uk And here with mdb_cursor_del: KEY OK: 16: ku.oc.repmulp MX WARNING 0 SIZE DATA KEY OK: 16: ku.oc.repmulp NS WARNING 0 SIZE DATA KEY OK: 21: ku.oc.repmulp.05pot A DATA OK: 29: 4160598 86400 212.159.180.202 KEY OK: 22: ku.oc.repmulp.05pot MX WARNING 0 SIZE DATA KEY OK: 25: ku.oc.repmulp.05pot.www A DATA OK: 29: 4160598 86400 212.159.180.202 KEY OK: 20: ku.oc.repmulp.3pop A DATA OK: 29: 4160598 86400 212.159.180.202 Behaviour seems to be the same regardless of whether I use MDB_NODUPDATA or 0 as the mdb_cursor_del flag (ie 0 length data returned and all duplicate entries deleted) Thanks, Mark

2 2

RE: ldapadd "ldap_bind: Invalid credentials (49)"
by Juergen.Sprenger＠swisscom.com 29 Aug '13

29 Aug '13

--On Thursday, August 29, 2013 12:35 AM +0000 Clint Petty <cpetty(a)luthresearch.com> wrote: > > > After upgrading from OpenLDAP 2.4.23 to 2.4.36, I can no longer add a > user: > > > ># ldapadd -x -D "cn=Manager,dc=luthresearch,dc=net" -w secret -f # >/etc/openldap/adduser.ldif Check Your config for RootPW and whether the hash algorithm used is still supported by Your build of OpenLDAP. Had a similar problem on an old server because --enable-crypt was not set when building OpenLDAP 2.4.36. You can check that by using slappasswd to create a String like the one used in Your config: # /usr/local/sbin/slappasswd -s secret -h '{crypt}' Password generation failed for scheme {crypt}: scheme not recognized --Jürgen Sprenger

3 2

ldapadd "ldap_bind: Invalid credentials (49)"
by Clint Petty 29 Aug '13

29 Aug '13

After upgrading from OpenLDAP 2.4.23 to 2.4.36, I can no longer add a user: # ldapadd -x -D "cn=Manager,dc=luthresearch,dc=net" -w secret -f /etc/openldap/adduser.ldif ldap_bind: Invalid credentials (49)

2 3

Unstable slapd-meta connection with MS AD LDAP
by Nick Anzalone 29 Aug '13

29 Aug '13

Hello, I'm trying to use slapd-meta (openldap version 2.4.28) as a proxy between a web application LDAP authentication request and a MS AD server. The idea being that if we have multiple LDAP authentication clients we can add another target with suffix massage to redirect requests to the appropriate LDAP server. We were forced to use a dedicated proxy because we were told the MS server's firewall requires an actual IP, not a FQDN, and we don't have a stable ip (we're using a load balancer service which only provides a FQDN). In general, it looked like this solution would work well. My problem is that the connection between the slapd-meta proxy and the MS server does not seem very robust. I would be extremely grateful if someone could help me understand where I might start looking to diagnose what is wrong. #################### Problem Summary ##################### The problem I'm seeing was reported as an "Operations Error" from the command line. Initially, I did not have idle-timeout set at all, and this error would occur reliably after 15 minutes of inactivity, and was not recoverable (I needed to restart the slapd server to correct the problem). I suspected that the cause was that the connection was remaining idle too long and getting invalidated by the MS LDAP server (which I don't have access to). To address this problem, I set idle-timeout to 10m (MS AD apparently has a default timeout of 15m). I have set up a cron job to "ping" the MS server every minute in an attempt to keep the connection open (although I'm not sure if it actually uses the same connection, so this may not be doing much). I also set the value of the nretries configuration directive to 20. These adjustments seemed to help significantly. With constant activity (authentication through the web application), everything appears to work great. However I still occasionally get the "operations error," which causes my web application to reject the initial authentication even with correct credentials. At this point it is most reliably reproduced by inducing more than 15 minutes of inactivity on the slapd-meta proxy, and then attempting a login. After an initial failed login attempt, the problem seems to correct for itself (i.e. a second login attempt through the web application with the same credentials will succeed). I am at all times able to connect directly to the LDAP server with no trouble. It is only connections through the slapd-meta proxy I have set up that (sometimes) fail. It may also be worth noting that I don't see any of these problems with an openldap test server that I set up. Thanks so much in advance for any help or suggestions. ################################## Problem Details ##################################### Below is an excerpt from my syslog from a failed authentication request initiated by my web application: -------------------- log output from syslog ------------------------------------------ Aug 28 20:33:26 my-proxy-server slapd[10330]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Aug 28 20:33:26 my-proxy-server slapd[10330]: daemon: epoll: listen=9 active_threads=0 tvp=NULL Aug 28 20:33:26 my-proxy-server slapd[10330]: daemon: epoll: listen=10 active_threads=0 tvp=NULL Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1 do_search Aug 28 20:33:26 my-proxy-server slapd[10330]: >>> dnPrettyNormal: <dc=AAA,dc=YYY,dc=ZZZ> Aug 28 20:33:26 my-proxy-server slapd[10330]: <<< dnPrettyNormal: <dc=AAA,dc=YYY,dc=ZZZ>, <dc=AAA,dc=YYY,dc=ZZZ> Aug 28 20:33:26 my-proxy-server slapd[10330]: SRCH "dc=AAA,dc=YYY,dc=ZZZ" 2 3 Aug 28 20:33:26 my-proxy-server slapd[10330]: 0 0 0 Aug 28 20:33:26 my-proxy-server slapd[10330]: begin get_filter Aug 28 20:33:26 my-proxy-server slapd[10330]: EQUALITY Aug 28 20:33:26 my-proxy-server slapd[10330]: end get_filter 0 Aug 28 20:33:26 my-proxy-server slapd[10330]: filter: (?SAMACCOUNTNAME=xxx) Aug 28 20:33:26 my-proxy-server slapd[10330]: => get_ctrls Aug 28 20:33:26 my-proxy-server slapd[10330]: => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical) Aug 28 20:33:26 my-proxy-server slapd[10330]: <= get_ctrls: n=1 rc=0 err="" Aug 28 20:33:26 my-proxy-server slapd[10330]: attrs: Aug 28 20:33:26 my-proxy-server slapd[10330]: Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1 SRCH base="dc=AAA,dc=YYY,dc=ZZZ" scope=2 deref=3 filter="(?SAMACCOUNTNAME=xxx)" Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1 meta_back_getconn: mc=0x7fafbc004500 conn=ROOTDN expired (tainted). Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1: meta_back_getconn[1] Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1 meta_back_getconn: candidates=1 conn=ROOTDN fetched Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1 >>> meta_back_search_start[1] Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1 >>> meta_search_dobind_init[1] Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1 <<< meta_search_dobind_init[1]=1 Aug 28 20:33:26 my-proxy-server slapd[10330]: ==> rewrite_context_apply [depth=1] string='dc=AAA,dc=YYY,dc=ZZZ' Aug 28 20:33:26 my-proxy-server slapd[10330]: ==> rewrite_rule_apply rule='((.+),)?dc=AAA,[ ]?dc=YYY,[ ]?dc=ZZZ$' string='dc=AAA,dc=YYY,dc=ZZZ' [1 pass(es)] Aug 28 20:33:26 my-proxy-server slapd[10330]: ==> rewrite_context_apply [depth=1] res={0,'ou=Org Unit,dc=AAA,dc=BBB,dc=CCC,dc=DDD'} Aug 28 20:33:26 my-proxy-server slapd[10330]: [rw] searchBase: "dc=AAA,dc=YYY,dc=ZZZ" -> "ou=Org Unit,dc=AAA,dc=BBB,dc=CCC,dc=DDD" Aug 28 20:33:26 my-proxy-server slapd[10330]: ==> rewrite_context_apply [depth=1] string='(SAMACCOUNTNAME=xxx)' Aug 28 20:33:26 my-proxy-server slapd[10330]: ==> rewrite_context_apply [depth=1] res={0,'NULL'} Aug 28 20:33:26 my-proxy-server slapd[10330]: [rw] searchFilter: "(SAMACCOUNTNAME=xxx)" -> "(SAMACCOUNTNAME=xxx)" Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1 meta_back_retry[1]: retrying URI="ldap://ms-ldap-server.AAA.BBB.CCC.DDD" DN="cn=bind-manager,ou=Org Unit,dc=AAA,dc=BBB,dc=CCC,dc=DDD". Aug 28 20:33:26 my-proxy-server slapd[10330]: >>> conn=1094 op=1 meta_back_bind_op_result[1] Aug 28 20:33:26 my-proxy-server slapd[10330]: <<< conn=1094 op=1 meta_back_bind_op_result[1] err=0 Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1 meta_back_retry[1]: meta_back_single_dobind=0 Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1 <<< meta_back_search_start[1]=1 Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1 meta_back_search: ncandidates=1 cnd=" *" Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1 meta_back_search[1] match="" err=1 (Operations error). Aug 28 20:33:26 my-proxy-server slapd[10330]: send_ldap_result: conn=1094 op=1 p=3 Aug 28 20:33:26 my-proxy-server slapd[10330]: send_ldap_result: err=1 matched="" text="" Aug 28 20:33:26 my-proxy-server slapd[10330]: send_ldap_response: msgid=2 tag=101 err=1 Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1 SEARCH RESULT tag=101 err=1 nentries=0 text= ######################### slapd.conf ######################## # This is the main slapd configuration file. See slapd.conf(5) for more # info on the configuration options. ####################################################################### # Global Directives: # Features to permit #allow bind_v2 # Schema and objectClass definitions include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema # Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /var/run/slapd/slapd.pid # List of arguments that were passed to the server argsfile /var/run/slapd/slapd.args # Read slapd.conf(5) for possible values # should reduce this once we're live loglevel any # Where the dynamically loaded modules are stored modulepath /usr/lib/ldap moduleload back_meta.la moduleload back_ldap.la # The maximum number of entries that is returned for a search operation sizelimit 500 # The tool-threads parameter sets the actual amount of cpu's that is used # for indexing. tool-threads 1 # experiment trying to figure out error below: # ber_get_next on fd 12 failed errno=34 (Numerical result out of range) #sockbuf_max_incoming_auth 5000000000 # Specific Backend Directives for 'other': # Backend specific directives apply to this backend until another # 'backend' directive occurs backend meta # this is broken - causes slapd to terminate #TLSCipherSuite ALL:!NULL #TLSCipherSuite ECDHE-RSA-AES256-SHA #TLSCipherSuite SECURE256 # TLS Security settings TLSCACertificateFile /etc/ldap/cert/private/ca.my-proxy-server.YYY.ZZZ.pem TLSCertificateFile /etc/ldap/cert/private/ca.my-proxy-server.YYY.ZZZ.pem TLSCertificateKeyFile /etc/ldap/cert/private/private.my-proxy-server.YYY.ZZZ.pem #TLSVerifyClient try # require TLS (secure) connection #security tls=1 ######################################################### # CUSTOM META SLAPD ################################################# database meta suffix "dc=YYY,dc=ZZZ" rootdn "cn=XXX,dc=YYY,dc=ZZZ" rootpw ***** # The following parameters were added to trouble-shoot the unstable connection w/ MS LDAP server idle-timeout 10m nretries 20 ####################################################################### # Test LDAP server on staging # Each LDAP server will get its own entry like this # Please document each server ####################################################### # The LDAP server URL. Note the dc=test in the suffix, which allows us to uniquely identify the request as # one that should be passed to our test server. We might use one like dc=AAA for an entry that would pass # requests to the AAA LDAP server uri "ldap://test.YYY.ZZZ/dc=test,dc=YYY,dc=ZZZ" # Tells the client to use a secure connection with the server. tls start # More connection specifics: specifies the filename/location of the client certificate if the server requires one # we also specify the DN used to bind, and credentials (password) for the binding DN. idassert-bind tls_cacert=/etc/ldap/cert/test.YYY.ZZZ.crt binddn="cn=admin,dc=YYY,dc=ZZZ" credentials="*****" # NB: There is a parameter that needs to "allow" the server to require a client certificate (tls_reqcert=allow), however it doesn't seem to # work. So we were forced to set this in the ldap.conf (client-side) config file. slapd uses this file to set default values for many # parameters, including this one. # This removes the "dc=test" specifier before delegating the LDAP request to the test server. suffixmassage "dc=test,dc=YYY,dc=ZZZ" "dc=YYY,dc=ZZZ" ########################################################################## # AAA LDAP Server Entry # Here is the AAA-provided "user context": # OU=Org Unit, DC=AAA, DC=BBB, DC=CCC, DC=DDD # ########################################################## uri "ldap://ms-ldap-server.AAA.BBB.CCC.DDD/dc=AAA,dc=YYY,dc=ZZZ" tls start idassert-bind tls_cacert=/etc/ldap/cert/AAA.BBB.CCC.DDD.crt binddn="cn=bind-manager,ou=Org Unit,dc=AAA,dc=BBB,dc=CCC,dc=DDD" credentials="******" suffixmassage "dc=AAA,dc=YYY,dc=ZZZ" "ou=Org Unit,dc=AAA,dc=BBB,dc=CCC,dc=DDD" default-target

2 1

Re : Re: OpenLDAP 2.4.36 slapd crash with "assertion failed" message
by "POISSON Frédéric" 29 Aug '13

29 Aug '13

Re Hello, Sorry that was for me the first time i use gdb and i haven't understand that it require to install rpm with debuginfo, now here is a new gdb trace with more informations : # gdb /usr/local/openldap/libexec/slapd 4700 GNU gdb (GDB) Red Hat Enterprise Linux (7.2-50.el6) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/local/openldap/libexec/slapd...Reading symbols from /usr/lib/debug/usr/local/openldap/libexec/slapd.debug...done. done. Attaching to program: /usr/local/openldap/libexec/slapd, process 4700 Reading symbols from /usr/local/berkeleydb/lib64/libdb-4.6.so...Reading symbols from /usr/lib/debug/usr/local/berkeleydb/lib64/libdb-4.6.so.debug... warning: "/usr/lib/debug/usr/local/berkeleydb/lib64/libdb-4.6.so.debug": separate debug info file has no debug info (no debugging symbols found)...done. (no debugging symbols found)...done. Loaded symbols for /usr/local/berkeleydb/lib64/libdb-4.6.so Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done. [Thread debugging using libthread_db enabled] [New Thread 0x7f0f51882700 (LWP 4814)] Loaded symbols for /lib64/libpthread.so.0 Reading symbols from /usr/lib64/libsasl2.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libsasl2.so.2 Reading symbols from /usr/lib64/libssl.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libssl.so.10 Reading symbols from /usr/lib64/libcrypto.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libcrypto.so.10 Reading symbols from /lib64/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libcrypt.so.1 Reading symbols from /lib64/libresolv.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libresolv.so.2 Reading symbols from /usr/lib64/libltdl.so.7...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libltdl.so.7 Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /lib64/libgssapi_krb5.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libgssapi_krb5.so.2 Reading symbols from /lib64/libkrb5.so.3...(no debugging symbols found)...done. Loaded symbols for /lib64/libkrb5.so.3 Reading symbols from /lib64/libcom_err.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libcom_err.so.2 Reading symbols from /lib64/libk5crypto.so.3...(no debugging symbols found)...done. Loaded symbols for /lib64/libk5crypto.so.3 Reading symbols from /lib64/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libz.so.1 Reading symbols from /lib64/libfreebl3.so...(no debugging symbols found)...done. Loaded symbols for /lib64/libfreebl3.so Reading symbols from /lib64/libkrb5support.so.0...(no debugging symbols found)...done. Loaded symbols for /lib64/libkrb5support.so.0 Reading symbols from /lib64/libkeyutils.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libkeyutils.so.1 Reading symbols from /lib64/libselinux.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libselinux.so.1 Reading symbols from /lib64/libnss_files.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libnss_files.so.2 Reading symbols from /usr/lib64/sasl2/libsasldb.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libsasldb.so Reading symbols from /lib64/libdb-4.7.so...(no debugging symbols found)...done. Loaded symbols for /lib64/libdb-4.7.so Reading symbols from /usr/lib64/sasl2/libanonymous.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libanonymous.so 0x0000003a00c0804d in pthread_join () from /lib64/libpthread.so.0 Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.23-13.el6.x86_64 db4-4.7.25-16.el6.x86_64 glibc-2.12-1.47.el6_2.12.x86_64 keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6_2.1.x86_64 libcom_err-1.41.12-11.el6.x86_64 libselinux-2.0.94-5.2.el6.x86_64 libtool-ltdl-2.2.6-15.5.el6.x86_64 nss-softokn-freebl-3.12.9-11.el6.x86_64 openssl-1.0.0-20.el6_2.4.x86_64 zlib-1.2.3-27.el6.x86_64 (gdb) backtrace full #0 0x0000003a00c0804d in pthread_join () from /lib64/libpthread.so.0 No symbol table info available. #1 0x000000000043a0e9 in slapd_daemon () at daemon.c:2929 i = <value optimized out> rc = <value optimized out> #2 0x0000000000426435 in main (argc=11, argv=<value optimized out>) at main.c:1012 i = <value optimized out> no_detach = 0 rc = -12 urls = 0x23f5010 "ldap://*:25389 ldaps://*:25636" username = 0x23f5080 "root" groupname = 0x23f50a0 "\026\065U" sandbox = 0x0 syslogUser = 160 pid = <value optimized out> waitfds = {9, 10} g_argc = 11 g_argv = <value optimized out> configfile = 0x0 configdir = 0x23f5040 "/usr/local/openldap/etc/openldap/slapd.d" serverName = <value optimized out> scp = <value optimized out> scp_entry = <value optimized out> debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = <value optimized out> slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 firstopt = <value optimized out> __PRETTY_FUNCTION__ = "main" (gdb) continue Continuing. [New Thread 0x7f0f51081700 (LWP 5623)] Program received signal SIGABRT, Aborted. [Switching to Thread 0x7f0f51081700 (LWP 5623)] 0x0000003a00432885 in raise () from /lib64/libc.so.6 (gdb) backtrace full #0 0x0000003a00432885 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x0000003a00434065 in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x0000003a0042b9fe in __assert_fail_base () from /lib64/libc.so.6 No symbol table info available. #3 0x0000003a0042bac0 in __assert_fail () from /lib64/libc.so.6 No symbol table info available. #4 0x0000000000450bed in slap_send_ldap_result (op=0x7f0f44002670, rs=0x7f0f51080950) at result.c:813 tmp = 0x0 otext = 0x7f0f5107f394 "" oref = 0x0 __PRETTY_FUNCTION__ = "slap_send_ldap_result" #5 0x000000000042d567 in config_back_modify (op=<value optimized out>, rs=<value optimized out>) at bconfig.c:5926 cfb = <value optimized out> ce = <value optimized out> last = 0xd00000000 ml = <value optimized out> ca = {argc = 2, argv = 0x7f0f44103f90, argv_size = 513, line = 0x7f0f44102cc0 "/dev/random", tline = 0x7f0f44103f70 "", fname = 0x5d1f79 "slapd", lineno = 0, log = "olcTLSRandFile: value #0", '\000' <repeats 4099 times>, reply = {err = 0, msg = '\000' <repeats 255 times>}, depth = 0, valx = -1, values = {v_int = 1141915104, v_uint = 1141915104, v_long = 139703543152096, v_ulong = 139703543152096, v_ber_t = 139703543152096, v_string = 0x7f0f44103de0 "0?\020D\017\177", v_bv = {bv_len = 139703543152096, bv_val = 0x0}, v_dn = {vdn_dn = { bv_len = 139703543152096, bv_val = 0x0}, vdn_ndn = {bv_len = 0, bv_val = 0x0}}, v_ad = 0x7f0f44103de0}, rvalue_vals = 0x0, rvalue_nvals = 0x0, op = 0, type = 4, ca_op = 0x7f0f44002670, be = 0x88e960, bi = 0x0, ca_entry = 0x24780d8, ca_private = 0x2477970, cleanup = 0x427a70 <config_tls_cleanup>, table = Cft_Global} rdn = {bv_len = 2, bv_val = 0x2477e30 "cn=config"} ptr = <value optimized out> rad = 0x2422450 do_pause = <value optimized out> #6 0x000000000045745b in fe_op_modify (op=0x7f0f44002670, rs=0x7f0f51080950) at modify.c:303 update = <value optimized out> repl_user = <value optimized out> op_be = <value optimized out> bd = 0x88e960 textbuf = "x,\000D\017\177", '\000' <repeats 18 times>, "\003\000\000\000\000\000\000\000\020/Z\000\000\000\000\000Â7Z\000\000\000\000\000`ó@\002\000\000\000\000ð\035\000D\017\177\000\000\200ªG\000\000\000\000\000\066¢E\000\000\000\000\000\016\000\000\000\000\000\000\000K,\020D\017\177", '\000' <repeats 18 times>, "\v\000\000\000\000\000\000\000À,\020D\017\177\000\000à+\000D\017\177\000\000à,\020D\017\177\000\000\000\000\000\000\000\000\000\000\200\236C\002", '\000' <repeats 28 times>, "\237nE\000\000\000\000\000\000\b\bQ\017\177\000\000p\t\bQ\017\177\000\000\000\001\000\000\000\000\000\000p&\000D\017\177\000\000\230&\000D\017\177\000\000¨&"... #7 0x0000000000457d86 in do_modify (op=0x7f0f44002670, rs=0x7f0f51080950) at modify.c:177 dn = {bv_len = 9, bv_val = 0x7f0f44102c37 "cn=config"} textbuf = "')\000D\017\177", '\000' <repeats 42 times>, "Ð\b\bQ\000\000\000\000°\n\bQ\017\177", '\000' <repeats 18 times>, "P\t\bQ\017\177\000\000ùäÀ\000:", '\000' <repeats 11 times>, "\211\022\\\000\000\000\000\000Ð\b\bQ\017\177\000\000p&\000D\017\177\000\000ÿÿÿÿ\017\177\000\000½ÄE\000\000\000\000\000P\t\bQ\017\177\000\000@\224x\000:", '\000' <repeats 11 times>, "\020&\000D\017\177\000\000à+\000D\017\177\000\000\000\000\020\000\000\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000°\n\bQ\017\177\000\000ð0I", '\000' <repeats 13 times>, "\005\000\000\000\061\000\000\000p&\000D\017"... tmp = <value optimized out> #8 0x000000000043fb79 in connection_operation (ctx=0x7f0f51080ab0, arg_v=0x7f0f44002670) at connection.c:1155 rc = 80 cancel = <value optimized out> op = 0x7f0f44002670 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = -12, sr_matched = 0x0, sr_text = 0x7f0f5107f394 "", sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 102 opidx = SLAP_OP_MODIFY conn = 0x2502d20 memctx = 0x7f0f44002be0 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #9 0x0000000000440365 in connection_read_thread (ctx=0x7f0f51080ab0, argv=<value optimized out>) at connection.c:1291 ---Type <return> to continue, or q <return> to quit--- rc = <value optimized out> cri = {op = 0x7f0f44002670, func = 0, arg = 0x0, ctx = 0x7f0f51080ab0, nullop = <value optimized out>} s = <value optimized out> #10 0x0000000000595b80 in ldap_int_thread_pool_wrapper (xpool=0x2425680) at tpool.c:688 pool = 0x2425680 task = 0x7f0f4c0008c0 work_list = <value optimized out> ctx = {ltu_id = 139703760721664, ltu_key = {{ltk_key = 0x43e990, ltk_data = 0x7f0f44002ad0, ltk_free = 0x43ea60 <conn_counter_destroy>}, {ltk_key = 0x492f40, ltk_data = 0x7f0f44002be0, ltk_free = 0x492f60 <slap_sl_mem_destroy>}, {ltk_key = 0x452d70, ltk_data = 0x0, ltk_free = 0x452b40 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 26 times>, { ltk_key = 0x0, ltk_data = 0x3a00c07e8a, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}} kctx = <value optimized out> keyslot = 990 hash = <value optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #11 0x0000003a00c077f1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #12 0x0000003a004e5ccd in clone () from /lib64/libc.so.6 No symbol table info available. (gdb) continue Continuing. [Thread 0x7f0f51081700 (LWP 5623) exited] [Thread 0x7f0f51882700 (LWP 4814) exited] Program terminated with signal SIGABRT, Aborted. The program no longer exists. (gdb) quit Regards Le 29/08/13, "POISSON Frédéric" <frederic.poisson(a)admin.gmessaging.net> a écrit : > Hello, > > Ok thanks for the information, i try the gdb with full backtrace and i have : > > # gdb /usr/local/openldap/libexec/slapd 9522 > GNU gdb (GDB) Red Hat Enterprise Linux (7.2-50.el6) > Copyright (C) 2010 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-redhat-linux-gnu". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>... > Reading symbols from /usr/local/openldap/libexec/slapd...(no debugging symbols found)...done. > Attaching to program: /usr/local/openldap/libexec/slapd, process 9522 > Reading symbols from /usr/local/berkeleydb/lib64/libdb-4.6.so...(no debugging symbols found)...done. > Loaded symbols for /usr/local/berkeleydb/lib64/libdb-4.6.so > Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done. > [Thread debugging using libthread_db enabled] > [New Thread 0x7f036993a700 (LWP 9523)] > Loaded symbols for /lib64/libpthread.so.0 > Reading symbols from /usr/lib64/libsasl2.so.2...(no debugging symbols found)...done. > Loaded symbols for /usr/lib64/libsasl2.so.2 > Reading symbols from /usr/lib64/libssl.so.10...(no debugging symbols found)...done. > Loaded symbols for /usr/lib64/libssl.so.10 > Reading symbols from /usr/lib64/libcrypto.so.10...(no debugging symbols found)...done. > Loaded symbols for /usr/lib64/libcrypto.so.10 > Reading symbols from /lib64/libcrypt.so.1...(no debugging symbols found)...done. > Loaded symbols for /lib64/libcrypt.so.1 > Reading symbols from /lib64/libresolv.so.2...(no debugging symbols found)...done. > Loaded symbols for /lib64/libresolv.so.2 > Reading symbols from /usr/lib64/libltdl.so.7...(no debugging symbols found)...done. > Loaded symbols for /usr/lib64/libltdl.so.7 > Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done. > Loaded symbols for /lib64/libc.so.6 > Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. > Loaded symbols for /lib64/ld-linux-x86-64.so.2 > Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done. > Loaded symbols for /lib64/libdl.so.2 > Reading symbols from /lib64/libgssapi_krb5.so.2...(no debugging symbols found)...done. > Loaded symbols for /lib64/libgssapi_krb5.so.2 > Reading symbols from /lib64/libkrb5.so.3...(no debugging symbols found)...done. > Loaded symbols for /lib64/libkrb5.so.3 > Reading symbols from /lib64/libcom_err.so.2...(no debugging symbols found)...done. > Loaded symbols for /lib64/libcom_err.so.2 > Reading symbols from /lib64/libk5crypto.so.3...(no debugging symbols found)...done. > Loaded symbols for /lib64/libk5crypto.so.3 > Reading symbols from /lib64/libz.so.1...(no debugging symbols found)...done. > Loaded symbols for /lib64/libz.so.1 > Reading symbols from /lib64/libfreebl3.so...(no debugging symbols found)...done. > Loaded symbols for /lib64/libfreebl3.so > Reading symbols from /lib64/libkrb5support.so.0...(no debugging symbols found)...done. > Loaded symbols for /lib64/libkrb5support.so.0 > Reading symbols from /lib64/libkeyutils.so.1...(no debugging symbols found)...done. > Loaded symbols for /lib64/libkeyutils.so.1 > Reading symbols from /lib64/libselinux.so.1...(no debugging symbols found)...done. > Loaded symbols for /lib64/libselinux.so.1 > Reading symbols from /lib64/libnss_files.so.2...(no debugging symbols found)...done. > Loaded symbols for /lib64/libnss_files.so.2 > Reading symbols from /usr/lib64/sasl2/libsasldb.so...(no debugging symbols found)...done. > Loaded symbols for /usr/lib64/sasl2/libsasldb.so > Reading symbols from /lib64/libdb-4.7.so...(no debugging symbols found)...done. > Loaded symbols for /lib64/libdb-4.7.so > Reading symbols from /usr/lib64/sasl2/libanonymous.so...(no debugging symbols found)...done. > Loaded symbols for /usr/lib64/sasl2/libanonymous.so > 0x0000003a00c0804d in pthread_join () from /lib64/libpthread.so.0 > Missing separate debuginfos, use: debuginfo-install openldap-ltb-2.4.36-1.el6.x86_64 > (gdb) backtrace full > #0 0x0000003a00c0804d in pthread_join () from /lib64/libpthread.so.0 > No symbol table info available. > #1 0x000000000043a0e9 in slapd_daemon () > No symbol table info available. > #2 0x0000000000426435 in main () > No symbol table info available. > (gdb) continue > Continuing. > [New Thread 0x7f0369139700 (LWP 11349)] > > Program received signal SIGABRT, Aborted. > [Switching to Thread 0x7f0369139700 (LWP 11349)] > 0x0000003a00432885 in raise () from /lib64/libc.so.6 > (gdb) backtrace full > #0 0x0000003a00432885 in raise () from /lib64/libc.so.6 > No symbol table info available. > #1 0x0000003a00434065 in abort () from /lib64/libc.so.6 > No symbol table info available. > #2 0x0000003a0042b9fe in __assert_fail_base () from /lib64/libc.so.6 > No symbol table info available. > #3 0x0000003a0042bac0 in __assert_fail () from /lib64/libc.so.6 > No symbol table info available. > #4 0x0000000000450bed in slap_send_ldap_result () > No symbol table info available. > #5 0x000000000042d567 in ?? () > No symbol table info available. > #6 0x000000000045745b in fe_op_modify () > No symbol table info available. > #7 0x0000000000457d86 in do_modify () > No symbol table info available. > #8 0x000000000043fb79 in ?? () > No symbol table info available. > #9 0x0000000000440365 in ?? () > No symbol table info available. > #10 0x0000000000595b80 in ?? () > No symbol table info available. > #11 0x0000003a00c077f1 in start_thread () from /lib64/libpthread.so.0 > No symbol table info available. > #12 0x0000003a004e5ccd in clone () from /lib64/libc.so.6 > No symbol table info available. > (gdb) continue > Continuing. > [Thread 0x7f0369139700 (LWP 11349) exited] > [Thread 0x7f036993a700 (LWP 9523) exited] > > Program terminated with signal SIGABRT, Aborted. > The program no longer exists. > (gdb) quit > > Tell me if it help, or if you need more. > > Regards, > > Le 29/08/13, Nick Milas <nick(a)eurobjects.com> a écrit : > > On 29/8/2013 12:42 μμ, "POISSON Frédéric" wrote: > > > > >The server shutdown when i add this entry and with slapd option "-d 255" i have : > > >slapd: result.c:813: slap_send_ldap_result: Assertion `!((rs->sr_err)<0)' failed. > > >/etc/init.d/slapd: line 285: 5461 Aborted $SLAPD_BIN -h "$SLAPD_SERVICES" $SLAPD_PARAMS > > > > > >Notice that i test this ldif modification on release 2.4.35 without problem. > > > > Can you try taking a full backtrace? > > > > See for example: http://www.openldap.org/lists/openldap-technical/201111/msg00243.html > > > > I am not a developer, but I have been through the same situation, so I know that a full backtrace is needed for troubleshooting. > > > > Best regards, > > Nick > > > > > > > -- > > Frederic Poisson > > > > > > -- Frederic Poisson

2 2

The RootDN
by Joseph D Carroll Jr 29 Aug '13

29 Aug '13

It's been 3 days since I first started reading and playing with openLDAP. Prior to this, I have had no ldap experience of any kind, so please bear with me. (Hopefully this doesn't reach a new low... ) I am working on setting up my first ldap server for a demo environment, and I can't seem to wrap my head around what a rootdn is. I have read several articles, even much of the Zytrax book, and I still cannot figure out what this rootdn is. I get that it is a user, so maybe better stated, I don't understand where the user exists. Is it an OS user with filesystem privileges? Is it a user that exists in every DIT? If so, when/where is it used, can you have multiple, is it only usuable/accesible when you "include" the core.schema, .. ? If I had to guess, I would say: - A rootdn exists in the DIT as a completely arbitrary user (absolutely no relation to the OS) - There can only be one rootdn per DIT - (Consquently) If a parent defines a rootdn, any referral cannot - The rootdn is used for some kind of system action (who knows what) I know this is the "technical" forum, but I am more so interested in the "why to's" and "reasons behind" than the "how to's". Any clarity would be greatly appreciated. Thanks, JD

3 2

Re : Re: OpenLDAP 2.4.36 slapd crash with "assertion failed" message
by "POISSON Frédéric" 29 Aug '13

29 Aug '13

Hello, Ok thanks for the information, i try the gdb with full backtrace and i have : # gdb /usr/local/openldap/libexec/slapd 9522 GNU gdb (GDB) Red Hat Enterprise Linux (7.2-50.el6) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/local/openldap/libexec/slapd...(no debugging symbols found)...done. Attaching to program: /usr/local/openldap/libexec/slapd, process 9522 Reading symbols from /usr/local/berkeleydb/lib64/libdb-4.6.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/berkeleydb/lib64/libdb-4.6.so Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done. [Thread debugging using libthread_db enabled] [New Thread 0x7f036993a700 (LWP 9523)] Loaded symbols for /lib64/libpthread.so.0 Reading symbols from /usr/lib64/libsasl2.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libsasl2.so.2 Reading symbols from /usr/lib64/libssl.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libssl.so.10 Reading symbols from /usr/lib64/libcrypto.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libcrypto.so.10 Reading symbols from /lib64/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libcrypt.so.1 Reading symbols from /lib64/libresolv.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libresolv.so.2 Reading symbols from /usr/lib64/libltdl.so.7...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libltdl.so.7 Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /lib64/libgssapi_krb5.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libgssapi_krb5.so.2 Reading symbols from /lib64/libkrb5.so.3...(no debugging symbols found)...done. Loaded symbols for /lib64/libkrb5.so.3 Reading symbols from /lib64/libcom_err.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libcom_err.so.2 Reading symbols from /lib64/libk5crypto.so.3...(no debugging symbols found)...done. Loaded symbols for /lib64/libk5crypto.so.3 Reading symbols from /lib64/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libz.so.1 Reading symbols from /lib64/libfreebl3.so...(no debugging symbols found)...done. Loaded symbols for /lib64/libfreebl3.so Reading symbols from /lib64/libkrb5support.so.0...(no debugging symbols found)...done. Loaded symbols for /lib64/libkrb5support.so.0 Reading symbols from /lib64/libkeyutils.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libkeyutils.so.1 Reading symbols from /lib64/libselinux.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libselinux.so.1 Reading symbols from /lib64/libnss_files.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libnss_files.so.2 Reading symbols from /usr/lib64/sasl2/libsasldb.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libsasldb.so Reading symbols from /lib64/libdb-4.7.so...(no debugging symbols found)...done. Loaded symbols for /lib64/libdb-4.7.so Reading symbols from /usr/lib64/sasl2/libanonymous.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libanonymous.so 0x0000003a00c0804d in pthread_join () from /lib64/libpthread.so.0 Missing separate debuginfos, use: debuginfo-install openldap-ltb-2.4.36-1.el6.x86_64 (gdb) backtrace full #0 0x0000003a00c0804d in pthread_join () from /lib64/libpthread.so.0 No symbol table info available. #1 0x000000000043a0e9 in slapd_daemon () No symbol table info available. #2 0x0000000000426435 in main () No symbol table info available. (gdb) continue Continuing. [New Thread 0x7f0369139700 (LWP 11349)] Program received signal SIGABRT, Aborted. [Switching to Thread 0x7f0369139700 (LWP 11349)] 0x0000003a00432885 in raise () from /lib64/libc.so.6 (gdb) backtrace full #0 0x0000003a00432885 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x0000003a00434065 in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x0000003a0042b9fe in __assert_fail_base () from /lib64/libc.so.6 No symbol table info available. #3 0x0000003a0042bac0 in __assert_fail () from /lib64/libc.so.6 No symbol table info available. #4 0x0000000000450bed in slap_send_ldap_result () No symbol table info available. #5 0x000000000042d567 in ?? () No symbol table info available. #6 0x000000000045745b in fe_op_modify () No symbol table info available. #7 0x0000000000457d86 in do_modify () No symbol table info available. #8 0x000000000043fb79 in ?? () No symbol table info available. #9 0x0000000000440365 in ?? () No symbol table info available. #10 0x0000000000595b80 in ?? () No symbol table info available. #11 0x0000003a00c077f1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #12 0x0000003a004e5ccd in clone () from /lib64/libc.so.6 No symbol table info available. (gdb) continue Continuing. [Thread 0x7f0369139700 (LWP 11349) exited] [Thread 0x7f036993a700 (LWP 9523) exited] Program terminated with signal SIGABRT, Aborted. The program no longer exists. (gdb) quit Tell me if it help, or if you need more. Regards, Le 29/08/13, Nick Milas <nick(a)eurobjects.com> a écrit : > On 29/8/2013 12:42 μμ, "POISSON Frédéric" wrote: > > >The server shutdown when i add this entry and with slapd option "-d 255" i have : > >slapd: result.c:813: slap_send_ldap_result: Assertion `!((rs->sr_err)<0)' failed. > >/etc/init.d/slapd: line 285: 5461 Aborted $SLAPD_BIN -h "$SLAPD_SERVICES" $SLAPD_PARAMS > > > >Notice that i test this ldif modification on release 2.4.35 without problem. > > Can you try taking a full backtrace? > > See for example: http://www.openldap.org/lists/openldap-technical/201111/msg00243.html > > I am not a developer, but I have been through the same situation, so I know that a full backtrace is needed for troubleshooting. > > Best regards, > Nick > > > -- Frederic Poisson

2 1

OpenLDAP 2.4.36 slapd crash with "assertion failed" message
by "POISSON Frédéric" 29 Aug '13

29 Aug '13

Hello, I'm testing the latest release of OpenLDAP 2.4.36 and my slapd stop while i'm doing a change on cn=config. My tests are with my own compilation of OpenLDAP on a RHEL6 server but i see the same problem with "LTB project RPMs" http://ltb-project.org/wiki/download#openldap with RHEL6 package. My aim is to modify cn=config like this in order to implement TLS, here is my ldif : dn: cn=config changetype: modify add: olcTLSRandFile olcTLSRandFile: /dev/random The server shutdown when i add this entry and with slapd option "-d 255" i have : slapd: result.c:813: slap_send_ldap_result: Assertion `!((rs->sr_err)<0)' failed. /etc/init.d/slapd: line 285: 5461 Aborted $SLAPD_BIN -h "$SLAPD_SERVICES" $SLAPD_PARAMS Notice that i test this ldif modification on release 2.4.35 without problem. Is there any changes inside cn=config behavior with release 2.4.36 that i don't see ? Thanks in advance, Regards, PS: This is my second submission to mailling list, sorry for the convenience. -- Frederic Poisson

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical