- openldap-bugs - openldap.org

(ITS#4821) test043 cores; apparently incorrect resource usage
by ando＠sys-net.it 27 Jan '07

27 Jan '07

Full_Name: Pierangelo Masarati Version: HEAD OS: Linux 2.6 (CentOS 4.4) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.28.220.33) Submitted by: ando test43 results in a couple of core dumps. The first occurs to the producer. Valgrind is showing ==1654== Invalid read of size 4 ==1654== at 0x8148BC3: bdb_locker_id_free (cache.c:1360) ==1654== by 0x81E5F7A: ldap_pvt_thread_pool_context_reset (tpool.c:903) ==1654== by 0x80B48EF: slap_destroy (init.c:275) ==1654== by 0x8062E2B: main (main.c:954) ==1654== Address 0x4ED36A0 is 520 bytes inside a block of size 680 free'd ==1654== at 0x4004EFA: free (vg_replace_malloc.c:235) ==1654== by 0x8217E09: ber_memfree_x (memory.c:149) ==1654== by 0x8217E6D: ber_memfree (memory.c:162) ==1654== by 0x58E09E: __os_free (in /lib/tls/i686/libdb-4.2.so) ==1654== by 0x56D6E6: __dbenv_close (in /lib/tls/i686/libdb-4.2.so) ==1654== by 0x56D816: __dbenv_close_pp (in /lib/tls/i686/libdb-4.2.so) ==1654== by 0x80FE3D8: bdb_db_close (init.c:512) ==1654== by 0x80F1430: over_db_close (backover.c:195) ==1654== by 0x808D7A4: backend_shutdown (backend.c:352) ==1654== by 0x80B4846: slap_shutdown (init.c:258) ==1654== by 0x8062E0A: main (main.c:947) bdb_locker_id_free() is passed to ldap_pvt_thread_pool_setkey() as cleanup function, but apparently the keys are cleaned up __after__ the key (the db env) has already been destroyed (in bdb_do_close()). The second core occurs again in the producer, since the test doesn't realize it cored and thus tries to restart it, according to the test pattern. Valgrind in this case only reports slapd: schema_check.c:87: entry_schema_check: Assertion `a->a_vals[0].bv_val != ((void *)0)' failed. If the same problem is reproduced without valgrind (the vgcore appears to be screwed), a NULL attribute seems to be left 'round: (gdb) bt #0 0x003957a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x003d57a5 in raise () from /lib/tls/libc.so.6 #2 0x003d7209 in abort () from /lib/tls/libc.so.6 #3 0x003ced91 in __assert_fail () from /lib/tls/libc.so.6 #4 0x080bc142 in entry_schema_check (op=0xb6f10760, e=0x8a606dc, oldattrs=0x0, manage=0, add_soc=1, text=0xb6f10738, textbuf=0xb6f1040c "��@", textlen=256) at schema_check.c:87 #5 0x08144565 in bdb_add (op=0xb6f10760, rs=0xb6f10724) at add.c:97 #6 0x080f1c30 in overlay_op_walk (op=0xb6f10760, rs=0xb6f10724, which=op_add, oi=0x89e5968, on=0x0) at backover.c:507 #7 0x080f1de5 in over_op_func (op=0xb6f10760, rs=0xb6f10724, which=op_add) at backover.c:559 #8 0x080f1ef1 in over_op_add (op=0xb6f10760, rs=0xb6f10724) at backover.c:605 #9 0x081a308d in accesslog_response (op=0x8a84160, rs=0xb6f111c8) at accesslog.c:1279 #10 0x080f1560 in over_back_response (op=0x8a84160, rs=0xb6f111c8) at backover.c:237 #11 0x08090f2d in slap_response_play (op=0x8a84160, rs=0xb6f111c8) at result.c:317 #12 0x080910cd in send_ldap_response (op=0x8a84160, rs=0xb6f111c8) at result.c:391 #13 0x08091dd2 in slap_send_ldap_result (op=0x8a84160, rs=0xb6f111c8) at result.c:638 #14 0x08103653 in bdb_modrdn (op=0x8a84160, rs=0xb6f111c8) at modrdn.c:784 #15 0x080f1c30 in overlay_op_walk (op=0x8a84160, rs=0xb6f111c8, which=op_modrdn, oi=0x89fb040, on=0x0) at backover.c:507 #16 0x080f1de5 in over_op_func (op=0x8a84160, rs=0xb6f111c8, which=op_modrdn) at backover.c:559 #17 0x080f1ecf in over_op_modrdn (op=0x8a84160, rs=0xb6f111c8) at backover.c:599 #18 0x0809e220 in fe_op_modrdn (op=0x8a84160, rs=0xb6f111c8) at modrdn.c:318 #19 0x0809db83 in do_modrdn (op=0x8a84160, rs=0xb6f111c8) at modrdn.c:185 #20 0x0807ef0f in connection_operation (ctx=0xb6f112a4, arg_v=0x8a84160) at connection.c:1129 #21 0x0807f3dc in connection_read_thread (ctx=0xb6f112a4, argv=0x10) at connection.c:1257 #22 0x081e57a8 in ldap_int_thread_pool_wrapper (xpool=0x89bd968) at tpool.c:704 #23 0x00692371 in start_thread () from /lib/tls/libpthread.so.0 #24 0x00475ffe in clone () from /lib/tls/libc.so.6 (gdb) frame 4 #4 0x080bc142 in entry_schema_check (op=0xb6f10760, e=0x8a606dc, oldattrs=0x0, manage=0, add_soc=1, text=0xb6f10738, textbuf=0xb6f1040c "��@", textlen=256) at schema_check.c:87 87 assert( a->a_vals[0].bv_val != NULL ); (gdb) p a $1 = (Attribute *) 0xb6f78e34 (gdb) p a->a_vals $2 = 0x8a93ef8 (gdb) p a->a_vals[0] $3 = {bv_len = 0, bv_val = 0x0} No solution comes to mind right now for the first problem; I'm investigating the second to see where the NULL attr comes from. p.

1 0

Re: (ITS#4820) More issues with modify opattrs in syncrepl
by ando＠sys-net.it 27 Jan '07

27 Jan '07

Howard Chu wrote: > I guess we could just set DBFLAG_NOLASTMOD on the db. We really only > need to make sure a structuralObjectClass and entryUUID gets set for an > Add operation. Just ot avoid overloading stuff, I prefer to add a field to the rs_modify structure that prevents from creating the operational attrs. There might be cases where occasionally we want opattrs and occasionally we don't, and having to create a copy of the BackendDB structure just to toggle a flag seems to be an overkill. I'm about to commit a patch to this. The fix allows to ask for most of the operational attrs in test017 and test018 (only entryCSN can't be checked only because it gets out of sort, I need to find why). In test019, if all modify opattrs are requested there are even more out of sort stuff, so I'm not going to touch it. In any case, I've checked that apart from the print order the values are all in sync. About print ordering, I guess a workaround would be to sort each LDIF line when comparing outputs. This would cure the tests, but it might still overload mods checking in syncrepl; redesigning syncrepl so that out-of-order is no longer an issue could be an option. p.

1 0

Re: (ITS#4820) More issues with modify opattrs in syncrepl
by hyc＠symas.com 27 Jan '07

27 Jan '07

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD (re23?) > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (87.28.220.33) > Submitted by: ando > > > I've modified syncrepl tests so that producer/consumer comparison includes all > operational attributes as well. This yields some surprises. For example, after > a modify, the modifiersName is changed into the consumer's rootdn. This occurs > because the modified entry returned by syncprov contains the same modifiersName > as the consumer's copy, so no modifiersName gets appended to the list of > modifications that's passed to the underlying database. At this point, the > underlying database adds the missing modify opattrs, thus breaking consistency. > I've modified syncrepl as to always check if the modify opattrs are present, > and, if absent, pull them off the entry sent by syncprov. However, in this > case, it's likely that the order of th attributes breaks between the producer > and the consumer, thus causing issues at the next check. Maybe a better fix > would be to allow syncrepl to instruct the database not to create the missing > modify opattrs. Comments? I guess we could just set DBFLAG_NOLASTMOD on the db. We really only need to make sure a structuralObjectClass and entryUUID gets set for an Add operation. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4819) test018-syncreplication-persist failed (exit 1)
by ando＠sys-net.it 27 Jan '07

27 Jan '07

michael.stroeder(a)t-systems.com wrote: > Comparing retrieved entries from master and slave... > test failed - master and slave databases differ Please post the testrun/server*.out files, or diff -u testrun/server1.out testrun/server2.out Needless to say, it's working fine here. p.

1 0

Re: (ITS#4818) Please guide me how to configuration LDAP client on Linux and HPUX OS
by ando＠sys-net.it 27 Jan '07

27 Jan '07

sakect(a)gmail.com wrote: The ITS is not a help desk. Please ask software related questions on the openldap-software mailing list. As per your specific questions, it is very likely that you can find answers yourself, by reading the quick start guide first, followed by the admin guide. For questions related to other software usage, which comprises the use of the *.conf files you mention that are not related to OpenLDAP software, you should ask on mailing lists appropriate for those software. This ITS is closed. p.

1 0

(ITS#4820) More issues with modify opattrs in syncrepl
by ando＠sys-net.it 27 Jan '07

27 Jan '07

Full_Name: Pierangelo Masarati Version: HEAD (re23?) OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.28.220.33) Submitted by: ando I've modified syncrepl tests so that producer/consumer comparison includes all operational attributes as well. This yields some surprises. For example, after a modify, the modifiersName is changed into the consumer's rootdn. This occurs because the modified entry returned by syncprov contains the same modifiersName as the consumer's copy, so no modifiersName gets appended to the list of modifications that's passed to the underlying database. At this point, the underlying database adds the missing modify opattrs, thus breaking consistency. I've modified syncrepl as to always check if the modify opattrs are present, and, if absent, pull them off the entry sent by syncprov. However, in this case, it's likely that the order of th attributes breaks between the producer and the consumer, thus causing issues at the next check. Maybe a better fix would be to allow syncrepl to instruct the database not to create the missing modify opattrs. Comments? p.

1 0

(ITS#4819) test018-syncreplication-persist failed (exit 1)
by michael.stroeder＠t-systems.com 27 Jan '07

27 Jan '07

Full_Name: Michael Ströder Version: HEAD OS: opensuse Linux 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.19.230) >>>>> Starting test018-syncreplication-persist ... running defines.sh Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd is running... Using ldapadd to create the context prefix entry in the master... Starting slave slapd on TCP/IP port 9014... Using ldapsearch to check that slave slapd is running... Using ldapadd to populate the master directory... Waiting 15 seconds for syncrepl to receive changes... Stopping the provider, sleeping 10 seconds and restarting it... Using ldapsearch to check that master slapd is running... Using ldapmodify to modify master directory... Waiting 15 seconds for syncrepl to receive changes... Stopping consumer to test recovery... Modifying more entries on the master... Restarting consumer... Waiting 25 seconds for syncrepl to receive changes... Try updating the slave slapd... Waiting 15 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the master... Using ldapsearch to read all the entries from the slave... Filtering master results... Filtering slave results... Comparing retrieved entries from master and slave... test failed - master and slave databases differ >>>>> ./scripts/test018-syncreplication-persist failed (exit 1) make[2]: *** [bdb-mod] Error 1 make[2]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/tests' make: *** [test] Error 2

1 0

(ITS#4818) Please guide me how to configuration LDAP client on Linux and HPUX OS
by sakect＠gmail.com 26 Jan '07

26 Jan '07

Full_Name: Sak Version: 2.3.32 OS: HPUX, Linux URL: Submission from: (NULL) (58.136.93.94) Hi All, I just start to installation and configuration OpenLDAP so please guide me how to configuration. -I install OpenLDAP version 2.3.32 on Linux to create LDAP server and configuration file at slapd.conf I try to use ldapsearch command then it work already. -I create another Linux OS and configuration at /etc/ldap.conf, /etc/openldap/ldap.conf and /etc/nsswitch.conf already but I am not sure it wrong or not because I can not log on by LDAP user in this machine but it can use ldapsearch command. Please give any example and guide to me how to do it. -Please give any example or guid to me how to configuration LDAP client if client site use HPUX or Tru64. Thank you very much for your help. Sak

1 0

Re: (ITS#3593) Contrib: addpartial overlay
by dhawes＠vt.edu 26 Jan '07

26 Jan '07

An updated version of addpartial is available at: ftp://ftp.openldap.org/incoming/david_hawes-addpartial-070126.tgz This version includes changes to work with OpenLDAP 2.3 as well as ensuring syncrepl works properly. david hawes

1 0

Re: (ITS#4817) modify "replace" command firing conflict error where it shouldn't be
by hyc＠symas.com 26 Jan '07

26 Jan '07

Daniel Henninger wrote: > RE23... ;D Does that mean I should wait for the next minor release? Or > shall I pull from CVS/SVN? or? You can pull the current slapd/entry.c from CVS (use the OPENLDAP_REL_ENG_2_3 tag) if you want to patch your current builds. The fix will be in 2.3.34. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4817) modify "replace" command firing conflict error where it shouldn't be
by hyc＠symas.com 26 Jan '07

26 Jan '07

daniel(a)ncsu.edu wrote: > set as many times as I want just fine. I've had "one a day" of these since > upgrading to 2.3.32. (note that we do daily updates) It appears to have > something to do with the order in which I slapadd'd these. Here's the LDIF (via > slapcat) from before I 'fixed' it: > > dn: uid=XXX,ou=students,ou=people,dc=ncsu,dc=edu > objectClass: person > objectClass: inetOrgPerson > objectClass: ncsuPerson > uid: XXX > cn: XXX > sn: XXX > title: Senior > ncsuTwoPartName: XXX > organizationalStatus: registered > o: NC State University > gn: XXX > initials: XXX > displayName: XXX > ncsuAltDisplayName: XXX > ncsuCampusID: XXX > ncsuClassCode: SR > ou: Physics > ncsuCurriculumCode: PY > ou: B S - Philosophy > ncsuCurriculumCode: LSL > mail: XXX(a)unity.ncsu.edu > ncsuPrimaryEMail: XXX(a)unity.ncsu.edu > registeredAddress: XXX > postalAddress: XXX > telephoneNumber: XXX > l: Raleigh > st: NC > postalCode: 27603 > ncsuPrimaryRole: staff > > Obviously I XXX'd out everything sensitive. Note the ordering of ou and > ncsucurriculumcode and ou again and ncsucurriculumcode. (this worked fine in > the 2.2 series which I migrated from, and as far as I can tell is perfectly > legit =) ) Thanks for the report, this now fixed in HEAD and RE23. Just as an fyi, slapcat should never produce a result like this, with attributes interleaved. It's hard to tell from RFC2849 but I'm pretty certain that it's invalid for normal input too, but we accept it anyway (and clean it up, when everything is working right). Unfortunately the grammar in the LDIF spec is inadequate and the text of the spec doesn't make any explicit statements to cover the grammar's deficiencies, so we see a lot of generated LDIF that is questionable... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4817) modify "replace" command firing conflict error where it shouldn't be
by daniel＠ncsu.edu 26 Jan '07

26 Jan '07

Full_Name: Daniel Henninger Version: 2.3.32 OS: Solaris 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (152.1.4.40) Using ldapmodify to replace an attribute, 'ou', with it's new settings (in this case, two ou entries): dn: uid=XXX,ou=students,ou=people,dc=ncsu,dc=edu changetype: modify replace: ou ou: B A - Physics ou: B S - Philosophy - replace: ncsucurriculumcode ncsucurriculumcode: PYA ncsucurriculumcode: LSL Caused an error: Jan 26 08:07:18 uni00ds.unity.ncsu.edu slapd[13230]: [ID 588225 local4.debug] co nn=62 op=4011 RESULT tag=103 err=20 text=modify/replace: ou: value #0 already ex ists (both are multivalued fields and should be fine) The way I had to fix it was to remove the attributes and retry: dn: uid=XXX,ou=students,ou=people,dc=ncsu,dc=edu changetype: modify delete: ou - replace: ou ou: B A - Physics ou: B S - Philosophy - delete: ncsucurriculumcode - replace: ncsucurriculumcode ncsucurriculumcode: PYA ncsucurriculumcode: LSL After that I can perform the original: dn: uid=XXX,ou=students,ou=people,dc=ncsu,dc=edu changetype: modify replace: ou ou: B A - Physics ou: B S - Philosophy - replace: ncsucurriculumcode ncsucurriculumcode: PYA ncsucurriculumcode: LSL set as many times as I want just fine. I've had "one a day" of these since upgrading to 2.3.32. (note that we do daily updates) It appears to have something to do with the order in which I slapadd'd these. Here's the LDIF (via slapcat) from before I 'fixed' it: dn: uid=XXX,ou=students,ou=people,dc=ncsu,dc=edu objectClass: person objectClass: inetOrgPerson objectClass: ncsuPerson uid: XXX cn: XXX sn: XXX title: Senior ncsuTwoPartName: XXX organizationalStatus: registered o: NC State University gn: XXX initials: XXX displayName: XXX ncsuAltDisplayName: XXX ncsuCampusID: XXX ncsuClassCode: SR ou: Physics ncsuCurriculumCode: PY ou: B S - Philosophy ncsuCurriculumCode: LSL mail: XXX(a)unity.ncsu.edu ncsuPrimaryEMail: XXX(a)unity.ncsu.edu registeredAddress: XXX postalAddress: XXX telephoneNumber: XXX l: Raleigh st: NC postalCode: 27603 ncsuPrimaryRole: staff Obviously I XXX'd out everything sensitive. Note the ordering of ou and ncsucurriculumcode and ou again and ncsucurriculumcode. (this worked fine in the 2.2 series which I migrated from, and as far as I can tell is perfectly legit =) ) According to Howard Chu from the mailing list, this appears to have to do with.. well I'll quote him: I see that slapadd is doing a case-sensitive comparison on its input attribute names, when it should be using case-insensitive. That's probably the problem. Once the data's gone into the DB and come out again via slapcat, all of the attribute names are normalized, so any case differences would have disappeared.

1 0

(ITS#4816) slurpd generates invalid ldapadd/modify requests
by gael.roualland＠oleane.net 26 Jan '07

26 Jan '07

Full_Name: Gaël Roualland Version: 2.3.33 OS: Linux URL: ftp://ftp.openldap.org/incoming/gael.roualland-070126.diff Submission from: (NULL) (213.56.0.199) Hello, Slurpd has a bug when replicating, in the way it generates the LDAPMod array of the add and modify operations : if the same attribute is present several times (for add) or in multiple change blocks (for modify) in the replication log, it simply adds all occurences to the LDAPMod array, hence having one or more attributes repeated serveral times which violates the protocol. This is usually fine with slapd because there is code there to accept invalid queries from the updatedn, but it is rejected if you're not using updatedn (which happens to be our case in a custom floating master scenario). The uploaded patch fixes this in slurpd by replacing its LDAPmod logic by one based on ldapmodify which generates proper requests. I know slurpd is considered deprecated, however this might be useful to others still using it and would allow to remove the exception from slapd code. Regards,

1 0

Re: (ITS#4789) can't add BDB database when monitoring
by ando＠sys-net.it 25 Jan '07

25 Jan '07

hyc(a)symas.com wrote: >> The X-ORDERED 'SIBLING' could be used throughout back-monitor, to get >> rid of those "cn=Database X", "cn=Overlay Y" stuff and so. > > One approach would be to add a pointer to the backend struct that points to > its cn=config entry. Then back-monitor can simply pull the DN from there and > strip the cn=config suffix. I think this should be first well integrated with back-config itself; for example, for what concerns private BackendDB structures. One case I've been trying to deal with for a while was the cached instances of back-ldap that are created by slapo-chain. I'm not sure I ever got it working, though. p.

1 0

Re: (ITS#4789) can't add BDB database when monitoring
by hyc＠symas.com 25 Jan '07

25 Jan '07

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> hyc(a)OpenLDAP.org wrote: >> >> >>> I presume there's some kind of callback for registering new suffixes >>> but I >>> haven't looked very hard. >>> >> >> This highlights some other issues lurking in here - back-monitor >> basically doesn't deal with dynamic configuration well at all. It >> assumes that all databases and overlays have been fully configured by >> the time it starts - an assumption that was valid for old-style >> slapd.conf use, but not with back-config. >> >> The monitor_subsys_database_init_one() function probably needs to be >> split into separate pieces so that database and overlay info can be >> set up and removed incrementally. >> > The point is that back-monitor has no clean means to detect what > database is serving what naming context, since it was designed way ahead > of back-config. So when time came to introduce monitor customization, > the best mechanism I could find was the extended filter on the naming > context. This is really creating trouble. The best solution would be to > re-design back-monitor so that the database section mimics back-config > using X-ORDERED 'SIBLING' style (and is updated accordingly, especially > when entry renaming will be supported by back-config). > > The X-ORDERED 'SIBLING' could be used throughout back-monitor, to get > rid of those "cn=Database X", "cn=Overlay Y" stuff and so. One approach would be to add a pointer to the backend struct that points to its cn=config entry. Then back-monitor can simply pull the DN from there and strip the cn=config suffix. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4805) memory leak in syncrepl code
by hyc＠symas.com 25 Jan '07

25 Jan '07

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re23 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.175.154.35) > Submitted by: ando > > > There seems to be few memory leaks in syncrepl code (detected by valgrind when > running test048); one is when parsing an entry and sync "present" or "done". > It's now fixed in HEAD/re23. Others are being investigated I've plugged everything that I saw in test048 in HEAD. As you can tell by the number of commits, there were several loose ends to chase down. Not sure how many are directly relevant to RE23. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4810) syncprov follows referrals
by hyc＠symas.com 24 Jan '07

24 Jan '07

dieter(a)dkluenter.de wrote: > Hi, > this is my test setup OK. This was a bug in back-bdb/id2entry.c, syncprov is fine. Fixed in HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4813) glue/syncrepl
by hyc＠symas.com 24 Jan '07

24 Jan '07

hyc(a)symas.com wrote: > Hm, in re-reading ITS#4626, I see a pertinent detail in followup #2. I think > I understand part of the problem. > > The particular entry was modified after the current refresh session began, so > that entry is omitted from the current refresh results. Since the entry is > actually missing from the refresh data, the consumer treats it as deleted. > Since the entry has children, it cannot actually be deleted, so it gets > turned into a glue entry. > > So there's two issues - the provider should still send the UUID of the entry, > so that the consumer doesn't consider it deleted. But also, this problem > ought to have self-corrected. Once the replication transitioned from Refresh > to Persist phase, the modified entry should have been sent to the consumer, > and the glue entry should have been replaced by the correct data. > > Looks like both problems are in the syncprov overlay. syncprov.c is now patched in HEAD to always send the UUIDs of the present entries. That appears to prevent the problem from arising. It's a bit difficult to automate a test for this because it requires such exact timing; a modification must occur on the provider while the consumer is just beginning its refresh search. Currently I can only test this by inserting a Debug message and a sleep() in the provider to indicate that the consumer is connected, and to give time to issue a modification. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4814) Tree Archiving
by ando＠sys-net.it 24 Jan '07

24 Jan '07

hyc(a)symas.com wrote: > wells_robert_frank(a)yahoo.com wrote: >> --0-2146048140-1169674999=:43135 >> Content-Type: text/plain; charset=iso-8859-1 >> Content-Transfer-Encoding: 8bit >> >> Apologies - >> >> This did in fact work. I had not been aware of the backend DB functionality. > > Apparently few people are, since most other LDAP servers don't support this > part of the LDAP specification. Although he claimed he needed subtree rename, in his example all was needed was just plain rename, which has been supported by OpenLDAP since ever (when LDAPv3 introduced rename, i.e. modrdn with new rdn). p.

1 0

Re: (ITS#4813) glue/syncrepl
by hyc＠symas.com 24 Jan '07

24 Jan '07

hyc(a)symas.com wrote: > Allan E. Johannesen wrote: >>>>>>> "hyc" == Howard Chu <hyc(a)symas.com> writes: >> hyc> Since you mention that this occurs more often in 2.3.33 than in "previous >> hyc> releases" - what previous version are you comparing to? >> >> Well, I should have said I've never seen it before. I've generally been >> running the new releases within a day of release, and I rebuild the data at >> each release, so everything starts clean. Therefore, it _may_ have existed >> previously, but never showed up in the days during which the given releases >> ran. >> >> I guess I only mentioned that since someone saw it several releases ago in a >> different ITS. I never saw it before. >> In 2.3.33, it happened right after loading the data. I thought I did it wrong, >> so I loaded things again and it was fine. After some days, though, it (meaning >> the change to "objectClass: glue") happened again. > > The only change to syncrepl between 2.3.32 and .33 was one or two debug > messages, no functional changes. In 2.3.32 there was no change to syncrepl at > all (the bug in ITS#4790 was in connection.c, not syncrepl.c). The only > change in 2.3.31 was also in debug messages, not functional changes. So as > unlikely as it seems, at the moment this appears to be a coincidence and the > bug must be older. > > If you see this happening repeatedly, turn on the sync debug level and > capture that output for a while. When you notice the problem, you should also > see some number of "syncrepl_del_nonpresent" messages in the log. We'll > probably need to see a large chunk of the log to be able to follow the > sequence of events. Hm, in re-reading ITS#4626, I see a pertinent detail in followup #2. I think I understand part of the problem. The particular entry was modified after the current refresh session began, so that entry is omitted from the current refresh results. Since the entry is actually missing from the refresh data, the consumer treats it as deleted. Since the entry has children, it cannot actually be deleted, so it gets turned into a glue entry. So there's two issues - the provider should still send the UUID of the entry, so that the consumer doesn't consider it deleted. But also, this problem ought to have self-corrected. Once the replication transitioned from Refresh to Persist phase, the modified entry should have been sent to the consumer, and the glue entry should have been replaced by the correct data. Looks like both problems are in the syncprov overlay. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4813) glue/syncrepl
by hyc＠symas.com 24 Jan '07

24 Jan '07

Allan E. Johannesen wrote: >>>>>> "hyc" == Howard Chu <hyc(a)symas.com> writes: > > hyc> Since you mention that this occurs more often in 2.3.33 than in "previous > hyc> releases" - what previous version are you comparing to? > > Well, I should have said I've never seen it before. I've generally been > running the new releases within a day of release, and I rebuild the data at > each release, so everything starts clean. Therefore, it _may_ have existed > previously, but never showed up in the days during which the given releases > ran. > > I guess I only mentioned that since someone saw it several releases ago in a > different ITS. I never saw it before. > > These are the build times of the past few releases: > > drwxrwxr-x 10 imphss 2000 4096 Dec 19 08:57 .snapshot/weekly.0/openldap-2.3.31/ > drwxrwxr-x 10 imphss 2000 4096 Jan 7 10:33 .snapshot/weekly.0/openldap-2.3.32/ > drwxrwx--- 10 aej 101 4096 Jan 18 14:29 .snapshot/weekly.0/openldap-2.3.33/ > > In 2.3.33, it happened right after loading the data. I thought I did it wrong, > so I loaded things again and it was fine. After some days, though, it (meaning > the change to "objectClass: glue") happened again. The only change to syncrepl between 2.3.32 and .33 was one or two debug messages, no functional changes. In 2.3.32 there was no change to syncrepl at all (the bug in ITS#4790 was in connection.c, not syncrepl.c). The only change in 2.3.31 was also in debug messages, not functional changes. So as unlikely as it seems, at the moment this appears to be a coincidence and the bug must be older. If you see this happening repeatedly, turn on the sync debug level and capture that output for a while. When you notice the problem, you should also see some number of "syncrepl_del_nonpresent" messages in the log. We'll probably need to see a large chunk of the log to be able to follow the sequence of events. > > hyc> Please provide the relevant section of your slave slapd.conf - the > hyc> database clause and its syncrepl statement at least. Are there any ACLs on > hyc> the provider that would prevent the slave from seeing parts of the > hyc> affected entries? > > In the client: > > > database bdb > suffix "dc=WPI,dc=EDU" > rootdn "cn=Manager,ou=Access,dc=wpi,dc=edu" > checkpoint 256 15 > > # limits for different users > > limits dn=wpieduPersonUUID=2af586df6800b3389cbe7bcbf2a920df,ou=People,dc=WPI,dc=EDU size=unlimited time=unlimited > limits dn=cn=application,ou=access,dc=wpi,dc=edu size=unlimited time=unlimited > limits dn="cn=pam,ou=access,dc=wpi,dc=edu" size=unlimited time=unlimited > limits users size=200 time=10 > limits anonymous size=20 time=1 > > directory /var/openldap-data > > # replication > > syncrepl rid=1 provider=ldap://ldapv2.wpi.edu type=refreshAndPersist retry="60 +" > searchbase="dc=WPI,dc=EDU" scope=sub starttls=yes bindmethod=sasl saslmech=gssapi > > > > Its keytab is k5start'd as ldap-manager, this is from the provider: > > > > sasl-regexp uid=ldap-manager/.*,cn=WPI.EDU,cn=gssapi,cn=auth ldap:///ou=access,dc=WPI,dc=EDU??one?(cn=manager) > sasl-regexp uid=(.*),cn=WPI.EDU,cn=gssapi,cn=auth ldap:///ou=people,dc=WPI,dc=EDU??one?(uid=$1) > > ####################################################################### > # bdb database definitions > ####################################################################### > > database bdb > suffix "dc=WPI,dc=EDU" > rootdn "cn=Manager,ou=Access,dc=wpi,dc=edu" > checkpoint 256 15 > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4814) Tree Archiving
by hyc＠symas.com 24 Jan '07

24 Jan '07

wells_robert_frank(a)yahoo.com wrote: > --0-2146048140-1169674999=:43135 > Content-Type: text/plain; charset=iso-8859-1 > Content-Transfer-Encoding: 8bit > > Apologies - > > This did in fact work. I had not been aware of the backend DB functionality. Apparently few people are, since most other LDAP servers don't support this part of the LDAP specification. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4815) TLSCipherSuite conversion to olcTLSCipherSuite
by hyc＠symas.com 24 Jan '07

24 Jan '07

erici(a)motown.cc.utexas.edu wrote: > Full_Name: Eric Irrgang > Version: 2.3.28 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.83.217.14) > > > TLSCipherSuite in slapd.conf does not get converted into olcTLSCipherSuite in > cn=config Thanks for the report. The libldap function to retrieve this option was actually missing. Fixed now in HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4815) TLSCipherSuite conversion to olcTLSCipherSuite
by erici＠motown.cc.utexas.edu 24 Jan '07

24 Jan '07

Full_Name: Eric Irrgang Version: 2.3.28 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.83.217.14) TLSCipherSuite in slapd.conf does not get converted into olcTLSCipherSuite in cn=config

1 0

Re: (ITS#4814) Tree Archiving
by wells_robert_frank＠yahoo.com 24 Jan '07

24 Jan '07

--0-2146048140-1169674999=:43135 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Apologies - This did in fact work. I had not been aware of the backend DB functionality. Regards, RFW Quanah Gibson-Mount <quanah(a)stanford.edu> wrote: --On Wednesday, January 24, 2007 6:55 PM +0000 wells_robert_frank(a)yahoo.com wrote: > Full_Name: Bob Wells > Version: 2.3.33 > OS: Linux RH 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (63.81.96.200) Isn't this just the modrdn operation? It is supported when using the back-hdb database. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html --0-2146048140-1169674999=:43135 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Apologies - This did in fact work.  I had not been aware of the backend DB functionality. Regards, RFW Quanah Gibson-Mount <quanah(a)stanford.edu> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> --On Wednesday, January 24, 2007 6:55 PM +0000 wells_robert_frank(a)yahoo.com wrote: > Full_Name: Bob Wells > Version: 2.3.33 > OS: Linux RH 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (63.81.96.200) Isn't this just the modrdn operation? It is supported when using the back-hdb database. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html </blockquote> --0-2146048140-1169674999=:43135--

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs