Re: (ITS#8940) FR: LDAP_AVA_FREE_ATTR in ldapava_free()
by hyc＠symas.com
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/
5 years
Re: (ITS#8940) FR: LDAP_AVA_FREE_ATTR in ldapava_free()
by erik＠halon.se
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.
>>>
>>
>
5 years
Re: (ITS#8940) FR: LDAP_AVA_FREE_ATTR in ldapava_free()
by hyc＠symas.com
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/
5 years
Re: (ITS#8940) FR: LDAP_AVA_FREE_ATTR in ldapava_free()
by erik＠halon.se
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.
>
5 years
Re: (ITS#8940) FR: LDAP_AVA_FREE_ATTR in ldapava_free()
by hyc＠symas.com
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/
5 years
(ITS#8940) FR: LDAP_AVA_FREE_ATTR in ldapava_free()
by erik＠halon.se
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....
5 years
(ITS#8939) back-sql broken, backsql_oc_get_attr_mapping() fails
by jl＠conductive.de
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
5 years
Re: (ITS#8938) ldap 2.4.40 replication
by michael＠stroeder.com
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.
5 years
(ITS#8938) ldap 2.4.40 replication
by p.vorkas＠live.com
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
5 years
Re: (ITS#8928) Reproducibility: Remove user, hostname, pwd from version string
by hyc＠symas.com
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=e3e8c48c4a494d9da741c1c...
>>
>> 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/
5 years
