Fw : backend SSL negociation timeout
by Louis Chanouha
Hello,
I experience some problems with slapd-meta with ldaps backend.
gnuTLS (or openssl) negociation timeout seems not to be handled, and i can't find any reference to modify this timeout on docs. My server becames unresponsive (too many connexion slots) when a ssl-secured backend server time out after TCP connexion establishment.
To reproduce the error, i have an meta directory configured like this:
database meta
suffix "dc=localauth"
rootdn "cn=Manager,dc=localauth"
rootpw XXX
uri "ldaps://localhost:666/ou=UT,dc=localauth"
lastmod off
suffixmassage "ou=UT,dc=localauth" "ou=people,dc=example,dc=fr"
timeout 1
conn-ttl 1
network-timeout 1
And i launch a netcat to listen to the 666 port:
nc -l -p 666
Then, this command never time out:
ldapwhoami -H ldap://YYYY:9009 -D uid=me,ou=UT,dc=localauth -W
Error does not happen when no ssl used ("timeout 1" option works well)
OS: Debian 8 Jessie x64
slapd: 2.4.40+dfsg-1+deb8u2
gnutls: 3.3.8-6+deb8u4
Sorry for my english, and thanks for the help,
Regards,
Louis Chanouha
University of Toulouse
6 years, 10 months
RE: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)
by Quanah Gibson-Mount
--On Thursday, February 02, 2017 1:26 PM -0800 Quanah Gibson-Mount
<quanah(a)symas.com> wrote:
> I've not been able to reproduce it. There's a regression test I wrote
> for it included in the RE24 source, but it's never really triggered for
> me. Please feel free to look it over and see if I've missed anything
> obvious in my reproduction attempts. :)
>
> You can execute it directly with ./run -b mdb its8444
Hm, actually it's only in master at the moment, since I couldn't get it to
trigger. ;) But feel free to peruse it and see if I missed something. :)
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 10 months
Re: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)
by Quanah Gibson-Mount
--On Tuesday, January 31, 2017 4:13 PM -0800 Quanah Gibson-Mount
<quanah(a)symas.com> wrote:
>> * compilation against openssl-1.1.0d works without issues and at a first
>> startup it also work :-) I'll report on further success...
>>
>> * but last: make test failed
>> ( attached make_test_result.txt )
>
> I'll see if I can repo the test058 failure.
I've not been able to reproduce this with RE24 even with several hundred
runs of the test. It may be timing related.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 10 months
Re: Syncrepl refreshAndPersist provider reboot
by Howard Chu
Quanah Gibson-Mount wrote:
> --On Wednesday, February 01, 2017 2:05 PM +0100 Thomas Hummel
> <thomas.hummel(a)pasteur.fr> wrote:
>
>> Is this a normal behavior providing I'm using refreshAndPersist mode ?
>
> No.
It is normal behavior if you didn't configure retries. Without seeing the
actual config, nobody can give a definitive yes or no answer to this question.
>
>> I mean do we have to restart the consumers each time the provider
> restarts ?
>
> No. But there several bugs in OpenLDAP 2.4.40 around replication, and that
> release should be used with care if replication is involved. The Redhat
> builds of course have additional issues. YMMV.
Without seeing configs, there is no evidence of any bug being relevant.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
6 years, 10 months
Re: Syncrepl refreshAndPersist provider reboot
by Quanah Gibson-Mount
--On Wednesday, February 01, 2017 5:04 PM +0100 Thomas Hummel
<thomas.hummel(a)pasteur.fr> wrote:
Hi Thomas,
> I know. Unfortunately my distro is stuck with this version (though I see
> there's a port version update right now).
There's nothing that requires anyone to run the 3rd party builds from
Redhat. There are significantly better options available if you require
pre-built binaries, such as the LTB project builds or the binaries produced
by Symas (which also has support options available). If you don't require
pre-built binaries, it's also fairly trivial to package up OpenLDAP.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 10 months
Re: Syncrepl refreshAndPersist provider reboot
by Quanah Gibson-Mount
--On Wednesday, February 01, 2017 2:05 PM +0100 Thomas Hummel
<thomas.hummel(a)pasteur.fr> wrote:
> Is this a normal behavior providing I'm using refreshAndPersist mode ?
No.
> I mean do we have to restart the consumers each time the provider
restarts ?
No. But there several bugs in OpenLDAP 2.4.40 around replication, and that
release should be used with care if replication is involved. The Redhat
builds of course have additional issues. YMMV.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 10 months
Syncrepl refreshAndPersist provider reboot
by Thomas Hummel
Hello,
today, in a simple setup consisting of one provider and 2 syncrepl
consumers [openldap-2.4.40-9 on CentOS Linux 7.2, cn=config, mdb
backend, refreshAndPersist mode], I noticed that after the provider
reboot (the ESX it ran on had some kind of maintenance) :
- slapd service was running dans correctly responding (ldapsearch...) on
the 3 servers
- replication wasn't working anymore (ldapmodify on the provider not
sync'ed on the consumers)
Rebooting the consumers seemed to fix the problem.
Is this a normal behavior providing I'm using refreshAndPersist mode ? I
mean do we have to restart the consumers each time the provider restarts ?
Thanks
--
Thomas HUMMEL
6 years, 10 months
help troubleshooting
by scar
I have inherited an LDAP server and admittedly do not have all the
technical expertise to troubleshoot the problems we have.
We are using slapd 2.4.40.
The first problem is nobody but the rootdn can change passwords. We'd
like to use "passwd" utility on our servers to change our passwords but
the error is "LDAP password information update failed: Insufficient access"
In slapd.conf we have (i have removed our dc for privacy):
access to attrs=userPassword
by self write
by anonymous auth
by dn="cn=Manager,dc=X,dc=Y,dc=Z" write
by * none
access to *
by self write
by dn="cn=Manager,dc=X,dc=Y,dc=Z" write
by * read
by * auth
access to *
by dn="uid=ldapadmin,dc=X,dc=Y,dc=Z" read
"cn=Manager,dc=X,dc=Y,dc=Z" is our rootdn and i have enabled logleve 128
However, this brings me to the next problem: the contents of slapd.conf
do not match the slapd.d/cn\=config.ldif file, so it seems the fixes i
am trying to the ACL's don't have any effect, even when i restart slapd.
If i try "ldapmodify -nv" it just hangs. When i try to stop slapd and
remove slapd.d/* and then start slapd, the contents are recreated
according to the config file, but then users can't login (all i see in
the logfile is access_allowed and slap_access_allowed but no conn lines)
So some basic troubleshooting help would be appreciated!
Thanks
6 years, 10 months
