- openldap-bugs - openldap.org

Re: (ITS#5836) hung writers
by quanah＠OpenLDAP.org 28 Nov '08

28 Nov '08

--On November 28, 2008 10:49:36 PM +0000 quanah(a)OpenLDAP.org wrote: > slapd ends up hanging indefinitely. This happened with 8 replicas > connected to the server, where for four of those replicas, the connection > between the master and the replica wouldn't connect (but you could go > from the replica to the master) at some point after the initial > connection was made. > > Patch to HEAD from Howard is committed. Patch from Howard needs to be expanded so that a new keyword is used for the idle timer here, rather than the value from idletimeout. This will require some reworking of the daemon to wake up for that interval as well. --Quanah

1 0

(ITS#5836) hung writers
by quanah＠OpenLDAP.org 28 Nov '08

28 Nov '08

Full_Name: Quanah Gibson-Mount Version: HEAD/RE24/RE23 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) In a scenario where the network is broken (or other reasons, but that's where I hit it), slapd can get locked up waiting on writers to finish. When that happens, everything ends up in a pthread_cond_wait, like this: Thread 8 (Thread 1098918240 (LWP 18884)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956c8f58 in ldap_pvt_thread_cond_wait (cond=0x385bdf0, mutex=0x385bca0) at thr_posix.c:299 #2 0x000000000043dc91 in send_ldap_ber (conn=0x385bc88, ber=0x41680610) at result.c:198 #3 0x0000000000441450 in slap_send_search_entry (op=0x625bc00, rs=0x41801d60) at result.c:1137 #4 0x0000002a9717b9e1 in bdb_search (op=0x625bc00, rs=0x41801d60) at search.c:879 #5 0x000000000049b9c9 in overlay_op_walk (op=0x625bc00, rs=0x41801d60, which=op_search, oi=0xdece00, on=0x0) at backover.c:650 #6 0x000000000049bb91 in over_op_func (op=0x625bc00, rs=0x41801d60, which=op_search) at backover.c:702 #7 0x000000000049bc27 in over_op_search (op=0x625bc00, rs=0x41801d60) at backover.c:724 #8 0x000000000042f1d8 in fe_op_search (op=0x625bc00, rs=0x41801d60) at search.c:355 #9 0x000000000042ecac in do_search (op=0x625bc00, rs=0x41801d60) at search.c:217 #10 0x000000000042bd9c in connection_operation (ctx=0x41801e90, arg_v=0x625bc00) at connection.c:1133 #11 0x000000000042c28c in connection_read_thread (ctx=0x41801e90, argv=0x1f) at connection.c:1261 #12 0x0000002a956c7c77 in ldap_int_thread_pool_wrapper (xpool=0x8a2f00) at tpool.c:478 #13 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #14 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #15 0x0000000000000000 in ?? () slapd ends up hanging indefinitely. This happened with 8 replicas connected to the server, where for four of those replicas, the connection between the master and the replica wouldn't connect (but you could go from the replica to the master) at some point after the initial connection was made. Patch to HEAD from Howard is committed. --Quanah

1 0

Re: (ITS#5804) attribute value regex expantion
by ando＠sys-net.it 28 Nov '08

28 Nov '08

quanah(a)zimbra.com wrote: > --On November 28, 2008 9:07:49 PM +0000 quanah(a)zimbra.com wrote: > >> >> --On November 28, 2008 9:02:27 PM +0000 manu(a)netbsd.org wrote: >> >>> Konstantinos Koukopoulos <kouk(a)noc.edunet.gr> wrote: >>> >>>> Turns out 'val' is nil and it doesn't seem like there's any check for >>>> that. Maybe naive fix: >>> I see Ando committed it. But there are many other locations in the file >>> where acl_string_expand is called with an unchecked val->bv_val. It >>> seems these also need to be fixed, but I miaght be missing a point. >> IIRC, this also broke ACI's in RE2.4, and that still needs fixing as well. > > Egh, in HEAD only, I mean, as this wasn't applied yet to RE24. :) I've reworked the use of string expansion (and lined up regex expansion in "by" dn). In order to fix ACIs, the dynacl API needs to be enhanced to support AclRegexMatches. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5804) attribute value regex expantion
by quanah＠zimbra.com 28 Nov '08

28 Nov '08

--On November 28, 2008 9:07:49 PM +0000 quanah(a)zimbra.com wrote: > > > --On November 28, 2008 9:02:27 PM +0000 manu(a)netbsd.org wrote: > >> Konstantinos Koukopoulos <kouk(a)noc.edunet.gr> wrote: >> >>> Turns out 'val' is nil and it doesn't seem like there's any check for >>> that. Maybe naive fix: >> >> I see Ando committed it. But there are many other locations in the file >> where acl_string_expand is called with an unchecked val->bv_val. It >> seems these also need to be fixed, but I miaght be missing a point. > > IIRC, this also broke ACI's in RE2.4, and that still needs fixing as well. Egh, in HEAD only, I mean, as this wasn't applied yet to RE24. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5804) attribute value regex expantion
by quanah＠zimbra.com 28 Nov '08

28 Nov '08

--On November 28, 2008 9:02:27 PM +0000 manu(a)netbsd.org wrote: > Konstantinos Koukopoulos <kouk(a)noc.edunet.gr> wrote: > >> Turns out 'val' is nil and it doesn't seem like there's any check for >> that. Maybe naive fix: > > I see Ando committed it. But there are many other locations in the file > where acl_string_expand is called with an unchecked val->bv_val. It > seems these also need to be fixed, but I miaght be missing a point. IIRC, this also broke ACI's in RE2.4, and that still needs fixing as well. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5804) attribute value regex expantion
by manu＠netbsd.org 28 Nov '08

28 Nov '08

Konstantinos Koukopoulos <kouk(a)noc.edunet.gr> wrote: > Turns out 'val' is nil and it doesn't seem like there's any check for > that. Maybe naive fix: I see Ando committed it. But there are many other locations in the file where acl_string_expand is called with an unchecked val->bv_val. It seems these also need to be fixed, but I miaght be missing a point. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5835) master slapd dying on lost writes
by quanah＠zimbra.com 28 Nov '08

28 Nov '08

--On November 28, 2008 11:35:45 AM -0800 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > > > --On November 28, 2008 7:24:27 PM +0000 quanah(a)zimbra.com wrote: > > >> As you can see, we lose a connection and then try to read from it (FD >> 40). This is where the log ends because the assert triggered. > > Printing the connection struct shows it is actually an issue with FD 26: The previous connection on FD 26 shows: Nov 29 00:27:02 new slapd[8930]: conn=335 fd=26 ACCEPT from IP=192.168.61.154:40988 (IP=192.168.58.179:389) Nov 29 00:27:02 new slapd[8930]: conn=335 op=0 STARTTLS Nov 29 00:27:02 new slapd[8930]: conn=335 op=0 RESULT oid= err=0 text= Nov 29 00:27:02 new slapd[8930]: conn=335 fd=26 TLS established tls_ssf=256 ssf=256 Nov 29 00:27:02 new slapd[8930]: conn=335 op=1 BIND dn="uid=zmreplica,cn=admins,cn=zimbra" method=128 Nov 29 00:27:02 new slapd[8930]: conn=335 op=1 BIND dn="uid=zmreplica,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 Nov 29 00:27:02 new slapd[8930]: conn=335 op=1 RESULT tag=97 err=0 text= Nov 29 00:27:02 new slapd[8930]: conn=335 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Nov 29 00:27:02 new slapd[8930]: conn=335 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN [then nothing for a long time until]: Nov 29 00:29:41 new slapd[8930]: conn=335 fd=26 closed (connection lost) Nov 29 00:29:41 new slapd[8930]: conn=496 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" method=128 Nov 29 00:29:41 new slapd[8930]: conn=496 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 Nov 29 00:29:41 new slapd[8930]: conn=496 op=0 RESULT tag=97 err=0 text= Nov 29 00:29:41 new slapd[8930]: conn=498 fd=26 ACCEPT from IP=192.168.58.231:45575 (IP=192.168.58.179:389) Nov 29 00:29:41 new slapd[8930]: connection_read(40): no connection! Nov 29 00:29:41 new slapd[8930]: conn=498 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" method=128 Nov 29 00:29:41 new slapd[8930]: conn=498 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 Nov 29 00:29:41 new slapd[8930]: conn=498 op=0 RESULT tag=97 err=0 text= [slapd crashes] The consumer here in conn 335 is a refreshAndPersist consumer. Not entirely clear why it's connection gets closed. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5835) master slapd dying on lost writes
by quanah＠zimbra.com 28 Nov '08

28 Nov '08

--On November 28, 2008 7:24:27 PM +0000 quanah(a)zimbra.com wrote: > As you can see, we lose a connection and then try to read from it (FD > 40). This is where the log ends because the assert triggered. Printing the connection struct shows it is actually an issue with FD 26: (gdb) print *c $1 = {c_struct_state = 2, c_conn_state = 2, c_conn_idx = 26, c_close_reason = 0x4be9fb "?", c_mutex = {__m_reserved = 1, __m_count = 0, __m_owner = 0x1000022ee, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, c_sb = 0xdcb1de0, c_starttime = 1227898781, c_activitytime = 1227898781, c_connid = 498, c_peer_domain = {bv_len = 7, bv_val = 0xe61c50 "unknown"}, c_peer_name = {bv_len = 23, bv_val = 0xc89d900 "IP=192.168.58.231:45575"}, c_listener = 0x88cf00, c_sasl_bind_in_progress = 0, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0xdeda80, c_authz_cookie = 0x0, c_authz = {sai_method = 128, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 30, bv_val = 0xdcb1d60 "uid=zimbra,cn=admins,cn=zimbra"}, sai_ndn = {bv_len = 30, bv_val = 0xdcb1cc0 "uid=zimbra,cn=admins,cn=zimbra"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 3, c_ops = {stqh_first = 0x0, stqh_last = 0x3670150}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x3670160}, c_write_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, c_write_cv = {__c_lock = {__status = 111669149696, __spinlock = 13}, __c_waiting = 0xd, __padding = "\r\000\000\000\000\000\000\000H\000g\003\000\000\000", __align = 0}, c_currentber = 0xdc6d410, c_writewaiter = 0, c_is_tls = 0, c_needs_tls_accept = 0, c_sasl_layers = 0, c_sasl_done = 0, c_sasl_authctx = 0x5d65000, c_sasl_sockctx = 0x0, c_sasl_extra = 0x5d64d98, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_cookie = 0, ps_count = 0}, c_n_ops_received = 1, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 1, c_n_get = 1, c_n_read = 1, c_n_write = 0, c_pb = 0x0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x43ea28 <slap_send_ldap_result>, c_send_search_entry = 0x43f723 <slap_send_search_entry>, c_send_search_reference = 0x441829 <slap_send_search_reference>, c_send_ldap_extended = 0x43f296 <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x43f51a <slap_send_ldap_intermediate>} which is the connection currently logged as binding right before slapd crashes. --quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5834) enable modrDN rewriting
by ando＠sys-net.it 28 Nov '08

28 Nov '08

kouk(a)noc.uoa.gr wrote: > The 'modrDN' rewrite context, as mentioned in the slapo-rwm documentation, is > not implemented. Instead there is a undocumented context called 'renameDN' which > when undefined will use the default context. The submitted patch simply enables > the 'modrDN' context. The fix required a little bit more than that, in order to deal with errors and cleanup as appropriate. Fixed in HEAD, including slapo-rwm(5). Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5835) master slapd dying on lost writes
by quanah＠zimbra.com 28 Nov '08

28 Nov '08

Full_Name: Quanah Gibson-Mount Version: 2.3.43 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) Multiple clients have reported issues with their master servers dying. Examination of the logs showed frequent lost connections. Finally isolating a server today under GDB where it was occurring frequently I found the following in the backtrace: Thread 3 (Thread 1140881760 (LWP 8942)): #0 0x0000003fca02e21d in raise () from /lib64/tls/libc.so.6 #1 0x0000003fca02fa1e in abort () from /lib64/tls/libc.so.6 #2 0x0000003fca027ae1 in __assert_fail () from /lib64/tls/libc.so.6 #3 0x000000000042b55e in connection_close (c=0x3670030) at connection.c:877 #4 0x000000000042ca18 in connection_read (s=26, cri=0x44006e10) at connection.c:1458 #5 0x000000000042c1f8 in connection_read_thread (ctx=0x44006e90, argv=0x1a) at connection.c:1254 #6 0x0000002a956c7c77 in ldap_int_thread_pool_wrapper (xpool=0x8a1f00) at tpool.c:478 #7 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #8 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #9 0x0000000000000000 in ?? () The connection.c code in question is: static void connection_close( Connection *c ) { ber_socket_t sd = AC_SOCKET_INVALID; assert( connections != NULL ); assert( c != NULL ); /* ITS#4667 we may have gotten here twice */ if ( c->c_conn_state == SLAP_C_INVALID ) return; assert( c->c_struct_state == SLAP_C_USED ); assert( c->c_conn_state == SLAP_C_CLOSING ); Example from stats level logging has: Nov 29 00:29:41 new slapd[8930]: conn=397 fd=40 closed (connection lost on write) Nov 29 00:29:41 new slapd[8930]: conn=335 fd=26 closed (connection lost) Nov 29 00:29:41 new slapd[8930]: conn=496 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" method=128 Nov 29 00:29:41 new slapd[8930]: conn=496 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 Nov 29 00:29:41 new slapd[8930]: conn=496 op=0 RESULT tag=97 err=0 text= Nov 29 00:29:41 new slapd[8930]: conn=498 fd=26 ACCEPT from IP=192.168.58.231:45575 (IP=192.168.58.179:389) Nov 29 00:29:41 new slapd[8930]: connection_read(40): no connection! Nov 29 00:29:41 new slapd[8930]: conn=498 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" method=128 Nov 29 00:29:41 new slapd[8930]: conn=498 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 Nov 29 00:29:41 new slapd[8930]: conn=498 op=0 RESULT tag=97 err=0 text= As you can see, we lose a connection and then try to read from it (FD 40). This is where the log ends because the assert triggered. This is likely also problematic in OpenLDAP 2.4, as the code hasn't really changed much there. --Quanah

1 0

Re: (ITS#5834) enable modrDN rewriting
by ando＠sys-net.it 28 Nov '08

28 Nov '08

kouk(a)noc.uoa.gr wrote: > Full_Name: Kostantinos Koukopoulos > Version: HEAD > OS: Solaris > URL: ftp://ftp.openldap.org/incoming/Kostantinos-Koukopoulos-081128.patch > Submission from: (NULL) (195.134.100.30) > > > The 'modrDN' rewrite context, as mentioned in the slapo-rwm documentation, is > not implemented. Instead there is a undocumented context called 'renameDN' which > when undefined will use the default context. The submitted patch simply enables > the 'modrDN' context. Thanks for noting this. I'd rather call "newRDN" the new rewrite context. Since the documentation is incorrect, I'd rather use "renameDN" for the old DN, and leave "newSuperiorDN" as is, since the documentation is consistent with the code. By default, "newRDN" should rather be empty, since the default rule rather applies to DNs that supposedly span the naming context. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5804) attribute value regex expantion
by ando＠sys-net.it 28 Nov '08

28 Nov '08

kouk(a)noc.edunet.gr wrote: > Turns out 'val' is nil and it doesn't seem like there's any check for > that. Maybe naive fix: The fix looks good. Applied to HEAD. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

RE: (ITS#5832) Networking and Replication.
by quanah＠zimbra.com 28 Nov '08

28 Nov '08

The emails you sent directly to me were deleted. Send any comments CC'd or directly to the ITS system if you want them included. In either case, at least up to 2.4.12, BDB 4.7.25 has been fine for me (and others). --Quanah --On November 27, 2008 2:08:06 PM +0000 Nils.Hammar(a)cybercomgroup.com wrote: > ------=_NextPart_000_0029_01C950A1.DC1D8A50 > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: 7bit > > Further investigation into this issue seems to indicate that the problem > is more related to the Berkeley DB 4.7.25 database than it is related to > OpenLDAP itself. > > Sorry for causing trouble on this issue, I'll stick to 4.6 for the moment. > > > ------=_NextPart_000_0029_01C950A1.DC1D8A50 > Content-Type: application/x-pkcs7-signature; name="smime.p7s" > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; filename="smime.p7s" > > MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL+jCCA > j0w > ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXM > BUG > A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ > 2Vy > dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfM > Qsw > CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgU > HVi > bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADg > Y0A > MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWh > BiH > mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY > 1zF > 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DM > w5d > 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiX > bix > 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAm > PPR > cZQwggTMMIIENaADAgECAhAcrp1rmvTmLyKKo9p0YWweMA0GCSqGSIb3DQEBBQUAMF8xCzAJB > gNV > BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsa > WMg > UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNTEwMjgwMDAwMDBaFw0xNTEwM > jcy > MzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVB > AsT > FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwc > zov > L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZ > GF0 > ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBI > C0g > RzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDJ36zn6vj4AxTEAJLVwX42wjzvf > HIV > y8CrjD0clc5vHhAsPwDtlybmtsfmrUMdP6SHR0dMPlT4bPjH/LGevTBwvJexAwXqlfGtQMVEe > ksF > ovJg/Nc6ZWLv/xB7ola7xU5wLdaiHzztsELoXo1XIaymmdkR6dIaB8B0R0IL/MU06v3muiTRH > QgV > N6LXc88BQS9jsjo/vqUabvTJSls9laYVuzUCGfnU77yPDnF2WbtLtj7W/FoW9NYOifJJ/mwM7 > RXp > 2Yh1nHnOYCfdua11zi9zlXpAOoV1SbC432i8q80TgoURUKPgPAuuwApTzdcwb4UyRhvkSRDCb > OKv > H3n/27S1AgMBAAGjggGEMIIBgDASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLY > IZI > AYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALB > gNV > HQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQc > ml2 > YXRlTGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVH > R8E > KjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDCBgQYDVR0jBHowe > KFj > pGEwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5Db > GFz > cyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5ghEAzbp/VvDf5LxU/ > iKs > s3KqVTANBgkqhkiG9w0BAQUFAAOBgQCxL9mW4ZKi7oFg5cgqIPvhZyzWAJhTowIb6ZBL+BhEn > w9G > 9/qg/tMdGKPSvxzs1hmfSk1D+Mq7vhOASQXdIXMzV8JCWr76AJOy5gQxkU5dPPBzBTdj67+DW > Zj9 > Zt7phjKakik8Oq5U2qYSUbGPyMrTR3jm26Uehwbj0RTAwiH2ujCCBOUwggPNoAMCAQICEE2vq > tiu > yqYVrOEv8MvOnVMwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZ > XJp > U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyV > GVy > bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVB > AsT > FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpd > mlk > dWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0wODEwMTQwMDAwMDBaFw0wOTEwMTcyMzU5NTlaM > IIB > HDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ld > Hdv > cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBie > SBS > ZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA > 1UE > CxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEUMBIGA1UEA > xQL > TmlscyBIYW1tYXIxLDAqBgkqhkiG9w0BCQEWHW5pbHMuaGFtbWFyQGN5YmVyY29tZ3JvdXAuY > 29t > MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDK9OCvNd7SoeHTv9CAtBkk2O4JDj37AtwYV > zyz > IiVvoqHZ9LEF8+WT4w+dUuFgsQfx1+bFd63U4SDuwzRj5KvIVbc+7FR1igcIdLZUU3Sxn4Ubd > PZT > tcYeyWt5Y8IuJK/k81uAeAo4nPvzwbMrymoIN4mBsB/RuH8fmr7o+00W/QIDAQABo4HiMIHfM > AkG > A1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAzAqMCgGCCsGAQUFBwIBFhxodHRwc > zov > L3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDB > AYI > KwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6L > y9J > bmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqh > kiG > 9w0BAQUFAAOCAQEAl5Y1KD8GgWQMmy6bFHps9DJqAG4TLPaGkz8IMg6Y9MbZeruhEZIYz5pZB > JCs > jjaejgiGIimQkirfVxg9aYl/hBPXDRmsyeruPg6Vx4GyQlS06ww/52ZYIawelQyyjk5tQQyQe > sJ4 > bnfNiTdAXTlujPnCN3POKXIIyjFEkD8MESudFm6Pv4lfFDV4eHAC8qd/AbPnV2WRG+SOL9YDO > oYd > N/rxL/X18/zcb8vFdzDuci3StC43LjOIoVAH7JUTFs8LHXi9gJcMyUiYGgDJ8m4eq3P/a4smz > KVM > ScHKUwTfX1W8Zs9onmsWDvTzjULkgojba/zs6oBvkdw8yCvYQM4DADGCBHMwggRvAgEBMIHyM > IHd > MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTa > Wdu > IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52Z > XJp > c2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1B > gNV > BAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEE2vq > tiu > yqYVrOEv8MvOnVMwCQYFKw4DAhoFAKCCAtYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcB > gkq > hkiG9w0BCQUxDxcNMDgxMTI3MTQwNzI2WjAjBgkqhkiG9w0BCQQxFgQUrD6KW0bWJzupmxglk > rOq > mpCpvY4wZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIK > oZI > hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwg > gED > BgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgS > W5j > LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2Ygd > XNl > IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvb > mEg > Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1Y > nNj > cmliZXIgQ0EgLSBHMgIQTa+q2K7KphWs4S/wy86dUzCCAQUGCyqGSIb3DQEJEAILMYH1oIHyM > IHd > MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTa > Wdu > IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52Z > XJp > c2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1B > gNV > BAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEE2vq > tiu > yqYVrOEv8MvOnVMwDQYJKoZIhvcNAQEBBQAEgYCpBG16o6yJunOIxpD8tXIeMLpr785llp0rS > Fzi > Bl29rw1EWwsVlU5aRyHlKzZUOwdS/WhPLlAb10aQUcCHv+2QDcWjLId+zOjQiubYHNCyh7inW > H+u 0dqDDTAMyVbBd6yDUWWIN7MQ+++vyCBJ0WCSDE2DsYhhg19h9v2C4s49KAAAAAAAAA== > > ------=_NextPart_000_0029_01C950A1.DC1D8A50-- > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5834) enable modrDN rewriting
by kouk＠noc.uoa.gr 28 Nov '08

28 Nov '08

Full_Name: Kostantinos Koukopoulos Version: HEAD OS: Solaris URL: ftp://ftp.openldap.org/incoming/Kostantinos-Koukopoulos-081128.patch Submission from: (NULL) (195.134.100.30) The 'modrDN' rewrite context, as mentioned in the slapo-rwm documentation, is not implemented. Instead there is a undocumented context called 'renameDN' which when undefined will use the default context. The submitted patch simply enables the 'modrDN' context.

1 0

Re: (ITS#5804) attribute value regex expantion
by kouk＠noc.edunet.gr 28 Nov '08

28 Nov '08

I got segfault with the latest cvs and I think it's related to this ITS. It happened when slapd was evaluating the acl pattern. by dn.exact,expand="uid=$1,ou=people,dc=domain,dc=gr" write The relevant info from the debugger was: <= check a_dn_pat: uid=1,ou=people,dc=domain,dc=gr t@3 (l@3) signal SEGV (no mapping at the fault address) in acl_mask_dn at line 914 in file "acl.c" 914 val->bv_val, tmp_matchesp ) ) /SCRATCH/NG/ldap.devel-2.4/UOAldap.sources/openldap-cvs-20081128/servers/slapd> /SCRATCH/NG/ldap.devel-2.4/UOAldap.sources/openldap-cvs-20081128/servers/slapd> /SCRATCH/NG/ldap.devel-2.4/UOAldap.sources/openldap-cvs-20081128/servers/slapd>where current thread: t@3 =>[1] acl_mask_dn(op = 0x3e4440, e = 0x3b217c, val = (nil), a = 0x36c118, matches = 0xfcffde64, bdn = 0x36cfd0, opndn = 0x3e44dc), line 914 in "acl.c" [2] slap_acl_mask(a = 0x36c118, mask = 0xfcfff138, op = 0x3e4440, e = 0x3b217c, desc = 0x322698, val = (nil), matches = 0xfcffde64, count = 5, state = 0xfcffde48, access = ACL_WADD), line 1184 in "acl.c" [3] slap_access_allowed(op = 0x3e4440, e = 0x3b217c, desc = 0x322698, val = (nil), access = ACL_WADD, state = 0xfcffde48, maskp = 0xfcfff3e0), line 297 in "acl.c" [4] fe_access_allowed(op = 0x3e4440, e = 0x3b217c, desc = 0x322698, val = (nil), access = ACL_WADD, state = (nil), maskp = 0xfcfff3e0), line 359 in "acl.c" [5] over_access_allowed(op = 0x3e4440, e = 0x3b217c, desc = 0x322698, val = (nil), access = ACL_WADD, state = (nil), maskp = 0xfcfff3e0), line 312 in "backover.c" [6] access_allowed_mask(op = 0x3e4440, e = 0x3b217c, desc = 0x322698, val = (nil), access = ACL_WADD, state = (nil), maskp = (nil)), line 462 in "acl.c" [7] bdb_add(op = 0x3e4440, rs = 0xfcfffcb0), line 284 in "add.c" [8] fe_op_add(op = 0x3e4440, rs = 0xfcfffcb0), line 334 in "add.c" [9] overlay_op_walk(op = 0x3e4440, rs = 0xfcfffcb0, which = op_add, oi = 0x3614f8, on = (nil)), line 670 in "backover.c" [10] over_op_func(op = 0x3e4440, rs = 0xfcfffcb0, which = op_add), line 722 in "backover.c" [11] over_op_add(op = 0x3e4440, rs = 0xfcfffcb0), line 768 in "backover.c" [12] do_add(op = 0x3e4440, rs = 0xfcfffcb0), line 194 in "add.c" [13] connection_operation(ctx = 0xfcfffe0c, arg_v = 0x3e4440), line 1090 in "connection.c" [14] connection_read_thread(ctx = 0xfcfffe0c, argv = 0xd), line 1216 in "connection.c" [15] ldap_int_thread_pool_wrapper(xpool = 0x326dd0), line 663 in "tpool.c" Turns out 'val' is nil and it doesn't seem like there's any check for that. Maybe naive fix: =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/acl.c,v retrieving revision 1.347 diff -u -r1.347 acl.c --- servers/slapd/acl.c 16 Nov 2008 02:22:27 -0000 1.347 +++ servers/slapd/acl.c 28 Nov 2008 14:28:34 -0000 @@ -911,7 +911,7 @@ if ( acl_string_expand( &bv, &bdn->a_pat, e->e_nname.bv_val, - val->bv_val, tmp_matchesp ) ) + (val?val->bv_val:NULL), tmp_matchesp ) ) { return 1; }

1 0

sync'ing fails for modrdn
by Steffen Kaiser 28 Nov '08

28 Nov '08

Hello, I have configured a central OpenLDAP, using Debian Etch, version: slapd 2.3.30-5+etch1, which is also a sync provider. Another Debian Etch box uses the sync: syncrepl rid=123 provider=ldap://example.com type=refreshAndPersist retry="5,2,30,2,60,+" interval=00:01:00:00 searchbase="basedn" filter="(objectClass=*)" scope=sub attrs="*,+" sizelimit=0 timelimit=0 schemachecking=on bindmethod=simple binddn="someDN" credentials="somePwd" starttls=critical This works fine, but moddn fails: for testing purpose I ldapadd : dn: c=testtt,ou=basedn c: testtt objectClass: country then: ldapmodrdn -r 'c=testtt,ou=basedn' 'c=testww' It works on the sync provider (schemacheck on) and the result is: dn: c=testww,ou=basedn objectClass: country c: testww But on the sync consumer: : syncrepl_entry: c=testww,ou=basedn : Entry (c=testww,ou=basedn attribute 'c' cannot have multiple values : entry failed schema check: attribute 'c' cannot have multiple values : null_callback : error code 0x13 : syncrepl_entry: be_modrdn (19) The testtt entry is still present on the secondary box. If I delete "testww" on the sync provider, the "testt" entry in the consumere is deleted. ==== Because I trust the sync provider I changed schemachecking=off of the syncrepl rid=123 entry Now I get this in the log: : syncrepl_entry: c=testww,ou=basedn : syncrepl_entry: be_modrdn (0) : syncrepl_entry: be_modify (0) For me it looks like that because of the sequence of the two operations, schema checking is not compatible with moddn and this should be noted in the man page. Bye, -- Steffen Kaiser

4 3

RE: (ITS#5832) Networking and Replication.
by quanah＠zimbra.com 28 Nov '08

28 Nov '08

--On November 27, 2008 2:08:06 PM +0000 Nils.Hammar(a)cybercomgroup.com wrote: > ------=_NextPart_000_0029_01C950A1.DC1D8A50 > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: 7bit > > Further investigation into this issue seems to indicate that the problem > is more related to the Berkeley DB 4.7.25 database than it is related to > OpenLDAP itself. > > Sorry for causing trouble on this issue, I'll stick to 4.6 for the moment. That makes no sense to me, BDB isn't communicating at the network level... Everything at that level is LDAP protocol. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5831) Replication unreliable
by quanah＠zimbra.com 28 Nov '08

28 Nov '08

--On November 27, 2008 11:08:43 AM +0000 nils.hammar(a)cybercomgroup.com wrote: > Right now I'm using BDB 4.6.21, since I wasn't able at all to make BDB > 4.7.25 (with patch) to work. Not even "make test" succeded with the first > test, it just hung. (which is another problem, probably not related to > this problem) Did you also patch BDB 4.7 with the patch included in the OpenLDAP/build directory distributed with the source? It's necessary on some servers. It would be nice if Oracle would release it. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: (ITS#5832) Networking and Replication.
by Nils.Hammar＠cybercomgroup.com 27 Nov '08

27 Nov '08

------=_NextPart_000_0029_01C950A1.DC1D8A50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Further investigation into this issue seems to indicate that the problem is more related to the Berkeley DB 4.7.25 database than it is related to OpenLDAP itself. Sorry for causing trouble on this issue, I'll stick to 4.6 for the moment. ------=_NextPart_000_0029_01C950A1.DC1D8A50 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL+jCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggTMMIIENaADAgECAhAcrp1rmvTmLyKKo9p0YWweMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNTEwMjgwMDAwMDBaFw0xNTEwMjcy MzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDJ36zn6vj4AxTEAJLVwX42wjzvfHIV y8CrjD0clc5vHhAsPwDtlybmtsfmrUMdP6SHR0dMPlT4bPjH/LGevTBwvJexAwXqlfGtQMVEeksF ovJg/Nc6ZWLv/xB7ola7xU5wLdaiHzztsELoXo1XIaymmdkR6dIaB8B0R0IL/MU06v3muiTRHQgV N6LXc88BQS9jsjo/vqUabvTJSls9laYVuzUCGfnU77yPDnF2WbtLtj7W/FoW9NYOifJJ/mwM7RXp 2Yh1nHnOYCfdua11zi9zlXpAOoV1SbC432i8q80TgoURUKPgPAuuwApTzdcwb4UyRhvkSRDCbOKv H3n/27S1AgMBAAGjggGEMIIBgDASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZI AYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNV HQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2 YXRlTGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8E KjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDCBgQYDVR0jBHoweKFj pGEwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFz cyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5ghEAzbp/VvDf5LxU/iKs s3KqVTANBgkqhkiG9w0BAQUFAAOBgQCxL9mW4ZKi7oFg5cgqIPvhZyzWAJhTowIb6ZBL+BhEnw9G 9/qg/tMdGKPSvxzs1hmfSk1D+Mq7vhOASQXdIXMzV8JCWr76AJOy5gQxkU5dPPBzBTdj67+DWZj9 Zt7phjKakik8Oq5U2qYSUbGPyMrTR3jm26Uehwbj0RTAwiH2ujCCBOUwggPNoAMCAQICEE2vqtiu yqYVrOEv8MvOnVMwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlk dWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0wODEwMTQwMDAwMDBaFw0wOTEwMTcyMzU5NTlaMIIB HDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBS ZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UE CxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEUMBIGA1UEAxQL TmlscyBIYW1tYXIxLDAqBgkqhkiG9w0BCQEWHW5pbHMuaGFtbWFyQGN5YmVyY29tZ3JvdXAuY29t MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDK9OCvNd7SoeHTv9CAtBkk2O4JDj37AtwYVzyz IiVvoqHZ9LEF8+WT4w+dUuFgsQfx1+bFd63U4SDuwzRj5KvIVbc+7FR1igcIdLZUU3Sxn4UbdPZT tcYeyWt5Y8IuJK/k81uAeAo4nPvzwbMrymoIN4mBsB/RuH8fmr7o+00W/QIDAQABo4HiMIHfMAkG A1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAzAqMCgGCCsGAQUFBwIBFhxodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYI KwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9J bmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqhkiG 9w0BAQUFAAOCAQEAl5Y1KD8GgWQMmy6bFHps9DJqAG4TLPaGkz8IMg6Y9MbZeruhEZIYz5pZBJCs jjaejgiGIimQkirfVxg9aYl/hBPXDRmsyeruPg6Vx4GyQlS06ww/52ZYIawelQyyjk5tQQyQesJ4 bnfNiTdAXTlujPnCN3POKXIIyjFEkD8MESudFm6Pv4lfFDV4eHAC8qd/AbPnV2WRG+SOL9YDOoYd N/rxL/X18/zcb8vFdzDuci3StC43LjOIoVAH7JUTFs8LHXi9gJcMyUiYGgDJ8m4eq3P/a4smzKVM ScHKUwTfX1W8Zs9onmsWDvTzjULkgojba/zs6oBvkdw8yCvYQM4DADGCBHMwggRvAgEBMIHyMIHd MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNV BAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEE2vqtiu yqYVrOEv8MvOnVMwCQYFKw4DAhoFAKCCAtYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDgxMTI3MTQwNzI2WjAjBgkqhkiG9w0BCQQxFgQUrD6KW0bWJzupmxglkrOq mpCpvY4wZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwggED BgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNj cmliZXIgQ0EgLSBHMgIQTa+q2K7KphWs4S/wy86dUzCCAQUGCyqGSIb3DQEJEAILMYH1oIHyMIHd MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNV BAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEE2vqtiu yqYVrOEv8MvOnVMwDQYJKoZIhvcNAQEBBQAEgYCpBG16o6yJunOIxpD8tXIeMLpr785llp0rSFzi Bl29rw1EWwsVlU5aRyHlKzZUOwdS/WhPLlAb10aQUcCHv+2QDcWjLId+zOjQiubYHNCyh7inWH+u 0dqDDTAMyVbBd6yDUWWIN7MQ+++vyCBJ0WCSDE2DsYhhg19h9v2C4s49KAAAAAAAAA== ------=_NextPart_000_0029_01C950A1.DC1D8A50--

1 0

(ITS#5832) Networking and Replication.
by nils.hammar＠cybercomgroup.com 27 Nov '08

27 Nov '08

Full_Name: Nils Hammar Version: 2.4.13 OS: CentOS 5.2 URL: Submission from: (NULL) (194.17.253.72) When running syncrepl between two nodes in MirrorMode the communication works as it should until there is a disturbance on the network stack on either node. This is applicable to Linux where iptables is used to filter traffic. Example: Node A and B are running and updates on A are replicated to B. An update is done on iptables on B and the iptables is reloaded through "/etc/init.d/iptables restart". Any further updates on A are no longer replicated to B until the slapd service is restarted on B. So it seems to me that there is no 'keep alive' or similar functionality in the networking that catches this kind of situation.

1 0

(ITS#5831) Replication unreliable
by nils.hammar＠cybercomgroup.com 27 Nov '08

27 Nov '08

Full_Name: Nils Hammar Version: 2.4.13 OS: CentOS 5.2 URL: http://www.bedug.com/pics/openldap/nils-hammar-081127.tgz Submission from: (NULL) (194.17.253.72) OpenLDAP 2.4.13 has caused me some problems. It doesn't work reliable when I try to set up MirrorMode replication following the example given in the documentation at http://www.openldap.org/doc/admin24/replication.html#MirrorMode What I do is to set up one node first using the setup in files found at: http://www.bedug.com/pics/openldap/nils-hammar-081127.tgz, then I import an LDIF file containing the data there. All is well so far, and then I start the second node (which is having a completely uninitialized database), and it starts to communicate with the node where I imported the LDIF file, but it soon "hangs" and no further progress is made. It doesn't seem to replicate any data at all. Using 2.4.12 everything works as I expect it to - the second node builds a mirror of the first. Right now I'm using BDB 4.6.21, since I wasn't able at all to make BDB 4.7.25 (with patch) to work. Not even "make test" succeded with the first test, it just hung. (which is another problem, probably not related to this problem)

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by ali.pouya＠free.fr 26 Nov '08

26 Nov '08

Howard Chu wrote : >You said you pulled from HEAD on November 3, and still saw the problem. Either >your checkout was wrong, or your configuration was wrong, because the fix was >definitely present in HEAD by then. Hi Howard, This time I downloaded the release 2.4.13 and ran several tests with my collegues. I send the results for your information : Let two mirror servers A and B. The server A is the main one on which we do usually the write operations and B is the fail-over mirror. We initiate the directory at the time t0 and do all write operations on A. At the time t1 we do only one write on B. Then we resume write operations on A. At t2 we stop B for a cold backup and do one write operation on A. After B startup, A scans internally all objects writtent after t1, checking for the attributes objectclass and entryCSN. If we do a similar operation (write on A while B stopped) at t3, then after startup again all objects written after t1 and up to t3 are scanned (so more and more objects in the directory lifetime). The behaviour of the server B seems OK (it does not scans objects). This situation is produced if we set "syncprov-nopresent TRUE" on both servers. Otherwise (without this directive) the server A scans the objects twice : 1) Once ALL directory objects, checking for their objectclass only, 2) A second time the objects written after t1, checking for objectclass and entryCSN. On the other hand the server B scans the objects writtent before t1 ! I do not know slapd and syncprov internals but I think that if at each startup only the biggest contextCSN values of the servers were compared, the most recent objects would be checked (only one object in our example). But may be this is not feasible for technical reasons that I ignore ? Thanks for your patience Best Regards Ali

1 0

Re: (ITS#5829) Missing moduleload doc. confusing chain/distproc/slapi.
by hyc＠symas.com 25 Nov '08

25 Nov '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > slapd.conf(5)'s moduleload description should say which filename a > module has: foo.so or foo.la. (Or worse - is that different on > different OSes? Windows, anyone?) "foo.la" will work on all platforms. The actual shared object that the .la file points to may have different naming conventions on different platforms. > It should say where the standard installed modules are found. > Also that is a default modulepath which as far as I can tell from > strace includes the standard installation directory and the system > loader's standard load path. And again, is it OS-dependent? It > uses libtool's lt_dlopenext(), I haven't looked for what it does yet. I would expect that of course yes, the system loader's standard path is OS-dependent. > slapd.plugin(5) should mention that slapi itself is a module which > may need to be loaded. And that it's "slapi.la", not "plugin.la". > The chain and distproc overlays are not found in<overlay>.la but in > back_ldap.la. This should be documented. I suggest a "moduleload > back_ldap.la" statement before all the other directives, with > explanation. > > However, even if documented, people will miss that. One does't look > for doc about what one already "knows". > > The simplest and maybe most informative fix would be to add dummy > modules which simply give an error message that the overlays are found > in the back_ldap module. When the software knows exactly what must be done, failing with an error message is just annoying. If we were to do anything here at all, dummy modules would better be replaced by symlinks to the actual module, so that It Just Works. But I think just noting the discrepancy in the documentation is sufficient. > An alternative would be to move them to separate modules which depend on > back-ldap - and document their dependency on back-ldap. More correct I > guess, but personally I don't see how it's an improvement. That might > just be because I have had little to do with maintaining binary > distributions though. I don't think it's an improvement either. > A third would be to store a module registry where module names are > mapped to one or more module filenames to load. Overkill? More > general, but also more complex. Yes, overkill. And there are probably more modules out there than we would ever know about for a registry, so ultimately not useful. -- -- 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#5818) Limits chapter for Admin Guide
by ghenry＠OpenLDAP.org 25 Nov '08

25 Nov '08

----- "andrew findlay" <andrew.findlay(a)skills-1st.co.uk> wrote: > Full_Name: Andrew Findlay > Version: HEAD > OS: Linux > URL: > ftp://ftp.openldap.org/incoming/andrew-findlay-limits.sdf-20081118 > Submission from: (NULL) (88.97.25.132) > > > The Admin Guide says very little about size limits and time limits. > I have supplied a chapter to remedy the lack: I suggest putting it in > after the > Access Control chapter: > > ftp://ftp.openldap.org/incoming/andrew-findlay-limits.sdf-20081118 > > Please check the section on limits for paged results extra carefully. > I found the definition in slapd.conf(5) a little ambiguous. > > I have also provided patches to the master sdf file and to the two > config > directive > chapters: > > ftp://ftp.openldap.org/incoming/andrew-findlay-limits-patch-20081118 > > Andrew I've read through and made certain changes to fit our style, but nothing major and committed. Thanks Andrew! Gavin. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#5829) Missing moduleload doc. confusing chain/distproc/slapi.
by h.b.furuseth＠usit.uio.no 25 Nov '08

25 Nov '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slapd.conf(5)'s moduleload description should say which filename a module has: foo.so or foo.la. (Or worse - is that different on different OSes? Windows, anyone?) It should say where the standard installed modules are found. Also that is a default modulepath which as far as I can tell from strace includes the standard installation directory and the system loader's standard load path. And again, is it OS-dependent? It uses libtool's lt_dlopenext(), I haven't looked for what it does yet. slapd.plugin(5) should mention that slapi itself is a module which may need to be loaded. And that it's "slapi.la", not "plugin.la". The chain and distproc overlays are not found in <overlay>.la but in back_ldap.la. This should be documented. I suggest a "moduleload back_ldap.la" statement before all the other directives, with explanation. However, even if documented, people will miss that. One does't look for doc about what one already "knows". The simplest and maybe most informative fix would be to add dummy modules which simply give an error message that the overlays are found in the back_ldap module. An alternative would be to move them to separate modules which depend on back-ldap - and document their dependency on back-ldap. More correct I guess, but personally I don't see how it's an improvement. That might just be because I have had little to do with maintaining binary distributions though. A third would be to store a module registry where module names are mapped to one or more module filenames to load. Overkill? More general, but also more complex.

1 0

Re: (ITS#5828) Some slap* man pages only talk about slapd.conf
by ghenry＠OpenLDAP.org 24 Nov '08

24 Nov '08

----- "andrew findlay" <andrew.findlay(a)skills-1st.co.uk> wrote: > On Mon, Nov 24, 2008 at 10:02:56AM +0000, ghenry(a)OpenLDAP.org wrote: > > > The following man pages still talk about only slapd.conf: > > > Will fix. > > When doing so, would it be possible to avoid the duplication that > has started showing up in the Admin Guide? One section for doing a > job with slapd.conf and another one for the same job using cn=config > seems like a sure-fire way to get inconsistent information. It also > means that updates take (at least) twice as long to write. We should maybe just pick on configuration method and stick to it throughout the whole guide. POssibly cn=config, then point to the man pages for normal slapd.conf, or the other way round. slapd.conf is easier for just copying and pasting, but saying that, so is an LDIF. Gavin. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5828) Some slap* man pages only talk about slapd.conf
by andrew.findlay＠skills-1st.co.uk 24 Nov '08

24 Nov '08

On Mon, Nov 24, 2008 at 10:02:56AM +0000, ghenry(a)OpenLDAP.org wrote: > The following man pages still talk about only slapd.conf: > Will fix. When doing so, would it be possible to avoid the duplication that has started showing up in the Admin Guide? One section for doing a job with slapd.conf and another one for the same job using cn=config seems like a sure-fire way to get inconsistent information. It also means that updates take (at least) twice as long to write. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5823) clients/tools don't honor ldap.conf defaults
by h.b.furuseth＠usit.uio.no 24 Nov '08

24 Nov '08

ghenry(a)OpenLDAP.org writes: > Cool. I say we rewrite it all in Java, this C stuff is hard to understand ;-) Perhaps we should take this to -devel now... -- Hallvard

1 0

Re: (ITS#5825) syncrepl default is no retry
by h.b.furuseth＠usit.uio.no 24 Nov '08

24 Nov '08

hyc(a)symas.com writes: > Have to ensure that the default setting doesn't persist in cn=config, > so that it will keep warning until an explicit value is set. That's on my wish list for cn=config defaults in general. -- Hallvard

1 0

(ITS#5828) Some slap* man pages only talk about slapd.conf
by ghenry＠OpenLDAP.org 24 Nov '08

24 Nov '08

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry The following man pages still talk about only slapd.conf: slapacl slapauth slapdn slappasswd slaptest Things like: "It opens the slapd.conf(5) configuration file," Will fix. Gavin.

1 0

ITS#5039 Support config for start_tls in ldap.conf
by hyc＠symas.com 23 Nov '08

23 Nov '08

In 2.4.13 you can specify "starttls" as an URL extension for the URI in the config file. This was discussed in this thread http://www.openldap.org/lists/openldap-devel/200810/msg00053.html I think that's sufficient to fulfill this enhancement request. -- -- 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#5827) Syncprov persistent operations info leaking
by hyc＠symas.com 23 Nov '08

23 Nov '08

hyc(a)symas.com wrote: > I don't think the current fix is complete. Due to the Abandon check at 1190, > it's possible (though extremely unlikely) for an Abandon to arrive between the > start and end of a mod op, and cause the final decrement to be skipped still. > Probably need to do some restructuring to catch this, I'll look at this some more. Never mind, syncprov_op_cleanup already catches these cases. -- -- 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#5827) Syncprov persistent operations info leaking
by hyc＠symas.com 23 Nov '08

23 Nov '08

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> ando(a)sys-net.it wrote: >>> Full_Name: Pierangelo Masarati >>> Version: >>> OS: >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (81.72.89.40) >>> Submitted by: ando >>> >>> >>> After heavily loading a MMR pool, valgrind finds the following: >>> >>> ==29650== 2,437 (240 direct, 2,197 indirect) bytes in 3 blocks are definitely >>> lo >>> st in loss record 13 of 15 >> Most likely because we increment s_inuse at line 1250, at the beginning of a >> non-Delete write op, and don't decrement it at the end of the op. I think this >> should be simple to fix, will take a look. > > Seems to work. Thanks, p. I don't think the current fix is complete. Due to the Abandon check at 1190, it's possible (though extremely unlikely) for an Abandon to arrive between the start and end of a mod op, and cause the final decrement to be skipped still. Probably need to do some restructuring to catch this, I'll look at this some more. -- -- 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#5827) Syncprov persistent operations info leaking
by ando＠sys-net.it 23 Nov '08

23 Nov '08

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> Full_Name: Pierangelo Masarati >> Version: >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (81.72.89.40) >> Submitted by: ando >> >> >> After heavily loading a MMR pool, valgrind finds the following: >> >> ==29650== 2,437 (240 direct, 2,197 indirect) bytes in 3 blocks are definitely >> lo >> st in loss record 13 of 15 > > Most likely because we increment s_inuse at line 1250, at the beginning of a > non-Delete write op, and don't decrement it at the end of the op. I think this > should be simple to fix, will take a look. Seems to work. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5827) Syncprov persistent operations info leaking
by hyc＠symas.com 23 Nov '08

23 Nov '08

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.72.89.40) > Submitted by: ando > > > After heavily loading a MMR pool, valgrind finds the following: > > ==29650== 2,437 (240 direct, 2,197 indirect) bytes in 3 blocks are definitely > lo > st in loss record 13 of 15 Most likely because we increment s_inuse at line 1250, at the beginning of a non-Delete write op, and don't decrement it at the end of the op. I think this should be simple to fix, will take a look. -- -- 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#5827) Syncprov persistent operations info leaking
by ando＠sys-net.it 23 Nov '08

23 Nov '08

Full_Name: Pierangelo Masarati Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando After heavily loading a MMR pool, valgrind finds the following: ==29650== 2,437 (240 direct, 2,197 indirect) bytes in 3 blocks are definitely lo st in loss record 13 of 15 ==29650== at 0x40053C0: malloc (vg_replace_malloc.c:149) ==29650== by 0x825903B: ber_memalloc_x (memory.c:226) ==29650== by 0x80A743C: ch_malloc (ch_malloc.c:54) ==29650== by 0x82029CA: syncprov_op_search (syncprov.c:2200) ==29650== by 0x8104F7B: overlay_op_walk (backover.c:660) ==29650== by 0x81051B0: over_op_func (backover.c:722) ==29650== by 0x8105234: over_op_search (backover.c:744) ==29650== by 0x80897F6: fe_op_search (search.c:366) ==29650== by 0x8089196: do_search (search.c:217) ==29650== by 0x8085F41: connection_operation (connection.c:1090) ==29650== by 0x808641B: connection_read_thread (connection.c:1216) ==29650== by 0x8222E9C: ldap_int_thread_pool_wrapper (tpool.c:663) ==29650== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==29650== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==29594== 2,913 (160 direct, 2,753 indirect) bytes in 2 blocks are definitely lo st in loss record 10 of 15 ==29594== at 0x40053C0: malloc (vg_replace_malloc.c:149) ==29594== by 0x825903B: ber_memalloc_x (memory.c:226) ==29594== by 0x80A743C: ch_malloc (ch_malloc.c:54) ==29594== by 0x82029CA: syncprov_op_search (syncprov.c:2200) ==29594== by 0x8104F7B: overlay_op_walk (backover.c:660) ==29594== by 0x81051B0: over_op_func (backover.c:722) ==29594== by 0x8105234: over_op_search (backover.c:744) ==29594== by 0x80897F6: fe_op_search (search.c:366) ==29594== by 0x8089196: do_search (search.c:217) ==29594== by 0x8085F41: connection_operation (connection.c:1090) ==29594== by 0x808641B: connection_read_thread (connection.c:1216) ==29594== by 0x8222E9C: ldap_int_thread_pool_wrapper (tpool.c:663) ==29594== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==29594== by 0xD42DBD: clone (in /lib/libc-2.5.so) p.

1 0

Re: (ITS#5825) syncrepl default is no retry
by ando＠sys-net.it 23 Nov '08

23 Nov '08

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> Full_Name: Pierangelo Masarati >> Version: irrelevant >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (82.63.140.131) >> Submitted by: ando >> >> >> Syncrepl by default uses no retry. This is extremely useless, as syncrepl with >> no retry will probably break, sooner or later, without notifying why it >> happened. > > Legacy behavior, since retry was added later... > >> I believe it would be safe to have either: >> >> - a "safe" retry value (not too often, e.g. every hour, forever) > > Sounds fine, just add it to the doc. > >> - a warning (or an error) if retry is not given when configuring syncrepl > > Sounds rather annoying. We could combine these: if no retry was configured, > give the warning and use a default of 1 hour. Have to ensure that the default > setting doesn't persist in cn=config, so that it will keep warning until an > explicit value is set. > >> Another interesting feature would be to register syncrepl-specific parameters in >> back-monitor's entry of each database, that > >> - show the status of syncrepl (whether it's up, if rp) >> >> - show the timestamp of the last successful refresh >> >> - show the timestamp of the last failed attempt, and the reason of the failure > > Sounds fine, but unless you can add these quickly I don't see any reason to > hold 2.4.13 for it. Didn't mean to :) By now, only the warning is being issued. I don't think I can implement the rest for 2.4.13, will need to wait for next release. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5823) clients/tools don't honor ldap.conf defaults
by ghenry＠OpenLDAP.org 22 Nov '08

22 Nov '08

----- hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: > > Pierangelo Masarati writes: > >> -ZZ should be deprecated, and -Z should simply and strictly > require > >> StartTLS. > > > > Good point. Except then people who are used to new clients will > > make insecure connections when using old clients. Maybe -Z should > > be an error instead... > > > > What I'd really really like to do is throw away all the options, > > rename the programs, and start over. This time with the same > option > > names in ldap tools, slap tools, and slapd itself. Goes with the > > someday-in-the-future library rewrite, I suppose. > > OpenLDAP 3.0... > > The question is, when do we stop the 2.x stream and begin 3.0? Cool. I say we rewrite it all in Java, this C stuff is hard to understand ;-) -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5825) syncrepl default is no retry
by hyc＠symas.com 22 Nov '08

22 Nov '08

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: irrelevant > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > Submitted by: ando > > > Syncrepl by default uses no retry. This is extremely useless, as syncrepl with > no retry will probably break, sooner or later, without notifying why it > happened. Legacy behavior, since retry was added later... > I believe it would be safe to have either: > > - a "safe" retry value (not too often, e.g. every hour, forever) Sounds fine, just add it to the doc. > - a warning (or an error) if retry is not given when configuring syncrepl Sounds rather annoying. We could combine these: if no retry was configured, give the warning and use a default of 1 hour. Have to ensure that the default setting doesn't persist in cn=config, so that it will keep warning until an explicit value is set. > Another interesting feature would be to register syncrepl-specific parameters in > back-monitor's entry of each database, that > - show the status of syncrepl (whether it's up, if rp) > > - show the timestamp of the last successful refresh > > - show the timestamp of the last failed attempt, and the reason of the failure Sounds fine, but unless you can add these quickly I don't see any reason to hold 2.4.13 for it. -- -- 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#5826) syncrepl leaking filter in MMR
by ando＠sys-net.it 22 Nov '08

22 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando The filterstring is not freed if generated. A fix is coming. p.

1 0

(ITS#5825) syncrepl default is no retry
by ando＠sys-net.it 22 Nov '08

22 Nov '08

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando Syncrepl by default uses no retry. This is extremely useless, as syncrepl with no retry will probably break, sooner or later, without notifying why it happened. I believe it would be safe to have either: - a "safe" retry value (not too often, e.g. every hour, forever) - a warning (or an error) if retry is not given when configuring syncrepl Another interesting feature would be to register syncrepl-specific parameters in back-monitor's entry of each database, that - show the status of syncrepl (whether it's up, if rp) - show the timestamp of the last successful refresh - show the timestamp of the last failed attempt, and the reason of the failure p.

1 0

ldap_domain2hostlist is for "ldap" service only
by Marc Lavergne 22 Nov '08

22 Nov '08

Have there been any considerations in providing a similar API for a service name other than "ldap"? For example, what if I wanted to find global catalog servers? Even though GCs are Active Directory specific, I don't see why OpenLDAP would not support that type of query. It seems like a new API where the service name can be passed in as a parameter (eg. "gc") would be useful. Before using ITS to issue a bug report, I thought I'd ask via this forum. Thanks.

4 4

Re: (ITS#5821) Small mistake in man page
by ando＠sys-net.it 22 Nov '08

22 Nov '08

andrew.findlay(a)skills-1st.co.uk wrote: > On Thu, Nov 20, 2008 at 02:43:22PM +0000, kkalev(a)gmail.com wrote: > >> In the manpage for slapd.conf (slapd.conf.5) in the limits directive description >> the value for the size.unchecked pattern should be disabled and not disable >> according to limits.c > > Well spotted! > > I am curious about why this feature was added. The man page says: > > If it is set to disable, the search is not even performed; this > can be used to disallow searches for a specific set of users. > > Disallowing searches seems more like an ACL job than a limit job > to me, so I did not mention this when writing up the Limits features > for the Admin Guide. > > Does anyone actually use unchecked=disabled and if so, why? ACLs act too late, after the search has been performed; this acts at the candidate selection level, and with similar granularity in terms of identity the request is performed as. Now, search access to the searchBase is checked, so a search can be stopped even earlier. This was not requested when this limits feature was introduced. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5821) Small mistake in man page
by andrew.findlay＠skills-1st.co.uk 21 Nov '08

21 Nov '08

On Thu, Nov 20, 2008 at 02:43:22PM +0000, kkalev(a)gmail.com wrote: > In the manpage for slapd.conf (slapd.conf.5) in the limits directive description > the value for the size.unchecked pattern should be disabled and not disable > according to limits.c Well spotted! I am curious about why this feature was added. The man page says: If it is set to disable, the search is not even performed; this can be used to disallow searches for a specific set of users. Disallowing searches seems more like an ACL job than a limit job to me, so I did not mention this when writing up the Limits features for the Admin Guide. Does anyone actually use unchecked=disabled and if so, why? Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5823) clients/tools don't honor ldap.conf defaults
by hyc＠symas.com 21 Nov '08

21 Nov '08

h.b.furuseth(a)usit.uio.no wrote: > Pierangelo Masarati writes: >> -ZZ should be deprecated, and -Z should simply and strictly require >> StartTLS. > > Good point. Except then people who are used to new clients will > make insecure connections when using old clients. Maybe -Z should > be an error instead... > > What I'd really really like to do is throw away all the options, > rename the programs, and start over. This time with the same option > names in ldap tools, slap tools, and slapd itself. Goes with the > someday-in-the-future library rewrite, I suppose. OpenLDAP 3.0... The question is, when do we stop the 2.x stream and begin 3.0? -- -- 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#5822 slapd goes into sleeping mode
by h.b.furuseth＠usit.uio.no 21 Nov '08

21 Nov '08

egarciab(a)alcatel-lucent.com writes: > Did you see anytime a similar problem of slapd sleeping mode? Slapd does not have a "sleeping mode", but there have been bugs with the locking code. E.g. a function takes a lock but in the case of some rare error return it forgets to release it. Then the next attempt to use that resource (e.g. a locked entry, or a locked database) will hang. I see you use "database oci". This was never part of OpenLDAP as far as I know. <google oci site:openldap.org> shows the code was submitted. I don't know the slapd SQL code and haven't checked if the code was rejected because of some problem, or merged into back-sql, or something else. If you browse these messages, maybe that'll turn up your problem. -- Hallvard

1 0

Re: (ITS#5823) clients/tools don't honor ldap.conf defaults
by ando＠sys-net.it 21 Nov '08

21 Nov '08

h.b.furuseth(a)usit.uio.no wrote: > Pierangelo Masarati writes: >> -ZZ should be deprecated, and -Z should simply and strictly require >> StartTLS. > > Good point. Except then people who are used to new clients will > make insecure connections when using old clients. Maybe -Z should > be an error instead... Mine was a generic criticism, not a suggestion for this specific case. > What I'd really really like to do is throw away all the options, > rename the programs, and start over. This time with the same option > names in ldap tools, slap tools, and slapd itself. Goes with the > someday-in-the-future library rewrite, I suppose. :) p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5823) clients/tools don't honor ldap.conf defaults
by h.b.furuseth＠usit.uio.no 21 Nov '08

21 Nov '08

Pierangelo Masarati writes: > -ZZ should be deprecated, and -Z should simply and strictly require > StartTLS. Good point. Except then people who are used to new clients will make insecure connections when using old clients. Maybe -Z should be an error instead... What I'd really really like to do is throw away all the options, rename the programs, and start over. This time with the same option names in ldap tools, slap tools, and slapd itself. Goes with the someday-in-the-future library rewrite, I suppose. -- Hallvard

1 0

Re: ITS#5822 slapd goes into sleeping mode
by ando＠sys-net.it 21 Nov '08

21 Nov '08

GARCIA BARRERA, Eduardo (Eduardo) wrote: > Ok, I can fully understand your point. > > Anyway, from your expert point of view on openldap, and understanding > that this is an obsolete version of slapd, I would like only two things > that you probably know without consuming much time from your side. It's not a matter of consuming my time. We're all condemned to consume all of our time sooner or later. It's a matter of consuming it on something we consider worth it, and enjoy it in the meanwhile. One of the pleasures of working at free software is that nobody can really tell you what to work at :) > Did you see anytime a similar problem of slapd sleeping mode? Slapd has no "sleeping mode" (would it make any sense?) Do the logs show anything relevant *before* slapd becomes unresponsive? You mentioned that attaching the process with gdb is not an option, since it's operating in a very critical environment. However, I believe you wouldn't make things any worse when it's no longer responding anyway. > Did you think if there is any solaris patches that could fix similar > problems? Not a solaris expert, sorry. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

RE: ITS#5822 slapd goes into sleeping mode
by egarciab＠alcatel-lucent.com 21 Nov '08

21 Nov '08

Ok, I can fully understand your point. Anyway, from your expert point of view on openldap, and understanding that this is an obsolete version of slapd, I would like only two things that you probably know without consuming much time from your side. Did you see anytime a similar problem of slapd sleeping mode? Did you think if there is any solaris patches that could fix similar problems? Thanks a lot for your time and effort Pierlangelo, Eduardo -----Original Message----- From: Pierangelo Masarati [mailto:ando@sys-net.it] Sent: viernes, 21 de noviembre de 2008 12:11 To: GARCIA BARRERA, Eduardo (Eduardo) Cc: openldap-its(a)openldap.org Subject: Re: ITS#5822 slapd goes into sleeping mode GARCIA BARRERA, Eduardo (Eduardo) wrote: > Pierlangelo, > > First of all, thanks for your quick answer. I just read carefully the > instructions on "how to report a bug", and I will try my best to > gather it. > > Anyway, I got a question for you. Since the slapd process does not > crash but keeps in a sleeping mode, and due to this machine is working > in a very critical enviroment for our customer, is it needed to run > gdb tool? > > Besides, the problem happens in a random way, so we could run those > commands when the slapd is sleeping and does not answer. When this > happens, the ldapsearch command is not answered. > > Platform: SunOS MVICBDS01D05 5.9 Generic_118558-35 sun4u sparc > SUNW,Sun-Fire-15000 > > In this machine is also running oracle version 9.2.0.8 . > > > The slapd.conf file is attached to this email. One issue is that you should clarify what version you're using. If you're really using a OpenLDAP 2.1 release, then it's probably not worth the effort of tracing the issue: that release became historic in early 2004. No one will ever spend time finding a bug in it, or even backporting fixes to known bugs (unless very well rewarded, I guess). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: ITS#5822 slapd goes into sleeping mode
by ando＠sys-net.it 21 Nov '08

21 Nov '08

GARCIA BARRERA, Eduardo (Eduardo) wrote: > Pierlangelo, > > First of all, thanks for your quick answer. I just read carefully the > instructions on "how to report a bug", and I will try my best to gather > it. > > Anyway, I got a question for you. Since the slapd process does not > crash but keeps in a sleeping mode, and due to this machine is working > in a very critical enviroment for our customer, is it needed to run gdb > tool? > > Besides, the problem happens in a random way, so we could run those > commands when the slapd is sleeping and does not answer. When this > happens, the ldapsearch command is not answered. > > Platform: SunOS MVICBDS01D05 5.9 Generic_118558-35 sun4u sparc > SUNW,Sun-Fire-15000 > > In this machine is also running oracle version 9.2.0.8 . > > > The slapd.conf file is attached to this email. One issue is that you should clarify what version you're using. If you're really using a OpenLDAP 2.1 release, then it's probably not worth the effort of tracing the issue: that release became historic in early 2004. No one will ever spend time finding a bug in it, or even backporting fixes to known bugs (unless very well rewarded, I guess). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

RE: ITS#5822 slapd goes into sleeping mode
by egarciab＠alcatel-lucent.com 21 Nov '08

21 Nov '08

This is a multi-part message in MIME format. ------_=_NextPart_001_01C94BC8.DD31A533 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Pierlangelo, First of all, thanks for your quick answer. I just read carefully the instructions on "how to report a bug", and I will try my best to gather it. Anyway, I got a question for you. Since the slapd process does not crash but keeps in a sleeping mode, and due to this machine is working in a very critical enviroment for our customer, is it needed to run gdb tool?=20 Besides, the problem happens in a random way, so we could run those commands when the slapd is sleeping and does not answer. When this happens, the ldapsearch command is not answered. Platform: SunOS MVICBDS01D05 5.9 Generic_118558-35 sun4u sparc SUNW,Sun-Fire-15000 In this machine is also running oracle version 9.2.0.8 . The slapd.conf file is attached to this email. Thanks a lot in advance Regards Eduardo -----Original Message----- From: Pierangelo Masarati [mailto:ando@sys-net.it]=20 Sent: jueves, 20 de noviembre de 2008 16:57 To: GARCIA BARRERA, Eduardo (Eduardo) Cc: openldap-its(a)openldap.org Subject: Re: ITS#5822 slapd goes into sleeping mode There exists no OpenLDAP 2.1 b102. There exists a 2.1 branch, which was obsoleted few years ago. Even if there existed one, you don't provide enough info that could help debugging your issue. Please see <http://www.openldap.org/faq/data/cache/56.html> for details about how to report an issue. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it ----------------------------------- ------_=_NextPart_001_01C94BC8.DD31A533 Content-Type: application/octet-stream; name="slapd.conf" Content-Transfer-Encoding: base64 Content-Description: slapd.conf Content-Disposition: attachment; filename="slapd.conf" aW5jbHVkZQkJL29wdC9sdWNlbnQzMi9ldGMvb3BlbmxkYXAvc2NoZW1hL2NvcmUuc2NoZW1hCmlu Y2x1ZGUgICAgICAgICAvb3B0L2x1Y2VudDMyL2V0Yy9vcGVubGRhcC9zY2hlbWEvY29zaW5lLnNj aGVtYQppbmNsdWRlCQkvb3B0L2x1Y2VudDMyL2V0Yy9vcGVubGRhcC9zY2hlbWEvaW5ldG9yZ3Bl cnNvbi5zY2hlbWEKCmluY2x1ZGUgICAgICAgICAvb3B0L2x1Y2VudDMyL2V0Yy9vcGVubGRhcC9z Y2hlbWEvc2l1LnNjaGVtYQppbmNsdWRlICAgICAgICAgL29wdC9sdWNlbnQzMi9ldGMvb3Blbmxk YXAvc2NoZW1hL3Nlc2lvbi5zY2hlbWEKI2luY2x1ZGUgICAgICAgIC9vcHQvbHVjZW50MzIvZXRj L29wZW5sZGFwL3NjaGVtYS9zZXNpb25fdW5kZXIuc2NoZW1hCmluY2x1ZGUgICAgICAgICAvb3B0 L2x1Y2VudDMyL2V0Yy9vcGVubGRhcC9zY2hlbWEvb3BlcmF0aXZvcy5zY2hlbWEKCnBpZGZpbGUJ CS9vcHQvbHVjZW50MzIvdmFyL3NsYXBkLnBpZAphcmdzZmlsZQkvb3B0L2x1Y2VudDMyL3Zhci9z bGFwZC5hcmdzCgp0aHJlYWRzIDE2CgojIGZ1bmNpb25hIGVsIGFjY2VzbyBzZSBjb250cm9sYSBw YXJhIHVzdWFyaW9zIGRlIHRpcG8gdWlkPSxvdT0sbz1iZGIKI2FjY2VzcyAJdG8gZG4uc3VidHJl ZT0ibz1iZGIiCiMgICAgICAgIGJ5IGFub255bW91cyBhdXRoCiMgICAgICAgIGJ5IGRuLnN1YnRy ZWU9Im91PXJlYWQsbz1iZGIiIHNlYXJjaAojICAgICAgICBieSBkbi5zdWJ0cmVlPSJvdT13cml0 ZSxvPWJkYiIgd3JpdGUKI2FjY2VzcyAJdG8gZG4uc3VidHJlZT0ibz1vY2kiCiMgICAgICAgIGJ5 IGFub255bW91cyBhdXRoCiMgICAgICAgIGJ5IGRuLnN1YnRyZWU9Im91PXJlYWQsbz1iZGIiIHNl YXJjaAojICAgICAgICBieSBkbi5zdWJ0cmVlPSJvdT13cml0ZSxvPWJkYiIgd3JpdGUKCiMgRXN0 byBmdW5jaW9uYQojYWNjZXNzIHRvIGRuLnN1YnRyZWU9Im89c2l1IgojCWJ5IGFub255bW91cyB3 cml0ZQojCWJ5IGFub255bW91cyByZWFkCgphY2Nlc3MgdG8gZG4uc3VidHJlZT0ibz1zaXUiCgli eSBhbm9ueW1vdXMgcmVhZAoJYnkgZ3JvdXAuYmFzZT0iY249YWRtaW4iIHdyaXRlCglieSAqIG5v bmUKCmFjY2VzcyB0byBkbi5zdWJ0cmVlPSJvPXNpdXgiCglieSBhbm9ueW1vdXMgcmVhZAoJYnkg Z3JvdXAuYmFzZT0iY249YWRtaW4iIHdyaXRlCglieSAqIG5vbmUKCgojIHNlIGNvbnRyb2xhIGVs IGFjY2VzbwojYWNjZXNzIAl0byBkbi5zdWJ0cmVlPSJvPWJkYiIKIyAgICAgICAgYnkgYW5vbnlt b3VzIGF1dGgKIyAgICAgICAgYnkgZG4uc3VidHJlZT0ibz1iZGIiIHdyaXRlCgojICAgICAgICBi eSAqIHNlYXJjaAojICAgICAgICBieSBkbi5zdWJ0cmVlPSJvPWJkYiIgd3JpdGUKCmFsbG93IGJp bmRfdjIKI2Rpc2FsbG93IGJpbmRfYW5vbiwgYmluZF9zaW1wbGVfdW5wcm90ZWN0ZWQKI2Rpc2Fs bG93IGJpbmRfc2ltcGxlCiNkaXNhbGxvdyBiaW5kX2Fub24KCnNpemVsaW1pdCAxMAp0aW1lbGlt aXQgNjAKCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjCiMgbGRibSBkYXRhYmFzZSBkZWZpbml0aW9ucwojIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIwoKZGF0YWJhc2UJYmRiCnN1ZmZpeAkJIm89YmRiIgpyb290ZG4JCSJjbj1hZG1pbixv PWJkYiIKcm9vdHB3CQlhZG1pbjEyMwojIFRoZSBkYXRhYmFzZSBkaXJlY3RvcnkgTVVTVCBleGlz dCBwcmlvciB0byBydW5uaW5nIHNsYXBkIEFORCAKIyBzaG91bGQgb25seSBiZSBhY2Nlc3NpYmxl IGJ5IHRoZSBzbGFwZCBhbmQgc2xhcCB0b29scy4KIyBNb2RlIDcwMCByZWNvbW1lbmRlZC4KZGly ZWN0b3J5CS9MVUNFTlQvdmFyL29wZW5sZGFwLWRhdGEKIyBJbmRpY2VzIHRvIG1haW50YWluCmlu ZGV4CW9iamVjdENsYXNzCWVxCgojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwojIG9jaSAgZGF0YWJhc2UgZGVmaW5p dGlvbnMKIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMKZGF0YWJhc2UgICAgICAgIG9jaQpzdWZmaXggICAgICAgICAg Im89c2l1Igpyb290ZG4gICAgICAgICAgImNuPWFkbWluLCBvPXNpdSIKcm9vdHB3ICAgICAgICAg IGFkbWluMTIzCmRiaG9zdCAgICAgICAgICBtdmljYmRzMDFkMDVfbmF2aXMKZGJuYW1lICAgICAg ICAgIG5hdmlzMTEKZGJ1c2VyICAgICAgICAgIGxkYXAKZGJwYXNzd2QgICAgICAgIGxkYXAxMjMK Y21pbgkJMQpjbWF4CQkxMAogCmRhdGFiYXNlICAgICAgICBvY2kKc3VmZml4ICAgICAgICAgICJv PXNpdXgiCnJvb3RkbiAgICAgICAgICAiY249YWRtaW4sIG89c2l1eCIKcm9vdHB3ICAgICAgICAg IGFkbWluMTIzCmRiaG9zdCAgICAgICAgICBtdmljYmRzMDFkMDVfbmF2aXMKZGJuYW1lICAgICAg ICAgIG5hdmlzMTEKZGJ1c2VyICAgICAgICAgIGxkYXAKZGJwYXNzd2QgICAgICAgIGxkYXAxMjMK Y21pbgkJMQpjbWF4CQkxMAoKI2RhdGFiYXNlICAgICAgICBvY2kKI3N1ZmZpeCAgICAgICAgICAi bz1zaXUiCiNyb290ZG4gICAgICAgICAgImNuPWFkbWluLCBvPXNpdSIKI3Jvb3RwdyAgICAgICAg ICBhZG1pbjEyMwojZGJob3N0ICAgICAgICAgIGNodWVjYQojZGJuYW1lICAgICAgICAgIHNpdQoj ZGJ1c2VyICAgICAgICAgIGFhYQojZGJwYXNzd2QgICAgICAgIGFhYTEyMwojY21pbgkJMQojY21h eAkJNAogCg== ------_=_NextPart_001_01C94BC8.DD31A533--

1 0

Re: (ITS#5823) clients/tools don't honor ldap.conf defaults
by ando＠sys-net.it 20 Nov '08

20 Nov '08

h.b.furuseth(a)usit.uio.no wrote: > hyc(a)OpenLDAP.org writes: >> I suggest that we use option==1 for on, and option>1 for off, to >> minimize the impact of the change. (E.g., to explicitly turn off >> referrals, use ldapsearch -CC.) > > That conflicts with today's -ZZ, which seems a bad option to > create confusion about. -ZZ should be deprecated, and -Z should simply and strictly require StartTLS. The concept itself of having StartTLS optional (without notice of whether it succeeded or not!) sounds extremely bogus to me. In all the clients I develop, I never provide such alternative, either on or off. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5824) #if/#elif issues in thread #includes
by h.b.furuseth＠usit.uio.no 20 Nov '08

20 Nov '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard This ldap_pvt_thread.h snippet is invalid: #define LDAP_PVT_THREAD_STACK_SIZE ( 1 * 1024 * 1024 * sizeof(void *) ) #elif LDAP_PVT_THREAD_STACK_SIZE == 0 The standard is worded so that the #elif expression is evaluated even when the preceding #if was true - so the sizeof(void*) causes a syntax error in the preprocessor. Noticed by Debian when compiling with the upcoming gcc 4.4: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505421 This ldap_int_thread.h snippet: #elif defined( HAVE_CTHREAD_H # include <cthreads.h> lacks a ')' and should test HAVE_CTHREAD*S*_H.

1 0

Re: (ITS#5823) clients/tools don't honor ldap.conf defaults
by hyc＠symas.com 20 Nov '08

20 Nov '08

Hallvard B Furuseth wrote: > hyc(a)OpenLDAP.org writes: >> I suggest that we use option==1 for on, and option>1 for off, to >> minimize the impact of the change. (E.g., to explicitly turn off >> referrals, use ldapsearch -CC.) > > That conflicts with today's -ZZ, which seems a bad option to > create confusion about. Also with ldapsearch -L[L[L]]. > > Another variant is -C = on and +C = off. Backwards, but it's > not our fault that Unix chose "-" for "on":-) Unless +foo > means something special on Windows command lines? > This may not be a big deal after all. The only options affected are -C and -N, and -C is essentially useless now. (And is undocumented.) So perhaps this can be mostly ignored, and we just need a workable approach for -N and any future boolean options. -- -- 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#5823) clients/tools don't honor ldap.conf defaults
by h.b.furuseth＠usit.uio.no 20 Nov '08

20 Nov '08

hyc(a)OpenLDAP.org writes: > I suggest that we use option==1 for on, and option>1 for off, to > minimize the impact of the change. (E.g., to explicitly turn off > referrals, use ldapsearch -CC.) That conflicts with today's -ZZ, which seems a bad option to create confusion about. Also with ldapsearch -L[L[L]]. Another variant is -C = on and +C = off. Backwards, but it's not our fault that Unix chose "-" for "on":-) Unless +foo means something special on Windows command lines? -- Hallvard

1 0

(ITS#5823) clients/tools don't honor ldap.conf defaults
by hyc＠OpenLDAP.org 20 Nov '08

20 Nov '08

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Various options in clients/tools/common.c are set as follows: /* referrals */ if( ldap_set_option( ld, LDAP_OPT_REFERRALS, referrals ? LDAP_OPT_ON : LDAP_OPT_OFF ) != LDAP_OPT_SUCCESS ) This means if the commandline option was provided, the option is turned on, otherwise it is turned off. I.e., the ldap.conf setting is completely overridden at all times. All of these options cases should be fixed to only issue the ldap_set_option() call if the corresponding argument was provided, to allow the default setting to take effect when the arguments are not provided. I suggest that we use option==1 for on, and option>1 for off, to minimize the impact of the change. (E.g., to explicitly turn off referrals, use ldapsearch -CC.)

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by rra＠stanford.edu 20 Nov '08

20 Nov '08

Howard Chu <hyc(a)symas.com> writes: > The real problem is that the standard POSIX gethost/getaddr* APIs don't > tell you the confidence level of the information they return. Nor do > they let you specify a minimum acceptable confidence level when you make > a query. (Analogous to the SSFs we use in OpenLDAP.) Yeah, that would be great. There are, unfortunately, a bunch of problems with those interfaces. Blocking behavior is another problem with them. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by hyc＠symas.com 20 Nov '08

20 Nov '08

rra(a)stanford.edu wrote: > Howard Chu<hyc(a)symas.com> writes: > >> Leaving aside your followup which clarified this clause: the obvious >> point is that a Kerberos client needs to have trusted *local* data to >> protect against this attack. > > All Kerberos clients have trusted local data. It's required by the > Kerberos protocol; the server gives you a TGT that you can only decrypt > using your trusted local data. So I'm not sure what you're getting at > here. The problem with DNS canonicalization is that it allows you to > attack clients even if those clients have trusted local data to establish > mutual authentication with the KDC. This is going way beyond off topic but... The real problem is that the standard POSIX gethost/getaddr* APIs don't tell you the confidence level of the information they return. Nor do they let you specify a minimum acceptable confidence level when you make a query. (Analogous to the SSFs we use in OpenLDAP.) -- -- 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#5812) New option to disable SASL host canonicalization
by rra＠stanford.edu 20 Nov '08

20 Nov '08

My apologies for completely failing reading comprehension and including so much material that had already been mentioned in this ITS. I hadn't realized until I reviewed the whole ITS log just how much I'd duplicated of what people had already said. :/ -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by hyc＠symas.com 20 Nov '08

20 Nov '08

geert(a)boskant.nl wrote: > Full_Name: Geert Jansen > Version: 2.4 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/geert-jansen-081115.patch > Submission from: (NULL) (12.230.186.195) > > > This is a resubmission of my earlier patch in [1]. I'm asking for this patch to > be included into OpenLDAP. > > The patch adds an LDAP option called LDAP_OPT_X_SASL_NOCANON to disable host > name canonicalization using reverse DNS for the host name that is passed into > SASL. Instead, it passes verbatim the host name part from the LDAP URI and lets > SASL do the canonicalization. The option is disabled by default. > Since some time MIT Kerberos has support for server-side canonicalization which > is an alternative for the DNS based scheme. By default it uses both, but with an > option "rdns = no", reverse DNS can be disabled. > > The use case for this is environments that do not have reverse DNS set up > correctly. Especially in Windows Active Directory environments this is very > common. Administrators are afraid to enable scavenging for their zones, and > therefore any server IP change will leave a stale PTR record in place. This > breaks reverse DNS based canonicalization if the IP adress is reassigned. > > The behaviour enabled by this patch should remain optional and cannot become the > default. It breaks the use case when multiple LDAP servers are load balanced > using a CNAME record. In reviewing this patch, I see some technical issues to resolve: 1) You seem to be making the ldap_set_option "arg" parameter optional; there appears to be no justification for this (significant) behavioral change. 2) If you're dealing with a KDC that supports this feature, then it would make the most sense for this to be a site-wide option. As such, it should be possible for the setting to become the default, and an ldap.conf keyword should exist to control that setting. 3) Your addition of the option to the command line tools is boolean; if the command line option is present the option will be turned on, otherwise it will be turned off. This requires too much knowledge on the part of the user running the tool, to decide whether they need the option or not. Again, it should allow a system-wide setting, and the command-line option should be tri-state: on / off / default. Users should not be required to learn about this option before using the commandline tools, the sysadmin should set it site-wide when the KDC is known to support it. -- -- 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#5820) segfault with slapacl
by ghenry＠OpenLDAP.org 20 Nov '08

20 Nov '08

----- ando(a)sys-net.it wrote: > Gavin Henry wrote: > >>> Anyone else seeing this? > >>> > >> Working here. > > > > I'm on 4.7.25 with patches, 32-bit. You? > > Same here. On a different 32-bit machine it passes on Head. Weird. Will check it out. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by rra＠stanford.edu 20 Nov '08

20 Nov '08

Howard Chu <hyc(a)symas.com> writes: > Leaving aside your followup which clarified this clause: the obvious > point is that a Kerberos client needs to have trusted *local* data to > protect against this attack. All Kerberos clients have trusted local data. It's required by the Kerberos protocol; the server gives you a TGT that you can only decrypt using your trusted local data. So I'm not sure what you're getting at here. The problem with DNS canonicalization is that it allows you to attack clients even if those clients have trusted local data to establish mutual authentication with the KDC. > Delegating administration authority still implies that you trust whoever > you delegated it to. Again, if you can't trust everyone then your > administrative procedures are broken and your framework has already been > compromised. Yes, it implies that you trust them to take the actions that you delegated to them. However, it *doesn't* imply that you trust them universally. You can delegate control of some principals and not others. That's a meaningful operation that is entirely valid within the Kerberos protocol trust model. Control of one principal in a realm should not imply an ability to spoof authentications to other principals in the same realm. Kerberos as a protocol can and is designed to be robust against attackers who have control over principals within your local realm provided that a client and a server agree on principal naming for a service. Kerberos clients are specifically cautioned in the Kerberos protocol specification against using insecure DNS to establish that agreement naming. Section 1.3 of RFC 4120, particularly the two paragraphs starting with: Implementations of Kerberos and protocols based on Kerberos MUST NOT use insecure DNS queries to canonicalize the hostname components of the service principal names (i.e., they MUST NOT use insecure DNS queries to map one name to another to determine the host part of the principal name with which one is to communicate). and the security considerations section of RFC 4752, namely: When constructing the input_name_string, the client SHOULD NOT canonicalize the server's fully qualified domain name using an insecure or untrusted directory service. are relevant here. The delegated administrative model that I describe is in widespread use; in fact, I don't know of any of my colleagues who *don't* do something similar to that. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5820) segfault with slapacl
by ando＠sys-net.it 20 Nov '08

20 Nov '08

Gavin Henry wrote: >>> Anyone else seeing this? >>> >> Working here. > > I'm on 4.7.25 with patches, 32-bit. You? Same here. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5820) segfault with slapacl
by ghenry＠OpenLDAP.org 20 Nov '08

20 Nov '08

> > > > Anyone else seeing this? > > > > Working here. I'm on 4.7.25 with patches, 32-bit. You? -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5820) segfault with slapacl
by ando＠sys-net.it 20 Nov '08

20 Nov '08

ghenry(a)OpenLDAP.org wrote: > ----- "Pierangelo Masarati" <ando(a)sys-net.it> wrote: > >> ghenry(a)OpenLDAP.org wrote: >> >>> I've just hit this: >>> >>> /usr/local/sbin/slapacl -f /usr/local/etc/openldap/slapd.conf -b >>> "dc=suretecsystems,dc=com" -U ghenry "userPassword/read:" >>> authcDN: "uid=ghenry,cn=auth" >>> read access to userPassword=: DENIED >>> Segmentation fault >> Fixed in HEAD, please test. Thanks, p. > > Thanks. I'm trying to build HEAD, but it's failing test43: > >>>>>> ./scripts/test043-delta-syncrepl failed (exit 1) > make[2]: *** [bdb-mod] Error 1 > make[2]: Leaving directory `/anything/src/openldap/ldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/anything/src/openldap/ldap/tests' > make: *** [test] Error 2 > > [ghenry@suretec testrun]$ diff -urN server1.out server2.out > --- server1.out 2008-11-20 20:49:08.000000000 +0000 > +++ server2.out 2008-11-20 20:49:08.000000000 +0000 > @@ -151,7 +151,7 @@ > contextCSN: 20081120204853.248356Z#000000#000#000000 > entryDN: dc=example,dc=com > subschemaSubentry: cn=Subschema > -auditContext: cn=log > +hasSubordinates: TRUE > > dn: cn=Gern Jensen,ou=Information Technology Division,ou=People,dc=example,dc= > com > > Anyone else seeing this? > Working here. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5820) segfault with slapacl
by ghenry＠OpenLDAP.org 20 Nov '08

20 Nov '08

----- "Pierangelo Masarati" <ando(a)sys-net.it> wrote: > ghenry(a)OpenLDAP.org wrote: > > > I've just hit this: > > > > /usr/local/sbin/slapacl -f /usr/local/etc/openldap/slapd.conf -b > > "dc=suretecsystems,dc=com" -U ghenry "userPassword/read:" > > authcDN: "uid=ghenry,cn=auth" > > read access to userPassword=: DENIED > > Segmentation fault > > Fixed in HEAD, please test. Thanks, p. Thanks. I'm trying to build HEAD, but it's failing test43: >>>>> ./scripts/test043-delta-syncrepl failed (exit 1) make[2]: *** [bdb-mod] Error 1 make[2]: Leaving directory `/anything/src/openldap/ldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/anything/src/openldap/ldap/tests' make: *** [test] Error 2 [ghenry@suretec testrun]$ diff -urN server1.out server2.out --- server1.out 2008-11-20 20:49:08.000000000 +0000 +++ server2.out 2008-11-20 20:49:08.000000000 +0000 @@ -151,7 +151,7 @@ contextCSN: 20081120204853.248356Z#000000#000#000000 entryDN: dc=example,dc=com subschemaSubentry: cn=Subschema -auditContext: cn=log +hasSubordinates: TRUE dn: cn=Gern Jensen,ou=Information Technology Division,ou=People,dc=example,dc= com Anyone else seeing this? -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by hyc＠symas.com 20 Nov '08

20 Nov '08

Russ Allbery wrote: > My impression is that the broader Kerberos community is increasingly > leaning towards not doing DNS canonicalization. That Kerberos libraries > have been canonicalizing hostnames using DNS for quite some time is > certainly true, but it's considered an unfortunate bug that needs to be > supported for backward compatibility but that is clearly not the right way > to do things. This is the reason why Kerberos implementations are > increasingly adding options to disable DNS canonicalization. > > (1) is a vulnerability that Kerberos can protect against if you use it > properly. It's called the Zanarotti attack, and the way that you defend > against it is by obtaining a service ticket for a principal in a local > keytab after initial authentication and verifying that the service ticket > matches. This uses your shared secret with the KDC to verify that you're > talking to the right KDC. Leaving aside your followup which clarified this clause: the obvious point is that a Kerberos client needs to have trusted *local* data to protect against this attack. Delegating the trust to the KDC obviously doesn't solve this problem. (Not to mention that again, a KDC is by definition a trusted 3rd party. If you can't trust it, then the entire Kerberos framework is compromised.) > Your analysis of (2) assumes that every ldap principal in your KDC is > created by someone you trust not to spoof any other ldap principal in your > KDC. Yes, again, that is implicit in the fact that the KDC is a trusted 3rd party. > That's a high bar to meet and many sites are not going to meet that > bar, nor want to given a competing desire for distributed administration. Delegating administration authority still implies that you trust whoever you delegated it to. Again, if you can't trust everyone then your administrative procedures are broken and your framework has already been compromised. > For example, Stanford allows students to run Kerberized services on their > personal computers if they wish, and therefore allows them to download > keytabs (and hence create ldap principals) for those computers. If they > can use DNS hijacking to return a CNAME for an LDAP server pointing to > their computer instead, they can obtain a legitimate keytab for the ldap > principal for that computer, and can successfully trick a client that > trusts DNS canonicalization. Trust within a realm is all-or-nothing. And of course, Kerberos trust is transitive... But the right way to handle regions under different administrative control is to place them in separate realms. For your example of students creating their own principals, independently from the centrally administered realm, you should be using a separate realm (and setup a cross-realm trust if that's appropriate.) That at least gives you consistent accountability, and you can uniformly limit the privileges granted to tickets from non-default realms. > Another, possibly more obvious case where (2) doesn't hold is in the > presence of cross-realm trust. If I can use DNS spoofing to return a > CNAME of ldap.stanford.edu to dorm-machine.mit.edu, and stanford.edu and > ATHENA.MIT.EDU have cross-realm trust, I can perform the same attack. So > you not only have to trust everyone who can create ldap principals in your > local realm, but everyone who can create ldap principals in any realm with > which you have cross-realm trust. Yes, and again, that is basic to the definition of Kerberos. If you don't actually trust everyone, then you should not be adding them into your KDC, because their presence in the KDC is a declaration of trust. Garbage-in-garbage-out applies here. > There are a lot of nasty things that you can do with DNS spoofing, and > this almost certainly isn't the most likely attack, but it is a potential > vulnerability that's been widely discussed within the Kerberos community, > including transition plans for how to get away from always doing > canonicalization. You can, for example, see part of the opinion of the > MIT developers in the comments around the relevant segment of code: > > if (maybe_use_reverse_dns(context, DEFAULT_RDNS_LOOKUP)) { > /* > * Do a reverse resolution to get the full name, just in > * case there's some funny business going on. If there > * isn't an in-addr record, give up. > */ > /* XXX: This is *so* bogus. There are several cases where > this won't get us the canonical name of the host, but > this is what we've trained people to expect. We'll > probably fix it at some point, but let's try to > preserve the current behavior and only shake things up > once when it comes time to fix this lossage. */ > > This is the reason why there's an rdns option in krb5.conf to disable this > code. There has been other discussion of it on krbdev and > kerberos(a)mit.edu in the past. > > I would agree that there's no way that you can change the default; too > much stuff would break. That's also why the Kerberos libraries continue > to do this by default. But I think the original bug reporter isn't > unreasonable for wanting a way to disable canonicalization if they know > that their code and environment will handle that appropriately. You've already proven that the option being discussed here is *not appropriate* because a non-local KDC cannot be trusted. So once again, solve the real problem. What's been proposed here is not a solution. -- -- 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#5812) New option to disable SASL host canonicalization
by rra＠stanford.edu 20 Nov '08

20 Nov '08

rra(a)stanford.edu writes: > (1) is a vulnerability that Kerberos can protect against if you use it > properly. It's called the Zanarotti attack, and the way that you defend > against it is by obtaining a service ticket for a principal in a local > keytab after initial authentication and verifying that the service > ticket matches. I'm sorry -- this is wrong. I overthought this. The scenario discussed here is not the Zanarotti attack. The Zanarotti attack involves spoofing the KDC so that you don't have to know the correct key for a principal; you instead use a key that you know and fool the system into talking to a KDC that uses the same key. It's an attack on login or a screen saver to allow someone to use a bogus password to authenticate. The protection against the scenario (1) listed here is integral into the Kerberos protocol. The Kerberos authentication process involves requesting a TGT from the KDC that's encrypted in your private key and then decrypting the return with your private key. You cannot spoof Kerberos initial authentication from a keytab or a correct password by using DNS to redirect the authentication to a bogus KDC because the bogus KDC won't know your correct private key and hence won't be able to return a TGT that you can decrypt. Similarly, you can't successfully redirect a TGS_REQ to a bogus KDC because that KDC doesn't have the private key and can't complete the protocol exchange. This is why kinit doesn't bother to protect against the Zanarotti attack; there's no need, since kinit doesn't provide increased local privileges and the Zanarotti attack is an attack only on the local system, not against a network service. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by rra＠stanford.edu 20 Nov '08

20 Nov '08

hyc(a)symas.com writes: > In the meantime, the arguments about secure DNS are pure red herrings: > 1. if your DNS has been hijacked, it's most likely that you'll be > directed to a rogue KDC first, so the question of which service you're > talking to is moot. > 2. there's nothing to gain from directing you to a rogue service, since if > you managed to contact the legitimate KDC, you're going to have a service > ticket that can only be decoded by the legitimate service principal. > On the other hand, if the rogue service is actually a valid principal in > your trusted KDC's database, then you clearly have an administrative problem > in your KDC. > > This patch attempts to provide a band-aid without actually solving the > real problem. It merely masks the problem temporarily, until it gets > even worse. My impression is that the broader Kerberos community is increasingly leaning towards not doing DNS canonicalization. That Kerberos libraries have been canonicalizing hostnames using DNS for quite some time is certainly true, but it's considered an unfortunate bug that needs to be supported for backward compatibility but that is clearly not the right way to do things. This is the reason why Kerberos implementations are increasingly adding options to disable DNS canonicalization. (1) is a vulnerability that Kerberos can protect against if you use it properly. It's called the Zanarotti attack, and the way that you defend against it is by obtaining a service ticket for a principal in a local keytab after initial authentication and verifying that the service ticket matches. This uses your shared secret with the KDC to verify that you're talking to the right KDC. Software such as PAM modules that do Kerberos authentications do this check as a matter of course. Once you've done that, further communication with the KDC is done using the session keys in your TGT, and a hijacked KDC won't be able to complete the protocol exchange because it can't decrypt the TGT. kinit and similar programs currently don't do this check by default, but there's no reason why they couldn't if an appropriate keytab is available. Your analysis of (2) assumes that every ldap principal in your KDC is created by someone you trust not to spoof any other ldap principal in your KDC. That's a high bar to meet and many sites are not going to meet that bar, nor want to given a competing desire for distributed administration. For example, Stanford allows students to run Kerberized services on their personal computers if they wish, and therefore allows them to download keytabs (and hence create ldap principals) for those computers. If they can use DNS hijacking to return a CNAME for an LDAP server pointing to their computer instead, they can obtain a legitimate keytab for the ldap principal for that computer, and can successfully trick a client that trusts DNS canonicalization. Another, possibly more obvious case where (2) doesn't hold is in the presence of cross-realm trust. If I can use DNS spoofing to return a CNAME of ldap.stanford.edu to dorm-machine.mit.edu, and stanford.edu and ATHENA.MIT.EDU have cross-realm trust, I can perform the same attack. So you not only have to trust everyone who can create ldap principals in your local realm, but everyone who can create ldap principals in any realm with which you have cross-realm trust. There are a lot of nasty things that you can do with DNS spoofing, and this almost certainly isn't the most likely attack, but it is a potential vulnerability that's been widely discussed within the Kerberos community, including transition plans for how to get away from always doing canonicalization. You can, for example, see part of the opinion of the MIT developers in the comments around the relevant segment of code: if (maybe_use_reverse_dns(context, DEFAULT_RDNS_LOOKUP)) { /* * Do a reverse resolution to get the full name, just in * case there's some funny business going on. If there * isn't an in-addr record, give up. */ /* XXX: This is *so* bogus. There are several cases where this won't get us the canonical name of the host, but this is what we've trained people to expect. We'll probably fix it at some point, but let's try to preserve the current behavior and only shake things up once when it comes time to fix this lossage. */ This is the reason why there's an rdns option in krb5.conf to disable this code. There has been other discussion of it on krbdev and kerberos(a)mit.edu in the past. I would agree that there's no way that you can change the default; too much stuff would break. That's also why the Kerberos libraries continue to do this by default. But I think the original bug reporter isn't unreasonable for wanting a way to disable canonicalization if they know that their code and environment will handle that appropriately. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5820) segfault with slapacl
by ando＠sys-net.it 20 Nov '08

20 Nov '08

ghenry(a)OpenLDAP.org wrote: > I've just hit this: > > /usr/local/sbin/slapacl -f /usr/local/etc/openldap/slapd.conf -b > "dc=suretecsystems,dc=com" -U ghenry "userPassword/read:" > authcDN: "uid=ghenry,cn=auth" > read access to userPassword=: DENIED > Segmentation fault Fixed in HEAD, please test. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: ITS#5821 Small mistake in man page
by ando＠sys-net.it 20 Nov '08

20 Nov '08

Fixed in HEAD; please check. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: ITS#5822 slapd goes into sleeping mode
by ando＠sys-net.it 20 Nov '08

20 Nov '08

There exists no OpenLDAP 2.1 b102. There exists a 2.1 branch, which was obsoleted few years ago. Even if there existed one, you don't provide enough info that could help debugging your issue. Please see <http://www.openldap.org/faq/data/cache/56.html> for details about how to report an issue. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5822) slapd goes into sleeping mode
by egarciab＠alcatel-lucent.com 20 Nov '08

20 Nov '08

Full_Name: Eduardo Garcia Version: slapd 2.1 b102 OS: solaris 5.9 URL: ftp://ftp.openldap.org/incoming/traza_mala Submission from: (NULL) (194.113.59.80) Hello, We are using a customized version of the slapd v2.1 b102. The problem that we are seeing in the last days is that the slapd process goes into a sleeping mode, and none ldap request is answered. This problems seems to happend in an intervals of 72 hours more or less. The process slapd is alive, but it seems to be stuck. Last time this problem arised, I run a truss command to get more clues about it. Above these lines, you can find the ooutput of truss and also a snoop of the port 389 in the slapd machine. Could you please look into this problem? Any further info you need , please tell me. Thanks a lot in advance Eduardo PS: we have implemented a local script to verify if the slapd process is up and answering and we could see that in the moment when this problem happens, the slapd did not answer to this local ldap request either. It kept sleeping and running This was the output of the truss command: /1: lwp_wait(2, 0xFFBFFCC4) (sleeping...) /4: lwp_park(0x00000000, 0) (sleeping...) /5: lwp_park(0x00000000, 0) (sleeping...) /7: lwp_park(0x00000000, 0) (sleeping...) /11: lwp_park(0x00000000, 0) (sleeping...) /8: lwp_park(0x00000000, 0) (sleeping...) /12: lwp_park(0x00000000, 0) (sleeping...) /13: lwp_park(0x00000000, 0) (sleeping...) /10: read(15, 0x002E6476, 2064) (sleeping...) /18: lwp_park(0x00000000, 0) (sleeping...) /17: lwp_park(0x00000000, 0) (sleeping...) /16: lwp_park(0x00000000, 0) (sleeping...) /3: lwp_park(0x00000000, 0) (sleeping...) /15: lwp_park(0x00000000, 0) (sleeping...) /9: lwp_park(0x00000000, 0) (sleeping...) /2: poll(0xFE3FD418, 3, -1) (sleeping...) /6: lwp_park(0x00000000, 0) (sleeping...) /14: lwp_park(0x00000000, 0) (sleeping...) I also get a snoop trace in the slapd machine to see which was the messages received and sent from our machine ---> traza_mala file at ftp://ftp.openldap.org/incoming/

1 0

(ITS#5821) Small mistake in man page
by kkalev＠gmail.com 20 Nov '08

20 Nov '08

Full_Name: Kostas Kalevras Version: 2.4.12 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (147.102.247.100) In the manpage for slapd.conf (slapd.conf.5) in the limits directive description the value for the size.unchecked pattern should be disabled and not disable according to limits.c

1 0

Re: (ITS#5793) RFE for flexible logging at 256/stats level
by ando＠sys-net.it 20 Nov '08

20 Nov '08

michael(a)stroeder.com wrote: > ando(a)sys-net.it wrote: >> Wouldn't it make sense to entirely give up syslog'ging and use >> slapo-accesslog instead? > > Hmm, I think this change would be too radical. I still see some value in > text messages going to syslog. Configuration issues are sometimes more > obvious if you see the syslog messages of LDAP-enabled components and > the LDAP server one after the other in the same log. I meant "give up" by not looking at logs for Gavin's purposes, not to eradicate them from the code. Modifying "stats" logging would not probably be a big issue, if we define a specific mask: one bit for each operation, and one bit for success/failure. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5793) RFE for flexible logging at 256/stats level
by michael＠stroeder.com 20 Nov '08

20 Nov '08

ando(a)sys-net.it wrote: > Wouldn't it make sense to entirely give up syslog'ging and use > slapo-accesslog instead? Hmm, I think this change would be too radical. I still see some value in text messages going to syslog. Configuration issues are sometimes more obvious if you see the syslog messages of LDAP-enabled components and the LDAP server one after the other in the same log. Ciao, Michael.

1 0

(ITS#5820) segfault with slapacl
by ghenry＠OpenLDAP.org 20 Nov '08

20 Nov '08

Full_Name: Gavin Henry Version: 2.4.12 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Hi All, I've just hit this: /usr/local/sbin/slapacl -f /usr/local/etc/openldap/slapd.conf -b "dc=suretecsystems,dc=com" -U ghenry "userPassword/read:" authcDN: "uid=ghenry,cn=auth" read access to userPassword=: DENIED Segmentation fault gdb: Starting program: /usr/local/sbin/slapacl -f /usr/local/etc/openldap/slapd.conf -b "dc=suretecsystems,dc=com" -U ghenry "userPassword/read:" (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1208350960 (LWP 10744)] authcDN: "uid=ghenry,cn=auth" read access to userPassword=: DENIED Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208350960 (LWP 10744)] 0x005f70c7 in free () from /lib/libc.so.6 (gdb) bt #0 0x005f70c7 in free () from /lib/libc.so.6 #1 0x00158c0a in ber_memfree_x (p=0x0, ctx=0x0) at memory.c:152 #2 0x08089ee8 in ch_free () #3 0x080d4d3c in slap_tool_destroy () #4 0x080d71a1 in slapacl () #5 0x080564d2 in main () (gdb) q I'm just compiling up HEAD now to test with the latest code and will get back to you. Gavin.

1 0

Re: (ITS#5819) On add, slapd does not add distinguished values if naming attribute already present
by ando＠sys-net.it 19 Nov '08

19 Nov '08

Fixed in HEAD; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5819) On add, slapd does not add distinguished values if naming attribute already present
by ando＠sys-net.it 19 Nov '08

19 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando To trigger, try # works fine dn: cn=Foo,dc=example,dc=com objectClass: device # error dn: cn=Bar,dc=example,dc=com objectClass: device cn: Foo I'd expect both to succeed, and a "cn" of "Foo" or "Bar" to be automatically added by slapd according to RFC4511 (since "cn" is multi-valued). p.

1 0

Re: (ITS#5793) RFE for flexible logging at 256/stats level
by ghenry＠OpenLDAP.org 19 Nov '08

19 Nov '08

----- "Pierangelo Masarati" <ando(a)sys-net.it> wrote: > ghenry(a)OpenLDAP.org wrote: > > > Just a quick note to say it would be nice to be able to break out > loglevel 256 > > i.e. Log just writes. The same as accesslog config. > > Are you thinking of something like a read/write/auth flag, plus > possibly > a success/failure flag, or a per-operation granularity? Probably the later. It's more to not lot searches, but writes, as 256 can really fill up your logfile. > Wouldn't it make sense to entirely give up syslog'ging and use > slapo-accesslog instead? For some users, yes. But having the phyiscal log is appealing too. Thanks. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5817) ldapadd crashes with '-' in input
by ando＠sys-net.it 19 Nov '08

19 Nov '08

Jan Safranek wrote: > Pierangelo Masarati wrote: >> I've applied a fix to HEAD code, please test. > > Thanks for a quick fix! Now it prints "ldap_add: Bad parameter to an > ldap routine (-9)", which is a bit better than the assert before. Yes. I modified ldap_add_ext(3) to further validate input parameters instead of crashing. ldapadd(1) needs work in order to intercept the issue earlier and complain as appropriate. I was more concerned by libldap because it might be used in more critical applications than ldapadd(1) itself. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5817) ldapadd crashes with '-' in input
by jsafrane＠redhat.com 19 Nov '08

19 Nov '08

Pierangelo Masarati wrote: > I've applied a fix to HEAD code, please test. Thanks for a quick fix! Now it prints "ldap_add: Bad parameter to an ldap routine (-9)", which is a bit better than the assert before. Jan

1 0

Re: (ITS#5764) addpartial patch
by ando＠sys-net.it 19 Nov '08

19 Nov '08

hyc(a)symas.com wrote: > dhawes(a)vt.edu wrote: >> The patch referenced previously can be discarded. This patch contains >> all changes against 2.4.12. > > I suspect HEAD and 2.4.12 are identical here so it's no big deal this time, > but remember for future reference, > > http://www.openldap.org/devel/contributing.html > > all contributions must be relative to HEAD. I also note that you should not diff generated files, like Makefile. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5793) RFE for flexible logging at 256/stats level
by ando＠sys-net.it 19 Nov '08

19 Nov '08

ghenry(a)OpenLDAP.org wrote: > Just a quick note to say it would be nice to be able to break out loglevel 256 > i.e. Log just writes. The same as accesslog config. Are you thinking of something like a read/write/auth flag, plus possibly a success/failure flag, or a per-operation granularity? Wouldn't it make sense to entirely give up syslog'ging and use slapo-accesslog instead? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5816) back-ldap stops searching if send_search_entry() returns harmless errors (like insufficientAccess)
by ando＠sys-net.it 18 Nov '08

18 Nov '08

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.72.89.40) > Submitted by: ando > > > To trigger: define acls that block one entry, and the search will stop at that > entry. A fix is coming... Fixed in HEAD (and in re24, apparently). I confirm back-meta does not appear to suffer from this issue. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5805) Problem when modifying access control
by rein＠OpenLDAP.org 18 Nov '08

18 Nov '08

emmanuel.duru(a)atosorigin.com skrev: > OK, my mistake, here follows a completely detailed description. > * I perform the ldap modifications with this LDIF file: [cut] > * I try to bind : > ldapsearch.exe -x -D cn=manager,c=fr -w secret -s base -b "" objectclass=* + > I get: > ldap_bind: Invalid credentials (49) > * I stop slapd [cut] > * I restart slapd > * I try to bind : > ldapsearch.exe -x -D cn=manager,c=fr -w secret -s base -b "" objectclass=* + > It works fine. Dynamic updates to the frontend ACL doesn't take place until slapd is restarted, ref ITS#5572. A fix is included in CVS HEAD and RE24, and will be included in the upcoming 2.4.13 release. Rein

1 0

Re: (ITS#5805) Problem when modifying access control
by ando＠sys-net.it 18 Nov '08

18 Nov '08

Emmanuel Duru wrote: > OK, my mistake, here follows a completely detailed description. I confirm HEAD and re24 behave as expected. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by hyc＠symas.com 18 Nov '08

18 Nov '08

ali.pouya(a)free.fr wrote: > So I checked out the HEAD last night. > The good news is that the problem is fixed now and every thing seems OK (six new > modifications have been made to syncprov.c since Nov 2, one of which being made > by Quanah and related to this issue). Not sure what you're looking at, but the CVS log clearly shows that this bug was fixed in revision 1.251 on November 2. http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/overlays/syncprov.c?… The updates after 1.252 are merely copying from HEAD to the RE24 branch. You said you pulled from HEAD on November 3, and still saw the problem. Either your checkout was wrong, or your configuration was wrong, because the fix was definitely present in HEAD by then. > So the issue can be closed :-) > Thanks again > Best Regards > Ali -- -- 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#5640) slapd scans too many objects at startup
by hyc＠symas.com 18 Nov '08

18 Nov '08

Ali Pouya wrote: > Hi Howard, > Sorry for being back again but I think that a residue of the problem of > whole tree scanning persists : > The improvement is that it only happens once if the mirrors are not > synchronized (the later statups are OK). That's the normal behavior for the syncrepl protocol. Read the Admin Guide or RFC4533 for details. -- -- 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#5818) Limits chapter for Admin Guide
by ghenry＠OpenLDAP.org 18 Nov '08

18 Nov '08

----- "andrew findlay" <andrew.findlay(a)skills-1st.co.uk> wrote: > Full_Name: Andrew Findlay > Version: HEAD > OS: Linux > URL: > ftp://ftp.openldap.org/incoming/andrew-findlay-limits.sdf-20081118 > Submission from: (NULL) (88.97.25.132) > > > The Admin Guide says very little about size limits and time limits. > I have supplied a chapter to remedy the lack: I suggest putting it in > after the > Access Control chapter: > > ftp://ftp.openldap.org/incoming/andrew-findlay-limits.sdf-20081118 > > Please check the section on limits for paged results extra carefully. > I found the definition in slapd.conf(5) a little ambiguous. > > I have also provided patches to the master sdf file and to the two > config > directive > chapters: > > ftp://ftp.openldap.org/incoming/andrew-findlay-limits-patch-20081118 > > Andrew Thanks Andrew, I'll review and get back to when possible. Gavin. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#5818) Limits chapter for Admin Guide
by andrew.findlay＠skills-1st.co.uk 18 Nov '08

18 Nov '08

Full_Name: Andrew Findlay Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/andrew-findlay-limits.sdf-20081118 Submission from: (NULL) (88.97.25.132) The Admin Guide says very little about size limits and time limits. I have supplied a chapter to remedy the lack: I suggest putting it in after the Access Control chapter: ftp://ftp.openldap.org/incoming/andrew-findlay-limits.sdf-20081118 Please check the section on limits for paged results extra carefully. I found the definition in slapd.conf(5) a little ambiguous. I have also provided patches to the master sdf file and to the two config directive chapters: ftp://ftp.openldap.org/incoming/andrew-findlay-limits-patch-20081118 Andrew

1 0

Re: (ITS#5817) ldapadd crashes with '-' in input
by ando＠sys-net.it 18 Nov '08

18 Nov '08

jsafrane(a)redhat.com wrote: > Full_Name: Jan Safranek > Version: 2.4.12 > OS: Linux (Fedora 9) > URL: > Submission from: (NULL) (89.102.11.105) > > > ldapadd crashes with assertion 'ldapadd: encode.c:392: ber_put_string: Assertion > `str != ((void *)0)' failed.' on following input: > > dn: nisMapName=netgroup.byhost,dc=my-domain,dc=com > nismapname: netgroup.byhost > objectClass: top > objectClass: nisMap > - > > The reason is probably at ldapmodify.c:445, where the lines containing dash are > skipped, apparently for modify operations: > > if ( line[0] == '-' && !line[1] ) { > BER_BVZERO( btype+i ); > freeval[i] = 0; > continue; > } > > ldap_add_ext() seems not to like these empty spaces. I think the fix belongs to ldap_add_ext(), as other applications may well call it with invalid parameters. I've applied a fix to HEAD code, please test. The fix is Checking in libraries/libldap/add.c; /repo/OpenLDAP/pkg/ldap/libraries/libldap/add.c,v <-- add.c new revision: 1.32; previous revision: 1.31 It hould apply straightforwardly to the release you're using. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5817) ldapadd crashes with '-' in input
by jsafrane＠redhat.com 18 Nov '08

18 Nov '08

Full_Name: Jan Safranek Version: 2.4.12 OS: Linux (Fedora 9) URL: Submission from: (NULL) (89.102.11.105) ldapadd crashes with assertion 'ldapadd: encode.c:392: ber_put_string: Assertion `str != ((void *)0)' failed.' on following input: dn: nisMapName=netgroup.byhost,dc=my-domain,dc=com nismapname: netgroup.byhost objectClass: top objectClass: nisMap - The reason is probably at ldapmodify.c:445, where the lines containing dash are skipped, apparently for modify operations: if ( line[0] == '-' && !line[1] ) { BER_BVZERO( btype+i ); freeval[i] = 0; continue; } ldap_add_ext() seems not to like these empty spaces. Full backtrace: (gdb) bt full #0 0x0000003ea4832215 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x0000003ea4833d83 in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x0000003ea482b039 in __assert_fail () from /lib64/libc.so.6 No symbol table info available. #3 0x0000000000440e0e in ber_put_string (ber=0x1573390, str=0x0, tag=18446744073709551615) at encode.c:392 __PRETTY_FUNCTION__ = "ber_put_string" #4 0x0000000000441f5e in ber_printf (ber=0x1573390, fmt=0x44b34e "s[V]N}") at encode.c:809 ap = {{gp_offset = 24, fp_offset = 48, overflow_arg_area = 0x7fffeaf5ed80, reg_save_area = 0x7fffeaf5ecc0}} s = 0x0 ss = (char **) 0x0 bv = (struct berval *) 0x7fffeaf5ecf0 bvp = (struct berval **) 0x157b718 rc = 0 i = 2 len = 0 __PRETTY_FUNCTION__ = "ber_printf" #5 0x0000000000414edd in ldap_add_ext (ld=0x15731d0, dn=0x157c714 "nisMapName=netgroup.byhost,dc=my-domain,dc=com", attrs=0x157b6e8, sctrls=0x0, cctrls=0x0, msgidp=0x7fffeaf5ee6c) at add.c:154 ber = (BerElement *) 0x1573390 i = 2 rc = 30 id = 2 __PRETTY_FUNCTION__ = "ldap_add_ext" #6 0x0000000000406c07 in domodify (dn=0x157c714 "nisMapName=netgroup.byhost,dc=my-domain,dc=com", pmods=0x157b6e8, pctrls=0x0, newentry=1) at ldapmodify.c:1094 msgid = 0 rc = -352981360 i = 3 j = 4474435 k = 0 notascii = 976894522 op = 0 bvp = (struct berval *) 0xa0 #7 0x00000000004063e9 in process_ldif_rec (rbuf=0x157c786 "", linenum=1) at ldapmodify.c:866 line = 0x0 dn = 0x157c714 "nisMapName=netgroup.byhost,dc=my-domain,dc=com" newrdn = 0x0 newsup = 0x0 rc = 0 modop = 0 expect_modop = 0 expect_sep = 0 deleteoldrdn = 1 new_entry = 1 delete_entry = 0 got_all = 0 pmods = (LDAPMod **) 0x157b6e8 lm = (LDAPMod *) 0x157b6a0 version = 0 pctrls = (LDAPControl **) 0x0 i = 5 j = 3 k = 6 lines = 5 idn = 1 nmods = 3 btype = (struct berval *) 0x157b5d0 vals = (struct berval *) 0x157b630 bvl = (struct berval **) 0x157b708 bv = {bv_len = 0, bv_val = 0x0} freeval = 0x157b690 "" mops = (unsigned char *) 0x0 #8 0x000000000040458b in main (argc=11, argv=0x7fffeaf5f178) at ldapmodify.c:341 rbuf = 0x157c710 "dn" rejbuf = 0x0 rejfp = (FILE *) 0x0 ldiffp = (struct LDIFFP *) 0x1572e50 ldifdummy = {fp = 0x0, prev = 0x0} matched_msg = 0x4473c0 "H\211l$�L\211|$�H\215-/\034!" error_msg = 0x0 rc = 0 retval = 0 len = 32767 i = 0 lineno = 1 nextline = 6 lmax = 4147 c = {{ldctl_oid = 0x7fffeaf5f020 "\214�|�����3\020", ldctl_value = {bv_len = 226974810936, bv_val = 0x3ea480ae20 "\016\001"}, ldctl_iscritical = 0 '\0'}}

1 0

RE: (ITS#5805) Problem when modifying access control
by emmanuel.duru＠atosorigin.com 18 Nov '08

18 Nov '08

Sorry the command to create the initial database is not slapadd -f configdb -l initialdatabase.ldif but slapadd -F configdb -l initialdatabase.ldif

1 0

RE: (ITS#5805) Problem when modifying access control
by emmanuel.duru＠atosorigin.com 18 Nov '08

18 Nov '08

OK, my mistake, here follows a completely detailed description. * I have a slapd.conf as follows -----------------begin slapd.conf include schema/core.schema include schema/cosine.schema include schema/inetorgperson.schema pidfile slapd.pid argsfile slapd.args access to * attrs=userPassword by self write by anonymous auth by * none access to dn=cn=manager,c=fr by self write by * none access to * by self write by users read by anonymous read by * none database bdb suffix "c=fr" rootdn "cn=manager,c=fr" cachesize 20000 checkpoint 10000 10 directory db index objectClass,entryCSN,entryUUID eq index cn,sn eq,sub -----------------end slapd.conf * I convert this slapd.conf to a configdb: slapd -f slapd.conf -F configdb * I stop slapd. * I create the initial database with the following LDIF file: -----------------begin initial database dn: c=fr objectClass: country c: fr dn: cn=manager,c=fr objectClass: person cn: manager sn: manager userPassword:: c2VjcmV0 dn: cn=user,c=fr objectClass: person cn: user sn: user userPassword:: dXNlcg== dn: cn=user2,c=fr objectClass: person cn: user2 sn: user2 userPassword:: dXNlcjI= -----------------end initial database slapadd -f configdb -l initialdatabase.ldif * I edit olcDatabase={0}config.ldif file to replace olcRootDN: cn=config by olcRootDN: cn=manager,c=fr * I start slapd slapd -d 256 -F configdb * I try to bind : ldapsearch.exe -x -D cn=manager,c=fr -w secret -s base -b "" objectclass=* + It works fine. * I perform the ldap modifications with this LDIF file: -----------------begin LDAP modifications dn: olcDatabase={-1}frontend,cn=config changetype: modify replace: olcAccess olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * no ne olcAccess: {1}to dn=cn=manager,c=fr by self write by * none olcAccess: {2}to * by self write by users read by anonymous read by * none dn: olcDatabase={0}config,cn=config changetype: modify replace: olcAccess olcAccess: {0}to * by * none -----------------end LDAP modifications ldapmodify -x -D cn=manager,c=fr -w secret -f LDAPmodifications.ldif * I try to bind : ldapsearch.exe -x -D cn=manager,c=fr -w secret -s base -b "" objectclass=* + I get: ldap_bind: Invalid credentials (49) * I stop slapd I get: filter_free: unknown filter type=19008 filter_free: unknown filter type=13304 slapd stopped. filter_free: unknown filter type=13744 filter_free: unknown filter type=1264 filter_free: unknown filter type=13744 filter_free: unknown filter type=1264 and slapd crashes. * I restart slapd * I try to bind : ldapsearch.exe -x -D cn=manager,c=fr -w secret -s base -b "" objectclass=* + It works fine.

1 0

(ITS#5816) back-ldap stops searching if send_search_entry() returns harmless errors (like insufficientAccess)
by ando＠sys-net.it 17 Nov '08

17 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando To trigger: define acls that block one entry, and the search will stop at that entry. A fix is coming... p.

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by ali.pouya＠free.fr 17 Nov '08

17 Nov '08

Hi Howard, Sorry for being back again but I think that a residue of the problem of whole tree scanning persists : The improvement is that it only happens once if the mirrors are not synchronized (the later statups are OK). I uploaded the new archive file ITS_5640_new.tar.gz to the FTP server (incoming directory). To reproduce the problem y can proceed as explained in folowwup 9. Thanks Best Regards Ali

1 0

Re: (ITS#5796) back-sql intermittently failing
by robb＠wtg.cw.com 17 Nov '08

17 Nov '08

Pierangelo Masarati wrote: > OK, this makes sense. In fact, back-sql does not seem to specifically > handle broken connections to the odbc. It appears it would need > something similar to idle-timeout as in back-ldap and back-meta. current work-around is to set "idletimeout" in openldap shorter than mysql's "wait_timeout" (default 8hrs).

1 0

Re: (ITS#5805) Problem when modifying access control
by ando＠sys-net.it 17 Nov '08

17 Nov '08

emmanuel.duru(a)atosorigin.com wrote: > I'm sorry, but I don't. > cn=manager,c=fr was already the rootdn of config database (as well as rootdn > of c=fr database) before doing the test, with no rootpw in the config > database. > My first test consisted in modifying both olcAccess and olcRootDn for all > databases (if present) without changing any value (replacing the existing > values with the same ones). Then I made another test, with olcAccess > modifications only (on both frontend and config databases), and the problem > still appears. It only appears if I modify olcAccess of both databases, and > in this order: frontend then config. Well, I simply followed what you described in your bug report (at least what I understood). Next time, please provide a full featured script that fires up slapd and performs the offending writes. I'll change "cannot reproduce" to "report obscure". p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs