openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#4884) Back-config inheritance issue
by hyc＠symas.com 07 Oct '07

07 Oct '07

ando(a)sys-net.it wrote: > I've committed to HEAD a fix that exploits inheritance. The rationale is: > > - lookup the structural objectClass; starting from it, check it and > subordinates for a function that successfully adds the entry > > - using all objectClass values, collect all, including ancestors, that > may be of use in checking configuration. > > Passes all tests (049->051), and allows to add an overlay using only the > overlay's objectClass, provided it's derived from olcOverlayConfig. > > Please test. p. Something's wrong here, it's only checking structural classes but not auxiliary classes. This breaks proxycache now, which uses an auxiliary class for the ldadd hook when adding its private DB. -- -- 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#5171) hdb txn_checkpoint failures
by hyc＠symas.com 07 Oct '07

07 Oct '07

Aaron Richton wrote: >> No. The BDB transaction log files don't know (or care) anything about IP >> addresses. Nothing at the slapd layer could have any direct effect on the BDB >> transaction logs. How exactly did you reconfigure the servers, did you stop >> them and restart them or did you use cn=config? > > echo 192.blahblah master.r.e >> /etc/hosts > > The master changed from 128.blahblah to 192.blahblah. Same physical > machine, just different interface. On slave4 and 6, I didn't touch slapd. (Of course, if you only appended to /etc/hosts then the old address is still in there and getting used first..) >> Might as well get the db_stat -l output for a few of them to compare. > > This isn't going well at all; they just can't join the environment. I > tried on slave1, it hung. I tried on slave4 under truss, it hung. (We're > talking >30 minutes here.) Although I swear I've run db_stat hot, I killed > db_stat (ungracefully, sadly) and stopped slapd (gracefully) on slave1, > ran db_stat again, and it hung there...and corrupted the environment to > the point where I couldn't get db_recover/slapd to run. (I ended up > blowing the slave1 database away; it's refreshing from syncrepl now.) > I've got a few more slaves that I haven't shot in the foot yet, and I only > tried this on one of the suffixes on slave{1,4}. Plenty of more > opportunities to screw this up yet if there's anything to try...I suppose > I could go for -N, or if the command line is going to be a pain, I could > join the slapd process with dbx and print ->log_stat myself (although I > might need a bit of hand holding on that)... > > [the hang on slave4] > db_stat -> libdb-4.2.so:*db_env_create(0xffbffaec, 0x0, 0x17154) > lwp_mutex_lock(0xFF0D0000) (sleeping...) > mutex type: USYNC_PROCESS > > ff307248 __db_des_get (29ac0, 29d78, 29d78, ffbff9d0, 0, ffbff9d9) + c0 > ff305780 __db_e_attach (29ac0, ffbffa94, 40400, 40000, 33e021, 29d71) + 6e0 > ff2ff434 __dbenv_open (29ac0, 0, 40400, 0, 0, 0) + 664 > 00016514 db_init (29ac0, 0, 4, 100000, ffbffba0, ff3deb54) + 64 > 00011e3c main (2, ffbffc44, ffbffc50, 29800, 0, 0) + 9a4 > 00011470 _start (0, 0, 0, 0, 0, 0) + 108 If this is happening even with slapd cleanly shut down then it should also prevent slapd from restarting, since slapd first attempts to join an existing environment before trying to create a new one. And that really implies that the rest of the environment is shot. -- -- 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#5164) slapi plugins prevent slapd starting.
by hyc＠symas.com 07 Oct '07

07 Oct '07

m.d.t.evans(a)qmul.ac.uk wrote: > Full_Name: Martin Evans > Version: 2.4.5beta > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (138.37.8.140) > > > This is mentioned in #4611 but marked as fixed there. Now fixed in HEAD. -- -- 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#5172) slash in dn
by ando＠sys-net.it 07 Oct '07

07 Oct '07

