openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#7735) Memory leaks on Multi-Master replications
by dmitrii.fonariuk＠gmail.com 29 Oct '13

29 Oct '13

Full_Name: Dmitrii Fonariuk Version: 2.4.37 OS: RHEL6.x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.210.4.1) Hi. I have 2 servers with OpenLDAP 2.4.37 in Multi-Master replication. If I send modify request to only one server no memory leaks. If I send different modify request on both servers I see a memory leaks on both servers. Here are the settings of one of the servers: dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcConfig objectClass: top objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /opt/local/OpenLDAP/data/mdb3 olcDbEnvFlags: writemap olcDbEnvFlags: mapasync olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbIndex: objectClass eq olcDbMaxSize: 5368709120 olcLimits: {0}dn.exact="uid=replica1,uid=admin,dc=rrr" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited olcMirrorMode: TRUE olcRootDN: dc=rrr olcRootPW: secret olcSuffix: dc=rrr olcSyncrepl: {0}rid=010 provider=ldap://srv-rrr03:3903 binddn="uid=replica1,uid=admin,dc=rrr" bindmethod=simple credentials=replica1 searchbase="dc=rrr" schemachecking=off type=refreshAndPersist retry="5 5 60 +" dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcSyncProvConfig objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top olcOverlay: {0}syncprov olcSpCheckpoint: 1000 5 Requests on one server: dn: id=1000000000[10000-30000],ou=subscriber,o=Megatron,dc=rrr changetype: modify replace: state state: [1-9] no memory leaks Requests on both servers: 1: dn: id=1000000000[10000-20000],ou=subscriber,o=Megatron,dc=rrr changetype: modify replace: state state: [1-9] 2: dn: id=1000000000[20001-30000],ou=subscriber,o=Megatron,dc=rrr changetype: modify replace: state state: [1-9] memory leaks * in square brackets ranges. Ranges for DN do not overlap for different servers. State is numericString attribute.

1 0

Re: (ITS#7705) mdb back-end segfaults sporadically with paged searches
by openldap＠semyon.org 28 Oct '13

28 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 The problem seems to be resolved in OPENLDAP_REL_ENG_2_4_37. Please close this ticket. Best Semyon -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQGcBAEBCgAGBQJSbugyAAoJEDnsppBba4kKtNcL/0YHZaQfYOL7X5LBkYlsHX86 JtLPPT8mCax9ehrTQUmz5ZzuzV2YkQ2KnzO45Gb8K721bNTCuNBwlXvT33yh+I0T QCEOAdMOxAasC27BW3L46Bbw+lW9/GPfxW8p6eGaw2qDCpIwRluxApysi+paRZR1 VCXu/z8/zLIEVMDKq/lktGnCBFR7uNBr575G4ePZVgytDO8aEk/F2VE+LQRBbfVL 25zlQesiO8EEPk5blbBhRFxTUZEBs/0EAnBB7hoBVKDlbog4tjOav6aNq1o4TegS +0oNgZS+K0Krop/3v27dr+LzaFy07jySE4aDgXKstgqzM4uvZzCSxarsFPZyUqbd sJNXBEKM5HUMn6orl6Ip7Z7h0MSkPYAH7OZLWXYTOmgl5wgJ8ArQSMMTD9+vC/yk McIDElkqCoRce/IRfRYjS+Ct+qaEB7AYKhtbzVAwPjJBIj4S5N24xUShjDCvkjay K6oj3GQFq78jp2ehITHn9zytiw12gmhv+V42hEQY+g== =VzO+ -----END PGP SIGNATURE-----

1 0

ITS#7731
by hyc＠symas.com 28 Oct '13

28 Oct '13

The ITS is for actual bug reports, not for software usage questions. This ITS will be closed. Since you're using an RHEL build you should contact RedHat for support. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7734) MDB_NORDAHEAD missing from valid flags bitfields
by dw＠botanicus.net 27 Oct '13

27 Oct '13

Full_Name: David Wilson Version: LMDB 0.9.9 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (178.238.153.20) Unless I'm missing something, this new flag cannot be set during mdb_env_open(), and since it is not in CHANGEABLE either, cannot be set with mdb_env_set_flags() commit dd0df21ce0a935955966aa7d3077d666741d027f Author: David Wilson <dw(a)botanicus.net> Date: Mon Oct 28 01:28:00 2013 +0000 Add MDB_NORDAHEAD to CHANGELESS. diff --git a/lib/mdb.c b/lib/mdb.c index 33be876..3ec7302 100644 --- a/lib/mdb.c +++ b/lib/mdb.c @@ -3929,7 +3929,7 @@ fail: * environment and re-opening it with the new flags. */ #define CHANGEABLE (MDB_NOSYNC|MDB_NOMETASYNC|MDB_MAPASYNC) -#define CHANGELESS (MDB_FIXEDMAP|MDB_NOSUBDIR|MDB_RDONLY|MDB_WRITEMAP|MDB_NOTLS|MDB_NOLOCK) +#define CHANGELESS (MDB_FIXEDMAP|MDB_NOSUBDIR|MDB_RDONLY|MDB_WRITEMAP|MDB_NOTLS|MDB_NOLOCK|MDB_NORDAHEAD) int mdb_env_open(MDB_env *env, const char *path, unsigned int flags, mdb_mode_t mode)

1 0

Re: (ITS#7733) Assert failure calling mdb_cursor_del()
by dw＠botanicus.net 27 Oct '13

27 Oct '13

--001a11c350da0b6da604e9c2bb08 Content-Type: text/plain; charset=ISO-8859-1 Repro here: https://raw.github.com/dw/py-lmdb/master/misc/its7733.c --001a11c350da0b6da604e9c2bb08 Content-Type: text/html; charset=ISO-8859-1 <div dir="ltr">Repro here: <a href="https://raw.github.com/dw/py-lmdb/master/misc/its7733.c">https://raw.github.com/dw/py-lmdb/master/misc/its7733.c</a><br></div> --001a11c350da0b6da604e9c2bb08--

1 0

(ITS#7733) Assert failure calling mdb_cursor_del()
by dw＠botanicus.net 27 Oct '13

27 Oct '13

Full_Name: David Wilson Version: LMDB 0.9.9 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (178.238.153.20) Given a new environment whose main DBI has the following records inserted (in the displayed order): ['a', ''] ['b', ''] ['baa', ''] ['d', ''] mdb_cursor_set(MDB_LAST) then mdb_cursor_del(..., 0) then mdb_cursor_del(..., 0) will cause an abort: Assertion failed: (indx < NUMKEYS(mp)), function mdb_node_del, file lib/mdb.c, line 6380.

1 0

(ITS#7732) CSN too old MMR setup
by lanfeust99＠gmail.com 24 Oct '13

24 Oct '13

Full_Name: Lanfeut Version: 2.4.36 OS: Centos URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.42.151.220) sometimes my server a not in sync. because server ignoring entry: do_syncrep2: rid=102 CSN too old, ignoring 20130923090023.266239Z#000000#002#000000 @(#) $OpenLDAP: slapd 2.4.36 (....) 4 server host1 and host 2: only one database c=fr ( contain an ou=apps-ext ) host3 and host 4: tow database: first ou=apps-ext (glued with c=fr ). writable by host1,2,3,4 second c=fr writable only by host1,2 ldap-int1 and ldap-int2 cn=config also into syncrepl mirrorMode ldap-ext1 and ldap-ext2 cn=config also into syncrepl mirrorMode all server are time sync. Configuration: grep serverID /etc/openldap/slapd.d/* /etc/openldap/slapd.d/cn=config.ldif:olcServerID: 1 ldaps://ldap-int1.dom.fr /etc/openldap/slapd.d/cn=config.ldif:olcServerID: 2 ldaps://ldap-int2.dom.fr /etc/openldap/slapd.d/cn=config.ldif:olcServerID: 3 ldaps://ldap-ext1.vlandata.dom.fr /etc/openldap/slapd.d/cn=config.ldif:olcServerID: 4 ldaps://ldap-ext2.vlandata.dom.fr syncrepl: ldap-int1 and ldap-int2 cn=config also into syncrepl olcSyncrepl: {0}rid=101 provider=ldaps://ldap-int1.dom.fr binddn="uid=syncrepl ,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXXXXX sea rchbase="c=fr" tls_reqcert=never type=refreshAndPersist retry="5 5 300 +" timeout=1 olcSyncrepl: {1}rid=102 provider=ldaps://ldap-int2.cdoms.fr binddn="uid=syncrepl ,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXXXXX sea rchbase="c=fr" tls_reqcert=never type=refreshAndPersist retry="5 5 300 +" timeout=1 olcSyncrepl: {2}rid=103 provider=ldaps://ldap-ext2.vlandata.dom.fr binddn="uid =syncrepl,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XX XXXX tls_reqcert=never searchbase="o=apps-ext,c=fr" type=refreshAndPersist r etry="5 5 300 +" timeout=1 olcSyncrepl: {3}rid=104 provider=ldaps://ldap-ext1.vlandata.dom.fr binddn="uid =syncrepl,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXX XXXX searchbase="o=apps-ext,c=fr" tls_reqcert=never type=refreshAndPersist r etry="5 5 300 +" timeout=1 syncrepl host3 and host4: database apps-ext: olcSyncrepl: {0}rid=303 provider=ldaps://ldap-ext1.vlandata.dom.fr binddn="uid =syncrepl,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXX XXXX searchbase="o=apps-ext,c=fr" tls_reqcert=never type=refreshAndPersist r etry="5 5 300 +" timeout=1 olcSyncrepl: {1}rid=304 provider=ldaps://ldap-ext2.vlandata.dom.fr binddn="uid =syncrepl,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXX XXX searchbase="o=apps-ext,c=fr" tls_reqcert=never type=refreshAndPersist r etry="5 5 300 +" timeout=1 database c=fr : olcSyncrepl: {0}rid=201 provider=ldaps://ldap-int1.dom.fr binddn="uid=syncrepl ,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXXXXX sea rchbase="c=fr" tls_reqcert=never type=refreshAndPersist retry="5 5 300 +" tim eout=1 olcSyncrepl: {1}rid=202 provider=ldaps://ldap-int2.dom.fr binddn="uid=syncrepl ,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXXXXX tls _reqcert=never searchbase="c=fr" type=refreshAndPersist retry="5 5 300 +" tim eout=1 ldap-int1 receive syncrepl modification from ldap-int2 with this log: ldap-int1 log: syncprov_matchops: skipping original sid 002 Oct 4 15:00:24 ldap-int1 slapd[24555]: slap_graduate_commit_csn: removing 0x7f7bf8200b40 20131004150021.988007Z#000000#002#000000 Oct 4 15:00:24 ldap-int1 slapd[24555]: syncrepl_entry: rid=102 be_add cn=502296-xxxxxx,ou=aaaaa,ou=bbbb,o=cccc,c=dd (0) ... ... ldap-ext2 receive the same modification an reply to ldap-int1 with new cookie ldap-int1 log Oct 4 15:00:24 ldap-int1 slapd[24555]: do_syncrep2: rid=103 NEW_COOKIE: rid=103,sid=004,csn=20130304121522.188962Z#000000#000#000000;20131004082718.688747Z#000000#001#000000;20131004150023.350876Z#000000#002#000000;20130920094950.036431Z#000000#003#000000;20130930134451.718477Z#000000#004#000000;20130304131428.455916Z#000000#00b#000000;20130304125618.164164Z#000000#00c#00000 Another modification from ldap-int2 isn't apply to ldap-int1 because of csn too old Oct 4 15:00:24 ldap-int1 slapd[24555]: syncrepl_entry: rid=102 be_add cn=502296-bbbb,ou=aaaaa,ou=bbbb,o=cccc,c=dd (0) Oct 4 15:00:24 ldap-int1 slapd[24555]: do_syncrep2: rid=102 cookie=rid=102,sid=002,csn=20131004150022.050845Z#000000#002#000000 Oct 4 15:00:24 ldap-int1 slapd[24555]: do_syncrep2: rid=102 CSN too old, ignoring 20131004150022.050845Z#000000#002#000000 (cn=502296-bbbb,ou=aaaaa,ou=bbbb,o=cccc,c=dd) Oct 4 15:00:24 ldap-int1 slapd[24555]: do_syncrep2: rid=102 cookie=rid=102,sid=002,csn=20131004150022.100121Z#000000#002#000000

1 0

Re: (ITS#7723) slapd crashes on multi core machines if a search request is *immediately* followed by an unbind
by jsynacek＠redhat.com 23 Oct '13

23 Oct '13

On 10/15/2013 02:03 PM, hyc(a)symas.com wrote: > Yes, your test config shows that the problem is that rwm_conn_destroy frees > the session context while rwm_op_search is using it. Seems like the rwm > overlay is not doing reference counting properly. > With the current master (fe49824f83bb0f2dd2f543c26f186b516c1d75bd), this is how the trace looks like: (gdb) t apply all bt Thread 5 (Thread 0x7f53f9009700 (LWP 28210)): #0 0x000000309360dded in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x0000003093609ba1 in _L_lock_790 () from /lib64/libpthread.so.0 #2 0x0000003093609aa7 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00007f5401b530a7 in ldap_pvt_thread_mutex_lock (mutex=0x7f53f980c768) at thr_posix.c:296 #4 0x0000000000445287 in connection_operation (ctx=0x7f53f9008bb0, arg_v=0x7f53e0001230) at connection.c:1147 #5 0x00007f5401b51993 in ldap_int_thread_pool_wrapper (xpool=0x937380) at tpool.c:945 #6 0x0000003093607c53 in start_thread () from /lib64/libpthread.so.0 #7 0x0000003092ef5e1d in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x7f53f3fff700 (LWP 28215)): #0 0x000000309360b575 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f5401b53054 in ldap_pvt_thread_cond_wait (cond=0x9373b8, mutex=0x937390) at thr_posix.c:277 #2 0x00007f5401b518be in ldap_int_thread_pool_wrapper (xpool=0x937380) at tpool.c:927 #3 0x0000003093607c53 in start_thread () from /lib64/libpthread.so.0 #4 0x0000003092ef5e1d in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x7f54016dd740 (LWP 28178)): #0 0x0000003093608d97 in pthread_join () from /lib64/libpthread.so.0 #1 0x00007f5401b52f95 in ldap_pvt_thread_join (thread=139998644971264, thread_return=0x0) at thr_posix.c:197 #2 0x0000000000441bb4 in slapd_daemon () at daemon.c:2907 #3 0x000000000041b28a in main (argc=10, argv=0x7fff84c32388) at main.c:1013 Thread 2 (Thread 0x7f53f980a700 (LWP 28197)): #0 0x0000003092ef63f3 in epoll_wait () from /lib64/libc.so.6 #1 0x00000000004406b4 in slapd_daemon_task (ptr=0x9c02d0) at daemon.c:2514 #2 0x0000003093607c53 in start_thread () from /lib64/libpthread.so.0 #3 0x0000003092ef5e1d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7f53f8808700 (LWP 28214)): #0 0x00000000004c121a in slap_sl_free (ptr=0x7f53e8000b40, ctx=0x7f53e80009d0) at sl_malloc.c:513 #1 0x0000000000449520 in do_search (op=0x7f53e0103c60, rs=0x7f53f8807ad0) at search.c:257 #2 0x00000000004451d4 in connection_operation (ctx=0x7f53f8807bb0, arg_v=0x7f53e0103c60) at connection.c:1134 #3 0x00007f5401b51993 in ldap_int_thread_pool_wrapper (xpool=0x937380) at tpool.c:945 #4 0x0000003093607c53 in start_thread () from /lib64/libpthread.so.0 #5 0x0000003092ef5e1d in clone () from /lib64/libc.so.6 (gdb) bt full #0 0x00000000004c121a in slap_sl_free (ptr=0x7f53e8000b40, ctx=0x7f53e80009d0) at sl_malloc.c:513 sh = 0x7f53e80009d0 size = 7286935691776455520 p = 0x7f53e8000b38 nextp = 0x6520e4bb49737e98 tmpp = 0x7f53f8807ad0 #1 0x0000000000449520 in do_search (op=0x7f53e0103c60, rs=0x7f53f8807ad0) at search.c:257 base = {bv_len = 6, bv_val = 0x7f53e00009c7 "o=test"} siz = 0 off = 0 i = 0 #2 0x00000000004451d4 in connection_operation (ctx=0x7f53f8807bb0, arg_v=0x7f53e0103c60) at connection.c:1134 rc = 80 cancel = 0 op = 0x7f53e0103c60 rs = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 2, sr_err = 80, sr_matched = 0x0, sr_text = 0x7f53f98d4fe6 "searchDN massage error", 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 = 99 opidx = SLAP_OP_SEARCH conn = 0x7f53f980c750 memctx = 0x7f53e80009d0 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #3 0x00007f5401b51993 in ldap_int_thread_pool_wrapper (xpool=0x937380) at tpool.c:945 pq = 0x937380 pool = 0x937280 task = 0x7f53ec113d60 work_list = 0x9373f0 ctx = {ltu_pq = 0x937380, ltu_id = 139998628185856, ltu_key = {{ltk_key = 0x444c86 <conn_counter_init>, ltk_data = 0x7f53e80008c0, ltk_free = 0x444a7d <conn_counter_destroy>}, {ltk_key = 0x4c0182 <slap_sl_mem_init>, ltk_data = 0x7f53e80009d0, ltk_free = 0x4bffa7 <slap_sl_mem_destroy>}, {ltk_key = 0x461f28 <slap_op_free>, ltk_data = 0x0, ltk_free = 0x461e7b <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 29 times>}} kctx = 0x0 i = 32 keyslot = 817 hash = 1596318513 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" I used the reproducer provided by Michael. The core was generated by the server running with slapd1.conf. -- Jan Synacek Software Engineer, Red Hat

1 0

Re: (ITS#7730) Error:passwd: Authentication token manipulation error
by quanah＠zimbra.com 19 Oct '13

19 Oct '13

--On Saturday, October 19, 2013 9:59 AM +0000 skadian1(a)gmail.com wrote: > Full_Name: sumit kadian > Version: 2.4.23 > OS: centos 6.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (122.176.201.133) The ITS system is for bug reports, not usage questions. Send questions to openldap-technical(a)openldap.org. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7730) Error:passwd: Authentication token manipulation error
by skadian1＠gmail.com 19 Oct '13

19 Oct '13

Full_Name: sumit kadian Version: 2.4.23 OS: centos 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (122.176.201.133) Hi, I have configured the openldap server with tls on Centos 6.4. And also authenticated the client with authconfig-gtk. Now I try to change the password of ldap user on the client machine, then it giving following error:- "passwd: Authentication token manipulation error " here is the configuration file ================================================================================== # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/corba.schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/duaconf.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/java.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/collective.schema # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 allow update_anon # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args # Load dynamic backend modules # - modulepath is architecture dependent value (32/64-bit system) # - back_sql.la overlay requires openldap-server-sql package # - dyngroup.la and dynlist.la cannot be used at the same time # modulepath /usr/lib/openldap # modulepath /usr/lib64/openldap # moduleload accesslog.la # moduleload auditlog.la # moduleload back_sql.la # moduleload chain.la # moduleload collect.la # moduleload constraint.la # moduleload dds.la # moduleload deref.la # moduleload dyngroup.la # moduleload dynlist.la # moduleload memberof.la # moduleload pbind.la # moduleload pcache.la # moduleload ppolicy.la # moduleload refint.la # moduleload retcode.la # moduleload rwm.la # moduleload seqmod.la # moduleload smbk5pwd.la # moduleload sssvlv.la #moduleload syncprov.la # moduleload translucent.la # moduleload unique.la # moduleload valsort.la # The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by running # /usr/libexec/openldap/generate-server-cert.sh. Your client software may balk # at self-signed certificates, however. #TLSCACertificatePath /etc/openldap/certs #TLSCertificateFile "\"OpenLDAP Server\"" #TLSCertificateKeyFile /etc/openldap/certs/password TLSCACertificatePath /etc/pki/tls/certs/ TLSCertificateFile /etc/pki/tls/certs/new.pem TLSCertificateKeyFile /etc/pki/tls/certs/new.pem # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: #access to dn.base="" by * read #access to dn.base="cn=Subschema" by * read #access to * by * read # access to attrs=userPassword # by self =xw # access to * by * write # access to * by anonymous none # by self write # by users read # by anonymous auth # access to attrs=userPassword by self write by anonymous auth by * none # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! # by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage # enable on-the-fly configuration (cn=config) database config access to * by * read by * write # enable server status monitoring (cn=monitor) database monitor access to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.exact="cn=Manager,dc=example,dc=com" read by * write ####################################################################### # database definitions ####################################################################### database bdb suffix "dc=example,dc=com" checkpoint 1024 15 rootdn "cn=Manager,dc=example,dc=com" #loglevel -1 #logfile /var/log/ldap.log # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw redhat # rootpw {crypt}ijFYNcSNctBYg #olcLogFile /var/log/slapd.log # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap # Indices to maintain for this database index objectClass eq #index ou,cn,mail,surname,givenname eq,pres,sub #index uidNumber,gidNumber,loginShell eq,pres #index uid,memberUid eq,pres,sub #index nisMapName,nisMapEntry eq,pres,sub #index entryCSN,entryUUID eq ========================================

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs