- openldap-bugs - openldap.org

Re: (ITS#6320)
by hyc＠symas.com 01 Oct '09

01 Oct '09

j(a)telepaths.org wrote: > Sorry about that .... resending to ITS address: > > Regarding use of the accesslog DB ..... is this still an option when > using 'mirrormode' ? I understand at least in the recent past, this > option was not compatible with the accesslog overlay ..... That's not correct. The accesslog overlay can always be used for logging purposes. It is just that using it for multimaster delta-syncrepl is not yet supported. -- -- Howard Chu CTO, 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#6217) proxycache not returning cached data
by masarati＠aero.polimi.it 01 Oct '09

01 Oct '09

> Sounds more like a schema config issue then. Most likely you don't have > the > matching schema in the proxy server, so it is unable to store the entries > it > has received. That was my first thought as well, but the proxy's slapd.conf he posted earlier included some samba-related schema file (I'm blindly assuming that file was defining sambaSamAccount). p.

1 0

(ITS#6320)
by j＠telepaths.org 01 Oct '09

01 Oct '09

Sorry about that .... resending to ITS address: Regarding use of the accesslog DB ..... is this still an option when using 'mirrormode' ? I understand at least in the recent past, this option was not compatible with the accesslog overlay ..... Jeff

1 0

Re: (ITS#6217) proxycache not returning cached data
by hyc＠symas.com 01 Oct '09

01 Oct '09

Jim van Keulen wrote: > Howard Chu wrote: >> w.van.keulen(a)few.vu.nl wrote: >>> masarati(a)aero.polimi.it wrote: >>>>> Here are slapd.conf and proxycache.conf as attachments. >>>> >>>> I just wanted to feed back before I leave for a few days. I don't see >>>> anything critical in your files. You explicitly give the rootdn write >>>> permissions, which is useless, but apart from this everything looks >>>> fine. >>>> >>>> I've tested a simple setup and it works as expected. I used HEAD and >>>> re24 >>>> code; the latter is nearly identical to 2.4.17. I also tested with TLS. >>>> >>>> At this point, I'm a bit clueless. There must be something we're >>>> overlooking. >> >>> Here is some more info, that I just discovered. >>> If my filter rule is >>> '(&(objectClass=sambaSamAccount)(uid=wvk))' >>> the data is cached the first time, but not returned >>> the second and later time. However when my filter rule is >>> (&(objectClass=posixAccount)(uid=wvk))' >>> it works as expected. >> >> Sounds like you may have already had the entry in the cache DB but with >> an incompatible objectclass before, and the attempt to update it with >> the new objectclass failed. This seems to be related to ITS#6242 which >> was recently fixed in HEAD. Can you please retest with the latest >> overlays/pcache.c? >> > > As you requested I retested with HEAD. However the cache is still not > working correctly. > > When my filter rule is: > '(&(objectClass=posixAccount)(uid=<who>))' the named attributes are > cached and correctly returned from the cache for every uid from the > existing user base > When my filter rule is: > '(&(objectClass=sambaSamAccount)(uid=<who>))' the named attributes are > cached and correctly returned from the cache for a subset of the > existing user base only. For all uid's the query is cached (according to > the log), but for some no data is returned. Sounds more like a schema config issue then. Most likely you don't have the matching schema in the proxy server, so it is unable to store the entries it has received. -- -- Howard Chu CTO, 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#6320) Replication Issues
by quanah＠zimbra.com 01 Oct '09

01 Oct '09

--On Thursday, October 01, 2009 12:20 PM -0700 Jeff Doyle <j(a)telepaths.org> wrote: > Yes, that is the first thing attempted (both via using LOCAL4 -> syslog > and via running slapd via cmd line) > > We see a brand-new server replicate all records (sids, csns, etc all look > fine) without incident. An existing server will receive, as I said, all > of the changes ... at least for awhile. > > Nothing in the sync activity looks out of the ordinary (and I have read > quite a few posts to be able to discern what the items inside mean) > > When a replication error occurs, often nothing at all is seen inside the > logs (no error mesg, no segfault, nothing) to indicate a failure has > occurred. Oftentimes, when SyncRepl fails to replicate, it is NOT during > testing, so it is difficult for us to find out exactly WHEN the error > occurred, as it could have happened at any point within the past 24 hrs, > and up to a week ago. > > I can try to replicate this error deliberately. Unfortunately it is very > difficult to make happen at-will. My concern is that someone will try to > close this ticket before I have witnessed the event. Hm, I would suggest creating an accesslog database on the master that records all of your changes. That way, you can look at the CSN stamp of what failed and look at the change in the accesslog DB. It sounds like however that the replica syncrepl is simply failing to see the change occur on the master if it isn't logging anything about the missing change. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6320) Replication Issues
by j＠telepaths.org 01 Oct '09

01 Oct '09

Yes, that is the first thing attempted (both via using LOCAL4 -> syslog and via running slapd via cmd line) We see a brand-new server replicate all records (sids, csns, etc all look fine) without incident. An existing server will receive, as I said, all of the changes ... at least for awhile. Nothing in the sync activity looks out of the ordinary (and I have read quite a few posts to be able to discern what the items inside mean) When a replication error occurs, often nothing at all is seen inside the logs (no error mesg, no segfault, nothing) to indicate a failure has occurred. Oftentimes, when SyncRepl fails to replicate, it is NOT during testing, so it is difficult for us to find out exactly WHEN the error occurred, as it could have happened at any point within the past 24 hrs, and up to a week ago. I can try to replicate this error deliberately. Unfortunately it is very difficult to make happen at-will. My concern is that someone will try to close this ticket before I have witnessed the event. Jeff On Oct 1, 2009, at 12:14 PM, Quanah Gibson-Mount wrote: > --On Thursday, October 01, 2009 3:19 AM +0000 j(a)telepaths.org wrote: > >> >> --Apple-Mail-6--965444022 >> Content-Transfer-Encoding: 7bit >> Content-Type: text/plain; >> charset=us-ascii; >> format=flowed > > Have you set the loglevel on all servers to include "sync" level > logging? > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6320) Replication Issues
by quanah＠zimbra.com 01 Oct '09

01 Oct '09

--On Thursday, October 01, 2009 3:19 AM +0000 j(a)telepaths.org wrote: > > --Apple-Mail-6--965444022 > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; > charset=us-ascii; > format=flowed Have you set the loglevel on all servers to include "sync" level logging? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6319) opened files
by hyc＠symas.com 01 Oct '09

01 Oct '09

M8R-njfnr31(a)mailinator.com wrote: > Full_Name: Miki Manó > Version: 2.4.18 > OS: debian linux > URL: > Submission from: (NULL) (91.120.159.49) > > > hello > > i'm running slapd server with 100 clients over ssl. i see the server don't > close > the file descriptors always and the limit of open files is exceeded. how could > i > help your work to find this bug? > > file limit is reached too with following options: > > idletimeout 60 > writetimeout 60 > > the creation time of file descriptors is older than 60s. Please provide the output from "lsof" on the slapd process. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

ITS#6312 published: SECURITY: VC++: stdio.h(358) : error C3163: '_vsnprintf': attributes inconsistent with previous declaration
by openldap-its＠OpenLDAP.org 01 Oct '09

01 Oct '09

Private ITS#6312 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6312

1 0

ITS#6313 published: SECURITY: VC++: stdio.h(358) : error C3163: '_vsnprintf': attributes inconsistent with previous declaration
by openldap-its＠OpenLDAP.org 01 Oct '09

01 Oct '09

Private ITS#6313 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6313

1 0

ITS#6314 published: SECURITY: VC++: stdio.h(358) : error C3163: '_vsnprintf': attributes inconsistent with previous declaration
by openldap-its＠OpenLDAP.org 01 Oct '09

01 Oct '09

Private ITS#6314 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6314

1 0

ITS#6315 published: SECURITY: VC++: stdio.h(358) : error C3163: '_vsnprintf': attributes inconsistent with previous declaration
by openldap-its＠OpenLDAP.org 01 Oct '09

01 Oct '09

Private ITS#6315 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6315

1 0

ITS#6316 published: SECURITY: VC++: stdio.h(358) : error C3163: '_vsnprintf': attributes inconsistent with previous declaration
by openldap-its＠OpenLDAP.org 01 Oct '09

01 Oct '09

Private ITS#6316 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6316

1 0

ITS#6317 published: SECURITY: _vsnprintf
by openldap-its＠OpenLDAP.org 01 Oct '09

01 Oct '09

Private ITS#6317 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6317

1 0

ITS#6318 published: SECURITY: vsnprintf
by openldap-its＠OpenLDAP.org 01 Oct '09

01 Oct '09

Private ITS#6318 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6318

1 0

Re: (ITS#6217) proxycache not returning cached data
by w.van.keulen＠few.vu.nl 01 Oct '09

01 Oct '09

Howard Chu wrote: > w.van.keulen(a)few.vu.nl wrote: >> masarati(a)aero.polimi.it wrote: >>>> Here are slapd.conf and proxycache.conf as attachments. >>> >>> I just wanted to feed back before I leave for a few days. I don't see >>> anything critical in your files. You explicitly give the rootdn write >>> permissions, which is useless, but apart from this everything looks >>> fine. >>> >>> I've tested a simple setup and it works as expected. I used HEAD and >>> re24 >>> code; the latter is nearly identical to 2.4.17. I also tested with TLS. >>> >>> At this point, I'm a bit clueless. There must be something we're >>> overlooking. > >> Here is some more info, that I just discovered. >> If my filter rule is >> '(&(objectClass=sambaSamAccount)(uid=wvk))' >> the data is cached the first time, but not returned >> the second and later time. However when my filter rule is >> (&(objectClass=posixAccount)(uid=wvk))' >> it works as expected. > > Sounds like you may have already had the entry in the cache DB but with > an incompatible objectclass before, and the attempt to update it with > the new objectclass failed. This seems to be related to ITS#6242 which > was recently fixed in HEAD. Can you please retest with the latest > overlays/pcache.c? > As you requested I retested with HEAD. However the cache is still not working correctly. When my filter rule is: '(&(objectClass=posixAccount)(uid=<who>))' the named attributes are cached and correctly returned from the cache for every uid from the existing user base When my filter rule is: '(&(objectClass=sambaSamAccount)(uid=<who>))' the named attributes are cached and correctly returned from the cache for a subset of the existing user base only. For all uid's the query is cached (according to the log), but for some no data is returned. regards Jim van K -- // Set startup state to online user_pref("offline.startup_state", 2);

1 0

Re: (ITS#6320) Replication Issues
by j＠telepaths.org 30 Sep '09

30 Sep '09

--Apple-Mail-6--965444022 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Forgive the typo: Our entire DIT is replicated in full, with no consistencies Where I meant: with no inconsistencies Sorry .. Jeff --Apple-Mail-6--965444022 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii <html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Forgive the typo:<div><br></div><div><span class="Apple-style-span" style="font-family: monospace; white-space: pre; ">Our entire DIT is replicated in full, with no consistencies</span></div><div><div><br></div><div>Where I meant:</div><div><br></div><div><span class="Apple-style-span" style="font-family: monospace; white-space: pre; ">with no inconsistencies</span></div><div><div><br></div><div><div>Sorry ..</div><div><br></div><div>Jeff</div></div></div></div></body></html> --Apple-Mail-6--965444022--

1 0

(ITS#6320) Replication Issues
by j＠telepaths.org 30 Sep '09

30 Sep '09

Full_Name: Jeff Doyle Version: 2.4.17 OS: Debian/Lenny URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (68.15.14.98) Greetings, I am faced with a persistent replication issue for which I am seeking guidance. First, my infrastructure: My organization is running Debian/Lenny .... HOWEVER we have backported a future release of Debian's ''slapd'' release to be more in-line with OpenLDAP current releases (as the actual release of ''slapd'' in Lenny is 2.4.11 is too far-behind, given some of the posts I've read on your site). We are running 2.4.17. I am absolutely stumped with random replication inconsistencies that have me running in circles. We're having random issues involving records added to a provider server not being replicated to all consumers. This occurs on a very random basis. It can occur with a single record, or many. Because of the severity of this issue, I have written a pretty gnarly script to check the content of each server and when differences are found, send out an alert. This script is run via cron. I simply cannot determine why our replication fails when it does. Here is a SyncRepl stanza from a "consumer" LDAP server in question: syncrepl rid=001 provider=ldaps://10.9.8.3:636/ bindmethod=simple binddn="uid=syncrepl,dc=example,dc=com" credentials=password scope=sub filter="(objectClass=*)" schemachecking=off searchbase="dc=example,dc=com" retry="120 +" sizelimit=unlimited timeout=1 type=refreshOnly interval=00:00:07:00 BE ADVISED, I have tried variations of this stanza involving: * Changing from refreshOnly to refreshAndPersist (and subsequently removing the 'interval' parameter, as it is not needed with refreshAndPersist) * Trying longer and shorter intervals, when still using refreshOnly * Trying repeated "retry" integers both with and without the "forever (+)" parameter * Using NO encryption, and also using StartTLS over 389 as opposed to LDAPS/636 * With and without the "filter" parameter * With and without the schemachecking parameter * With and without the timeout parameter * Tried the 'network-timeout' parameter with a variety of integers (after reading the man page) * Using SASL/Kerberos for the bind method instead of simple binds * Using the ROOTDN for the user instead of our dedicated SyncRepl user (who has Confirmed 100% read-access to the DIT and ALL of its OCs and Attributes) Assuming we just built this slave (with the stanza above) in our production environment, starting slapd with any mix of debugging modes show normal syncrepl, ber, acl-processing and other activities in progress. Everything seems fine. Our entire DIT is replicated in full, with no consistencies. Network conditions between all hosts is relatively calm. No policy issues or routing issues exist. LDAP search operations from every possible angle are tested. The network is internally wide-open to itself. Everything looks fine on both the provider and consumer. We can add records to a Provider server, and the records (or changes to existing records, such as deletions) are replicated just fine to the consumer. We can try this for any length of time without errors. Using a variety of 'delays' between operations, bind-users, etc. All conceivable permutations end in success. OK, now ... wait any specified amount of time. A day or two, maybe a week (during which all of the servers are doing mostly READ operations). I receive an alert via email: Records have stopped replicating to one or more hosts. We don't understand why. The prescribed fix for it its to delete the slave's database and let it rebuild. But calling that solution a "Hack" doesn't quite tell you how i Really feel about it. Help. Please. This is not production-grade behavior, I think you would agree. If you want more of my slapd.conf or other details, Just ask, and I will promptly supply them. Thanks Jeff

1 0

(ITS#6312)
by neustradamus＠hotmail.com 30 Sep '09

30 Sep '09

--_add76be3-02e1-47b1-b978-259bce59b479_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You must change in configure and \include\PORTABLE.H : #define vsnprintf _vsnprintf with #if _MSC_VER < 1500 // 1500 =3D=3D VC++ 9.0 #define vsnprintf _vsnprintf #endif or #if _MSC_VER < 1500 #define vsnprintf _vsnprintf #endif Sorry for issues ITS#6313 at ITS#6318 but I have an error : "The system encountered a fatal error can't get info in find_id The last error code was: No such file or directory" Thanks in advance=2C Regards=2C Neustradamus =0A= _________________________________________________________________=0A= In=E9dit ! Des Emotic=F4nes D=E9jant=E9es! Installez les dans votre Messeng= er !=0A= http://www.ilovemessenger.fr/Emoticones/EmoticonesDejantees.aspx= --_add76be3-02e1-47b1-b978-259bce59b479_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style></style> </head> <body class=3D'hmmessage'> You must change in configure and \include\PORTABLE.H :<br><br>#define vsnpr= intf _vsnprintf<br><br>with<br><br>#if _MSC_VER &lt=3B 1500&nbsp=3B // 1500= =3D=3D VC++ 9.0<br>#define vsnprintf _vsnprintf<br> #endif<br><br>or<br><b= r> #if _MSC_VER &lt=3B 1500<br>#define vsnprintf _vsnprintf<br> #endif<br><= br> Sorry for issues ITS#6313 at ITS#6318 but I have an error :<br>"The sys= tem encountered a fatal error<br>can't get info in find_id<br>The last erro= r code was: No such file or directory"<br><br>Thanks in advance=2C<br><br>R= egards=2C<br><br>Neustradamus<br> <br /><hr />Souhaitez vous =A0= =AB=A0=EAtre au bureau sans y =EAtre=A0=BB=A0? <a href=3D'http://www.micros= oft.com/france/windows/bts/default.mspx' target=3D'_new'>Oui je le veux !</= a></body> </html>= --_add76be3-02e1-47b1-b978-259bce59b479_--

1 0

(ITS#6319) opened files
by M8R-njfnr31＠mailinator.com 30 Sep '09

30 Sep '09

Full_Name: Miki Manó Version: 2.4.18 OS: debian linux URL: Submission from: (NULL) (91.120.159.49) hello i'm running slapd server with 100 clients over ssl. i see the server don't close the file descriptors always and the limit of open files is exceeded. how could i help your work to find this bug? file limit is reached too with following options: idletimeout 60 writetimeout 60 the creation time of file descriptors is older than 60s.

1 0

Re: (ITS#6311) configure --enable-dds/--enable-deref broken
by hyc＠symas.com 29 Sep '09

29 Sep '09

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > configure.in says > if test "$ol_enable_deref" != no ; then > BUILD_DDS=$ol_enable_deref > instead of > BUILD_DEREF=$ol_enable_deref > That breaks e.g. --enable-dds --disable-deref. > Also BUILD_DEREF is not initialized and has no AC_SUBST(). > Is deref supposed to be in configure? > ITS#5768 says deref was committed to RE24 so presumably so. This is now fixed in HEAD... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6311) configure --enable-dds/--enable-deref broken
by h.b.furuseth＠usit.uio.no 29 Sep '09

29 Sep '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard configure.in says if test "$ol_enable_deref" != no ; then BUILD_DDS=$ol_enable_deref instead of BUILD_DEREF=$ol_enable_deref That breaks e.g. --enable-dds --disable-deref. Also BUILD_DEREF is not initialized and has no AC_SUBST(). Is deref supposed to be in configure?

1 0

Re: (ITS#6302) second-guessing of libsasl ABI is incorrect for Linux distributions
by h.b.furuseth＠usit.uio.no 29 Sep '09

29 Sep '09

hyc(a)symas.com writes: > Though it goes against our usual desire to minimize distro-specific patch > maintenance, I think in this case I have to recommend that you continue to > carry this patch on your side. Wrap such code in #ifdef on OPTIMISTIC_LIBVERSION_SASL or something in OpenLDAP, so that people with 3rd party code done right can ./configure CPPFLAGS=-DOPTIMISTIC_LIBVERSION_SASL instead of patching the code? -- Hallvard

1 0

Re: (ITS#6305) slapo-chain(5): description for chain-rebind-as-user missing
by hyc＠symas.com 29 Sep '09

29 Sep '09

Michael Ströder wrote: > hyc(a)symas.com wrote: >> michael(a)stroeder.com wrote: >>> Full_Name: Michael Ströder >>> Version: HEAD >>> OS: >>> URL: >>> Submission from: (NULL) (84.163.127.85) >>> >>> >>> In slapo-chain(5) there is no descriptive text for configuration directive >>> 'chain-rebind-as-user' yet like for the other directives. >> >> rebind-as-user is in slapd-ldap(5) and the slapo-chain(5) manpage already states: >> >> >> >> There are very few chain overlay specific directives; however, directives >> related to the instances of the ldap backend that may be implicitly >> instantiated by the overlay may assume a special meaning when used in >> conjunction with this overlay. They are described in slapd−ldap(5), and they >> also need to be prefixed by chain−. >> << >> >> I don't see any need for action here, this ITS will be closed. > > I disagree. IMO each possible configuration directive should be mentioned > literally. I agree that the text could be limited to "this means 'foo' > prefixed with 'bar'". Too much duplication of effort, IMO. But feel free to submit a patch. -- -- Howard Chu CTO, 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#6305) slapo-chain(5): description for chain-rebind-as-user missing
by michael＠stroeder.com 29 Sep '09

29 Sep '09

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Full_Name: Michael Ströder >> Version: HEAD >> OS: >> URL: >> Submission from: (NULL) (84.163.127.85) >> >> >> In slapo-chain(5) there is no descriptive text for configuration directive >> 'chain-rebind-as-user' yet like for the other directives. > > rebind-as-user is in slapd-ldap(5) and the slapo-chain(5) manpage already states: > > >> > There are very few chain overlay specific directives; however, directives > related to the instances of the ldap backend that may be implicitly > instantiated by the overlay may assume a special meaning when used in > conjunction with this overlay. They are described in slapd−ldap(5), and they > also need to be prefixed by chain−. > << > > I don't see any need for action here, this ITS will be closed. I disagree. IMO each possible configuration directive should be mentioned literally. I agree that the text could be limited to "this means 'foo' prefixed with 'bar'". Ciao, Michael.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs