openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#8942) Font correction in man pages
by jtrupp＠symas.com 04 Dec '18

04 Dec '18

Full_Name: Jason Trupp Version: 2.4.46 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.197.13.194) The impacted man pages contain the following (example) .ft setting in the "EXAMPLES" section: .ft tt /opt/symas/bin/slapadd \-l ldif .ft "tt" refers to the mono-spaced font "teletype" which is no longer recognized by groff/troff and modern web browsers. The affected man pages include: ./man8/slapadd.8, ./man8/slapcat.8, ./man8/slapacl.8, ./man8/slaptest.8, ./man8/slapdn.8, ./man8/slapindex.8, ./man8/slapmodify.8, ./man8/slapd.8, ./man8/slapschema.8, ./man8/slapauth.8 and ./man5/ldif.5 The current verbiage should be replaced by: .EX /opt/symas/bin/slapadd \-l ldif .EE Please refer to man 7 groff_man for an explanation of these settings. The replacement syntax has been tested and works as expected.

1 0

(ITS#8941) Font correction in man pages
by jtrupp＠symas.com 04 Dec '18

04 Dec '18

1 0

Re: (ITS#8940) FR: LDAP_AVA_FREE_ATTR in ldapava_free()
by hyc＠symas.com 30 Nov '18

30 Nov '18

Erik Lax wrote: > It's building a custom LDAPDN object from an internal data structure to be used with ldap_dn2str(). The use-case for such flag/pointer ownership for others may > be limited as I suspect not so many build their own LDAPDN objects from scratch. That doesn't matter. You still aren't going to be constructing from an open ended set of RDN attributeTypes. Make them constants and forget about it. > > Regards > Erik > > On 2018-11-30 16:11, Howard Chu wrote: >> Erik Lax wrote: >>> In our case the pointer/allocated string ownership is preferable moved to the LDAPAVA object for both the value and attribute as the char* does not have the >>> same lifetime as the LDAPAVA object. >> Then your app is almost certainly mis-designed. The set of attributeTypes in a schema is always finite >> and usually small; alloc'ing and free'ing the same strings over and over is foolish. >> >> Out of curiosity, what is your software actually trying to do? >>> Regards >>> Erik >>> >>> On 2018-11-30 14:51, Howard Chu wrote: >>>> erik(a)halon.se wrote: >>>>> Full_Name: Erik Lax >>>>> Version: 2.4.46 >>>>> OS: Linux >>>>> URL: >>>>> Submission from: (NULL) (212.85.68.184) >>>>> >>>>> >>>>> Hi, >>>>> >>>>> It's possible to set the flag LDAP_AVA_FREE_VALUE to clear ber values on the >>>>> LDAPAVA structure in ldapava_free() but it's not possible to set the >>>>> LDAP_AVA_FREE_ATTR to clear attributes. I suspect OpenLDAP internals does not >>>>> need to free attributes in this way (hence the missing code). >>>> Attribute Types are usually constant strings, so right, there should be no need to free them. >>>> >>>>> I'm building a custom LDAPAVA (LDAPDN) object and it would be useful to be able >>>>> to set this flags to have it properly clean up both values and attributes in >>>>> ldap_dnfree(). >>>> It would be better to simply avoid the need to free them. >>>> >>> >> > > -- -- 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#8940) FR: LDAP_AVA_FREE_ATTR in ldapava_free()
by erik＠halon.se 30 Nov '18

30 Nov '18

It's building a custom LDAPDN object from an internal data structure to be used with ldap_dn2str(). The use-case for such flag/pointer ownership for others may be limited as I suspect not so many build their own LDAPDN objects from scratch. Regards Erik On 2018-11-30 16:11, Howard Chu wrote: > Erik Lax wrote: >> In our case the pointer/allocated string ownership is preferable moved to the LDAPAVA object for both the value and attribute as the char* does not have the >> same lifetime as the LDAPAVA object. > Then your app is almost certainly mis-designed. The set of attributeTypes in a schema is always finite > and usually small; alloc'ing and free'ing the same strings over and over is foolish. > > Out of curiosity, what is your software actually trying to do? >> Regards >> Erik >> >> On 2018-11-30 14:51, Howard Chu wrote: >>> erik(a)halon.se wrote: >>>> Full_Name: Erik Lax >>>> Version: 2.4.46 >>>> OS: Linux >>>> URL: >>>> Submission from: (NULL) (212.85.68.184) >>>> >>>> >>>> Hi, >>>> >>>> It's possible to set the flag LDAP_AVA_FREE_VALUE to clear ber values on the >>>> LDAPAVA structure in ldapava_free() but it's not possible to set the >>>> LDAP_AVA_FREE_ATTR to clear attributes. I suspect OpenLDAP internals does not >>>> need to free attributes in this way (hence the missing code). >>> Attribute Types are usually constant strings, so right, there should be no need to free them. >>> >>>> I'm building a custom LDAPAVA (LDAPDN) object and it would be useful to be able >>>> to set this flags to have it properly clean up both values and attributes in >>>> ldap_dnfree(). >>> It would be better to simply avoid the need to free them. >>> >> >

1 0

Re: (ITS#8940) FR: LDAP_AVA_FREE_ATTR in ldapava_free()
by hyc＠symas.com 30 Nov '18

30 Nov '18

Erik Lax wrote: > In our case the pointer/allocated string ownership is preferable moved to the LDAPAVA object for both the value and attribute as the char* does not have the > same lifetime as the LDAPAVA object. Then your app is almost certainly mis-designed. The set of attributeTypes in a schema is always finite and usually small; alloc'ing and free'ing the same strings over and over is foolish. Out of curiosity, what is your software actually trying to do? > > Regards > Erik > > On 2018-11-30 14:51, Howard Chu wrote: >> erik(a)halon.se wrote: >>> Full_Name: Erik Lax >>> Version: 2.4.46 >>> OS: Linux >>> URL: >>> Submission from: (NULL) (212.85.68.184) >>> >>> >>> Hi, >>> >>> It's possible to set the flag LDAP_AVA_FREE_VALUE to clear ber values on the >>> LDAPAVA structure in ldapava_free() but it's not possible to set the >>> LDAP_AVA_FREE_ATTR to clear attributes. I suspect OpenLDAP internals does not >>> need to free attributes in this way (hence the missing code). >> Attribute Types are usually constant strings, so right, there should be no need to free them. >> >>> I'm building a custom LDAPAVA (LDAPDN) object and it would be useful to be able >>> to set this flags to have it properly clean up both values and attributes in >>> ldap_dnfree(). >> It would be better to simply avoid the need to free them. >> > > -- -- 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#8940) FR: LDAP_AVA_FREE_ATTR in ldapava_free()
by erik＠halon.se 30 Nov '18

30 Nov '18

In our case the pointer/allocated string ownership is preferable moved to the LDAPAVA object for both the value and attribute as the char* does not have the same lifetime as the LDAPAVA object. Regards Erik On 2018-11-30 14:51, Howard Chu wrote: > erik(a)halon.se wrote: >> Full_Name: Erik Lax >> Version: 2.4.46 >> OS: Linux >> URL: >> Submission from: (NULL) (212.85.68.184) >> >> >> Hi, >> >> It's possible to set the flag LDAP_AVA_FREE_VALUE to clear ber values on the >> LDAPAVA structure in ldapava_free() but it's not possible to set the >> LDAP_AVA_FREE_ATTR to clear attributes. I suspect OpenLDAP internals does not >> need to free attributes in this way (hence the missing code). > Attribute Types are usually constant strings, so right, there should be no need to free them. > >> I'm building a custom LDAPAVA (LDAPDN) object and it would be useful to be able >> to set this flags to have it properly clean up both values and attributes in >> ldap_dnfree(). > It would be better to simply avoid the need to free them. >

1 0

Re: (ITS#8940) FR: LDAP_AVA_FREE_ATTR in ldapava_free()
by hyc＠symas.com 30 Nov '18

30 Nov '18

erik(a)halon.se wrote: > Full_Name: Erik Lax > Version: 2.4.46 > OS: Linux > URL: > Submission from: (NULL) (212.85.68.184) > > > Hi, > > It's possible to set the flag LDAP_AVA_FREE_VALUE to clear ber values on the > LDAPAVA structure in ldapava_free() but it's not possible to set the > LDAP_AVA_FREE_ATTR to clear attributes. I suspect OpenLDAP internals does not > need to free attributes in this way (hence the missing code). Attribute Types are usually constant strings, so right, there should be no need to free them. > I'm building a custom LDAPAVA (LDAPDN) object and it would be useful to be able > to set this flags to have it properly clean up both values and attributes in > ldap_dnfree(). It would be better to simply avoid the need to free them. -- -- 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#8940) FR: LDAP_AVA_FREE_ATTR in ldapava_free()
by erik＠halon.se 30 Nov '18

30 Nov '18

Full_Name: Erik Lax Version: 2.4.46 OS: Linux URL: Submission from: (NULL) (212.85.68.184) Hi, It's possible to set the flag LDAP_AVA_FREE_VALUE to clear ber values on the LDAPAVA structure in ldapava_free() but it's not possible to set the LDAP_AVA_FREE_ATTR to clear attributes. I suspect OpenLDAP internals does not need to free attributes in this way (hence the missing code). I'm building a custom LDAPAVA (LDAPDN) object and it would be useful to be able to set this flags to have it properly clean up both values and attributes in ldap_dnfree(). https://github.com/openldap/openldap/blob/master/libraries/libldap/getdn.c#…

1 0

(ITS#8939) back-sql broken, backsql_oc_get_attr_mapping() fails
by jl＠conductive.de 25 Nov '18

25 Nov '18

Full_Name: Joel Linn Version: 2.4.45 as well as git OS: Ubuntu (docker image) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.120.2.83) Hi, I wanted to use back-sql and tried against our Firebird database, as that didn't work i spun up a Postgres container with the data from the sources. For both cases it seems the backend is broken as it reports empty fields when loading the attribute mappings, although they are definetly not empty: 5bfaced6 backsql_oc_get_attr_mapping(): executing at_query "SELECT sel_expr_u,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,name FROM ldap_attr_mappings WHERE oc_map_id=?" for objectClass "document" with param oc_id=2 5bfaced6 backsql_oc_get_attr_mapping(): required column #0 "name" is empty I played with the sources (moved the snprintf/DEBUG code before the field checking section that generates the error, around line 370 in schema-map.c) and found out that the first 3 columns are always null, you can confirm that by defining the at_query in slapd.conf and swapping the field names around. My guess is the binding in backsql_BindRowAsStrings is faulty. As I said i tried two different ODBC drivers. full log https://pastebin.com/4B2wjCLp configuration https://pastebin.com/JMwVVMDx

1 0

Re: (ITS#8938) ldap 2.4.40 replication
by michael＠stroeder.com 19 Nov '18

19 Nov '18

On 11/19/18 11:43 AM, p.vorkas(a)live.com wrote: > Its now been a month and i still couldn't find a way to create a replication > server. > I have transferred my old db from previous version of ldap. everything works > just fine except the replication part. > > i tried synproc etc but nothing.. does any one has some idea about that? The ITS is only used for reporting bugs. In general you should follow instructions in the OpenLDAP admin guide: https://www.openldap.org/doc/admin24/replication.html For asking usage questions please subscribe to openldap-technical mailing list and post your question there: https://www.openldap.org/lists/mm/listinfo/openldap-technical You should describe what you want to achieve, the exact version you're using, OS platform, the config you've tried and some relevant log excerpts if available. Ciao, Michael.

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