(ITS#8112) man pages suggest using deprecated fuctions
by quanah＠openldap.org
Full_Name: Quanah Gibson-Mount
Version: RE24
OS: NA
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (75.111.52.177)
ldap_get_dn(3) states that when using the ldap_explode_rdn function,
ldap_value_free can be used to free the results. However, ldap_value_free is
deprecated.
Making things worse, it is suggested that the replacement for ldap_value_free is
ldap_value_free_len. ldap_value_free_len expects a bval array, whereas
ldap_explode_rdn returns a char* array.
Finally, if you look at the actual OpenLDAP library code, what is done there
is:
vv = ldap_explode_rdn( values[ n ], 0 );
LDAP_VFREE( vv );
where:
#define LDAP_VFREE(v) (ber_memvfree_x((void **)(v),NULL))
so NEITHER ldap_value_free NOR ldap_value_free_len are even used when using the
ldap_explode_rdn function.
7 years, 7 months
Re: (ITS#8111) Re-ordering schema attributeTypes crashes slapd
by zach＠puppetlabs.com
Below is the attempted ldif modification.
dn: cn={5}puppet,cn=schema,cn=config
changetype: modify
replace: olcAttributeTypes
olcAttributeTypes: {1}( 1.3.6.1.4.1.34380.556 NAME ('github' 'githubUsername')
DESC 'github' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatc
h SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
olcAttributeTypes: {2}( 1.3.6.1.4.1.34380.558 NAME ('pronoun' 'preferredPronou
n') DESC 'prefered gender pronoun' EQUALITY caseIgnoreMatch SUBSTR case
IgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
olcAttributeTypes: {3}( 1.3.6.1.4.1.34380.560 NAME 'skills' DESC 'skills, lang
uages, specialties' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsM
atch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
olcAttributeTypes: {4}( 1.3.6.1.4.1.34380.562 NAME 'onCall' DESC 'whether they
are oncall or not that week' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.14
66.115.121.1.7 )
olcAttributeTypes: {5}( 1.3.6.1.4.1.34380.563 NAME 'googleGroups' DESC 'email
groups they are in' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsM
atch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
olcAttributeTypes: {6}( 1.3.6.1.4.1.34380.566 NAME 'projects' DESC 'ownership
of projects' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
olcAttributeTypes: {7}( 1.3.6.1.4.1.34380.569 NAME 'interestingFact' DESC 'int
eresting fact from first all hands' EQUALITY caseIgnoreMatch SUBSTR caseI
gnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
olcAttributeTypes: {8}( 1.3.6.1.4.1.34380.570 NAME ('twitterHandle' 'twitter')
DESC 'twitter handle' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstrin
gsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
olcAttributeTypes: {9}( 1.3.6.1.4.1.34380.571 NAME ('ircNickname' 'irc') DESC
'irc nickname' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
olcAttributeTypes: {10}( 1.3.6.1.4.1.34380.572 NAME 'shirtSize' DESC 'shirtsiz
e' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3
.6.1.4.1.1466.115.121.1.15 )
olcAttributeTypes: {11}( 1.3.6.1.4.1.34380.573 NAME 'dietaryRestrictions' DE
SC 'carnivore, omnivore, veg, vegan, glutenfree, soyfree, air free' EQUALIT
Y caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.146
6.115.121.1.15 )
olcAttributeTypes: {12}( 1.3.6.1.4.1.34380.567 NAME 'steamAccount' DESC 'ste
amaccount for games' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstrings
Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
olcAttributeTypes: {13}( 1.3.6.1.4.1.34380.801 NAME 'bribeMeWith' DESC 'thin
gs I like' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SY
NTAX 1.3.6.1.4.1.1466.115.121.1.15 )
olcAttributeTypes: {14}( 1.3.6.1.4.1.34380.802 NAME 'languages' DESC 'what d
o you speak' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
olcAttributeTypes: {15}( 1.3.6.1.4.1.34380.574 NAME 'x-kvm-access' DESC 'kvm
access level' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
olcAttributeTypes: {2}( 1.3.6.1.4.1.34380.557 NAME ('forge' 'forgeUsername')
DESC 'forge' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
--
Zach Leslie :: Puppet Labs
7 years, 7 months
(ITS#8111) Re-ordering schema attributeTypes crashes slapd
by zach＠puppetlabs.com
Full_Name: Zach Leslie
Version: 2.4.40-1
OS: Debian Wheezy
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (192.69.65.15)
I have a custom schema that contains a handful of attributeTypes and a few
objectClasses. If I add a new attributeType to the existing schema, and then
attempt to reorder that type, slapd crashes. Starting the service again, slapd
seems to behave normally, and the schema looks intact as it did prior to the
attempted order modification.
7 years, 7 months
Re: (ITS#8008) proxyauth with saslmech EXTERNAL not working
by mathieu.baeumler＠gmail.com
Hello,
just in case someone is still looking on this, I stumbled on the same
issue when upgrading openldap from an old version (2.4.2x) to 2.4.40.
Used first a debian package, then compiled it myself, same behaviour.
However, I managed to make it work by setting explicitly the
"override" flag in the chain-idassert-bind parameters ( I'm not sure
it's the right way to fix this "issue"):
chain-idassert-authzFrom "dn:*"
chain-idassert-bind bindmethod=sasl
saslmech="EXTERNAL"
mode=self
flags=override,proxy-authz-critical
starttls=critical
tls_cacert=/etc/ldap/ssl/CA.pem
tls_key=/etc/ldap/ssl/private/key.pem
tls_cert=/etc/ldap/ssl/proxy.pem
tls_reqcert=demand
For those who like the cn=config syntax better:
olcDbIDAssertBind: mode=self
flags=flags=prescriptive,override,proxy-authz-critical bindmethod=sasl
timeout=0 network-timeout=0 saslmech=EXTERNAL keepalive=0:0:0
starttls=critical tls_cert="/opt/SNet/etc/ldap/ssl/proxy.pem"
tls_key="/opt/SNet/etc/ldap/ssl/private/key.pem"
tls_cacert="/opt/SNet/etc/ldap/ssl/CA.pem" tls_reqcert=demand
Note:
Previous to that, the flags were NOT set explicitly, so the following
default values were used:
olcDbIDAssertBind: mode=self
flags=prescriptive,proxy-authz-non-critical bindmethod=sasl timeout=0
network-timeout=0 saslmech=EXTERNAL keepalive=0:0:0 starttls=critical
tls_cert="/opt/SNet/etc/ldap/ssl/proxy.pem"
tls_key="/opt/SNet/etc/ldap/ssl/private/key.pem"
tls_cacert="/opt/SNet/etc/ldap/ssl/CA.pem" tls_reqcert=demand
7 years, 7 months
Re: (ITS#8110) ldap_sasl_bind_s does not honor LDAP_OPT_NETWORK_TIMEOUT for TLS connections
by ahochhaus＠samegoal.com
On Tue, Apr 21, 2015 at 12:58 PM, Howard Chu <hyc(a)symas.com> wrote:
>
> ahochhaus(a)samegoal.com wrote:
>>
>> Full_Name: Andy
>> Version: 2.4.30
>> OS: Debian Linux (Jessie)
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (67.188.115.159)
>>
>>
>> Hello,
>>
>> When connecting over TLS to an LDAP server with high packet loss, my calls to
>> ldap_sasl_bind_s() block forever some of the time despite have set a 10s limit
>> on all of LDAP_OPT_NETWORK_TIMEOUT, LDAP_OPT_TIMEOUT and LDAP_OPT_TIMELIMIT.
>>
>> I see the following stack trace on the deadlocked process.
>>
>> @ 0x7f2ff0c0f8d0 (unknown)
>> @ 0x7f2ff0c0eac0 __libc_read
>> @ 0x5cdc68 sb_debug_read
>> @ 0x5c26f5 tlso_bio_read
>> @ 0x451b64 BIO_read
>> @ 0x49bf86 ssl3_read_n
>> @ 0x49d52b ssl3_get_record
>> @ 0x49caea ssl3_read_bytes
>> @ 0x496f61 ssl3_get_message
>> @ 0x496944 ssl3_get_finished
>> @ 0x5e4aab ssl3_connect
>> @ 0x5e164b ssl23_connect
>> @ 0x5c1b3c tlso_session_connect
>> @ 0x5b6773 ldap_int_tls_start
>> @ 0x5b3a77 ldap_int_open_connection
>> @ 0x5a730e ldap_new_connection
>> @ 0x5b3365 ldap_open_defconn
>> @ 0x5a68e3 ldap_send_initial_request
>> @ 0x5a4c1e ldap_sasl_bind
>> @ 0x5a4d99 ldap_sasl_bind_s
>>
>> Inspecting the source, I see that SSL_connect() is called from
>> tlso_session_connect(). Does openldap attempt to pass timeout information to
>> openssl?
>>
>> Sorry for the vague bug report. The issue is non-deterministic so it is hard to
>> provide too much information. Please let me know what I can do to be more
>> helpful.
>>
>> I was able to find an old posting (from 2006) reporting a similar issue. I'm
>> uncertain if the root cause is the same or not though.
>>
>> http://www.openldap.org/lists/openldap-software/200601/msg00440.html
>
>
> There is no API for setting a timeout in the TLS library.
>
> http://www.openldap.org/lists/openldap-software/200707/msg00346.html
Thanks for the pointer. Feel free to close this issue.
-Andy
7 years, 7 months
Re: (ITS#8110) ldap_sasl_bind_s does not honor LDAP_OPT_NETWORK_TIMEOUT for TLS connections
by hyc＠symas.com
ahochhaus(a)samegoal.com wrote:
> Full_Name: Andy
> Version: 2.4.30
> OS: Debian Linux (Jessie)
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (67.188.115.159)
>
>
> Hello,
>
> When connecting over TLS to an LDAP server with high packet loss, my calls to
> ldap_sasl_bind_s() block forever some of the time despite have set a 10s limit
> on all of LDAP_OPT_NETWORK_TIMEOUT, LDAP_OPT_TIMEOUT and LDAP_OPT_TIMELIMIT.
>
> I see the following stack trace on the deadlocked process.
>
> @ 0x7f2ff0c0f8d0 (unknown)
> @ 0x7f2ff0c0eac0 __libc_read
> @ 0x5cdc68 sb_debug_read
> @ 0x5c26f5 tlso_bio_read
> @ 0x451b64 BIO_read
> @ 0x49bf86 ssl3_read_n
> @ 0x49d52b ssl3_get_record
> @ 0x49caea ssl3_read_bytes
> @ 0x496f61 ssl3_get_message
> @ 0x496944 ssl3_get_finished
> @ 0x5e4aab ssl3_connect
> @ 0x5e164b ssl23_connect
> @ 0x5c1b3c tlso_session_connect
> @ 0x5b6773 ldap_int_tls_start
> @ 0x5b3a77 ldap_int_open_connection
> @ 0x5a730e ldap_new_connection
> @ 0x5b3365 ldap_open_defconn
> @ 0x5a68e3 ldap_send_initial_request
> @ 0x5a4c1e ldap_sasl_bind
> @ 0x5a4d99 ldap_sasl_bind_s
>
> Inspecting the source, I see that SSL_connect() is called from
> tlso_session_connect(). Does openldap attempt to pass timeout information to
> openssl?
>
> Sorry for the vague bug report. The issue is non-deterministic so it is hard to
> provide too much information. Please let me know what I can do to be more
> helpful.
>
> I was able to find an old posting (from 2006) reporting a similar issue. I'm
> uncertain if the root cause is the same or not though.
>
> http://www.openldap.org/lists/openldap-software/200601/msg00440.html
There is no API for setting a timeout in the TLS library.
http://www.openldap.org/lists/openldap-software/200707/msg00346.html
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 7 months
(ITS#8110) ldap_sasl_bind_s does not honor LDAP_OPT_NETWORK_TIMEOUT for TLS connections
by ahochhaus＠samegoal.com
Full_Name: Andy
Version: 2.4.30
OS: Debian Linux (Jessie)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (67.188.115.159)
Hello,
When connecting over TLS to an LDAP server with high packet loss, my calls to
ldap_sasl_bind_s() block forever some of the time despite have set a 10s limit
on all of LDAP_OPT_NETWORK_TIMEOUT, LDAP_OPT_TIMEOUT and LDAP_OPT_TIMELIMIT.
I see the following stack trace on the deadlocked process.
@ 0x7f2ff0c0f8d0 (unknown)
@ 0x7f2ff0c0eac0 __libc_read
@ 0x5cdc68 sb_debug_read
@ 0x5c26f5 tlso_bio_read
@ 0x451b64 BIO_read
@ 0x49bf86 ssl3_read_n
@ 0x49d52b ssl3_get_record
@ 0x49caea ssl3_read_bytes
@ 0x496f61 ssl3_get_message
@ 0x496944 ssl3_get_finished
@ 0x5e4aab ssl3_connect
@ 0x5e164b ssl23_connect
@ 0x5c1b3c tlso_session_connect
@ 0x5b6773 ldap_int_tls_start
@ 0x5b3a77 ldap_int_open_connection
@ 0x5a730e ldap_new_connection
@ 0x5b3365 ldap_open_defconn
@ 0x5a68e3 ldap_send_initial_request
@ 0x5a4c1e ldap_sasl_bind
@ 0x5a4d99 ldap_sasl_bind_s
Inspecting the source, I see that SSL_connect() is called from
tlso_session_connect(). Does openldap attempt to pass timeout information to
openssl?
Sorry for the vague bug report. The issue is non-deterministic so it is hard to
provide too much information. Please let me know what I can do to be more
helpful.
I was able to find an old posting (from 2006) reporting a similar issue. I'm
uncertain if the root cause is the same or not though.
http://www.openldap.org/lists/openldap-software/200601/msg00440.html
Thanks,
-Andy
7 years, 7 months
Re: (ITS#7145) cn=Connection 0
by hguo＠suse.com
Good day Michael.
I built the branch OPENLDAP_REL_ENG_2_4 revision d281bd3, unfortunately
connection 0 still shows up twice.
The source code of my test case is here:
https://github.com/HouzuoGuo/ldap-conn0
Would you mind to try it out in your test environment?
Thanks.
Regards,
Howard
On 10/04/15 15:44, Michael Ströder wrote:
> hguo(a)suse.com wrote:
>> Is your build identical to the 2.4.40 on OBS in terms of patches/source
>> code revision?
>
> No. It's RE24 with all changes to be released as 2.4.41.
>
>> What distribution did you use for testing?
>
> openSUSE Tumbleweed x86_64.
>
> Ciao, Michael.
> .
7 years, 7 months
Re: (ITS#8095) Patch
by rouzier＠gmail.com
--047d7bfcf1deec63470514165cd2
Content-Type: text/plain; charset=UTF-8
My Testing does show it is not worth it for the data size in the db.
Also there is a race condition using sendfile on linux that could happen.
It is avoidable but it would require changes to the protocol to avoid it
which I am not willing to do.
So dismiss my patch with extreme prejudice
On Wed, Apr 15, 2015 at 10:37 PM, Howard Chu <hyc(a)symas.com> wrote:
> rouzier(a)gmail.com wrote:
>
>> Full_Name: James Rouzier
>> Version:
>> OS:
>> URL: ftp://ftp.openldap.org/incoming/james-rouzier-150331.patch
>> Submission from: (NULL) (192.222.129.11)
>>
>>
>> I am working on a proof of concept of a simple key value store service
>> using
>> lmdb as the back end.
>> I am using sendfile to avoid an extra copy.
>> I accomplished this by creating function to extract get the mmap ptr from
>> the
>> env so I can calculate the offset of data.
>>
>
> I'm quite reluctant to return the mmap pointer. In a WRITEMAP environment
> that invites all manner of undetectable/unpreventable corruptions.
>
> Have you actually measured the performance difference between using
> sendfile() here and plain write() or send()? The kernel doesn't physically
> copy the written data from user space to kernel space, it just maps in a
> particular page. Since LMDB data is already mmap'd, the kernel has very
> little work to do since the relevant pages are already present in the
> kernel's page tables.
>
> Ultimately sending data over TCP involves byte-by-byte iteration anyway,
> since TCP checksums must be computed on all outgoing data. Doesn't seem to
> me like sendfile can be a very significant optimization here.
>
>>
>> I figured that function might be useful to the bigger community.
>>
>> If it does not fit in the bigger vision of lmdb it is fine not to include
>> it.
>>
>>
>> I, James Rouzier, 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.
>>
>>
>>
>>
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
>
--047d7bfcf1deec63470514165cd2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">My Testing doe=
s show it is not worth it for the data size in the db.<br><br><div>Also the=
re is a race condition using sendfile on linux that could happen.<br>It is =
avoidable but it would require changes to=C2=A0the protocol to avoid it whi=
ch I am not willing to do.<br><br>So dismiss my patch with extreme prejudic=
e<br><br><br></div></div><div><div><div class=3D"gmail_extra"><br><div clas=
s=3D"gmail_quote">On Wed, Apr 15, 2015 at 10:37 PM, Howard Chu <span dir=3D=
"ltr"><<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com<=
/a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><a href=3D"mailto:r=
ouzier(a)gmail.com" target=3D"_blank">rouzier(a)gmail.com</a> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Full_Name: James Rouzier<br>
Version:<br>
OS:<br>
URL: <a href=3D"ftp://ftp.openldap.org/incoming/james-rouzier-150331.patch"=
target=3D"_blank">ftp://ftp.openldap.org/incoming/james-rouzier-150331.pat=
ch</a><br>
Submission from: (NULL) (192.222.129.11)<br>
<br>
<br>
I am working on a proof of concept of a simple key value store service usin=
g<br>
lmdb as the back end.<br>
I am using sendfile to avoid an extra copy.<br>
I accomplished this by creating function to extract get the mmap ptr from t=
he<br>
env so I can calculate the offset of data.<br>
</blockquote>
<br>
I'm quite reluctant to return the mmap pointer. In a WRITEMAP environme=
nt that invites all manner of undetectable/unpreventable corruptions.<br>
<br>
Have you actually measured the performance difference between using sendfil=
e() here and plain write() or send()? The kernel doesn't physically cop=
y the written data from user space to kernel space, it just maps in a parti=
cular page. Since LMDB data is already mmap'd, the kernel has very litt=
le work to do since the relevant pages are already present in the kernel=
9;s page tables.<br>
<br>
Ultimately sending data over TCP involves byte-by-byte iteration anyway, si=
nce TCP checksums must be computed on all outgoing data. Doesn't seem t=
o me like sendfile can be a very significant optimization here.<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
I figured that function might be useful to the bigger community.<br>
<br>
If it does not fit in the bigger vision of lmdb it is fine not to include i=
t.<br>
<br>
<br>
I, James Rouzier, hereby place the following modifications to OpenLDAP Soft=
ware<br>
(and only these modifications) into the public domain. Hence, these<br>
modifications may be freely used and/or redistributed for any purpose with =
or<br>
without attribution and/or other notice.<br>
<br>
<br>
<br><span><font color=3D"#888888">
</font></span></blockquote><span><font color=3D"#888888">
<br>
<br>
-- <br>
=C2=A0 -- Howard Chu<br>
=C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"=
http://www.symas.com" target=3D"_blank">http://www.symas.com</a><br>
=C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland=
sun.com/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a><br>
=C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p=
roject/" target=3D"_blank">http://www.openldap.org/project/</a><br>
</font></span></blockquote></div><br></div>
</div></div></div><br></div>
--047d7bfcf1deec63470514165cd2--
7 years, 7 months
