openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

(ITS#7028) [PATCH] various manpage fixes
by jvcelak＠redhat.com 24 Aug '11

24 Aug '11

Full_Name: Jan Vcelak Version: master OS: Linux URL: Submission from: (NULL) (209.132.186.34) Hi, I have uploaded various manual page fixes which are included in Fedora. ftp://ftp.openldap.org/incoming/jvcelak-20110804-man-slapo-unique.patch - adds information about missing quotes around keyword and uri (maybe ITS #6181) - adds missing <attribute...> parameter ftp://ftp.openldap.org/incoming/jvcelak-20110804-man-ldap_sync.patch - fixes invalid prototype of ldap_sync_destroy Jan

1 0

Re: (ITS#7027) [PATCH] Implement priority/weight for DNS SRV records
by james.leddy＠redhat.com 23 Aug '11

23 Aug '11

File at james-leddy-110823.patch.1 The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat Inc. Red Hat Inc. has not assigned rights and/or interest in this work to any party. I, James M. Leddy am authorized by Red Hat Inc., my employer, to release this work under the following terms. Red Hat Inc. hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. -- James M. Leddy Technical Account Manager Red Hat Inc.

1 0

(ITS#7027) [PATCH] Implement priority/weight for DNS SRV records
by james.leddy＠redhat.com 23 Aug '11

23 Aug '11

Full_Name: James M Leddy Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.187.233.202) >From RFC 2782: A client MUST attempt to contact the target host with the lowest-numbered priority it can reach. This patch sorts the DNS SRV records by their priority, and additionally gives records with a larger weight a higher probability of appearing earlier. This way, the DNS SRV records are tried in the order of their priority.

1 0

Re: (ITS#7026) "the backglue code doesn't install a handler for the Abandon operation"
by hans.moser＠ofd-z.niedersachsen.de 23 Aug '11

23 Aug '11

hans.moser(a)ofd-z.niedersachsen.de schrieb: > Full_Name: Marc Patermann > Version: 2.4.26 > OS: SLES 11 SP1 x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.37.205.30) This is only a double post (reloading the ITS page by accident) of #7025 and can be closed. Sorry. Marc

1 0

(ITS#7026) "the backglue code doesn't install a handler for the Abandon operation"
by hans.moser＠ofd-z.niedersachsen.de 23 Aug '11

23 Aug '11

Full_Name: Marc Patermann Version: 2.4.26 OS: SLES 11 SP1 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.37.205.30) Hi, thankfully Howard tracked down the issue I posted on openldap-technical as "provider crash on high replication load" down to: "I believe the problem is much simpler - the backglue code doesn't install a handler for the Abandon operation, and this is preventing syncprov's abandon handler from running, so it never gets to clean up when a consumer connection closes. By now you should submit a bug report to the ITS so we can track this further. It should only require a small patch to the backglue code." The provider has three databases, which are glued together under one root database. Each of the three subordinates is replicated by about 60 consumers. On heavy replication load (all 180 consumers do initial sync), I can crash the server with on little mod on an object in one of the subordinate databases. If I can provide any further information on this, please let me know.

1 0

Re: (ITS#7024) OpenLDAP does not save the attribute "jpegPhoto" in the sql database
by masarati＠aero.polimi.it 23 Aug '11

23 Aug '11

> >> back-sql calls backsql_BindParamBerVal(), which indeed considers the >> data as >> SQL_C_CHAR, SQL_VARCHAR. A binary variant can be easily defined, but >> back-sql >> will need to know what attribute values need to be treated as binaries. >> A >> general approach to this requires to modify the attribute mapping, to >> add a >> "type" flag. >> >> p. >> > I have carefully read the documentation (man slapd-sql) but could not > find how to modify the attribute mapping and add a "type" flag. I meant: modify the code. Since back-sql is basically unmaintained (any volunteers out there?) this feature won't likely be added, not to mention the fact that it would break all existing installations. p.

1 0

(ITS#7025) "the backglue code doesn't install a handler for the Abandon operation"
by hans.moser＠ofd-z.niedersachsen.de 23 Aug '11

23 Aug '11

1 0

Re: (ITS#7024) OpenLDAP does not save the attribute "jpegPhoto" in the sql database
by daniil＠chics.ru 22 Aug '11

22 Aug '11

> back-sql calls backsql_BindParamBerVal(), which indeed considers the data as > SQL_C_CHAR, SQL_VARCHAR. A binary variant can be easily defined, but back-sql > will need to know what attribute values need to be treated as binaries. A > general approach to this requires to modify the attribute mapping, to add a > "type" flag. > > p. > I have carefully read the documentation (man slapd-sql) but could not find how to modify the attribute mapping and add a "type" flag.

1 0

Re: (ITS#7024) OpenLDAP does not save the attribute "jpegPhoto" in the sql database
by Pierangelo Masarati 22 Aug '11

22 Aug '11

back-sql calls backsql_BindParamBerVal(), which indeed considers the data as SQL_C_CHAR, SQL_VARCHAR. A binary variant can be easily defined, but back-sql will need to know what attribute values need to be treated as binaries. A general approach to this requires to modify the attribute mapping, to add a "type" flag. p.

1 0

Re: (ITS#6993)
by masarati＠aero.polimi.it 22 Aug '11

22 Aug '11

> Hello > > This problem occurs at the end of the connection init. > At the end of the connection_init, the connection is provided to the > listener list (through slapd_add_internal call) and then, the connection > mutex is freed. > > ==> At this point, the connection is available to the listener but the > back end initialization has not been done. > > The backend_connection_init call is done out of the connection mutex > protection. > If the connection mutex is freed after the connection_init call, all the > back end should performed their initialization before it could be used > in the operation Thank you. I understand your point, and I agree that the connection initialization is not over until all backends had an opportunity to deal with it. My concern is about any harm this change may cause to existing code. A quick search in official backends and overlays shows that only slapo-rwm(5) is currently setting this hook. Let alone this possible bug, this fact triggers something in my mind: bi_connection_init() might not be the best place for your initialization to occur. In fact, this is intended to provide something to *all* connections, but a connection being created does not imply that your backend will be used, so it may be a waste of resources to initialize your backend for *all* connections. You might be better off initializing your backend's connections only when they are actually needed, i.e. each operation within your backend should (mutex-protected) check whether initialization occurred and, if it didn't, do it; if it's ongoing, just pause waiting for it to finish. p.

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