(ITS#8095) Patch
by rouzier＠gmail.com
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 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.
8 years, 6 months
Re: (ITS#8094) OpenLdap2.4 rpm for RHEL5.11
by quanah＠zimbra.com
--On Monday, March 30, 2015 12:49 PM +0000 shashikanthbussa(a)gmail.com wrote:
> Full_Name: shashikanth.bussa
> Version: 2.4
> OS: RHEL5.11
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (115.160.252.10)
>
>
> Hi,
>
> Please letme know the rpm repo file for Openldap2.4 on RHEL5.11 as i
> have not found the openldap2.4 version for RHEl 5.11.
The OpenLDAP foundation only releases source. If you want pre-compiled
builds, you can look at the builds provided by Symas or the LTB project.
As the ITS system is only for reporting bugs, this ITS will be closed. In
the future, questions such as this should be directed to the
openldap-technical list.
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
8 years, 6 months
(ITS#8094) OpenLdap2.4 rpm for RHEL5.11
by shashikanthbussa＠gmail.com
Full_Name: shashikanth.bussa
Version: 2.4
OS: RHEL5.11
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (115.160.252.10)
Hi,
Please letme know the rpm repo file for Openldap2.4 on RHEL5.11 as i have not
found the openldap2.4 version for RHEl 5.11.
and When i tried to install from source tar ball. i am facing issue with the
Barkley DB.
hecking for Berkeley DB major version in db.h... 4
checking for Berkeley DB minor version in db.h... 3
checking if Berkeley DB version supported by BDB/HDB backends... no
configure: error: BerkeleyDB version incompatible with BDB/HDB backends
...
Please help on the above
8 years, 6 months
Re: (ITS#8091) Updateref for openldap 2.4.39 not work
by michael＠stroeder.com
This is a cryptographically signed message in MIME format.
--------------ms090909080601010706070208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
betchenhuang(a)163.com wrote:
> Updateref for openldap 2.4.39 not work
> i configured updateref option in slapd.conf for consumer slapd, later i=
restart
> slapd Successfully, but when i add new record to consumer, it failed. t=
his new
> recored not refer to master slapd.
> in log ,i found the return code 10 which means:
> ldap_add: Referral (10)
> referrals:
> ldaps://xxx:xxx/uid=3Dmeixuan,ou=3DPeoples,dc=3Dhadoop,dc=3Dcom
It seems you did not load slapo-chain in your configuration which impleme=
nts=20
the consumer-side referral chasing. Therefore the consumer sends the refe=
rral=20
back to your LDAP client.
Read about chaining here:
http://www.openldap.org/doc/admin24/overlays.html#Chaining
See another config example here:
http://www.openldap.org/faq/data/cache/1434.html
The ITS is only used for bug reports.
Please post configuration questions to the openldap-technical mailing lis=
t.
Ciao, Michael.
--------------ms090909080601010706070208
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DIEwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe
Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE
ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg
U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0
ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp
pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9
b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q
zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX
9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/
4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E
BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw
HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG
AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu
Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB
FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw
Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC
AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py
TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm
CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz
uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm
z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT
5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp
sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076
khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8
J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX
un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBkUwggUtoAMCAQICAwtNUDANBgkqhkiG
9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTE0MDkyMzIw
NDc1NVoXDTE1MDkyNDIyMDUxOFowXzEZMBcGA1UEDRMQNk0yWTdpOXpEdGU2alV3MDEdMBsG
A1UEAwwUbWljaGFlbEBzdHJvZWRlci5jb20xIzAhBgkqhkiG9w0BCQEWFG1pY2hhZWxAc3Ry
b2VkZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAynIH09fU597v4fg4
uwqFJDPUxQHV9qxrfM/c3veStPyYl0JorqKHrD+hfCNZ+Toy65NN9f9vO26WnnLoDF+FE2Dk
Qi61iTgK5jZTr5dJG1WQkk698UNWO87lUWBRYYiUM7wC3ek2E0rzR99qIxE4dG9wws19F3KK
JvNN8tMTyoPw5Vkw4qx2SW54WEBMx7oCXBIZPPDD8ovled6vDVweVSaYXFUbkxbKJR87Msih
34Ba+cM5SAHQNQ11jaSJjFeqbQnXjf0nESnvo0XIckc9w240w3jcgu6b5SIQBI2vv5TaIv7v
KqNk0o+cGc9NnCw5/xD/OAB9Aj/qDca6NheHCQIDAQABo4IC2jCCAtYwCQYDVR0TBAIwADAL
BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTj
z1BhELZO3zEJfmZQ4I+c6NCXIjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAf
BgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYL
KwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9w
b2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1
dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0
byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20g
Q0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj
b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAt
MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEF
BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns
YXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2Nl
cnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0
YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAAfByd9CEZ5pYuRa3XuE5xeJoIpDol22
A1mIGuRqxaBFIummmDoYr/tVgFod/3evQJO+ad8T5wpooY422HkHN4a1UI7ujCKcU/PrQSxm
v28AAsl4Fo/InY1nSFjMy8Ywj3EG+Edj1ZpCkzTRNGZjBa6Uj7UY7UW71kYcSdCBe8vc9Zi3
6OnHGkXROWIii3wBKLDEZqxknw0Cj9TTy5lyllYzyHku4aXLDPhiYrTzhWiwgYmweaLvW/yq
YVsHRpW8udzqOr6xvUVcuRmfMTENM7RSlRZVw2+5+I+zn7jqOrrULO1FP7Lo5cPilsMpSMOw
oJnPLQgNZvXOPFO6VaDCOboxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl
IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh
dGUgQ2xpZW50IENBAgMLTVAwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkq
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMyNjA3MDMwNFowLwYJKoZIhvcNAQkEMSIE
INUwr+VrzD6DxfJr7U+Sku8f+I6JqX5ty0KBRXsQe1eUMGwGCSqGSIb3DQEJDzFfMF0wCwYJ
YIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCB
lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl
Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs
YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwgacGCyqGSIb3DQEJ
EAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG
A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh
cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwtNUDANBgkq
hkiG9w0BAQEFAASCAQA77XDFu6SAsZn0FmyMD2rRN73NV6nvP7h6O9ppe+H2J0S4+hGmTotu
VPLZ7Sc9V1Ybv1xqFXjhwjzuVkKFHn7h+iN+OF4ejzdOVuHI/YIZNepZiBMS0cQKuEachzBQ
S42su/6Cs22EzIUB0QrvD0hSI4Ijwwa8bmUh24DP08hnlbZGf7pJoYUjdZv7vNPWpm15TMTD
ZJKHJHyqA+0gYW4HKYRsncLL9x0ZN60EMI95J6n4S3NeQt5ccibsL+nhzVch20fZufWTufO9
CpNtlYUXs+6C/IJ3kkgLSnnzCHNmT9lOiE7/S3svyBhM/Lq6ATtG716LKJjcQ/LvQNF60oCB
AAAAAAAA
--------------ms090909080601010706070208--
8 years, 6 months
(ITS#8092) slapd crash with sasl auxprop and empty suffix
by ryan＠nardis.ca
Full_Name: Ryan Tandy
Version: master, 2.4
OS: Debian
URL:
Submission from: (NULL) (24.68.37.4)
Based on a Debian bug report: https://bugs.debian.org/781162
./configure --enable-spasswd
cat > slapd.conf << EOF
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
database mdb
directory .
suffix ""
EOF
slapadd -f slapd.conf << EOF
dn: dc=com
objectClass: domain
dn: dc=example,dc=com
objectClass: domain
dn: uid=test,dc=example,dc=com
objectClass: account
objectClass: simpleSecurityObject
userPassword: {SASL}test(a)EXAMPLE.COM
EOF
ldapwhoami -x -D uid=test,dc=example,dc=com
Enter LDAP Password:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffeebab700 (LWP 28815)]
__strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:210
210 ../sysdeps/x86_64/multiarch/../strcmp.S: No such file or directory.
(gdb) bt
#0 __strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:210
#1 0x0000000000441689 in select_backend (dn=0x7fffeebaa1a8, noSubs=1) at
backend.c:704
#2 0x000000000049c7c2 in slap_auxprop_lookup (glob_context=0x0,
sparams=0x7fffe0001cd0, flags=0,
user=0x7fffe0001861 "test(a)EXAMPLE.COM", ulen=16) at sasl.c:370
#3 0x00007ffff7bc463b in _sasl_auxprop_lookup (sparams=0x7fffe0001cd0,
flags=flags@entry=0,
user=0x7fffe0001861 "test(a)EXAMPLE.COM", ulen=16) at ../../lib/auxprop.c:959
#4 0x00007ffff7bc5467 in _sasl_auxprop_lookup_user_props
(oparams=0x7fffe0001330, flags=3, conn=0x7fffe0000ac0)
at ../../lib/canonusr.c:220
#5 _sasl_canon_user_lookup (conn=conn@entry=0x7fffe0000ac0,
user=user@entry=0x7fffe0001460 "test(a)EXAMPLE.COM",
ulen=ulen@entry=0, flags=flags@entry=3,
oparams=oparams@entry=0x7fffe0001330) at ../../lib/canonusr.c:281
#6 0x00007ffff7bc5d39 in auxprop_verify_password (conn=0x7fffe0000ac0,
userstr=0x7fffe0001460 "test(a)EXAMPLE.COM",
passwd=0x7fffe0002696 "asdf", service=<optimized out>, user_realm=<optimized
out>) at ../../lib/checkpw.c:159
#7 0x00007ffff7bcee78 in _sasl_checkpass (conn=conn@entry=0x7fffe0000ac0,
user=0x7fffe0001460 "test(a)EXAMPLE.COM",
userlen=userlen@entry=16, pass=pass@entry=0x7fffe0002696 "asdf",
passlen=passlen@entry=4)
at ../../lib/server.c:1922
#8 0x00007ffff7bd1e50 in sasl_checkpass (conn=0x7fffe0000ac0, user=<optimized
out>, userlen=16,
pas3D0x0x7fffe0002696 "asdf", passlen=4) at ../../lib/server.c:1989
#9 0x000000000049e4db in chk_sasl (sc=0x8cac98, passwd=0x7fffeebaa8a0,
cred=0x7fffe0002700, text=0x7fffeebaaae0)
at sasl.c:990
#10 0x0000000000535278 in lutil_passwd (passwd=0x7fffe0003188,
cred=0x7fffe0002700, schemes=0x0, text=0x7fffeebaaae0)
at passwd.c:327
#11 0x0000000000474aa6 in slap_passwd_check (op=0x7fffe00026b0,
e=0x7fffe0002f28, a=0x7fffe0002fa8,
cred=0x7fffe0002700, text=0x7fffeebaaae0) at passwd.c:529
#12 0x00000000005088e7 in mdb_bind (op=0x7fffe00026b0, rs=0x7fffeebaaac0) at
bind.c:120
#13 0x00000000004584f6 in fe_op_bind (op=0x7fffe00026b0, rs=0x7fffeebaaac0) at
bind.c:383
#14 0x0000000000457bb4 in do_bind (op=0x7fffe00026b0, rs=0x7fffeebaaac0) at
bind.c:205
#15 0x000000000042f68a in connection_operation (ctx=0x7fffeebaabf0,
arg_v=0x7fffe00026b0) at connection.c:1134
#16 0x000000000042fc3a in connection_read_thread (ctx=0x7fffeebaabf0, argv=0xc)
at connection.c:1280
#17 0x00000000005401bf in ldap_int_thread_pool_wrapper (xpool=0x8b83c0) at
tpool.c:958
#18 0x00007ffff74750a4 in start_thread (arg=0x7fffeebab700) at
pthread_create.c:309
#19 0x00007ffff71aa04d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
I don't know how auxprop is intended to be configured; I'm going to follow up on
that when I have time. This is just about a segv that happens when
pwcheck_method is auxprop (the default) and the suffix is the empty string.
8 years, 6 months
(ITS#8091) Updateref for openldap 2.4.39 not work
by betchenhuang＠163.com
Full_Name: marix wong
Version: 2.4.39
OS: redhat 6.4
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (119.145.14.210)
Updateref for openldap 2.4.39 not work
i configured updateref option in slapd.conf for consumer slapd, later i restart
slapd Successfully, but when i add new record to consumer, it failed. this new
recored not refer to master slapd.
in log ,i found the return code 10 which means:
ldap_add: Referral (10)
referrals:
ldaps://xxx:xxx/uid=meixuan,ou=Peoples,dc=hadoop,dc=com
this is my configuration:
syncrepl rid=124
provider=ldaps://167.52.0.35:21780
type=refreshAndPersist%0 interval=00:00:00:15
searchbase="dc=hadoop,dc=com"
filter="(objectClass=*)"
scope=sub
attrs="*,+"
tls_reqcert=allow
tls_cacert=/opt/cert/cacert.pem
schemachecking=off
bindmethod=simple
binddn="cn=root,dc=hadoop,dc=com"
credentials=Ldap@123
retry="15 +"
updateref ldaps://167.52.0.35:21780
so i want to know how to make this option work better?
8 years, 6 months
(ITS#8090) libldap bugfix: Spurious initial LDAP_CONNECT_ERROR with LDAP_OPT_CONNECT_ASYNC enabled
by olli.salli＠vincit.fi
Full_Name: Olli Salli
Version: git master
OS: Windows 8.1, Linux 3.18.10
URL: ftp://ftp.openldap.org/incoming/olli-salli-150325.patch
Submission from: (NULL) (83.102.45.242)
We are working on an application which needs to perform some simple LDAP search
queries every once in a while. The application is running as a daemon in an
embedded server environment and has no user interface, and is instead remotely
controlled and configured via a control TCP connection. This includes the
configuration specifying the LDAP server address and port, and whether the LDAP
queries should be attempted at all (if there is no server available). We are
currently developing on Windows 8.1 with Visual Studio 2013 but will also run in
Linux environments.
To ensure the control TCP connection stays alive at all times (and the daemon
otherwise functional), and to avoid using threads, whahave used the openldap
asynchronous APIs, including the asynchronous connect option - if the configured
LDAP server is unreachable, the initial search query can block for a very long
time otherwise. It is here that we have hit a small issue.
When using LDAP_OPT_CONNECT_ASYNC, if the LDAP server is unreachable, the
initial request (e.g. using ldap_search_ext) does not block, which is correct.
However, this first call returns LDAP_CONNECT_ERROR. If we disregard this, and
continue reissuing the ldap_search_ext request periodically, following calls
correctly return LDAP_X_CONNECTING. Then when the NETWORK_TIMEOUT has elapsed,
LDAP_CONNECT_ERROR is returned again, which is correct.
LDAP_CONNECT_ERROR might result in the first ldap_search_ext call from
legitimate error conditions in connect() even in asynchronous mode, for example
out-of-resource conditions (EADDRNOTAVAIL), or all local network interfaces
being down (ENETUNREACH), etc. These should be handled as fatal errors, but
would be impossible to distinguish from the false initial LDAP_CONNECT_ERROR
resulting from using LDAP_OPT_CONNECT_ASYNC.
The issue seems to be in ldap_send_initial_request
(http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=librarie...).
When async connect is enabled what happens during the first request is:
1) sd is initialized to AC_SOCKET_INVALID
2) ber_sockbuf_ctrl( ... LBER_SB_OPT_GET_FD ... ) is called to determine whether
there is already a connection, and to fetch its socket descriptor to sd
3) as there is no connection, it returns -1 and sd stays AC_SOCKET_INVALID
4) a new connection is formed using ldap_open_defconn()
5) ldap_int_check_async_open( ld, sd ) is called, but sd is still
AC_SOCKET_INVALID, and thus the poll fails
6) LDAP_CONNECT_ERROR is returned
On successive calls, what happens is
1) ber_sockbuf_ctrl( ... LBER_SB_OPT_GET_FD ... ) returns success and a valid
socket descriptor
2) opening a new connection is skipped
3) ldap_int_check_async_open( ld, sd ) is called this time with a valid socket
descriptor
4) the poll works as intended
A simple fix is to simply reissue ber_sockbuf_ctrl( ... LBER_SB_OPT_GET_FD ... )
after opening the connection. This fixes the first poll to return
LDAP_X_CONNECTING as intended. This is implemented in the patch at the URL. A
perhaps more semantically correct alternative could be to return the created
socket descriptor from ldap_open_defconn().
8 years, 6 months
(ITS#8089) LMDB hangs on mdb_txn_renew0 if MDB_NOSYNC flag is used
by pk＠dbic.pro
Full_Name: Pavel Kraynyukhov
Version: only LMDB from git and lmdb-0.9.14
OS: Gentoo Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (37.99.47.171)
Hello there, I have ran into an issue with LMDB, which I can reproduce at will,
but it seems a specific one. The git commit is
3368d1f5e243225cba4d730fba19ff600798ebe3
And this commit and my issue seems to be related.
1. I use MDB_NOTLS flag on environment open.
2. if I use MDB_NOSYNC flag for LMDB environment, the writer thread is stuck
after several transactions (writer thread backtrace):
#0 0x00007fe5534a25dc in __lll_robust_lock_wait () from /lib64/libpthread.so.0
#1 0x00007fe553498ba1 in __pthread_mutex_lock_full () from
/lib64/libpthread.so.0
#2 0x00007fe553ed895a in mdb_txn_renew0 (txn=txn@entry=0x661810) at mdb.c:2638
#3 0x00007fe553ed9558 in mdb_txn_begin (env=0x6606c0, parent=0x0,
flags=<optimized out>, ret=0x7fe552bebd08) at mdb.c:2813
#4 0x000000000041cd0c in beginWOTxn (parent=0x0, this=0x6603a8) at
../ITCFramework/include/LMDBEnv.h:220
#5 itc::lmdb::WOTxn::WOTxn (this=0x7fe552bebdb0, ref=...) at
../ITCFramework/include/LMDBWOTxn.h:51
#6 0x0000000000420c5b in itc::lmdb::DBWriter::dbWrite
(this=this@entry=0x661b08) at ../ITCFramework/include/LMDBWriter.h:185
#7 0x00000000004210ff in itc::lmdb::DBWriter::execute (this=0x661b08) at
../ITCFramework/include/LMDBWriter.h:98
#8 0x0000000000414eac in itc::sys::CancelableThread<itc::lmdb::DBWriter>::run
(this=0x7ffff31f7cd0) at ../ITCLib/include/sys/CancelableThread.h:84
#9 0x0000000000439dc4 in itc::sys::invoke (context=0x7ffff31f7cd0) at
src/Thread.cpp:56
#10 0x00007fe55349b4c6 in start_thread () from /lib64/libpthread.so.0
#11 0x00007fe5531e000d in clone () from /lib64/libc.so.6
Before you might ask:
1. There is only one writer thread. Only this thread begins writable
transactions and only this thread commits them and of course only this thread
calls mdb_put().
2. There suppose to be a multiple reader threads. For the test I'm running one
only. And there are no read operations or cursor usage during this test at the
same time when the writer is working.
3. When I write hang, I mean only the application not the system. The test
application consume no CPU after it hang.
4. If no MDB_NOSYNC flag is used, then there is no bug/deadlock. This however
may be due to very slow file system operations of my PC. It is about 35 writable
transactions per second and about 27-39% I/O wait on the CPU.
P.S. tested against system provided lmdb version 0.9.14 and result is the same.
So this maybe not related to latest commit in git.
8 years, 6 months