reinhold.may(a)gmx.de wrote: > I'm fairly new to OpenLDAP and hope I've not misunderstood things... in that > case: sorry. > > I've been trying to import the following .ldif: > > dn: dc=somedomain,dc=org > objectclass: top > objectclass: dcObject > objectclass: organization > o: somedomain LDAP > dc: somedomain > > dn: ou=My address book,dc=somedomain,dc=org > objectclass: top > objectclass: organizationalUnit > ou: My address book > > dn: ou=With/Slash,ou=My address book,dc=somedomain,dc=org > objectclass: top > objectclass: organizationalUnit > ou: Medical > > dn: cn=With/Slash,ou=My address book,dc=somedomain,dc=org > objectclass: top > objectclass: person > objectclass: organizationalPerson > objectclass: inetOrgPerson > objectclass: mozillaAbPersonAlpha > cn: With/Slash > sn: With/Slash The above LDIF is inconsistent: the "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" entry is repeated, and in the first occurrence it is inconsistent: the distinguished value "With/Slash" is not present in the entry, there's a "Medical" instead. I suspect you messed things up when sanitizing your data. > > The "/" results into the following error message: > > ldap_add: No such object (32) > additional info: Parent does not exist This error means that the parent of the entry you're trying to add does not exist. Here "parent" means the entry immediately below the one you're trying to add, so assuming you're trying to add "cn=With/Slash,ou=My address book,dc=somedomain,dc=org", what appears to be missing is "ou=My address book,dc=somedomain,dc=org". Are you sure it exists? By looking at the server's logs at "stats,trace" level, can you tell what DN is being looked up for the parent? > If my last entry reads: > > dn: cn=WithoutSlash,ou=My address book,dc=somedomain,dc=org > objectclass: top > objectclass: person > objectclass: organizationalPerson > objectclass: inetOrgPerson > objectclass: mozillaAbPersonAlpha > cn: WithoutSlash > sn: WithoutSlash > > slapd accepts the entry and adds it to its directory. > > I've read RFCs 2849 (about LDIF) and 2253 (about DNs) and can't even find "/" to > be a special character. But just in case it was forgotten, I tried to represent > it as "\/" and "\2f" but neither solution helped. Yes, it's not. Using OpenLDAP 2.3 code, I can correctly parse the DN you suspect to trigger the unexpected behavior you reported: $ slapdn 'cn=With/Slash,ou=My address book,dc=somedomain,dc=org' DN: <cn=With/Slash,ou=My address book,dc=somedomain,dc=org> check succeeded normalized: <cn=with/slash,ou=my address book,dc=somedomain,dc=org> pretty: <cn=With/Slash,ou=My address book,dc=somedomain,dc=org> $ ./libraries/libldap/dntest 'cn=With/Slash,ou=My address book,dc=somedomain,dc=org' ldap_rdn2str() = "cn=With/Slash" ldap_rdn2str() = "ou=My address book" ldap_rdn2str() = "dc=somedomain" ldap_rdn2str() = "dc=org" ldap_dn2str(ldap_str2dn("cn=With/Slash,ou=My address book,dc=somedomain,dc=org")) = "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" ldap_dn2domain("cn=With/Slash,ou=My address book,dc=somedomain,dc=org") = "somedomain.org" ldap_dn2ufn("cn=With/Slash,ou=My address book,dc=somedomain,dc=org") = "With/Slash, My address book, somedomain.org" ldap_dn2dcedn("cn=With/Slash,ou=My address book,dc=somedomain,dc=org") = "/dc=org/dc=somedomain/ou=My address book/cn=With\/Slash" ldap_dcedn2dn("/dc=org/dc=somedomain/ou=My address book/cn=With\/Slash") = "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" ldap_dn2ad_canonical("cn=With/Slash,ou=My address book,dc=somedomain,dc=org") = "somedomain.org/My address book/With\/Slash" ldap_explode_dn("cn=With/Slash,ou=My address book,dc=somedomain,dc=org"): "cn=With/Slash" ldap_explode_rdn("cn=With/Slash") 'cn=With/Slash' ldap_explode_rdn("cn=With/Slash") (no types) "With/Slash" "ou=My address book" ldap_explode_rdn("ou=My address book") 'ou=My address book' ldap_explode_rdn("ou=My address book") (no types) "My address book" "dc=somedomain" ldap_explode_rdn("dc=somedomain") 'dc=somedomain' ldap_explode_rdn("dc=somedomain") (no types) "somedomain" "dc=org" ldap_explode_rdn("dc=org") 'dc=org' ldap_explode_rdn("dc=org") (no types) "org" ldap_explode_dn("cn=With/Slash,ou=My address book,dc=somedomain,dc=org") (no types): "With/Slash" "My address book" "somedomain" "org" "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" == "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" ? yes 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

(ITS#5172) slash in dn
by reinhold.may＠gmx.de 07 Oct '07

07 Oct '07

Full_Name: Reinhold May Version: 2.3.35 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.216.115.71) I'm fairly new to OpenLDAP and hope I've not misunderstood things... in that case: sorry. I've been trying to import the following .ldif: dn: dc=somedomain,dc=org objectclass: top objectclass: dcObject objectclass: organization o: somedomain LDAP dc: somedomain dn: ou=My address book,dc=somedomain,dc=org objectclass: top objectclass: organizationalUnit ou: My address book dn: ou=With/Slash,ou=My address book,dc=somedomain,dc=org objectclass: top objectclass: organizationalUnit ou: Medical dn: cn=With/Slash,ou=My address book,dc=somedomain,dc=org objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: mozillaAbPersonAlpha cn: With/Slash sn: With/Slash The "/" results into the following error message: ldap_add: No such object (32) additional info: Parent does not exist If my last entry reads: dn: cn=WithoutSlash,ou=My address book,dc=somedomain,dc=org objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: mozillaAbPersonAlpha cn: WithoutSlash sn: WithoutSlash slapd accepts the entry and adds it to its directory. I've read RFCs 2849 (about LDIF) and 2253 (about DNs) and can't even find "/" to be a special character. But just in case it was forgotten, I tried to represent it as "\/" and "\2f" but neither solution helped.

1 0

Re: (ITS#5171) hdb txn_checkpoint failures
by richton＠nbcs.rutgers.edu 07 Oct '07

07 Oct '07

> No. The BDB transaction log files don't know (or care) anything about IP > addresses. Nothing at the slapd layer could have any direct effect on the BDB > transaction logs. How exactly did you reconfigure the servers, did you stop > them and restart them or did you use cn=config? echo 192.blahblah master.r.e >> /etc/hosts The master changed from 128.blahblah to 192.blahblah. Same physical machine, just different interface. On slave4 and 6, I didn't touch slapd. > Might as well get the db_stat -l output for a few of them to compare. This isn't going well at all; they just can't join the environment. I tried on slave1, it hung. I tried on slave4 under truss, it hung. (We're talking >30 minutes here.) Although I swear I've run db_stat hot, I killed db_stat (ungracefully, sadly) and stopped slapd (gracefully) on slave1, ran db_stat again, and it hung there...and corrupted the environment to the point where I couldn't get db_recover/slapd to run. (I ended up blowing the slave1 database away; it's refreshing from syncrepl now.) I've got a few more slaves that I haven't shot in the foot yet, and I only tried this on one of the suffixes on slave{1,4}. Plenty of more opportunities to screw this up yet if there's anything to try...I suppose I could go for -N, or if the command line is going to be a pain, I could join the slapd process with dbx and print ->log_stat myself (although I might need a bit of hand holding on that)... [the hang on slave4] db_stat -> libdb-4.2.so:*db_env_create(0xffbffaec, 0x0, 0x17154) lwp_mutex_lock(0xFF0D0000) (sleeping...) mutex type: USYNC_PROCESS ff307248 __db_des_get (29ac0, 29d78, 29d78, ffbff9d0, 0, ffbff9d9) + c0 ff305780 __db_e_attach (29ac0, ffbffa94, 40400, 40000, 33e021, 29d71) + 6e0 ff2ff434 __dbenv_open (29ac0, 0, 40400, 0, 0, 0) + 664 00016514 db_init (29ac0, 0, 4, 100000, ffbffba0, ff3deb54) + 64 00011e3c main (2, ffbffc44, ffbffc50, 29800, 0, 0) + 9a4 00011470 _start (0, 0, 0, 0, 0, 0) + 108

1 0

Re: ITS#4976 test008 crash with -lmcheck
by hyc＠symas.com 06 Oct '07

06 Oct '07

Howard Chu wrote: > hyc(a)symas.com wrote: >> I suspect this is a bug in glibc mcheck's pthread support, since ElectricFence >> with EF_PROTECT_BELOW set will detect 100% of all memory underruns, and no >> such error occurs there. >> >> Also this report (which it seems the original is no longer accessible) implies >> the same problem with mcheck >> >> http://www.google.com/search?q=cache:dAqJIBQSNRQJ:groups.google.com/group/g… >> > Eh... > Looking at glibc's mcheck code > http://sourceware.org/cgi-bin/cvsweb.cgi/libc/malloc/?cvsroot=glibc > shows that it has no mutex protection at all. It is completely invalid here, > this ITS will be closed. By the way, this stzck trace confirms the problem: (gdb) info thr 17 Thread 1208023360 (LWP 4680) 0x00002ae575308491 in clone () from /lib64/libc.so.6 16 Thread 1199630656 (LWP 4679) 0x00002ae575277535 in raise () from /lib64/libc.so.6 15 Thread 1191237952 (LWP 4678) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 * 14 Thread 1182845248 (LWP 4677) 0x00002ae5752bc3b7 in memset () from /lib64/libc.so.6 13 Thread 1174452544 (LWP 4676) 0x00002ae5752b8733 in mcheck_check_all () from /lib64/libc.so.6 12 Thread 1166059840 (LWP 4675) 0x00002ae5752b8762 in unlink_blk () from /lib64/libc.so.6 11 Thread 1157667136 (LWP 4674) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 10 Thread 1149274432 (LWP 4673) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 9 Thread 1140881728 (LWP 4672) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 8 Thread 1132489024 (LWP 4671) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 7 Thread 1124096320 (LWP 4670) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 6 Thread 1115703616 (LWP 4669) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 5 Thread 1107310912 (LWP 4665) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 4 Thread 1098918208 (LWP 4655) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 3 Thread 1090525504 (LWP 4650) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 2 Thread 1082132800 (LWP 4639) 0x00002ae5753088b8 in ?? () from /lib64/libc.so.6 1 Thread 47165004620160 (LWP 4632) 0x00002ae5746795d5 in pthread_join () from /lib64/libpthread.so.0 (gdb) thr 13 [Switching to thread 13 (Thread 1174452544 (LWP 4676))]#0 0x00002ae5752b8733 in mcheck_check_all () from /lib64/libc.so.6 (gdb) bt #0 0x00002ae5752b8733 in mcheck_check_all () from /lib64/libc.so.6 #1 0x00002ae5752b89b9 in mallochook () from /lib64/libc.so.6 #2 0x00002ae57410f865 in ber_memalloc_x (s=9297104, ctx=0x2ae57410f865) at ../../../head/libraries/liblber/memory.c:226 #3 0x00002ae57410fd68 in ber_dupbv_x (dst=0x46009b80, src=0x2aaaaadae240, ctx=0x0) at ../../../head/libraries/liblber/memory.c:501 #4 0x00002ae573ed26ce in ldap_bv2escaped_filter_value_x (in=0x2aaaaadae240, out=0x46009b80, inplace=0, ctx=0x933bd0) at search.c:468 #5 0x000000000043d239 in filter2bv_x (op=0x92e4c0, f=0x2aaaaadae280, fstr=0x92e538) at ../../../head/servers/slapd/filter.c:608 #6 0x000000000043a943 in do_search (op=0x92e4c0, rs=0x4600acb0) at ../../../head/servers/slapd/search.c:138 #7 0x0000000000437e5e in connection_operation (ctx=0x4600ade0, arg_v=0x92e4c0) at ../../../head/servers/slapd/connection.c:1145 #8 0x0000000000438332 in connection_read_thread (ctx=0x4600ade0, argv=0xb) at ../../../head/servers/slapd/connection.c:1271 #9 0x00002ae573ece7e7 in ldap_int_thread_pool_wrapper (xpool=0x7dae80) at ../../../head/libraries/libldap_r/tpool.c:614 #10 0x00002ae57467809e in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae5753084cd in clone () from /lib64/libc.so.6 #12 0x0000000000000000 in ?? () (gdb) thr 12 [Switching to thread 12 (Thread 1166059840 (LWP 4675))]#0 0x00002ae5752b8762 in unlink_blk () from /lib64/libc.so.6 (gdb) bt #0 0x00002ae5752b8762 in unlink_blk () from /lib64/libc.so.6 #1 0x00002ae5752b8a36 in freehook () from /lib64/libc.so.6 #2 0x000000000045b93d in ch_free (ptr=0x7d9370) at ../../../head/servers/slapd/ch_malloc.c:139 #3 0x000000000049accd in slap_sasl_open (conn=0x2ae5769dbe60, reopen=<value optimized out>) at ../../../head/servers/slapd/sasl.c:1395 #4 0x00000000004368d9 in connection_init (s=18, listener=0x7a2ad0, dnsname=0x4efe78 "unknown", peername=0x45808ca0 "IP=127.0.0.1:36732", flags=0, ssf=0, authid=0x0, peerbv=0x45808c80) at ../../../head/servers/slapd/connection.c:633 #5 0x00000000004332e0 in slap_listener (sl=0x7a2ad0) at ../../../head/servers/slapd/daemon.c:1823 #6 0x0000000000433489 in slap_listener_thread (ctx=0x45809de0, ptr=0x7a2ad0) at ../../../head/servers/slapd/daemon.c:1856 #7 0x00002ae573ece7e7 in ldap_int_thread_pool_wrapper (xpool=0x7dae80) at ../../../head/libraries/libldap_r/tpool.c:614 #8 0x00002ae57467809e in start_thread () from /lib64/libpthread.so.0 #9 0x00002ae5753084cd in clone () from /lib64/libc.so.6 #10 0x0000000000000000 in ?? () (gdb) Note that thread 12 is removing a block from the chunk list while thread 13 is walking the list. There is absolutely no thread safety here whatsoever. -- -- 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#4976 test008 crash with -lmcheck
by hyc＠symas.com 06 Oct '07

06 Oct '07

hyc(a)symas.com wrote: > I suspect this is a bug in glibc mcheck's pthread support, since ElectricFence > with EF_PROTECT_BELOW set will detect 100% of all memory underruns, and no > such error occurs there. > > Also this report (which it seems the original is no longer accessible) implies > the same problem with mcheck > > http://www.google.com/search?q=cache:dAqJIBQSNRQJ:groups.google.com/group/g… > Eh... Looking at glibc's mcheck code http://sourceware.org/cgi-bin/cvsweb.cgi/libc/malloc/?cvsroot=glibc shows that it has no mutex protection at all. It is completely invalid here, this ITS will be closed. -- -- 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#5171) hdb txn_checkpoint failures
by hyc＠symas.com 06 Oct '07

06 Oct '07

Aaron Richton wrote: > With that said, "some admin specifically disturbed the log files around > that time." Logs show that I was the only person in a position to do so > (unless somebody broke in and covered their tracks; we'll ignore that > theoretical possibility). On September 24, I reconfigured the slaves to > use a different IP address to the master instead of the existing > connection. The times are too coincidental to be unrelated: > > (slave4) reconfigured Sep 24 09:41 (first syslog complaint 09:43) > (slave6) reconfigured Sep 24 09:39 (first syslog complaint 09:44) > > > So...is there something that's cued off the (reverse?) name service > entries for the master? Does the master IP hash in to a CSN somehow? And > if this is indeed the case/root cause...well, quite honestly, I think that > assuming a name service database will remain constant throughout a slapd > instance is a fallacy. Furthermore, if this is indeed the case, it should > be absolutely trivial for me to reproduce this (I can perform a DR on > slave4/6, and reconfigure their network again). No. The BDB transaction log files don't know (or care) anything about IP addresses. Nothing at the slapd layer could have any direct effect on the BDB transaction logs. How exactly did you reconfigure the servers, did you stop them and restart them or did you use cn=config? > > With that in mind, I'll likely test this reproduction early next week. I > can still get db_stat from all slaves (working and not) at this point if > that's interesting. Comments? > Might as well get the db_stat -l output for a few of them to compare. -- -- 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#5171) hdb txn_checkpoint failures
by richton＠nbcs.rutgers.edu 06 Oct '07

06 Oct '07

> Have you got backups from just before these occurrences? Can you see what the > last valid transaction log files were before this? Or perhaps you can get > some db_stat's off any other slaves that are still running OK? The idea is to > see whether the current valid CSNs on an equivalent slave are anywhere near > the numbers being logged here, e.g. 1/188113 or 1/8730339. > > Have you actually run out of disk space on the partitions holding the logs? > It's rather suspicious that two machines would act up at the same time unless > some admin specifically disturbed the log files on those two systems at > around that time. I don't have backups for slave bdb logs. The master slapcat output is considered sacred data; the slave bdb log files are considered derivable thereof and don't get backed up (we'd sooner just replace the entire slave if it acts up). The odds of the partitions filling is minimal; Solaris has that logged at kern.notice (which on our configuration is serious enough to mean a write to NVRAM), and logs that extend prior to September 24 don't show any such messages. With that said, "some admin specifically disturbed the log files around that time." Logs show that I was the only person in a position to do so (unless somebody broke in and covered their tracks; we'll ignore that theoretical possibility). On September 24, I reconfigured the slaves to use a different IP address to the master instead of the existing connection. The times are too coincidental to be unrelated: (slave4) reconfigured Sep 24 09:41 (first syslog complaint 09:43) (slave6) reconfigured Sep 24 09:39 (first syslog complaint 09:44) So...is there something that's cued off the (reverse?) name service entries for the master? Does the master IP hash in to a CSN somehow? And if this is indeed the case/root cause...well, quite honestly, I think that assuming a name service database will remain constant throughout a slapd instance is a fallacy. Furthermore, if this is indeed the case, it should be absolutely trivial for me to reproduce this (I can perform a DR on slave4/6, and reconfigure their network again). With that in mind, I'll likely test this reproduction early next week. I can still get db_stat from all slaves (working and not) at this point if that's interesting. Comments?

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