openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

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

(ITS#8938) ldap 2.4.40 replication
by p.vorkas＠live.com 19 Nov '18

19 Nov '18

Full_Name: Panayiotis V Version: 2.4.40 OS: centos 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.116.198.226) 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? thanks

1 0

Re: (ITS#8928) Reproducibility: Remove user, hostname, pwd from version string
by hyc＠symas.com 18 Nov '18

18 Nov '18

douglas.royds(a)taitradio.com wrote: > URL: ftp://ftp.openldap.org/incoming/douglas-royds-181120.patch > > > On 19/11/18 12:34 PM, Howard Chu wrote: > >> Thanks. According to this link, we shouldn't even need the date/time portion >> of this patch. >> >> Under the section "Reading the Variable" we have >>> gcc (>= 7, Debian >= 5.3.1-17, Debian >= 6.1.1-1) >> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e3e8c48c4a494d9da741c1c8e… >> >> I.e., gcc itself will set __DATE__ and __TIME__ accordingly if SOURCE_DATE_EPOCH is set. >> >> I'm inclined to just tweak WHOWHERE and let gcc handle the rest. > > > Once again, good point. I have removed the date and time changes from > the patch, and only kept the WHOWHERE change, still using the existence > of a SOURCE_DATE_EPOCH to decide whether to fix the string or not. > Thanks. Added to master. -- -- 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#8928) Reproducibility: Remove user, hostname, pwd from version string
by douglas.royds＠taitradio.com 18 Nov '18

18 Nov '18

URL: ftp://ftp.openldap.org/incoming/douglas-royds-181120.patch On 19/11/18 12:34 PM, Howard Chu wrote: > Thanks. According to this link, we shouldn't even need the date/time portion > of this patch. > > Under the section "Reading the Variable" we have >> gcc (>= 7, Debian >= 5.3.1-17, Debian >= 6.1.1-1) > https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e3e8c48c4a494d9da741c1c8e… > > I.e., gcc itself will set __DATE__ and __TIME__ accordingly if SOURCE_DATE_EPOCH is set. > > I'm inclined to just tweak WHOWHERE and let gcc handle the rest. Once again, good point. I have removed the date and time changes from the patch, and only kept the WHOWHERE change, still using the existence of a SOURCE_DATE_EPOCH to decide whether to fix the string or not.

1 0

Re: (ITS#8928) Reproducibility: Remove user, hostname, pwd from version string
by hyc＠symas.com 18 Nov '18

18 Nov '18

douglas.royds(a)taitradio.com wrote: > On 17/11/18 11:42 AM, Howard Chu wrote: > >> douglas.royds(a)taitradio.com wrote: >>> URL: ftp://ftp.openldap.org/incoming/douglas-royds-181026.patch >>> >>> This updated patch also sets the date and time strings to the >>> SOURCE_DATE_EPOCH. >> Are you intending a SOURCE_DATE_EPOCH to be a Unix time value? I.e., an integer? >> This value format needs to be documented. >> >> Unfortunately, your use of date -d is nonportable, it appears that only the GNU tools >> understand this option. It will fail on other platforms like *BSD, Solaris, that aren't >> using a GNU userland. >> >> Why can't you simply provide an already formatted date & time that can be used >> directly, instead of needing to be reformatted here? > > > URL: ftp://ftp.openldap.org/incoming/douglas-royds-181119.patch > > Good point about BSD, my mistake. I have modified the patch to support > BSD platforms as well, though I don't have access to a BSD platform to > test it. > > I have added a code comment with a link to the SOURCE_DATE_EPOCH > specification: https://reproducible-builds.org/specs/source-date-epoch/ > > A more human-readable description and tips for its use can be found > here: https://reproducible-builds.org/docs/source-date-epoch/ Thanks. According to this link, we shouldn't even need the date/time portion of this patch. Under the section "Reading the Variable" we have > gcc (>= 7, Debian >= 5.3.1-17, Debian >= 6.1.1-1) https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e3e8c48c4a494d9da741c1c8e… I.e., gcc itself will set __DATE__ and __TIME__ accordingly if SOURCE_DATE_EPOCH is set. I'm inclined to just tweak WHOWHERE and let gcc handle the rest. -- -- 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#8928) Reproducibility: Remove user, hostname, pwd from version string
by douglas.royds＠taitradio.com 18 Nov '18

18 Nov '18

On 17/11/18 11:42 AM, Howard Chu wrote: > douglas.royds(a)taitradio.com wrote: >> URL: ftp://ftp.openldap.org/incoming/douglas-royds-181026.patch >> >> This updated patch also sets the date and time strings to the >> SOURCE_DATE_EPOCH. > Are you intending a SOURCE_DATE_EPOCH to be a Unix time value? I.e., an integer? > This value format needs to be documented. > > Unfortunately, your use of date -d is nonportable, it appears that only the GNU tools > understand this option. It will fail on other platforms like *BSD, Solaris, that aren't > using a GNU userland. > > Why can't you simply provide an already formatted date & time that can be used > directly, instead of needing to be reformatted here? URL: ftp://ftp.openldap.org/incoming/douglas-royds-181119.patch Good point about BSD, my mistake. I have modified the patch to support BSD platforms as well, though I don't have access to a BSD platform to test it. I have added a code comment with a link to the SOURCE_DATE_EPOCH specification: https://reproducible-builds.org/specs/source-date-epoch/ A more human-readable description and tips for its use can be found here: https://reproducible-builds.org/docs/source-date-epoch/

1 0

Re: (ITS#8936) SASL/SCRAM-SHA-1 bind returns other(80) instead of invalidCredentials (49) in case of wrong password
by quanah＠symas.com 18 Nov '18

18 Nov '18

--On Sunday, November 18, 2018 7:20 PM +0100 Michael Str=C3=B6der=20 <michael(a)stroeder.com> wrote: >> since they're working on getting the 2.1.27 release out anytime now >> and this should likely be fixed as a part of that release. > It seems they cut the release yesterday: > > ftp://ftp.cyrusimap.org/cyrus-sasl/ Nice, they said they were going to cut another RC first. Guess that went=20 out the window:=20 <https://lists.andrew.cmu.edu/pipermail/cyrus-devel/2018-November/004383.htm= l> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

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