openldap-technical February 2017

openldap-technical@openldap.org

34 participants
62 discussions

Fw : backend SSL negociation timeout
by Louis Chanouha 03 Feb '17

03 Feb '17

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

1 0

RE: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)
by Quanah Gibson-Mount 02 Feb '17

02 Feb '17

--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>

1 0

Re: Transform accesslog database to LDIF for ldapmodify or other way
by Quanah Gibson-Mount 02 Feb '17

02 Feb '17

--On Thursday, February 02, 2017 5:51 PM +0100 Michael Wandel <m.wandel(a)t-online.de> wrote: > Great , thank you very very much > > > best regards > > Michael The canonical source can be found at: <https://github.com/quanah/ldap-tools/tree/master/a2ldif> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Transform accesslog database to LDIF for ldapmodify or other way
by Howard Chu 02 Feb '17

02 Feb '17

Michael Wandel wrote: > Hey, > > I'm searching for a tool which is able to transform an accesslog > Database to an ldif file, what can be used for ldapmodify. > > Or is there an alternative way to use the accesslog to rebuild an ldap > database from a backup time to actual ? > > Every hint is welcome I use this perl script. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)
by Quanah Gibson-Mount 01 Feb '17

01 Feb '17

--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>

2 1

Re: Syncrepl refreshAndPersist provider reboot
by Howard Chu 01 Feb '17

01 Feb '17

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/

2 1

Re: Syncrepl refreshAndPersist provider reboot
by Quanah Gibson-Mount 01 Feb '17

01 Feb '17

--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>

1 0

Re: Syncrepl refreshAndPersist provider reboot
by Quanah Gibson-Mount 01 Feb '17

01 Feb '17

--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>

2 1

Syncrepl refreshAndPersist provider reboot
by Thomas Hummel 01 Feb '17

01 Feb '17

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

1 0

help troubleshooting
by scar 01 Feb '17

01 Feb '17

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

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical February 2017