openldap-bugs

openldap-bugs@openldap.org

1 participants
20964 discussions

ITS#5375
by ecizaguirre＠gmv.com 14 Feb '08

14 Feb '08

Nice to know that, if you need any more information regarding this problem let me know. As soon as there is any patch or new version available I will test it and send you the results. Thanks and cheers. Eduardo. ________________________________ Eduardo Izaguirre Pazos Administrador de Sistemas / Systems Administrator GRUPO TECNOLÓGICO E INDUSTRIAL GMV,S.A. Isaac Newton, 11 P.T.M. Tres Cantos E-28760 Madrid Tel. +34 91 807 21 00 Fax +34 91 807 21 99 www.gmv.com ______________________ Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informacion clasificada por su emisor como confidencial en el marco de su Sistema de Gestion de Seguridad de la Informacion siendo para uso exclusivo del destinatario, quedando prohibida su divulgacion copia o distribucion a terceros sin la autorizacion expresa del remitente. Si Vd. ha recibido este mensaje erroneamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboracion. ______________________ This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. ______________________

1 0

Re: ITS#5375
by ando＠sys-net.it 14 Feb '08

14 Feb '08

.. in any case I think I located the original issue in modify_add_values() when permissive is set. I'll see if I can figure out a simple fix. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: ITS#5375
by ando＠sys-net.it 14 Feb '08

14 Feb '08

ecizaguirre(a)gmv.com wrote: > Assertion failed: ( nvals == NULL && (*a)->a_nvals == (*a)->a_vals ) || ( nvals != NULL && ( ( (*a)->a_vals == NULL && (*a)->a_nvals == NULL ) || ( (*a)->a_nvals != (*a)->a_vals ) ) ), file attr.c, line 480 > Program received signal SIGABRT, Aborted. > [Switching to LWP 4] > 0xfe2c12a4 in _lwp_kill () from /usr/lib/libc.so.1 > (gdb) bt > #0 0xfe2c12a4 in _lwp_kill () from /usr/lib/libc.so.1 > #1 0xfe25fe20 in raise () from /usr/lib/libc.so.1 > #2 0xfe240040 in abort () from /usr/lib/libc.so.1 > #3 0xfe24027c in _assert () from /usr/lib/libc.so.1 > #4 0x0005e104 in attr_merge (e=0xfcbfeaf0, desc=0x33a9b0, vals=0x3da650, nvals=0x3d8b08) at attr.c:477 > #5 0x000d3854 in modify_add_values (e=0xfcbfeaf0, mod=0xfcbfead0, permissive=1, text=0xfcbfeb24, textbuf=0xfcbfe9d0 "", > textlen=256) at mods.c:155 > #6 0x001be108 in rwm_attrs (op=0x3c1490, rs=0xfcbffc90, a_first=0x49bc00, stripEntryDN=1) at rwm.c:1232 > #7 0x001be3b0 in rwm_send_entry (op=0x3c1490, rs=0xfcbffc90) at rwm.c:1323 > #8 0x001be930 in rwm_response (op=0x3c1490, rs=0xfcbffc90) at rwm.c:1518 > #9 0x000f17dc in over_back_response (op=0x3c1490, rs=0xfcbffc90) at backover.c:241 #10 0x0006918c in slap_response_play (op=0x3c1490, rs=0xfcbffc90) at result.c:307 > #11 0x0006b3c4 in slap_send_search_entry (op=0x3c1490, rs=0xfcbffc90) at result.c:771 I have another concern: you don't need slapo-rwm(5) with slapd-meta(5), since it has internal rewrite capabilities. See slapd-meta(5). 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5378) hot slapcat for slapadd issues with delta-sync
by hyc＠symas.com 14 Feb '08

14 Feb '08

Pierangelo Masarati wrote: > hyc(a)OpenLDAP.org wrote: > >> Another possibility would be to filter out any entries whose entryCSNs are >> newer than the contextCSN in the LDIF before trying to slapadd it. > > Should slapadd take care of it (perhaps if instructed to do so)? Of course it might be better to change the delta-sync consumer to check the target's entryCSN after a modification fails, to see if it matches the current modification attempt. If so, then the failure can be safely ignored. -- -- Howard Chu Chief Architect, 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#5378) hot slapcat for slapadd issues with delta-sync
by hyc＠symas.com 14 Feb '08

14 Feb '08

Pierangelo Masarati wrote: > hyc(a)OpenLDAP.org wrote: > >> Another possibility would be to filter out any entries whose entryCSNs are >> newer than the contextCSN in the LDIF before trying to slapadd it. > > Should slapadd take care of it (perhaps if instructed to do so)? I guess that would be ok. It seems that doc/devel/toolargs isn't up to date now, dunno what option flag would make sense here. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

ITS#5375
by ecizaguirre＠gmv.com 14 Feb '08

14 Feb '08

