openldap-technical

openldap-technical@openldap.org

8 participants
9792 discussions

Re: Syncrepl losing connection
by Quanah Gibson-Mount 02 Mar '17

02 Mar '17

--On Wednesday, March 01, 2017 8:48 AM +0200 Nick Milas <nick(a)eurobjects.com> wrote: > Hello, > > I have recently installed two syncrepl consumers using 2.4.44 on CentOS 7 > using LTB rpm packages. > > I am almost daily facing issues with consumers losing connection to the > master. I always have to restart the consumer in order to re-establish > connection. > > Note 1: These two consumers have replaced two older ones running 2.4.39 > LTB (and earlier versions) on CentOS 5 without any such issues. > > Note 2: Master is using 2.4.44 version as well (but on CentOS 5). > > Is this a known bug or I need to change/add something in the config when > using this OpenLDAP version so that the problem gets resolved? Have you tried setting the "keepalive" parameter in your syncrepl configs? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

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

02 Mar '17

--On Tuesday, February 14, 2017 5:04 PM -0800 "Paul B. Henson" <henson(a)acm.org> wrote: > On Tue, Feb 14, 2017 at 04:13:17PM -0800, Quanah Gibson-Mount wrote: > >> I have a test setup from a coworker who managed to trigger this to >> examine and see if I can push it into the test script. :) > > Cool, good to hear; it will be nice to track this down and quash it. I > don't know what it is about my environment that triggers it so often, > perhaps because we add/remove group members frequently. Hi Paul, In the ITS, you didn't provide your configuration -- I'm curious to see the order in which you load the overlays. In the initial report from Mark, he loads them in this order (on the primary data db): dynlist memberof syncprov accesslog So I'd like to know the order in which your overlays are loaded. Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 2

Re: 2.4.44 + ITS 8432 patch segfault in modify_add_values
by Quanah Gibson-Mount 01 Mar '17

01 Mar '17

--On Wednesday, February 22, 2017 7:29 PM -0800 "Paul B. Henson" <henson(a)acm.org> wrote: > On Mon, Feb 20, 2017 at 04:30:00PM -0800, Quanah Gibson-Mount wrote: > >> Ok, I can see if I can reproduce something like this. Do you have a >> link to the schema file in use that adds this attribute? > > https://spaces.internet2.edu/display/macedir/OpenLDAP+eduPerson Great, thanks. I want to look at the attribute rules. :) See if I can reproduce the crash in some way. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

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

01 Mar '17

--On Wednesday, February 22, 2017 7:21 PM -0800 "Paul B. Henson" <henson(a)acm.org> wrote: > On Tue, Feb 21, 2017 at 01:14:58PM -0800, Quanah Gibson-Mount wrote: > >> So I'd like to know the order in which your overlays are loaded. > > First there's > > database mdb > suffix cn=accesslog > overlay syncprov > > Then > > database mdb > suffix "dc=cpp,dc=edu" > overlay memberof > overlay syncprov > overlay accesslog > > > I don't recall ever seeing a requirement for a specific ordering of the > overlays. Should it matter? no. Can it matter? Maybe. I always load up syncprov first, accesslog second, anything else after that. It would be curious if reordering had any effect. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Syncrepl losing connection
by Nick Milas 28 Feb '17

28 Feb '17

Hello, I have recently installed two syncrepl consumers using 2.4.44 on CentOS 7 using LTB rpm packages. I am almost daily facing issues with consumers losing connection to the master. I always have to restart the consumer in order to re-establish connection. Note 1: These two consumers have replaced two older ones running 2.4.39 LTB (and earlier versions) on CentOS 5 without any such issues. Note 2: Master is using 2.4.44 version as well (but on CentOS 5). Is this a known bug or I need to change/add something in the config when using this OpenLDAP version so that the problem gets resolved? Below follows a log example from one of them (it includes my restart to re-establish connection): OpenLDAP Log excerpt: =========================================================================== Feb 28 16:19:20 vdns slapd[10375]: do_syncrep2: rid=353 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Feb 28 16:19:20 vdns slapd[10375]: do_syncrep2: rid=353 cookie=rid=353,csn=20170228140139.002723Z#000000#000#000000 Feb 28 16:19:20 vdns slapd[10375]: slap_queue_csn: queueing 0x7f9314225d90 20170228140139.002723Z#000000#000#000000 Feb 28 16:19:20 vdns slapd[10375]: slap_graduate_commit_csn: removing 0x7f9314225d90 20170228140139.002723Z#000000#000#000000 Feb 28 16:19:21 vdns slapd[10380]: [OK] OpenLDAP started Feb 28 18:19:23 vdns slapd[10375]: do_syncrep2: rid=353 (-1) Can't contact LDAP server Feb 28 18:19:23 vdns slapd[10375]: do_syncrepl: rid=353 rc -1 retrying (14 retries left) Feb 28 18:20:23 vdns slapd[10375]: do_syncrep2: rid=353 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Feb 28 20:20:37 vdns slapd[10375]: do_syncrep2: rid=353 (-1) Can't contact LDAP server Feb 28 20:20:37 vdns slapd[10375]: do_syncrepl: rid=353 rc -1 retrying (14 retries left) Feb 28 20:21:37 vdns slapd[10375]: do_syncrep2: rid=353 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Feb 28 22:21:52 vdns slapd[10375]: do_syncrep2: rid=353 (-1) Can't contact LDAP server Feb 28 22:21:52 vdns slapd[10375]: do_syncrepl: rid=353 rc -1 retrying (14 retries left) Feb 28 22:22:52 vdns slapd[10375]: do_syncrep2: rid=353 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Mar 1 00:23:06 vdns slapd[10375]: do_syncrep2: rid=353 (-1) Can't contact LDAP server Mar 1 00:23:06 vdns slapd[10375]: do_syncrepl: rid=353 rc -1 retrying (14 retries left) Mar 1 00:24:06 vdns slapd[10375]: do_syncrep2: rid=353 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Mar 1 02:24:21 vdns slapd[10375]: do_syncrep2: rid=353 (-1) Can't contact LDAP server Mar 1 02:24:21 vdns slapd[10375]: do_syncrepl: rid=353 rc -1 retrying (14 retries left) Mar 1 02:25:21 vdns slapd[10375]: do_syncrep2: rid=353 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Mar 1 04:25:35 vdns slapd[10375]: do_syncrep2: rid=353 (-1) Can't contact LDAP server Mar 1 04:25:35 vdns slapd[10375]: do_syncrepl: rid=353 rc -1 retrying (14 retries left) Mar 1 04:26:35 vdns slapd[10375]: do_syncrep2: rid=353 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Mar 1 06:26:50 vdns slapd[10375]: do_syncrep2: rid=353 (-1) Can't contact LDAP server Mar 1 06:26:50 vdns slapd[10375]: do_syncrepl: rid=353 rc -1 retrying (14 retries left) Mar 1 06:27:50 vdns slapd[10375]: do_syncrep2: rid=353 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Mar 1 08:17:54 vdns slapd[18585]: [INFO] Using /etc/default/slapd for configuration Mar 1 08:17:54 vdns slapd[18590]: [INFO] Halting OpenLDAP... Mar 1 08:17:54 vdns slapd[10375]: daemon: shutdown requested and initiated. Mar 1 08:17:54 vdns slapd[10375]: slapd shutdown: waiting for 1 operations/tasks to finish Mar 1 08:17:54 vdns slapd[10375]: slapd stopped. Mar 1 08:17:55 vdns slapd[18594]: [OK] OpenLDAP stopped after 1 seconds Mar 1 08:17:55 vdns slapd[18595]: [INFO] No data backup done Mar 1 08:17:55 vdns slapd[18607]: [INFO] Using /etc/default/slapd for configuration Mar 1 08:17:55 vdns slapd[18612]: [INFO] Launching OpenLDAP configuration test... Mar 1 08:17:56 vdns slapd[18626]: [OK] OpenLDAP configuration test successful Mar 1 08:17:56 vdns slapd[18637]: [INFO] No db_recover done Mar 1 08:17:56 vdns slapd[18638]: [INFO] Launching OpenLDAP... Mar 1 08:17:56 vdns slapd[18639]: [OK] File descriptor limit set to 1024 Mar 1 08:17:56 vdns slapd[18640]: @(#) $OpenLDAP: slapd 2.4.44 (Feb 15 2016 11:14:35) $#012#011clement@centos7.unix.example.com:/home/clement/build/BUILD/openldap-2.4.44/servers/slapd Mar 1 08:17:56 vdns slapd[18641]: slapd starting Mar 1 08:17:56 vdns slapd[18641]: do_syncrep2: rid=353 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Mar 1 08:17:56 vdns slapd[18641]: do_syncrep2: rid=353 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Mar 1 08:17:56 vdns slapd[18641]: do_syncrep2: rid=353 cookie=rid=353,csn=20170301060829.837823Z#000000#000#000000 Mar 1 08:17:56 vdns slapd[18641]: slap_queue_csn: queueing 0x7f33f4225d90 20170301060829.837823Z#000000#000#000000 Mar 1 08:17:56 vdns slapd[18641]: slap_graduate_commit_csn: removing 0x7f33f4225d90 20170301060829.837823Z#000000#000#000000 Mar 1 08:17:57 vdns slapd[18646]: [OK] OpenLDAP started =========================================================================== Configuration on this consumer: =========================================================================== include /usr/local/openldap/etc/openldap/schema/core.schema include /usr/local/openldap/etc/openldap/schema/cosine.schema include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema include /usr/local/openldap/etc/openldap/schema/nis.schema include /usr/local/openldap/etc/openldap/schema/eduperson.schema include /usr/local/openldap/etc/openldap/schema/postfix.schema include /usr/local/openldap/etc/openldap/schema/dyngroup.schema include /usr/local/openldap/etc/openldap/schema/misc.schema include /usr/local/openldap/etc/openldap/schema/ppolicy.schema include /usr/local/openldap/etc/openldap/schema/schac-20090326-1.4.0.schema include /usr/local/openldap/etc/openldap/schema/dnsdomain2.schema include /usr/local/openldap/etc/openldap/schema/proftpd-quota.schema include /usr/local/openldap/etc/openldap/schema/kerberos.schema include /usr/local/openldap/etc/openldap/schema/localemail.schema include /usr/local/openldap/etc/openldap/schema/entryaccess.schema include /usr/local/openldap/etc/openldap/schema/radius.schema pidfile /usr/local/openldap/var/run/slapd.pid argsfile /usr/local/openldap/var/run/slapd.args modulepath /usr/local/openldap/lib64 loglevel sync sizelimit unlimited timelimit unlimited TLSCACertificateFile /usr/local/openldap/etc/openldap/cacerts/DigiCertCA.crt TLSCertificateFile /usr/local/openldap/etc/openldap/cacerts/vdns_noa_gr-1058189.crt TLSCertificateKeyFile /usr/local/openldap/etc/openldap/cacerts/vdns_noa_gr-1058189.key TLSVerifyClient never database mdb suffix "dc=noa,dc=gr" rootdn "cn=Manager,dc=noa,dc=gr" rootpw {SSHA}<SECRET> include /usr/local/openldap/etc/openldap/acl.conf directory /usr/local/openldap/var/mdb maxsize 10737418240 index objectClass eq,pres index cn eq,pres,sub index uid eq,pres index ou eq,pres index owner eq index entryCSN,entryUUID eq index associatedDomain pres,eq,sub index dc eq syncrepl rid=353 provider=ldaps://ldap.noa.gr type=refreshAndPersist tls_reqcert=never retry="60 15 180 +" searchbase="dc=noa,dc=gr" schemachecking=off bindmethod=simple binddn="uid=syncuser,dc=noa,dc=gr" credentials="secret" database monitor access to * by dn.exact="cn=Manager,dc=noa,dc=gr" read by * none =========================================================================== Please let me know of any hint/advice to resolve this issue! Thanks in advance, Nick

1 0

How correctly convert ldif dump size to mdb olcDbMaxSize value
by Ikonta 28 Feb '17

28 Feb '17

Hi everybody, I use simple OpenLDAP installation (two servers in mirror mode, something above 30000 leafs tree). Some time ago I've migrated it to mdb backend. The database dump in ldif weight about 300M. Initially I've set olcDbMaxSize to 2147483648 bytes (2G). Imported into directory it became about 450M data.mdb on node1 and after mirror synced — 1.5G replicated data.mdb on node2. Why instances database sizes are so different? Am I right guessing olcDbMaxSize is maximum size of data.mdb file? And how should I, starting with present and perspective ldif dump size, count proper value of olcDbMaxSize? For example, if I expect ldif dump may grow up to 500 M? WBR

1 0

Dynamic groups/lists
by Saša-Stjepan Bakša 27 Feb '17

27 Feb '17

Hi, I have access to LDAP server which doesn't have any groups defined. All users have only attributes which are used to distinguish to which type of users they belong and for application which I have intention to use groups are necessary. I don't have authority to change that but I can create my own LDAP proxy server and direct my application to it. Question is, can I create dynamic groups which will reside only on that proxy server. I am already familiar with translucent and ordinary proxy servers. Br Sasa

2 2

user removed from ldap group but Linux groups command still shows user as member of the group
by Bernard Fay 24 Feb '17

24 Feb '17

Hi, I removed a user from an LDAP group about a week ago. Today, this user still shows as member of the group with the Linux command groups. Also, the group (Administrators) appears twice in the output of the command id: uid=10000(username) gid=10000(Administrators) groups=10001(users),10005(devel),10011(video),10015(ansible),10000(Administrators) The command getent though shows the proper group assignation: getent group | grep username | cut -d: -f1 users devel video ansible All of those groups are LDAP group. Does someone knows why and would know how to fix this? Thanks,

5 14

Fwd: user removed from ldap group but Linux groups command still shows user as member of the group
by Bernard Fay 24 Feb '17

24 Feb '17

On Fri, Feb 24, 2017 at 9:08 AM, Dan White <dwhite(a)cafedemocracy.org> wrote: > On 02/24/17 08:55 -0500, Bernard Fay wrote: > >> I removed a user from an LDAP group about a week ago. Today, this user >> still shows as member of the group with the Linux command groups. Also, >> the >> group (Administrators) appears twice in the output of the command id: >> uid=10000(username) gid=10000(Administrators) >> groups=10001(users),10005(devel),10011(video),10015(ansible) >> ,10000(Administrators) >> >> The command getent though shows the proper group assignation: >> getent group | grep username | cut -d: -f1 >> users >> devel >> video >> ansible >> >> All of those groups are LDAP group. >> > > Is this from a long running shell? If so, start a new shell or > run newgrp. > > Otherwise, verify that it is not cached (such as with nscd), and trouble > shoot as an nss ldap problem. > > No, it is not from a long running shell. I logged out and logged back in since I remove this user from the group. By the way the group in question is Administrators. How can I verify it is not cached? My guess is that it is cached. I tried to use "nscd -i group" but that did not change anything.

1 0

Long ldap session when ldap server failover
by Huynh Phuoc Tai 23 Feb '17

23 Feb '17

Hi, I have an issue with long ldap session when ldap server failover. [01/Dec/2016:11:34:29 +0100] conn=7187095 op=-1 msgId=-1 - fd=89 slot=89 LDAPS connection from 10.14.97.45:55287 to 113.216.102.167 [01/Dec/2016:11:34:29 +0100] conn=7187095 op=-1 msgId=-1 - SSL 128-bit AES-128; client CN=HRM3; issuer O=E,OU=eOAM,CN=jerarm003NECertCA [01/Dec/2016:11:34:29 +0100] conn=7187095 op=-1 msgId=-1 - SSL failed to map client certificate to LDAP DN (No such object) [01/Dec/2016:11:34:29 +0100] conn=7187095 op=0 msgId=1 - BIND dn="cn=ProxyUser,ou=proxyagent,ou=com,dc=jerarm,dc=roma,dc=te,dc=com" method=128 version=3 [01/Dec/2016:11:34:29 +0100] conn=7187095 op=0 msgId=1 - RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=proxyuser,ou=proxyagent,ou=com,dc=jerarm,dc=roma,dc=te,dc=com" [01/Dec/2016:11:34:29 +0100] conn=7187095 op=1 msgId=2 - SRCH base="dc=jerarm,dc=roma,dc=te,dc=com" scope=2 filter="(&(&(objectClass=posixAccount)(|(eUserAuthenticationScope=HLRALL)(eUserAuthenticationScope=HRM3)(eUserAuthenticationScope=\2a)))(&(objectClass=posixAccount)(|(eUserAuthenticationScope=HLRALL)(eUserAuthenticationScope=HRM3)(eUserAuthenticationScope=\2a)))(uid=us000001))" attrs=ALL [01/Dec/2016:11:34:29 +0100] conn=7187095 op=1 msgId=2 - RESULT err=0 tag=101 nentries=1 etime=0 [01/Dec/2016:11:34:29 +0100] conn=7187095 op=2 msgId=3 - BIND dn="uid=us000001,ou=people,dc=jerarm,dc=roma,dc=te,dc=com" method=128 version=3 [01/Dec/2016:11:34:29 +0100] conn=7187095 op=2 msgId=3 - RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=us000001,ou=people,dc=jerarm,dc=roma,dc=te,dc=com" [01/Dec/2016:11:34:29 +0100] conn=7187095 op=3 msgId=4 - BIND dn="cn=ProxyUser,ou=proxyagent,ou=com,dc=jerarm,dc=roma,dc=te,dc=com" method=128 version=3 [01/Dec/2016:11:34:29 +0100] conn=7187095 op=3 msgId=4 - RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=proxyuser,ou=proxyagent,ou=com,dc=jerarm,dc=roma,dc=te,dc=com" [01/Dec/2016:11:40:01 +0100] conn=7187095 op=4 msgId=5 - UNBIND [01/Dec/2016:11:40:01 +0100] conn=7187095 op=4 msgId=-1 - closing from 10.14.97.45:55287 - U1 - Connection closed by unbind client - [01/Dec/2016:11:40:01 +0100] conn=7187095 op=-1 msgId=-1 - closed. The openldap client didn't send UNBIND soon but sent after several minutes. Could you suggest me any way forward to find the root cause?openldap2-client-2.4.26-0.62.2 Regards,Tai

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical