openldap-bugs April 2007

openldap-bugs@openldap.org

38 participants
126 discussions

Re: (ITS#4916) syncrpl consumer not listing contextcsn as operation attr
by hyc＠symas.com 06 Apr '07

06 Apr '07

brian(a)zimbra.com wrote: > Full_Name: Brian Peterson > Version: 2.3.34 > OS: Linux > URL: pro > Submission from: (NULL) (66.92.25.194) > > > When setup sync replication the contextCSN is available via ldapsearch on the > provider but not the consumer as an operation attribute. If we do a slapcat on > the consumer the resulting ldif contains the contextCSN. This is because your context entry has no DN, it's a glue entry. When you do a search on it you get the contents of the server rootDSE instead of your glue entry. The search works on the provider because the syncprov overlay intercepts searches to insert the current contextCSN value in the result. You can add a syncprov overlay to the consumer to get the same effect. > Top entry from slapcat ldif on the consumer. > dn: > objectClass: glue > structuralObjectClass: glue > contextCSN: 20070405182202Z#000000#00#000000 > entryCSN: 20070405182202Z#000000#00#000000 > modifiersName: uid=zimbra,cn=admins,cn=zimbra > modifyTimestamp: 20070405182202Z > > > -- -- 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#4917) at_insert() moves sat_ad_mutex
by h.b.furuseth＠usit.uio.no 06 Apr '07

06 Apr '07

hyc(a)symas.com wrote: >h.b.furuseth(a)usit.uio.no wrote: >> If so, the simplest clean fix may be to destroy and reinitialize >> the mutexes (instead of swapping them back), I think strictly >> speaking behaviour is undefined if one copies mutexes around at >> all. Or since one will immediately be destroyed, maybe they should >> be destroyed when SLAP_AT_DELETED is set, if it is not needed then. > > Destroying immediately is not feasible since the attribute may still > be in use. OK. > Show me the POSIX spec that indicates this behavior is undefined. I wasn't thinking of POSIX in particular (OpenLDAP supports several mutex types afer all), though the pthread_mutex_init() spec says Only mutex itself may be used for performing synchronization. The result of referring to copies of mutex in calls to pthread_mutex_lock(), pthread_mutex_trylock(), pthread_mutex_unlock(), and pthread_mutex_destroy() is undefined. Attempting to initialize an already initialized mutex results in undefined behavior. The current swap definitely makes it undefined. Whether swapping and copying back does so as well is probably just pedantry when they are unlocked, though in theory I imagine some thread magic could happen even to "passive" mutexes. Except I take it only one thread is running... -- Regards, Hallvard

1 0

Re: (ITS#4917) at_insert() moves sat_ad_mutex
by hyc＠symas.com 06 Apr '07

06 Apr '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > slapd/at.c:at_insert() swaps the contents of the initialized > mutexes 'old_sat->sat_ad_mutex' and 'sat->sat_ad_mutex' in the > /* replacing a deleted definition? */ code. > > I hope they are at least unlocked at the time... > Does ldap_pvt_thread_pool_pause() in config_back_add() & co block > the other threads? Yes of course, otherwise none of the config activities would be safe. > If so, the simplest clean fix may be to destroy and reinitialize > the mutexes (instead of swapping them back), I think strictly > speaking behaviour is undefined if one copies mutexes around at > all. Or since one will immediately be destroyed, maybe they should > be destroyed when SLAP_AT_DELETED is set, if it is not needed then. Destroying immediately is not feasible since the attribute may still be in use. Show me the POSIX spec that indicates this behavior is undefined. -- -- 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#4917) at_insert() moves sat_ad_mutex
by h.b.furuseth＠usit.uio.no 06 Apr '07

06 Apr '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard slapd/at.c:at_insert() swaps the contents of the initialized mutexes 'old_sat->sat_ad_mutex' and 'sat->sat_ad_mutex' in the /* replacing a deleted definition? */ code. I hope they are at least unlocked at the time... Does ldap_pvt_thread_pool_pause() in config_back_add() & co block the other threads? If so, the simplest clean fix may be to destroy and reinitialize the mutexes (instead of swapping them back), I think strictly speaking behaviour is undefined if one copies mutexes around at all. Or since one will immediately be destroyed, maybe they should be destroyed when SLAP_AT_DELETED is set, if it is not needed then.

1 0

(ITS#4916) syncrpl consumer not listing contextcsn as operation attr
by brian＠zimbra.com 06 Apr '07

06 Apr '07

Full_Name: Brian Peterson Version: 2.3.34 OS: Linux URL: pro Submission from: (NULL) (66.92.25.194) When setup sync replication the contextCSN is available via ldapsearch on the provider but not the consumer as an operation attribute. If we do a slapcat on the consumer the resulting ldif contains the contextCSN. relavent slapd.conf entries from provider(please let me know if you want the entire file). database bdb suffix "" rootdn "uid=zimbra,cn=admins,cn=zimbra" # recommended for replication index entryUUID eq index entryCSN eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 500 slapd.conf entries from consumer. database bdb suffix "" rootdn "uid=zimbra,cn=admins,cn=zimbra" syncrepl rid=022 provider=ldap://ldapmaster:389 retry="60 +" type=refreshAndPersist schemachecking=off updatedn="uid=zimbrareplication,cn=admins,cn=zimbra" searchbase="" bindmethod=simple binddn="uid=zimbra,cn=admins,cn=zimbra" creditionals=secret updateref ldap://ldapmaster:389 Ldap search output from the consumer ldapsearch -LLL -x -D uid=zimbra,cn=admins,cn=zimbra -w secret -H ldap://ldapreplica:389 -s base -b "" + dn: structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.334810.2.3 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedFeatures: 1.3.6.1.1.14 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 3 entryDN: subschemaSubentry: cn=Subschema Top entry from slapcat ldif on the consumer. dn: objectClass: glue structuralObjectClass: glue contextCSN: 20070405182202Z#000000#00#000000 entryCSN: 20070405182202Z#000000#00#000000 modifiersName: uid=zimbra,cn=admins,cn=zimbra modifyTimestamp: 20070405182202Z

1 0

Re: (ITS#4915) Syncrepl task exits are not logged
by hyc＠symas.com 05 Apr '07

05 Apr '07

unix.gurus(a)gmail.com wrote: > Full_Name: Sean Burford > Version: 2.3.32 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (65.57.245.11) > > > It is hard to tell when the syncrepl task has exited. The attached patch adds > logging of syncrepl hard and soft failures. > > Using this patch, it is easier to spot unfortunate conditions where recoverable > failures are treated as hard failures, for example the third line below shows > that a (temporarily) unavailable kerberos credential cache causes a hard > failure: > GSSAPI Error: Miscellaneous failure (No credentials cache found) > do_syncrep1: rid 123 ldap_sasl_interactive_bind_s failed (-2) > do_syncrepl: rid 123 hard failure Looks like a good idea, thanks. I think I'd just change the messages to "giving up" or "quitting", and "retrying". That final else clause in your patch should never occur, there is no 3rd outcome. > > Hmm, no attachment because the FTP server returns: > 200 PORT command successful. > 150 Opening ASCII mode data connection for > 'openldap-2.3.32-syncrepl-log-failure.patch'. > ## > 452 Error writing file: No space left on device. > 1104 bytes sent in 0.00011 seconds (1e+04 Kbytes/s) > > The patch was: > *** openldap-2.3.32.orig/servers/slapd/syncrepl.c Wed Apr 4 17:21:31 > 2007 > --- openldap-2.3.32/servers/slapd/syncrepl.c Wed Apr 4 17:55:58 2007 > *************** > *** 1147,1159 **** > --- 1147,1169 ---- > } > > if ( !si->si_retrynum || si->si_retrynum[i] == RETRYNUM_TAIL ) > { > + Debug( LDAP_DEBUG_ANY, > + "do_syncrepl: rid %03d hard failure\n", > + si->si_rid, 0, 0 ); > ldap_pvt_runqueue_remove( &slapd_rq, rtask ); > } else if ( RETRYNUM_VALID( si->si_retrynum[i] ) ) { > if ( si->si_retrynum[i] > 0 ) > si->si_retrynum[i]--; > + Debug( LDAP_DEBUG_ANY, > + "do_syncrepl: rid %03d soft failure, > rescheduling (retries left: %d)\n", > + si->si_rid, si->si_retrynum[i], 0 ); > rtask->interval.tv_sec = si->si_retryinterval[i]; > ldap_pvt_runqueue_resched( &slapd_rq, rtask, 0 ); > slap_wake_listener(); > + } else { > + Debug( LDAP_DEBUG_ANY, > + "do_syncrepl: rid %03d soft failure, > rescheduling\n", > + si->si_rid, 0, 0 ); > } > } > > > -- -- 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#4915) Syncrepl task exits are not logged
by unix.gurus＠gmail.com 05 Apr '07

05 Apr '07

Full_Name: Sean Burford Version: 2.3.32 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.57.245.11) It is hard to tell when the syncrepl task has exited. The attached patch adds logging of syncrepl hard and soft failures. Using this patch, it is easier to spot unfortunate conditions where recoverable failures are treated as hard failures, for example the third line below shows that a (temporarily) unavailable kerberos credential cache causes a hard failure: GSSAPI Error: Miscellaneous failure (No credentials cache found) do_syncrep1: rid 123 ldap_sasl_interactive_bind_s failed (-2) do_syncrepl: rid 123 hard failure Hmm, no attachment because the FTP server returns: 200 PORT command successful. 150 Opening ASCII mode data connection for 'openldap-2.3.32-syncrepl-log-failure.patch'. ## 452 Error writing file: No space left on device. 1104 bytes sent in 0.00011 seconds (1e+04 Kbytes/s) The patch was: *** openldap-2.3.32.orig/servers/slapd/syncrepl.c Wed Apr 4 17:21:31 2007 --- openldap-2.3.32/servers/slapd/syncrepl.c Wed Apr 4 17:55:58 2007 *************** *** 1147,1159 **** --- 1147,1169 ---- } if ( !si->si_retrynum || si->si_retrynum[i] == RETRYNUM_TAIL ) { + Debug( LDAP_DEBUG_ANY, + "do_syncrepl: rid %03d hard failure\n", + si->si_rid, 0, 0 ); ldap_pvt_runqueue_remove( &slapd_rq, rtask ); } else if ( RETRYNUM_VALID( si->si_retrynum[i] ) ) { if ( si->si_retrynum[i] > 0 ) si->si_retrynum[i]--; + Debug( LDAP_DEBUG_ANY, + "do_syncrepl: rid %03d soft failure, rescheduling (retries left: %d)\n", + si->si_rid, si->si_retrynum[i], 0 ); rtask->interval.tv_sec = si->si_retryinterval[i]; ldap_pvt_runqueue_resched( &slapd_rq, rtask, 0 ); slap_wake_listener(); + } else { + Debug( LDAP_DEBUG_ANY, + "do_syncrepl: rid %03d soft failure, rescheduling\n", + si->si_rid, 0, 0 ); } }

1 0

Re: (ITS#4907) Syncrepl consumer failing to perform deletes
by unix.gurus＠gmail.com 05 Apr '07

05 Apr '07

------=_Part_45311_2874873.1175811229646 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 4/3/07, Howard Chu <hyc(a)symas.com> wrote: > The log says that ITS#4638 was already fixed in 2.3.32. Why are you > still using that particular patch, given that an alternate solution is > already present in the release? I can't replicate ITS#4638 under 2.3.32, so you can mark ITS#4907 resolved (I removed the bad patch). I also see that in RE23 we had one more patch to fix some interaction > between slapo-rwm and back-meta for filter processing. I suggest you > test against the current RE23 code. I expect to push 2.3.35 out pretty > soon. Thank you. Sean ------=_Part_45311_2874873.1175811229646 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline <span class="gmail_quote">On 4/3/07, <b class="gmail_sendername">Howard Chu</b> <<a href="mailto:hyc@symas.com">hyc(a)symas.com</a>> wrote:</span><br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> The log says that ITS#4638 was already fixed in 2.3.32. Why are you<br>still using that particular patch, given that an alternate solution is<br>already present in the release?</blockquote><div><br>I can't replicate ITS#4638 under 2.3.32, so you can mark ITS#4907 resolved (I removed the bad patch).<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I also see that in RE23 we had one more patch to fix some interaction <br>between slapo-rwm and back-meta for filter processing. I suggest you<br>test against the current RE23 code. I expect to push 2.3.35 out pretty soon.</blockquote><div><br>Thank you. <br></div><br></div>Sean ------=_Part_45311_2874873.1175811229646--

1 0

Re: (ITS#4913) configure & BerkleyDB
by ando＠sys-net.it 05 Apr '07

05 Apr '07

fredo(a)sundancer.us wrote: > Full_Name: Fred Obermann > Version: 2.3.34 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.20.15.25) > > > I just downloaded, built and installed openldap-2.3.34 using BerkeleyDB-4.5.20. > > > There seems to be a disconnect between where openldap-2.3.34 'configure' expects > db.h is and where Oracle's build procedure puts db.h. > > For 4.5.20, db.h is located in "/usr/local/BerkeleyDB.4.5/include". Setting: > CPPFLAGS="I/usr/local/BerkeleyDB.4.5/include", prior to invoking 'configure' Perhaps adding a "-" before "I" could help. Please check and report. > does not seem to enable 'configure' to find 'db.h'. Providing soft link from > /usr/local/BerkeleyDB.4.5/include/db.h to /usr/include seems to fix this > problem > > Furthermore there seems to be a disconnect between the Oracle naming convention > for the BerkeleyDB libraries and what openldap's 'configure' utility seems to > expect. > > I set: > LIBS=-L/usr/local/BerkeleyDB.4.5/lib prior to invoking 'configure' > > But 'configure' is looking for libdb45.a or libdb-45.a or libdb4.5.a. > > However, what the Oracle build procedure produces are: libdb-4.5.a > libdb-4.5.la libdb-4.5.so libdb-4.so libdb.a libdb.so > > Creating a soft link from libdb-4.5.a to libdb45.a seems to fix this problem. > > Nonetheless, it would be better if the 'configure' script were expanded to > gracefully handle this latest release of BerkeleyDB from Oracle. > > > > > > 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#4913) configure & BerkleyDB
by hyc＠symas.com 05 Apr '07

05 Apr '07

fredo(a)sundancer.us wrote: > Full_Name: Fred Obermann > Version: 2.3.34 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.20.15.25) > > > I just downloaded, built and installed openldap-2.3.34 using BerkeleyDB-4.5.20. > > > There seems to be a disconnect between where openldap-2.3.34 'configure' expects > db.h is and where Oracle's build procedure puts db.h. > > For 4.5.20, db.h is located in "/usr/local/BerkeleyDB.4.5/include". Setting: > CPPFLAGS="I/usr/local/BerkeleyDB.4.5/include", prior to invoking 'configure' > does not seem to enable 'configure' to find 'db.h'. Providing soft link from > /usr/local/BerkeleyDB.4.5/include/db.h to /usr/include seems to fix this > problem If that's exactly what you used, you're missing the "-" in CPPFLAGS="-I..." > Furthermore there seems to be a disconnect between the Oracle naming convention > for the BerkeleyDB libraries and what openldap's 'configure' utility seems to > expect. The configure script works perfectly fine with all 4.x releases of BerkeleyDB, including 4.6 which has not yet been publicly released. 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

← Newer
1
...
6
7
8
9
10
11
12
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2007