This is a multi-part message in MIME format. ------_=_NextPart_001_01C86EFB.88B8168F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =20 Hi Pierangelo, I have configured slapd as a metadirectory against two Activ= e Directory servers. Our goal is to use it as the primary ldap network name= service for all of our Unix/Linux systems. The slapd config file is attach= ed with this mail. This problem only happens when a search is issued for a specific user entry= and all attributes of that entry are requested. I would send you all attri= butes of that entry if you need to check them. The analisys of the core file with gdb and following your instructions, giv= es us the followng results: (gdb) frame 4 #4 0x0005e104 in attr_merge (e=3D0xfd3feaf0, desc=3D0x33a9b0, vals=3D0x3db= 1b0, nvals=3D0x3d96b0) at attr.c:477 477 assert( ( nvals =3D=3D NULL && (*a)->a_nvals =3D=3D= (*a)->a_vals ) (gdb) p nvals $1 =3D (BerVarray) 0x3d96b0 (gdb) p (*a)->a_nvals $2 =3D (BerVarray) 0x3daef8 (gdb) p (*a)->a_vals $3 =3D (BerVarray) 0x3daef8 (gdb) p vals[0] $4 =3D {bv_len =3D 5, bv_val =3D 0x3d9020 "10001"} (gdb) p nvals[0] $5 =3D {bv_len =3D 5, bv_val =3D 0x3d9020 "10001"} (gdb) p (*a)->a_vals[0] $6 =3D {bv_len =3D 2, bv_val =3D 0x3d8f70 "10"} (gdb) p (*a)->a_nvals[0] $7 =3D {bv_len =3D 2, bv_val =3D 0x3d8f70 "10"} (gdb) p (*a)->a_desc[0] $8 =3D {ad_next =3D 0x0, ad_type =3D 0x33bbc8, ad_cname =3D {bv_len =3D 9, = bv_val =3D 0x33b550 "gidNumber"}, ad_tags =3D {bv_len =3D 0, bv_val =3D 0x0}, ad_flags =3D 0} (gdb) p (*a)->a_numvals $9 =3D 1 (gdb) p (*a)->a_flags $10 =3D 0 If you need more information don't hesitate in contact me. Thanks and cheers. Eduardo. ________________________________ Eduardo Izaguirre Pazos Administrador de Sistemas / Systems Administrator =20=09=20 GRUPO TECNOL=D3GICO E INDUSTRIAL GMV,S.A. Isaac Newton, 11 P.T.M. Tres Cantos E-28760 Madrid Tel. +34 91 807 21 00 Fax +34 91 807 21 99 www.gmv.com =09 ______________________ Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informacion clasificada por su emisor como confidencial en el marco de su Sistema de Gestion de Seguridad de la=20 Informacion siendo para uso exclusivo del destinatario, quedando=20 prohibida su divulgacion copia o distribucion a terceros sin la=20 autorizacion expresa del remitente. Si Vd. ha recibido este mensaje=20 erroneamente, se ruega lo notifique al remitente y proceda a su borrado.= =20 Gracias por su colaboracion. ______________________ This message including any attachments may contain confidential=20 information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. ______________________ ------_=_NextPart_001_01C86EFB.88B8168F Content-Type: application/octet-stream; name="slapd.conf" Content-Transfer-Encoding: base64 Content-Description: slapd.conf Content-Disposition: attachment; filename="slapd.conf" Iw0KIyBTZWUgc2xhcGQuY29uZig1KSBmb3IgZGV0YWlscyBvbiBjb25maWd1 cmF0aW9uIG9wdGlvbnMuDQojIFRoaXMgZmlsZSBzaG91bGQgTk9UIGJlIHdv cmxkIHJlYWRhYmxlLg0KIw0KIyMjIEZpY2hlcm8gZGUgc2NoZW1hIGJhc2lj byBkZSBPcGVuTERBUC4NCmluY2x1ZGUgICAgICAgICAvb3B0L29wZW5sZGFw LTIuMy4zOC9ldGMvb3BlbmxkYXAvc2NoZW1hL2NvcmUuc2NoZW1hDQojIyMg RGVmaW5pY2lvbmVzIGluY2x1aWRhcyBjb24gT3BlbkxEQVAuIEVzIGltcG9y dGFudGUgdXNhciBlbCBvcmRlbiBkYWRvIHlhDQojIyMgcXVlIGhheSBhdHJp YnV0b3MgZGVmaW5pZG9zIGVuIHVuIHNjaGVtYSBxdWUgc2UgdXNhbiBlbiBs b3Mgc2lndWllbnRlcy4NCmluY2x1ZGUgICAgICAgICAvb3B0L29wZW5sZGFw LTIuMy4zOC9ldGMvb3BlbmxkYXAvc2NoZW1hL2Nvc2luZS5zY2hlbWENCmlu Y2x1ZGUgICAgICAgICAvb3B0L29wZW5sZGFwLTIuMy4zOC9ldGMvb3Blbmxk YXAvc2NoZW1hL2luZXRvcmdwZXJzb24uc2NoZW1hDQojIyMgRGVmaW5pY2lv biBkZSBhdHJpYnV0b3MgZGUgQWN0aXZlIERpcmVjdG9yeS4NCmluY2x1ZGUg ICAgICAgICAvb3B0L29wZW5sZGFwLTIuMy4zOC9ldGMvb3BlbmxkYXAvc2No ZW1hL0FELnNjaGVtYQ0KIyMjIERlZmluaWNpb24gaW5jbHVpZGEgY29uIE9w ZW5MREFQIHBhcmEgdXNhciBMREFQIGNvbW8gc2VydmljaW8gTklTLg0KaW5j bHVkZSAgICAgICAgIC9vcHQvb3BlbmxkYXAtMi4zLjM4L2V0Yy9vcGVubGRh cC9zY2hlbWEvbmlzLnNjaGVtYQ0KIyMjIERlZmluaWNpb24gZGUgYXRyaWJ1 dG9zIHkgb2JqZXRvcyBkZSBHcnVwbyBHTVYuDQppbmNsdWRlICAgICAgICAg L29wdC9vcGVubGRhcC0yLjMuMzgvZXRjL29wZW5sZGFwL3NjaGVtYS9sb2Nh bC5zY2hlbWENCiMjIyBEZWZpbmljaW9uIGRlIGF0cmlidXRvcyB5IG9iamV0 b3MgZGUgc2FtYmEuDQppbmNsdWRlICAgICAgICAgL29wdC9vcGVubGRhcC0y LjMuMzgvZXRjL29wZW5sZGFwL3NjaGVtYS9zYW1iYS5zY2hlbWENCg0KIyBE ZWZpbmUgZ2xvYmFsIEFDTHMgdG8gZGlzYWJsZSBkZWZhdWx0IHJlYWQgYWNj ZXNzLg0KDQpwaWRmaWxlCQkvb3B0L29wZW5sZGFwLTIuMy4zOC92YXIvcnVu L3NsYXBkLnBpZA0KYXJnc2ZpbGUJL29wdC9vcGVubGRhcC0yLjMuMzgvdmFy L3J1bi9zbGFwZC5hcmdzDQoNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj DQojDQojIERlZmluaWNpb24gZGUgdW5hIGJhc2UgZGUgZGF0b3MgTWV0YWRp cmVjdG9yaW8gcGFyYSBjb25zdWx0YXMgYSBBRC4NCiMNCiMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjDQpiYWNrZW5kCQltZXRhDQpkYXRhYmFzZQltZXRh DQoNCiMjIFN1ZmlqbyBkZWwgYXJib2wgbW9zdHJhZG8gcG9yIGVsIG1ldGFk aXJlY3RvcmlvIHkgdXN1YXJpbw0KIyMgYWRtaW5pc3RyYWRvciBkZWwgbWlz bW8oc3VwZXJ1c3VhcmlvIGRlIGxkYXApLg0Kc3VmZml4CQkiZGM9Z212LGRj PWVzIg0Kcm9vdGRuCQkiY249ZGlyYWRtaW4sZGM9Z212LGRjPWVzIg0KIyMg UGFzc3dvcmQgZGVsIHN1cGVydXN1YXJpbywgcGFzYXIgYSB0ZXh0byBjaWZy YWRvIGNvbiBzbGFwcGFzc3dkLiANCnJvb3RwdwkJKioqKioqDQoNCiMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMNCiMj IyBPcGNpb25lcyBjb211bmVzIGEgdG9kbyBlbCBtZXRhZGlyZWN0b3Jpby4N CiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj DQojIyMjIERpcmVjdGl2YXMgY29tdW5lcyBkZSBjb25maWd1cmFjaW9uLg0K IyMgVFRMIHBhcmEgdGlyYXIgdW5hIGNvbmV4aW9uLCBhdW5xdWUgbm8gZXN0 ZSBpbmFjdGl2YS4NCmNvbm4tdHRsIDYwDQojIyBWZXJzaW9uIGRlbCBwcm90 b2NvbG8gTERBUCBhIHV0aWxpemFyLg0KcHJvdG9jb2wtdmVyc2lvbiAzDQoj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMNCiMjIyBEZWZpbmljaW9uIGRlbCBM REFQIHJlbW90byBwYXJhIGxhcyBjb25zdWx0YXMgZGUgaW5mb3JtYWNpb24g ZGUNCiMjIyB1c3VhcmlvIHkgZ3J1cG9zIFVOSVggZGVzZGUgbWFxdWluYXMg cXVlIHNvbiBjbGllbnRlcyBMREFQLg0KIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjDQojIyBEZWZpbmljaW9uIGRlIGxvcyBzZXJ2aWRvcmVzIHRhcmdldCBy ZW1vdG9zIGEgY29uc3VsdGFyLg0KIyMgU2UgY29uc3VsdGFyYSBlbCBwcmlt ZXIgc2Vydmlkb3IgcmVtb3RvIHF1ZSByZXNwb25kYS4NCiMjIERlZmlubyB1 bmEgbGlzdGEgZGUgZGNzIHF1ZSBwdWVkZW4gcmVzcG9uZGVyIHBhcmEgZWwg Y29udGV4dG8gZGUgDQojIyBub21icmUgZGM9Z212LGRjPWVzLiBQcmltZXIg dGFyZ2V0IGNvbiBzdXMgcGFyYW1ldHJvcyBkZSBjb25maWd1cmFjaW9uLg0K dXJpICJsZGFwOi8vZ212ZGMxLmdtdi5lcy9EQz1nbXYsREM9ZXMJbGRhcDov L2dtdmRjMi5nbXYuZXMvIg0KIyMgSGFiaWxpdGFtb3MgZWwgc2lzdGVtYSBk ZSByZWVzY3JpdHVyYSBwYXJhIGxhcyBjb25zdWx0YXMuDQpyZXdyaXRlRW5n aW5lIG9uDQpvdmVybGF5IHJ3bQ0KIyMgQWNjaW9uIGFudGUgdW4gcmVmZXJy YWwuDQpjaGFzZS1yZWZlcnJhbHMgbm8NCiMjIFRUTCBwYXJhIHRpcmFyIHVu YSBjb25leGlvbiBpbmFjdGl2YSAoMSBob3JhKS4NCmlkbGUtdGltZW91dCAw MTAwDQojIyBQc2V1ZG9yb290IEROLg0KI3BzZXVkb3Jvb3RkbiAiQ049QWRt aW5pc3RyYWRvcixDTj1Vc2VycyxEQz1nbXYsREM9ZXMiDQojcHNldWRvcm9v dHB3IGVjZWwraTINCiNpZGFzc2VydC1hdXRoekZyb20gIkNOPUFkbWluaXN0 cmFkb3IsQ049VXNlcnMsREM9Z212LERDPWVzIg0KI2lkYXNzZXJ0LWJpbmQg ZWNlbCtpMg0KcHNldWRvcm9vdGRuICJDTj1wcm94eW1ldGFkaXIsT1U9U0lT VEVNQVMsT1U9VXN1YXJpb3MsREM9Z212LERDPWVzIg0KcHNldWRvcm9vdHB3 ICoqKioqKg0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIw0KIyBEZWZpbmljaW9uIGRlIGxhcyByZWdsYXMgZGUgcmVl c2NyaXR1cmEgYSB1dGlsaXphciBwYXJhIGxvcyBEQ3MuDQojIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjDQojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQojIyBSZWds YXMgZGUgcmVlc2NyaXR1cmEgcGFyYSBidXNjYXIgaW5mb3JtYWNpb24gZW4g bG9zIERDcy4NCiMjIFByaW1lcm8gc2UgY2FtYmlhIGVsIHN1ZmlqbyBkZWwg YXJib2wgcGFyYSBidXNjYXIgZ3J1cG9zLg0KcndtLXN1ZmZpeG1hc3NhZ2Ug Im91PWdyb3VwLGRjPWdtdixkYz1lcyIgIk9VPVByb3llY3RvcyxPVT1HcnVw b3MsREM9Z212LERDPWVzIg0KIyMgQWhvcmEgc2UgbW9kaWZpY2EgcGFyYSBi dXNjYXIgbGFzIGN1ZW50YXMgZGUgdXN1YXJpby4NCnJ3bS1zdWZmaXhtYXNz YWdlICJvdT1wZW9wbGUsZGM9Z212LGRjPWVzIiAiT1U9VXN1YXJpb3MsREM9 Z212LERDPWVzIg0KIyMgUmVnbGEgZGUgcmVlc2NyaXR1cmEgcGFyYSBlbCBE TiBkZSBsb3MgZ3J1cG9zLg0KIyMgVGVvcmljYW1lbnRlIHNvbG8gZGViZXJp YSBhcGxpY2Fyc2UgYSBsb3MgcmVzdWx0YWRvcyBkZXZ1ZWx0b3MNCiMjIGEg bG9zIGNsaWVudGVzIGRlbCBzZXJ2aWRvci4NCnJ3bS1yZXdyaXRlQ29udGV4 dCBzZWFyY2hFbnRyeURODQpyd20tcmV3cml0ZVJ1bGUgIiguKyk/X3Byaixv dT1Hcm91cCxkYz1nbXYsZGM9ZXMiICIkMSxvdT1Hcm91cCxkYz1nbXYsZGM9 ZXMiDQojIyBBaG9yYSB2aWVuZW4gbGFzIHJlZ2xhcyBkZSByZWVzY3JpdHVy YSBkZSBsb3MgYXRyaWJ1dG9zIHkgbGFzDQojIyBjbGFzZXMgZGUgb2JqZXRv IGRlIGN1ZW50YXMgZGUgdXN1YXJpbyB5IGdydXBvIFVOSVguDQpyd20tbWFw IG9iamVjdENsYXNzIHBvc2l4QWNjb3VudCB1c2VyDQpyd20tbWFwIG9iamVj dENsYXNzIHNoYWRvd0FjY291bnQgcGVyc29uDQpyd20tbWFwIG9iamVjdENs YXNzIHBvc2l4R3JvdXAgZ3JvdXANCiMjDQojIyBEZWZpbmljaW9uIGRlIGF0 cmlidXRvcyBhIG1hcGVhciBjb24gTVMgU0ZVIDMuMC4NCiMjDQpyd20tbWFw IGF0dHJpYnV0ZSBnZWNvcyBtc1NGVTMwR2Vjb3MNCnJ3bS1tYXAgYXR0cmli dXRlIGhvbWVEaXJlY3RvcnkgbXNTRlUzMEhvbWVEaXJlY3RvcnkNCnJ3bS1t YXAgYXR0cmlidXRlIHVpZE51bWJlciBtc1NGVTMwVWlkTnVtYmVyDQpyd20t bWFwIGF0dHJpYnV0ZSBsb2dpblNoZWxsIG1zU0ZVMzBMb2dpblNoZWxsDQpy d20tbWFwIGF0dHJpYnV0ZSBnaWROdW1iZXIgbXNTRlUzMEdpZE51bWJlcg0K cndtLW1hcCBhdHRyaWJ1dGUgbWVtYmVyVWlkIG1zU0ZVMzBNZW1iZXJVaWQN CnJ3bS1tYXAgYXR0cmlidXRlIFNoYWRvd0ZsYWcgbXNTRlUzMFNoYWRvd0Zs YWcNCnJ3bS1tYXAgYXR0cmlidXRlIFNoYWRvd0V4cGlyZSBtc1NGVTMwU2hh ZG93RXhwaXJlDQpyd20tbWFwIGF0dHJpYnV0ZSBTaGFkb3dJbmFjdGl2ZSBt c1NGVTMwU2hhZG93SW5hY3RpdmUNCnJ3bS1tYXAgYXR0cmlidXRlIFNoYWRv d01heCBtc1NGVTMwU2hhZG93TWF4DQpyd20tbWFwIGF0dHJpYnV0ZSBTaGFk b3dXYXJuaW5nIG1zU0ZVMzBTaGFkb3dXYXJuaW5nDQpyd20tbWFwIGF0dHJp YnV0ZSBTaGFkb3dMYXN0Q2hhbmdlIG1zU0ZVMzBTaGFkb3dMYXN0Q2hhbmdl DQpyd20tbWFwIGF0dHJpYnV0ZSBTaGFkb3dNaW4gbXNTRlUzMFNoYWRvd01p bg0KIyMjIENvbW8gaGF5IGRvcyBhdHJpYnV0b3MgaWd1YWxlcyBwYXJhIGxv cyB1c3VhcmlvcyB5IHBhcmENCiMjIyBsb3MgZ3J1cG9zIGhhcmVtb3MgZXN0 YSBkaXN0aW5jaW9uIGVudHJlIHVub3MgeSBvdHJvcw0KIyMjIHBhcmEgcmVh bGl6YXIgZWwgbWFwZW8gZW50cmUgbG9zIGRvcy4NCiMjIExvcyBncnVwb3Mg c2UgaWRlbnRpZmljYW4gcG9yIGNuLg0KcndtLW1hcCBhdHRyaWJ1dGUgY24g bXNTRlUzME5hbWUNCiMjIExvcyB1c3VhcmlvcyBzZSBpZGVudGlmaWNhbiBw b3IgdWlkLg0KcndtLW1hcCBhdHRyaWJ1dGUgdWlkIHNBTUFjY291bnROYW1l DQojIyBFbCByZXN0byBkZSBhdHJpYnV0b3Mgbm8gbG9zIHF1aWVybyBwYXJh IG5hZGEgYXNpIHF1ZSBtZSBsb3MNCiMjIGNhcmdvIGNvbiBsb3Mgc2lndWll bnRlcyBtYXBlb3MuDQpyd20tbWFwIGF0dHJpYnV0ZSBEU0NPUkVQUk9QQUdB VElPTkRBVEENCnJ3bS1tYXAgYXR0cmlidXRlIFNIT1dJTkFERFJFU1NCT09L DQpyd20tbWFwIGF0dHJpYnV0ZSBNU0VYQ0hIT01FU0VSVkVSTkFNRQ0Kcndt LW1hcCBhdHRyaWJ1dGUgTVNFWENIQUxPQkpFQ1RWRVJTSU9ODQpyd20tbWFw IGF0dHJpYnV0ZSBNU0VYQ0hNQUlMQk9YU0VDVVJJVFlERVNDUklQVE9SDQpy d20tbWFwIGF0dHJpYnV0ZSBNU0VYQ0hVU0VSQUNDT1VOVENPTlRST0wNCnJ3 bS1tYXAgYXR0cmlidXRlIE1TRVhDSE1BSUxCT1hHVUlEDQpyd20tbWFwIGF0 dHJpYnV0ZSBQUk9YWUFERFJFU1NFUw0KcndtLW1hcCBhdHRyaWJ1dGUgTUVN QkVST0YNCnJ3bS1tYXAgYXR0cmlidXRlIEhPTUVNVEENCnJ3bS1tYXAgYXR0 cmlidXRlIEhPTUVNREINCnJ3bS1tYXAgYXR0cmlidXRlIFVTRVJBQ0NPVU5U Q09OVFJPTA0KcndtLW1hcCBhdHRyaWJ1dGUgbWFuYWdlcg0KcndtLW1hcCBh dHRyaWJ1dGUgTEVHQUNZRVhDSEFOR0VETg0KcndtLW1hcCBhdHRyaWJ1dGUg QkFEUFdEQ09VTlQNCnJ3bS1tYXAgYXR0cmlidXRlIEJBRFBBU1NXT1JEVElN RQ0KcndtLW1hcCBhdHRyaWJ1dGUgTEFTVExPR09GRg0KcndtLW1hcCBhdHRy aWJ1dGUgTEFTVExPR09ODQpyd20tbWFwIGF0dHJpYnV0ZSBVU0VSV09SS1NU QVRJT05TDQpyd20tbWFwIGF0dHJpYnV0ZSBQV0RMQVNUU0VUDQpyd20tbWFw IGF0dHJpYnV0ZSBPQkpFQ1RTSUQNCnJ3bS1tYXAgYXR0cmlidXRlIEFETUlO Q09VTlQNCnJ3bS1tYXAgYXR0cmlidXRlIEFDQ09VTlRFWFBJUkVTDQpyd20t bWFwIGF0dHJpYnV0ZSBMT0dPTkNPVU5UDQpyd20tbWFwIGF0dHJpYnV0ZSBE SVJFQ1RSRVBPUlRTDQpyd20tbWFwIGF0dHJpYnV0ZSBVU05DUkVBVEVEDQpy d20tbWFwIGF0dHJpYnV0ZSBVU05DSEFOR0VEDQpyd20tbWFwIGF0dHJpYnV0 ZSBDT0RFUEFHRQ0KcndtLW1hcCBhdHRyaWJ1dGUgT0JKRUNUR1VJRA0Kcndt LW1hcCBhdHRyaWJ1dGUgTURCVVNFREVGQVVMVFMNCnJ3bS1tYXAgYXR0cmli dXRlIHRpdGxlDQpyd20tbWFwIGF0dHJpYnV0ZSBwaHlzaWNhbERlbGl2ZXJ5 T2ZmaWNlTmFtZQ0KcndtLW1hcCBhdHRyaWJ1dGUgb2JqZWN0Q2F0ZWdvcnkN CnJ3bS1tYXAgYXR0cmlidXRlIExBU1RMT0dPTlRJTUVTVEFNUA0KcndtLW1h cCBhdHRyaWJ1dGUgTVNFWENIUE9MSUNJRVNJTkNMVURFRA0KcndtLW1hcCBh dHRyaWJ1dGUgTVNSVENTSVAtUFJJTUFSWUhPTUVTRVJWRVINCnJ3bS1tYXAg YXR0cmlidXRlIE1TUlRDU0lQLVBSSU1BUllVU0VSQUREUkVTUw0KcndtLW1h cCBhdHRyaWJ1dGUgTVNSVENTSVAtRkVERVJBVElPTkVOQUJMRUQNCnJ3bS1t YXAgYXR0cmlidXRlIE1TUlRDU0lQLU9QVElPTkZMQUdTDQpyd20tbWFwIGF0 dHJpYnV0ZSBzdHJlZXQNCnJ3bS1tYXAgYXR0cmlidXRlIGpwZWdQaG90bw0K cndtLW1hcCBhdHRyaWJ1dGUgVVNFUlBBUkFNRVRFUlMNCg0KIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjDQojIyMgRGVmaW5pY2lvbiBkZWwgTERBUCBsb2Nh bCBwYXJhIGxhcyBjb25zdWx0YXMgZGUgaW5mb3JtYWNpb24gZGUNCiMjIyBt YXBhcyBkZSBhdXRvbW91bnQsIHBlcmZpbGVzIGRlIGluaWNpYWxpemFjaW9u IGRlIGNsaWVudGVzIFNvbGFyaXMNCiMjIyB5IGxvcyBuZXRncm91cHMuDQoj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMNCiMjIEFob3JhIGRlZmlubyBlbCBs ZGFwIHF1ZSBjb250aWVuZSBsb3MgbWFwYXMgZGUgYXV0b2ZzDQojIyBhc2kg Y29tbyBsb3MgcGVyZmlsZXMgcGFyYSBsb3MgY2xpZW50ZXMgTERBUCBTb2xh cmlzLg0KIyMgRGUgbW9tZW50byBoYWdvIGxhIHBydWViYSBlbiBsb2NhbC4N CnVyaSAibGRhcDovLzE3Mi4yMi40LjM0OjM5MC9kYz1nbXYsZGM9ZXMiDQoj IyBIYWJpbGl0YW1vcyBlbCBzaXN0ZW1hIGRlIHJlZXNjcml0dXJhIHBhcmEg bGFzIGNvbnN1bHRhcy4NCnJld3JpdGVFbmdpbmUgb24NCiNvdmVybGF5IHJ3 bQ0KIyMgQWNjaW9uIGFudGUgdW4gcmVmZXJyYWwuDQpjaGFzZS1yZWZlcnJh bHMgbm8NCiMjIFRUTCBwYXJhIHRpcmFyIHVuYSBjb25leGlvbiBpbmFjdGl2 YSAoMSBob3JhKS4NCmlkbGUtdGltZW91dCAwMTAwDQojIyBQc2V1ZG9yb290 IEROLg0KcHNldWRvcm9vdGRuICJDTj1wcm94eW1ldGFkaXIsT1U9U0lTVEVN QVMsT1U9VXN1YXJpb3MsREM9Z212LERDPWVzIg0KcHNldWRvcm9vdHB3ICoq KioqKg0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQojIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMNCiMgRGVmaW5pY2lvbiBkZSBsYXMgcmVnbGFz IGRlIHJlZXNjcml0dXJhIGEgdXRpbGl6YXIgcGFyYSBlbCBMREFQIGxvY2Fs Lg0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQojIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMNCiMjIEFob3JhIGxhcyByZWdsYXMgZGUgcmVlc2Ny aXR1cmEgZGVsIHNlcnZpZG9yIExEQVAgcXVlIGNvbnRpZW5lDQojIyBsb3Mg bWFwYXMgZGUgYXV0b21vdW50IGFzaSBjb21vIGxvcyBwZXJmaWxlcyBkZSBT b2xhcmlzIHkgbG9zDQojIyBuZXRncm91cHMgZGUgVW5peC4NCnJ3bS1zdWZm aXhtYXNzYWdlICJvdT1Qcm9maWxlLGRjPWdtdixkYz1lcyIgIm91PVByb2Zp bGUsb3U9VW5peCxkYz1nbXYsZGM9ZXMiDQpyd20tc3VmZml4bWFzc2FnZSAi b3U9QXV0b21vdW50LGRjPWdtdixkYz1lcyIgIm91PUF1dG9tb3VudCxvdT1V bml4LGRjPWdtdixkYz1lcyINCnJ3bS1zdWZmaXhtYXNzYWdlICJvdT1uZXRn cm91cCxkYz1nbXYsZGM9ZXMiICJvdT1OZXRncm91cCxvdT1Vbml4LGRjPWdt dixkYz1lcyINCnJ3bS1zdWZmaXhtYXNzYWdlICJhdXRvbW91bnRtYXBuYW1l PWF1dG9faG9tZSxkYz1nbXYsZGM9ZXMiICJhdXRvbW91bnRtYXBuYW1lPWF1 dG9faG9tZSxvdT1Vbml4LGRjPWdtdixkYz1lcyINCnJ3bS1zdWZmaXhtYXNz YWdlICJhdXRvbW91bnRtYXBuYW1lPWF1dG9fbWFzdGVyLGRjPWdtdixkYz1l cyIgImF1dG9tb3VudG1hcG5hbWU9YXV0b19tYXN0ZXIsb3U9VW5peCxkYz1n bXYsZGM9ZXMiDQpyd20tc3VmZml4bWFzc2FnZSAiYXV0b21vdW50bWFwbmFt ZT1hdXRvX2RpcmVjdCxkYz1nbXYsZGM9ZXMiICJhdXRvbW91bnRtYXBuYW1l PWF1dG9fZGlyZWN0LG91PVVuaXgsZGM9Z212LGRjPWVzIg0KcndtLW1hcCBv YmplY3RDbGFzcyBuaXNPYmplY3QgbmlzT2JqZWN0DQpyd20tbWFwIG9iamVj dENsYXNzIG5pc05ldGdyb3VwIG5pc05ldGdyb3VwDQpyd20tbWFwIG9iamVj dENsYXNzIGF1dG9tb3VudE1hcCBhdXRvbW91bnRNYXANCnJ3bS1tYXAgb2Jq ZWN0Q2xhc3MgYXV0b21vdW50IGF1dG9tb3VudA0KcndtLW1hcCBhdHRyaWJ1 dGUgbWVtYmVyTmlzTmV0Z3JvdXAgbWVtYmVyTmlzTmV0Z3JvdXANCnJ3bS1t YXAgYXR0cmlidXRlIGF1dG9tb3VudE1hcE5hbWUgYXV0b21vdW50TWFwTmFt ZQ0KcndtLW1hcCBhdHRyaWJ1dGUgYXV0b21vdW50S2V5IGF1dG9tb3VudEtl eQ0KcndtLW1hcCBhdHRyaWJ1dGUgbmlzTmV0Z3JvdXBUcmlwbGUgbmlzTmV0 Z3JvdXBUcmlwbGUNCg0K ------_=_NextPart_001_01C86EFB.88B8168F--

