openldap-bugs February 2009

openldap-bugs@openldap.org

47 participants
298 discussions

ITS#5924
by ando＠sys-net.it 05 Feb '09

05 Feb '09

Using valgrind, I note few issues conn=0 op=1 MODRDN dn="olcDatabase={2}bdb,cn=config" ==17038== Thread 3: ==17038== Invalid read of size 1 ==17038== at 0x821D904: lutil_strncopy (utils.c:438) ==17038== by 0x80A12E6: build_new_dn (dn.c:1172) ==17038== by 0x80715C1: config_rename_kids (bconfig.c:3816) ==17038== by 0x80719E1: config_rename_one (bconfig.c:3893) ==17038== by 0x8071C08: config_renumber_one (bconfig.c:3943) ==17038== by 0x8073A4C: config_rename_del (bconfig.c:4663) ==17038== by 0x8075703: config_back_modrdn (bconfig.c:5373) ==17038== by 0x80A7273: fe_op_modrdn (modrdn.c:314) ==17038== by 0x80A6BD6: do_modrdn (modrdn.c:186) ==17038== by 0x8086511: connection_operation (connection.c:1100) ==17038== by 0x80869EB: connection_read_thread (connection.c:1226) ==17038== by 0x8224F80: ldap_int_thread_pool_wrapper (tpool.c:663) ==17038== Address 0x475F140 is 0 bytes inside a block of size 48 free'd ==17038== at 0x4004FDA: free (vg_replace_malloc.c:233) ==17038== by 0x825B5A9: ber_memfree_x (memory.c:152) ==17038== by 0x80A8129: ch_free (ch_malloc.c:139) ==17038== by 0x8071583: config_rename_kids (bconfig.c:3814) ==17038== by 0x80719E1: config_rename_one (bconfig.c:3893) ==17038== by 0x8071C08: config_renumber_one (bconfig.c:3943) ==17038== by 0x8073A4C: config_rename_del (bconfig.c:4663) ==17038== by 0x8075703: config_back_modrdn (bconfig.c:5373) ==17038== by 0x80A7273: fe_op_modrdn (modrdn.c:314) ==17038== by 0x80A6BD6: do_modrdn (modrdn.c:186) ==17038== by 0x8086511: connection_operation (connection.c:1100) ==17038== by 0x80869EB: connection_read_thread (connection.c:1226) ==17038== ==17038== Invalid read of size 1 ==17038== at 0x821D904: lutil_strncopy (utils.c:438) ==17038== by 0x80A12E6: build_new_dn (dn.c:1172) ==17038== by 0x80715EE: config_rename_kids (bconfig.c:3818) ==17038== by 0x80719E1: config_rename_one (bconfig.c:3893) ==17038== by 0x8071C08: config_renumber_one (bconfig.c:3943) ==17038== by 0x8073A4C: config_rename_del (bconfig.c:4663) ==17038== by 0x8075703: config_back_modrdn (bconfig.c:5373) ==17038== by 0x80A7273: fe_op_modrdn (modrdn.c:314) ==17038== by 0x80A6BD6: do_modrdn (modrdn.c:186) ==17038== by 0x8086511: connection_operation (connection.c:1100) ==17038== by 0x80869EB: connection_read_thread (connection.c:1226) ==17038== by 0x8224F80: ldap_int_thread_pool_wrapper (tpool.c:663) ==17038== Address 0x475F1A0 is 0 bytes inside a block of size 48 free'd ==17038== at 0x4004FDA: free (vg_replace_malloc.c:233) ==17038== by 0x825B5A9: ber_memfree_x (memory.c:152) ==17038== by 0x80A8129: ch_free (ch_malloc.c:139) ==17038== by 0x8071594: config_rename_kids (bconfig.c:3815) ==17038== by 0x80719E1: config_rename_one (bconfig.c:3893) ==17038== by 0x8071C08: config_renumber_one (bconfig.c:3943) ==17038== by 0x8073A4C: config_rename_del (bconfig.c:4663) ==17038== by 0x8075703: config_back_modrdn (bconfig.c:5373) ==17038== by 0x80A7273: fe_op_modrdn (modrdn.c:314) ==17038== by 0x80A6BD6: do_modrdn (modrdn.c:186) ==17038== by 0x8086511: connection_operation (connection.c:1100) ==17038== by 0x80869EB: connection_read_thread (connection.c:1226) conn=0 op=1 RESULT tag=109 err=0 text= which eventually result in the screwed name of the children entries of the renamed database. I'm investigating... 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: Docs: admin guide describes log levels inconsistently (ITS#5904)
by ando＠sys-net.it 05 Feb '09

05 Feb '09

gavin.henry(a)gmail.com wrote: > Ok, but wouldn't that detail be best served staying in the man page? I > mean, what "user" will want to enter hex for loglevels? Actually, I wonder what user would use the decimal notation. I introduced the hexadecimal because I find it a little more intuitive in terms of bitwise (then I decided to move to string-based :) 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: Docs: admin guide describes log levels inconsistently (ITS#5904)
by gavin.henry＠gmail.com 05 Feb '09

05 Feb '09

Ok, but wouldn't that detail be best served staying in the man page? I mean, what "user" will want to enter hex for loglevels? I'll make the same anyway. Thanks. On 05/02/2009, quanah(a)zimbra.com <quanah(a)zimbra.com> wrote: > --On Thursday, February 05, 2009 11:41 AM +0000 ghenry(a)OpenLDAP.org wrote: > >> Awww, aren't we nice! ;-) >> >> Patch applied, > > The new patch is definitely an improvement, however it fails to document > the hexadecimal notation for log levels, which is also perfectly valid. > See slapd.conf(5): > > 1 (0x1 trace) trace function calls > 2 (0x2 packets) debug packet handling > 4 (0x4 args) heavy trace debugging (function args) > > > and the description therein: > > The desired log level can be input as a single integer that > combines the (ORed) desired levels, both in decimal or in > hexadecimal notation, as a list of integers (that are ORed > internally), or as a list of the names that are shown between > brackets, such that > > loglevel 129 > loglevel 0x81 > loglevel 128 1 > loglevel 0x80 0x1 > loglevel acl trace > > are equivalent. > > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > > -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/

1 0

Re: (ITS#5326) Add could re-build entry's DN using parent's DN and entry's RDN
by ando＠sys-net.it 05 Feb '09

05 Feb '09

Fixed in HEAD for back-bdb & back-hdb; back-ldif does not suffer from this issue. proxy backends and so should neither. Not sure about other backends like back-sql and back-ndb. 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

Re: (ITS#5923) slapo-rwm may cause double frees when rewriting DN-valued attrs in search entry responses
by ando＠sys-net.it 05 Feb '09

05 Feb '09

ando(a)sys-net.it wrote: > A fix is coming (hopefully for 2.4.14 :). p. Fixed in HEAD. 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#5925) [backend config] glue: no superior found in N-Way Multi-Master replication
by tchemineau＠linagora.com 05 Feb '09

05 Feb '09

Full_Name: Thomas Chemineau Version: OPENLDAP_REL_ENG_2_4 OS: CentOS 5.2 64 bits URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.243.192) When : when a replica replicates its entire cn=config from a provider, and the configuration has gluing databases. Suppose you have into your config backend the following : 8<-------- dn: olcDatabase={0}config,cn=config olcSyncrepl: {0}rid=001 provider=ldap://1.2.3.4/ binddn="cn=config" bin dmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPer sist retry="5 +" timeout=3 olcSyncrepl: {1}rid=002 provider=ldap://1.2.3.5/ binddn="cn=config" bin dmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPer sist retry="5 +" timeout=3 [...] dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config [...] dn: olcDatabase={2}ldap,cn=config olcSuffix: o=1,o=2 olcSubordinate: TRUE [...] dn: olcDatabase={3}bdb,cn=config olcSuffix: o=2 [...] dn: olcOverlay={0}glue,olcDatabase={3}bdb,cn=config [...] 8<-------- slaptest passes successfully, and OpenLDAP starts. When a new provider joins the N-Way Multi-Master replication, it replicates all the configuration from the primary provider (which is indicated in its minimalistic configuration). But, the replication failed on the following error : 8<-------- Feb 5 18:25:04 server2 slapd[6202]: syncrepl_entry: rid=001 be_search (0) Feb 5 18:25:04 server2 slapd[6202]: syncrepl_entry: rid=001 olcDatabase={2}ldap,cn=config Feb 5 18:25:04 server2 slapd[6202]: glue: no superior found for sub o=1,o=2! Feb 5 18:25:04 server2 slapd[6202]: olcSubordinate: value #0: <olcSubordinate> handler exited with 32! Feb 5 18:25:04 server2 slapd[6202]: null_callback : error code 0x50 Feb 5 18:25:04 server2 slapd[6202]: syncrepl_entry: rid=001 be_add (80) Feb 5 18:25:04 server2 slapd[6202]: syncrepl_entry: rid=001 be_add failed (80) Feb 5 18:25:04 server2 slapd[6202]: do_syncrepl: rid=001 retrying 8<-------- It appears that ldap's backend which is subordinate to an other backend should be declared after this gluing database. This is exactly the contrary on how works slapd.conf. Thomas.

1 0

(ITS#5924) [backend config] modify rdn on a backend entry will cause bad renaming of all subentries when retrieving by ldapsearch
by tchemineau＠linagora.com 05 Feb '09

05 Feb '09

Full_Name: Thomas Chemineau Version: OPENLDAP_REL_ENG_2_4 OS: CentOS 5.2 64 bits URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.243.192) Renaming an entry of a configugred OpenLDAP backend causes bad renaming of its subentries and all subentries of all other backends, when retrieving them by a simple LDAP search. For example, suppose you have these configuration into slapd.conf : 8<-------- database bdb suffix "o=1" directory /usr/local/openldap-2.4/var/openldap-data-1 overlay rwm rwm-suffixmassage o=1 dc=1 database bdb suffix "o=2" overlay glue rootdn "cn=Directory Manager,o=2" rootpw secret directory /usr/local/openldap-2.4/var/openldap-data-2 database bdb suffix "o=3" rootdn "cn=Directory Manager,o=3" rootpw secret directory /usr/local/openldap-2.4/var/openldap-data-3 8<-------- When you convert slapd.conf to slapd.d (backend config), then you should obtain something like the following (slapcat -b cn=config -F ...) : 8<-------- [...] dn: olcDatabase={-1}frontend,cn=config [...] dn: olcDatabase={0}config,cn=config [...] dn: olcDatabase={1}monitor,cn=config [...] dn: olcDatabase={2}bdb,cn=config olcSuffix: o=1 [...] dn: olcOverlay={0}rwm,olcDatabase={2}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: {0}rwm-suffixmassage "o=1" "dc=1" olcRwmTFSupport: false olcRwmNormalizeMapped: FALSE dn: olcDatabase={3}bdb,cn=config olcSuffix: o=2 [...] dn: olcOverlay={0}glue,olcDatabase={3}bdb,cn=config objectClass: olcOverlayConfig olcOverlay: {0}glue dn: olcDatabase={4}bdb,cn=config olcSuffix: o=3 [...] 8<-------- Now, for some reason, you want to rename olcDatabase={2}bdb,cn=config into olcDatabase={3}bdb,cn=config (to invert declaration for example). This operation works successfully but causes all subentries DN to be rename improperly. You obtain someting like the following via ldapsearch (not via slapcat) : 8<-------- [...] dn: olcDatabase={-1}frontend,cn=config [...] dn: olcDatabase={0}config,cn=config [...] dn: olcDatabase={1}monitor,cn=config [...] dn: olcDatabase={2}bdb,cn=config olcSuffix: o=2 [...] dn:: IHFbGSxvbGNEYXRhYmFzZT17Mn1iZGIsY249Y29uZmlnAGJkYixjbj1jb25maWc= objectClass: olcOverlayConfig olcOverlay: {0}glue [...] dn: olcDatabase={3}bdb,cn=config olcSuffix: o=1 [...] dn:: LG9sY0RhdGFiYXNlPXszfWJkYixjbj1jb25maWcAezJ9YmRiLGNuPWNvbmZpZw== objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: {0}rwm-suffixmassage "o=1" "dc=1" olcRwmTFSupport: false olcRwmNormalizeMapped: FALSE dn: olcDatabase={4}bdb,cn=config [...] 8<-------- When decoding DN, we obtain bad characters. This issue provide broken replication in a N-Way Multi-Master cluster. Thomas.

1 0

Re: Re (ITS#5843) N-way Multi-master doesn't replicate deletes under certain circumstances.
by ghenry＠suretecsystems.com 05 Feb '09

05 Feb '09

adrien.futschik(a)atosorigin.com wrote: > >> No. Replication is supposed to work regardless of mode, refreshOnly / >> refreshAndPersist should yield identical results. > ... > >> There is still a bug here. > > You mean that the fact that N-way Multi-master doesn't replicate deletes properly when using "refreshOnly" is a bug ? > > But N-way Multi-master seams to be working correctly when using "refreshAndPersist". I see some reasons why using "refreshOnly" instead of "refreshAndPersist", will this be corrected in the next release of OpenLDAP ? > > What is recommended with OpenLDAP 2.4.11. Should we wait for the next stable release if we intend to use N-way Multi-master in production ? I would wait for 2.4.14. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

1 0

Re: Docs: admin guide describes log levels inconsistently (ITS#5904)
by quanah＠zimbra.com 05 Feb '09

05 Feb '09

--On Thursday, February 05, 2009 11:41 AM +0000 ghenry(a)OpenLDAP.org wrote: > Awww, aren't we nice! ;-) > > Patch applied, The new patch is definitely an improvement, however it fails to document the hexadecimal notation for log levels, which is also perfectly valid. See slapd.conf(5): 1 (0x1 trace) trace function calls 2 (0x2 packets) debug packet handling 4 (0x4 args) heavy trace debugging (function args) and the description therein: The desired log level can be input as a single integer that combines the (ORed) desired levels, both in decimal or in hexadecimal notation, as a list of integers (that are ORed internally), or as a list of the names that are shown between brackets, such that loglevel 129 loglevel 0x81 loglevel 128 1 loglevel 0x80 0x1 loglevel acl trace are equivalent. -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5923) slapo-rwm may cause double frees when rewriting DN-valued attrs in search entry responses
by ando＠sys-net.it 05 Feb '09

05 Feb '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.6) Submitted by: ando A fix is coming (hopefully for 2.4.14 :). p.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2009