openldap-bugs October 2013

openldap-bugs@openldap.org

25 participants
95 discussions

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

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

18 Oct '13

This is a cryptographically signed message in MIME format. --------------ms050104040805090407080805 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hyc(a)symas.com wrote: > Yes, your test config shows that the problem is that rwm_conn_destroy f= rees=20 > the session context while rwm_op_search is using it. Seems like the rwm= =20 > overlay is not doing reference counting properly. I had problems with a certain configuration of slapo-rwm where slapcat se= g faulted after writing all the LDIF data. Could this be related? Never found the time to construct a simple config showing the issue thoug= h. Ciao, Michael. --------------ms050104040805090407080805 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMDE4MjIyOTE0WjAj BgkqhkiG9w0BCQQxFgQUpusHNy0yKlNww0KbhZA5EJpix5kwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAshlSUWOl5MUBUKz+KUpiNpAdAxQObrGR gVzeWE41HIVpNtzJ9Ay179lryM/geFL65OJlQuotw7qpwwCBQicr/ryYWwJzKbMMKRHROEkj 9J8vutxDnbK4ugSuW6FfoIbvSgV2+olagyKBtO6Cu+TFPUyXpyHS0FiPx6xyBFSMo/xkMZ03 DLd8UPAga+LrV/JRtMXShGsyNHifk7wl14lHxPi7OpZ53ny14PNhfRCC0vldD/2RX5hWWivU 0lkPd7QPGHZnsHZfsStnF7s6TdA578zumQTb23spRNrqS8OCWvxbr25K+srcQDgWM1Upe+K9 I1WTDt31Zw+km2DN1jTGvQAAAAAAAA== --------------ms050104040805090407080805--

1 0

Re: (ITS#7726) how to config kerberos with openldap via clear passwords?
by quanah＠zimbra.com 18 Oct '13

18 Oct '13

--On Friday, October 18, 2013 9:14 PM +0000 mostafa.basu(a)gmail.com wrote: > Full_Name: Mostafa Moeini > Version: 2.4.23 > OS: CentOS 5 X86 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (199.201.121.184) > > > I want to use kerberos with openldap backend. > but the problem is kerberos encrypt passwords before save into ldap > database . how can I config kerberos to use clear mode for saving (and > reading) passwords? The ITS system is for reporting bugs. It is *not* for asking "how do I" questions. Please use the appropriate resource (the openldap-technical(a)openldap.org mailing list). This ITS will be closed. I would also strongly advise you to upgrade to a current openldap release. 2.4.23 is years old. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7726) how to config kerberos with openldap via clear passwords?
by mostafa.basu＠gmail.com 18 Oct '13

18 Oct '13

Full_Name: Mostafa Moeini Version: 2.4.23 OS: CentOS 5 X86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (199.201.121.184) I want to use kerberos with openldap backend. but the problem is kerberos encrypt passwords before save into ldap database . how can I config kerberos to use clear mode for saving (and reading) passwords?

1 0

Re: (ITS#7705) mdb back-end segfaults sporadically with paged searches
by quanah＠zimbra.com 18 Oct '13

18 Oct '13

--On Tuesday, September 24, 2013 5:58 PM +0000 openldap(a)semyon.org wrote: > On 13-09-23 10:16 PM, Howard Chu wrote: > >> If you backup the DB with slapcat and reload it on another server with >> slapadd, can you still reproduce the fault on the copy? > > Unfortunately, yes. It breaks trying to retrieve the same record as > before, on the same instruction in back_mdb: > > yesterday: > [126393.233615] slapd[19244]: segfault at 7f499f38d000 ip > 00007f4da0e9b6a1 sp 00007f499f1fa540 error 6 in > back_mdb-2.4.so.2.9.2[7f4da0e80000+34000] > > today: > [517860.953779] slapd[24871]: segfault at 7fdeb50a0000 ip > 00007fe2b63ad6a1 sp 00007fdeb4f0d540 error 6 in > back_mdb-2.4.so.2.9.2[7fe2b6392000+34000] Please provide a useful bug report. I.e., get a stack trace from gdb, as noted in: <http://www.openldap.org/faq/data/cache/59.html> Sample data/testcase/configs always welcome as well. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2013