openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

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 01 Oct '09

01 Oct '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 01 Oct '09

01 Oct '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

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