openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

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 20 Oct '13

20 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 19 Oct '13

19 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

Re: (ITS#7713) Segmentation fault if the pagesize of the Operating system is not equal to 4096.
by hyc＠symas.com 16 Oct '13

16 Oct '13

sumanth wrote: > As per ur suggestions,tried changing > > 1. MDB_PAGESIZE to 65536 > 2. changing pb_lower and pb_upper to uint32_t. > As of now it is running fine for the existing testcases in openldap-2.4.36. > However there were problems in 2.4.35. Also saw the comments in > openldap-devel. So whether this will make to openldap 2.4.36? The current plan is to fix this in OpenLDAP 2.5, and we are now halting new development in 2.4. -- -- 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

Re: (ITS#7713) Segmentation fault if the pagesize of the Operating system is not equal to 4096.
by sumantk2＠linux.vnet.ibm.com 16 Oct '13

16 Oct '13

This is a multi-part message in MIME format. --------------050805010104090604050102 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit As per ur suggestions,tried changing 1. MDB_PAGESIZE to 65536 2. changing pb_lower and pb_upper to uint32_t. As of now it is running fine for the existing testcases in openldap-2.4.36. However there were problems in 2.4.35. Also saw the comments in openldap-devel. So whether this will make to openldap 2.4.36? Thank you, Sumanth K --------------050805010104090604050102 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> As per ur suggestions,tried changing 1. MDB_PAGESIZE to 65536 2. changing pb_lower and pb_upper to uint32_t. As of now it is running fine for the existing testcases in openldap-2.4.36. However there were problems in 2.4.35. Also saw the comments in openldap-devel. So whether this will make to openldap 2.4.36? Thank you, Sumanth K <span style="color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); display: inline !important; float: none;"> </body> </html> --------------050805010104090604050102--

1 0

RE: (ITS#7717) Sudden memory increase leading to Master LDAP crash
by quanah＠zimbra.com 15 Oct '13

15 Oct '13

--On Tuesday, October 15, 2013 11:47 PM +0200 Bruno Marcon <marcon.bruno(a)free.fr> wrote: > I have found the origin of the memory increase. The problem occur with a > huge group and the RefreshAndPersist mode replication without using DELTA > Sync. So each slaves pull from the master the entire entry. > > The LDAP contains about 100.000 users. All of them are member of a group > name "XXX". The group XXX is a group with 100.000 attributes "member", > one for each user. > > So when I assign 20 users per seconds to the XXX group, the master LDAP > push (or the slaves pull ?) the group XXX 20 times per seconds for each > slaves (there is 5 slaves). > > 5x20x100.000 = 10.000.000 attributes per seconds... The master LDAP handle > this rate for several seconds, perhaps one minute, then suddenly increase > in memory and is killed by the OS at 2Go of memory. > > To avoid this, i have set the DELTA sync replication to only send the > modification : for each assignition of a user in the group, only the > attribute member for the user is replicate. > > A question is why the LDAP is increasing in memory ? it should be slowed > rather than store something in memory after having reach a limit ? > > Our main problem now is : we have two masters in mirror mode, and 4 > replicas. For the replicas, I can use the DELTA sync mode. For the > recovery master (for fail over), I can't use DELTA sync because this mode > is not supported in Mirror mode. > So we have configure the masters replication in RefreshOnly mode with a > polling period of 5 seconds, to avoid this memory increase in > RefreshAndPersist mode without DELTA sync. > Doing this, the recovery master have 5s of delay before replicate the > primary master, so if the primary master crash for any reason, the > recovery master may have missed up to 5s of modifications (users creation > for example). BUT replicas are up to date with the old primary master are > more up to date than the recovery master and may have more users, because > there replication is immediate (RefreshAndPersist mode). > > If we can restart the "old" primary master, the recovery master get the > missing users thanks to replication. If we can't restart the primary > master because it is KO, we have a recovery master with less users than > slave, so we have some onconsistency between replicas and the recovery > master. > > Do you have any solution to this problem ? It occures with big LDAP > database and hight rate of modifications on the master because we work on > a huge project with thousands of users (and perhaps in the future > millions of users). > > Regards, > Bruno Marcon. > > > -----Message d'origine----- > De : MARCON Bruno [mailto:Bruno.MARCON@thalesgroup.com] > Envoyé : mercredi 9 octobre 2013 14:04 > À : Bruno Marcon > Objet : RE: (ITS#7717) Sudden memory increase leading to Master LDAP > crash > > > > Bruno Marcon > ThereSIS Innovation lab, ICT Security Unit > - IT Security Expert > - Software Architect > > Thales Research & Technology > Campus Polytechnique > 1, avenue Augustin Fresnel > 91767 Palaiseau cedex > France > Office: +33 (0)1 69 41 60 96 > Fax: +33 (0)1 69 41 55 63 > > > -----Message d'origine----- > De : Bruno Marcon [mailto:marcon.bruno@free.fr] Envoyé : mardi 8 > octobre 2013 18:05 À : MARCON Bruno Objet : TR: (ITS#7717) Sudden > memory increase leading to Master LDAP crash > > > > -----Message d'origine----- > De : Quanah Gibson-Mount [mailto:quanah@zimbra.com] > Envoyé : lundi 7 octobre 2013 16:56 > À : marcon.bruno(a)free.fr; openldap-its(a)openldap.org > Objet : Re: (ITS#7717) Sudden memory increase leading to Master LDAP > crash > > --On Thursday, October 03, 2013 1:14 PM +0000 marcon.bruno(a)free.fr wrote: > >> The problem is very easy to replay : one master and one slave are >> sufficient. Then run 9 windows with a script adding an entry and >> modifying an entry. > > Please provide full configuration details. > > --Quanah > > > -- > > Quanah Gibson-Mount > Architect - Server > Zimbra Software, LLC > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

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