Issue with mdb_cursor_del in MDB_DUPSORT databases
by Mark Zealey
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
7 years, 7 months
RE: ldapadd "ldap_bind: Invalid credentials (49)"
by Juergen.Sprenger＠swisscom.com
--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
7 years, 7 months
ldapadd "ldap_bind: Invalid credentials (49)"
by Clint Petty
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)
7 years, 7 months
Unstable slapd-meta connection with MS AD LDAP
by Nick Anzalone
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
7 years, 7 months
Re : Re: OpenLDAP 2.4.36 slapd crash with "assertion failed" message
by "POISSON Frédéric"
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
7 years, 7 months
The RootDN
by Joseph D Carroll Jr
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
7 years, 7 months
Re : Re: OpenLDAP 2.4.36 slapd crash with "assertion failed" message
by "POISSON Frédéric"
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
7 years, 7 months
OpenLDAP 2.4.36 slapd crash with "assertion failed" message
by "POISSON Frédéric"
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
7 years, 7 months
OpenLDAP Samba4
by Pascal den Bekker
Hello,
I want to use openldap as a backend for Samba4. I set up the openldap
with a different port, because samba4 has an own "ldap" server running
on port 389.
I set up the standard config for samba4 like this:
passdb backend = ldapsam:ldap://ldap.example.com:3389
ldap suffix = dc=ldap,dc=example,dc=com
ldap user suffix = ou=users
ldap group suffix = ou=groups
ldap machine suffix = ou=computers
ldap idmap suffix = ou=Idmap
ldap delete dn = no
ldap admin dn = cn=admin,dc=ldap,dc=example,dc=com
ldap ssl = no
ldap passwd sync = yes
idmap_ldb:use rfc2307 = Yes
invalid users = root
Created also the ou's in openldap, added a couple of users in openldap.
Also set the smbpasswd, but everytime when I try to ask the openldap
through samba. Im getting:
smbldap_search_domain_info: Adding domain info for OPENCHANGE failed
with NT_STATUS_UNSUCCESSFUL
Do I still need to load the samba.schema in openldap ? And when yes..
How do I do that??
openldap: 2.4.31
samba: 4.0.1
OS: Debian Wheezy
Cheers,
--
Pascal den Bekker
Linux System Administrator
Affinitas GmbH | Kohlfurter Straße 41/43 | 10999 Berlin | Germany
email: pascal_den.bekker(a)affinitas.de | tel: +49 30 868 000 140
www.edarling.de | www.shopaman.de
Geschäftsführer: Lukas Brosseder, David Khalil, Michael Schrezenmaier
Eingetragen beim Amtsgericht Berlin-Charlottenburg, HRB 115958
7 years, 7 months
Object not found
by espeake＠oreillyauto.com
I have a user name readonly that we use in our applications to get uid's.
THis has worked in the past with our old LDAP solution. We have moved to
2.4.31 on Ubuntu 12.04 with a n-way Multi master setup.
The slap cat for this database looks like this.
dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=oreillyauto,dc=com
olcAccess: {0}to attrs=userPassword by anonymous auth by * none
olcAccess: {1}to dn.subtree="dc=oreillyauto,dc=com" by
group/groupOfUniqueName
s/uniqueMember="cn=System Administrators,ou=Groups,dc=oreillyauto,dc=com"
wri
te by group/groupOfUniqueNames/uniqueMember="cn=LDAP
Admin,ou=Groups,dc=oreil
lyauto,dc=com" write by * none break
olcAccess: {2}to attrs=userPassword by
group/groupOfUniqueNames/uniqueMember="
cn=Authenticate,ou=Groups,dc=oreillyauto,dc=com" write by anonymous auth
by s
elf write
olcAccess: {3}to attrs=uid by anonymous read by users read
olcAccess: {4}to attrs=ou,employeeNumber by users read
olcAccess: {5}to dn.subtree="ou=System,dc=oreillyauto,dc=com" by
dn.subtree="o
u=Users,dc=oreillyauto,dc=com" none by users read
olcAccess: {6}to dn.children="ou=Groups,dc=oreillyauto,dc=com" by
dnattr=owner
write by dnattr=uniqueMember read by * none
olcAccess: {7}to dn.children="ou=Users,dc=oreillyauto,dc=com" by self read
by
group/groupOfUniqueNames/uniqueMember="cn=Authenticate,ou=Groups,dc=oreillya
uto,dc=com" read by * none
olcAccess: {8}to * by self read by users read
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcLimits: {0}dn.exact="uid=syncrepl,ou=System,dc=oreillyauto,dc=com"
time.sof
t=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
olcLimits: {1}dn.exact="uid=ldapAdmin,ou=System,dc=oreillyauto,dc=com"
time.so
ft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
olcLimits: {2}dn.exact="uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com"
time
.soft=unlimited time.hard=unlimited size.soft=unlimited
size.hard=unlimited
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: uid=admin,dc=oreillyauto,dc=com
olcRootPW:: c2VjcmV0
olcSyncUseSubentry: FALSE
olcDbCacheSize: 50000
olcDbCheckpoint: 512 30
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 150000
olcDbIndex: objectClass eq
olcDbIndex: cn eq
olcDbIndex: uid eq
olcDbIndex: oreillyGroup eq
olcDbIndex: locationEntry eq
olcDbIndex: counterNumber eq
olcDbIndex: businessCategory eq
olcDbIndex: locationNumber eq
olcDbIndex: position eq
olcDbIndex: title eq,subany
olcDbIndex: givenName eq,subany
olcDbIndex: functionListing eq
olcDbIndex: manager eq
olcDbIndex: sn eq,subany
olcDbIndex: nickName eq,subany
olcDbIndex: employeeNumber eq
olcDbIndex: ou eq
olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
olcDbIndex: supervisor eq
olcDbIndex: status eq
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcHdbConfig
entryUUID: 91ce693e-9e13-1032-84c2-0151b658a842
createTimestamp: 20130820183919Z
creatorsName: cn=config
olcMirrorMode: TRUE
olcSyncrepl: {0}rid=004 provider=ldap://tntest-ldap-3.oreillyauto.com b
inddn="uid=admin,dc=oreillyauto,dc=com" bindmethod=simple
credentials=<password>
searchbase="dc=oreillyauto,dc=com" type=refreshAndPersist retry="5 5 5 +"
tim
eout=1
olcSyncrepl: {1}rid=005 provider=ldap://tntest-ldap-1.oreillyauto.com
binddn="
uid=admin,dc=oreillyauto,dc=com" bindmethod=simple credentials=<password>
searchb
ase="dc=oreillyauto,dc=com" type=refreshAndPersist retry="5 5 5 +"
timeout=1
olcSyncrepl: {2}rid=006 provider=ldap://tntest-ldap-2.oreillyauto.com
binddn="
uid=admin,dc=oreillyauto,dc=com" bindmethod=simple credentials=<password>
searchb
ase="dc=oreillyauto,dc=com" type=refreshAndPersist retry="5 5 5 +"
timeout=1
entryCSN: 20130821193620.549061Z#000000#002#000000
modifiersName: uid=admin,dc=oreillyauto,dc=com
modifyTimestamp: 20130821193620Z
And the ldap logs show this:
Aug 28 07:56:48 tntest-ldap-1 slapd[3067]: conn=27464 op=0 BIND
dn="uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com" method=128
Aug 28 07:56:48 tntest-ldap-1 slapd[3067]: conn=27464 op=0 BIND
dn="uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com" mech=SIMPLE ssf=0
Aug 28 07:56:48 tntest-ldap-1 slapd[3067]: conn=27464 op=0 RESULT tag=97
err=0 text=
Aug 28 07:56:48 tntest-ldap-1 slapd[3067]: conn=27464 op=1 SRCH
base="uid=espeake,ou=Users,dc=oreillyauto,dc=com" scope=0 deref=3
filter="(objectClass=*)"
Aug 28 07:56:48 tntest-ldap-1 slapd[3067]: conn=27464 op=1 SEARCH RESULT
tag=101 err=32 nentries=0 text=
Aug 28 07:56:48 tntest-ldap-1 slapd[3067]: conn=27464 op=2 UNBIND
Aug 28 07:56:48 tntest-ldap-1 slapd[3067]: conn=27464 fd=40 closed
We had one issue with this server not running a rebuild last night due to a
certificate error of the cacert not being found and we are addressing the
through the following article:
http://www.mikepilat.com/blog/2011/05/adding-a-certificate-authority-to-t...
Searching as the ldapadmin user I find the user. So I am thinking that I
need to adjust the ACL here but I'm not seeing what is wrong.
Thanks,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
7 years, 7 months