1 0

(ITS#5379) Undefined reference when --without-tls
by hyc＠OpenLDAP.org 14 Feb '08

14 Feb '08

Full_Name: Howard Chu Version: RE24/HEAD OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc slapd/config.c references ldap_pvt_tls_get_option outside of #ifdef HAVE_TLS

1 0

Re: (ITS#5378) hot slapcat for slapadd issues with delta-sync
by ando＠sys-net.it 14 Feb '08

14 Feb '08

hyc(a)OpenLDAP.org wrote: > Another possibility would be to filter out any entries whose entryCSNs are > newer than the contextCSN in the LDIF before trying to slapadd it. Should slapadd take care of it (perhaps if instructed to do so)? 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: ITS#5375
by ando＠sys-net.it 14 Feb '08

14 Feb '08

ecizaguirre(a)gmv.com wrote: > Hi Quanah, I have followed your instructions. As you can check the slapd binary is not stripped: > > -bash-3.00# file slapd > > slapd: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped > > The backtrace of the slapd process is the following: > > <<< dnPretty: <cn=Eduardo Izaguirre Pazos,ou=SISTEMAS,ou=people,dc=gmv,dc=es> > > Assertion failed: ( nvals == NULL && (*a)->a_nvals == (*a)->a_vals ) || ( nvals != NULL && ( ( (*a)->a_vals == NULL && (*a)->a_nvals == NULL ) || ( (*a)->a_nvals != (*a)->a_vals ) ) ), file attr.c, line 480 ^^^ this is very interesting, as it's supposed to never happen. In order to try to figure out what is actually happening, I need your configuration and the exact operation that triggered this issue. In the meanwhile, you could probably post the contents of the variables used in that assert. For this purpose, from within gdb, you should: (gdb) frame 4 (gdb) p nvals (gdb) p (*a)->a_vals (gdb) p (*a)->a_nvals unless any of the above is NULL, you should also print its contents up to the first value of the array, namely (gdb) p vals[0] (gdb) p nvals[0] (gdb) p (*a)->a_vals[0] (gdb) p (*a)->a_nvals[0] If any of the above contains info that you consider sensible, do not post it; only tell whether the value is present or NULL (note: by NULL I mean the corresponding struct berval has a NULL bv_val member) Also, please do (gdb) p (*a)->a_desc[0] (gdb) p (*a)->a_numvals (gdb) p (*a)->a_flags > Program received signal SIGABRT, Aborted. > [Switching to LWP 4] > 0xfe2c12a4 in _lwp_kill () from /usr/lib/libc.so.1 > (gdb) bt > #0 0xfe2c12a4 in _lwp_kill () from /usr/lib/libc.so.1 > #1 0xfe25fe20 in raise () from /usr/lib/libc.so.1 > #2 0xfe240040 in abort () from /usr/lib/libc.so.1 > #3 0xfe24027c in _assert () from /usr/lib/libc.so.1 > #4 0x0005e104 in attr_merge (e=0xfcbfeaf0, desc=0x33a9b0, vals=0x3da650, nvals=0x3d8b08) at attr.c:477 > #5 0x000d3854 in modify_add_values (e=0xfcbfeaf0, mod=0xfcbfead0, permissive=1, text=0xfcbfeb24, textbuf=0xfcbfe9d0 "", > textlen=256) at mods.c:155 > #6 0x001be108 in rwm_attrs (op=0x3c1490, rs=0xfcbffc90, a_first=0x49bc00, stripEntryDN=1) at rwm.c:1232 > #7 0x001be3b0 in rwm_send_entry (op=0x3c1490, rs=0xfcbffc90) at rwm.c:1323 > #8 0x001be930 in rwm_response (op=0x3c1490, rs=0xfcbffc90) at rwm.c:1518 > #9 0x000f17dc in over_back_response (op=0x3c1490, rs=0xfcbffc90) at backover.c:241 #10 0x0006918c in slap_response_play (op=0x3c1490, rs=0xfcbffc90) at result.c:307 > #11 0x0006b3c4 in slap_send_search_entry (op=0x3c1490, rs=0xfcbffc90) at result.c:771 > #12 0x00135aa0 in meta_send_entry (op=0x3c1490, rs=0xfcbffc90, mc=0x3c18f8, target=0, e=0x4d9320) at search.c:2071 > #13 0x00132a40 in meta_back_search (op=0x3c1490, rs=0xfcbffc90) at search.c:1128 > #14 0x000f2668 in overlay_op_walk (op=0x3c1490, rs=0xfcbffc90, which=op_search, oi=0x35ef80, on=0x0) at backover.c:652 > #15 0x000f2874 in over_op_func (op=0x3c1490, rs=0xfcbffc90, which=op_search) at backover.c:704 > #16 0x000f2924 in over_op_search (op=0x3c1490, rs=0xfcbffc90) at backover.c:726 > #17 0x00053adc in fe_op_search (op=0x3c1490, rs=0xfcbffc90) at search.c:368 > #18 0x00053294 in do_search (op=0x3c1490, rs=0xfcbffc90) at search.c:217 > #19 0x0004f4f8 in connection_operation (ctx=0xfcbffe00, arg_v=0x3c1490) at connection.c:1083 #20 0x0004fc30 in connection_read_thread (ctx=0xfcbffe00, argv=0xb) at connection.c:1210 > #21 0x001f58d8 in ldap_int_thread_pool_wrapper (xpool=0x33cdb0) at tpool.c:625 > #22 0xfe2c00b8 in _lwp_start () from /usr/lib/libc.so.1 > #23 0xfe2c00b8 in _lwp_start () from /usr/lib/libc.so.1 Backtrace stopped: previous frame identical to this frame (corrupt stack?) 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5378) hot slapcat for slapadd issues with delta-sync
by hyc＠OpenLDAP.org 14 Feb '08

14 Feb '08

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.40 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.23.156.219) > > > If someone is using delta-syncrepl for replication, and does a hot slapcat of a > server, and a change occurs during the slapcat, the resulting LDIF file cannot > be used on a replica. This is because the replica will try to resume from the > CSN in the LDIF file, which is from before the change occurred. Since the > change is in the LDIF file, when the replica contacts the master, it tries to > re-replicate the change (which obviously fails). At that point, the replica is > stuck and unable to progress. The only guaranteed way to get a viable slapcat > when using delta-syncrepl is to put the server being dumped into RO mode or to > stop it. Another possibility would be to filter out any entries whose entryCSNs are newer than the contextCSN in the LDIF before trying to slapadd it. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs