openldap-technical

openldap-technical@openldap.org

3 participants
9937 discussions

unique values
by A. Schulze 06 Mar '17

06 Mar '17

Hello, while planning a data scheme update we found it handy to have a unique value for each entry. short time later we found "entryUUID" :-) But we are still unsure.Should we simply use entryUUID or should we extend our schema to hold a new attribute similar to entryUUID. so what are the pros and cons on using entryUUID for a second purpose? + entryUUID is implicit available for each and every entry + automatically generated + saved as part of our backup using slapcat - what happen on a complete disaster restore? will the entryUUID values remain if we build a new server from a slapcat backup? - a separate but similar attribute has to be defined is there a suggested schema? "grep -ri uuid /path/to/openldap-source/servers/slapd/schema/" did not disclose the definition of entryUUID. It's somehow defined in servers/slapd/schema_prep.c - a separate but similar attribute has to be written while creating a new entry could that be automated somehow? - what is 'NO-USER-MODIFICATION' in a schema definition and what are the implications if I define an attribute as NO-USER-MODIFICATION? Do you have any thoughts or suggestions on this? A quick search in the list-archive didn't helped me to answer my questions. Thanks, Andreas

1 0

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

05 Mar '17

--On Wednesday, February 15, 2017 6:36 PM -0800 "Paul B. Henson" <henson(a)acm.org> wrote: > On Wed, Feb 15, 2017 at 12:22:29PM -0800, Quanah Gibson-Mount wrote: > >> I would suggest filing an ITS with the full backtrace info, so I can >> track it. > > Ok, will do. > >> It could be useful to have the entry data from the accesslog as >> well for the failed replication op, as we can see the failed entry DN in >> the output of your backtrace. > > That would be in the accesslog on the server that crashed? Hmm, the > server that crashed is the master, and all updates were going to it. Am > I confused, or did the update that caused the crash come in via syncrepl > though, and hence originate from a different server? So the accesslog > entry you want would be from that server, not the server that crashed? > But given no other servers should have been receiving updates, how would > an update have been received via replication? Or is this another issue > like the memberOf problem where updates are being improperly replicated? It appears to be crashing while writing the change to the accesslog database. It's odd that the value for the attribute is NULL. Do we know for sure what the client doing the write op to the server is sending? > Hmm, looking at the logs that correspond with one of the crashes: > This operation appears to succeed? Then there's this: > > Feb 14 04:00:13 fosse slapd[12524]: conn=37859 op=806 MOD > dn="uid=vntruong,ou=user,dc=csupomona,dc=edu" Feb 14 04:00:13 fosse > slapd[12524]: conn=37859 op=806 MOD attr=csupomonaEduPersonExpiration Yeah, so this is the operation that actually failed... It'd be interesting to know if it succeeded in the primary DB, but failed when writing to the accesslog DB (I.e., the master and its consumers are now out of sync for that entry), or if the entire write op failed (master and consumers are in sync for the entry) > when I restarted the server. I guess I am confused; the entryCSN has > serverID 0, the ID of this server, so this isn't a replicated op, it's > an op from this server. So why does the backtrace show the change coming > in via syncrepl? It seems like it's getting applied twice. The change is > deleting the attribute, so the second time it's getting applied you > would get a no such attribute error... Hm, so I guess my question would be is it doing the op like this: dn: ... changetype: modify replace: csupomonaEduPersonExpiration csupomonaEduPersonExpiration: Or is it doing it like this: dn: ... changetype: modify delete: csupomonaEduPersonExpiration Because the NULL value seems to imply the former. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 4

Re: How correctly convert ldif dump size to mdb olcDbMaxSize value
by Quanah Gibson-Mount 04 Mar '17

04 Mar '17

--On Tuesday, February 28, 2017 2:48 PM +0300 Ikonta <ikonta(a)yandex.ru> wrote: > 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? Generally, you just set it to something *very large*. I usually go with 80GB. You're not supposed to try and keep it down to a small value that's "near" the actual DB size. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Long ldap session when ldap server failover
by Quanah Gibson-Mount 02 Mar '17

02 Mar '17

--On Friday, February 24, 2017 7:27 AM +0000 Huynh Phuoc Tai <fucai1116(a)yahoo.com> wrote: > > > Hi, > > > I have an issue with long ldap session when ldap server failover. > [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 Well, it shows that the LDAP client didn't unbind until after 5 minutes. We have no idea *what* that client is, only you do. What is "cn=ProxyUser,ou=proxyagent,ou=com,dc=jerarm,dc=roma,dc=te,dc=com"? Are you sure it's an *openldap* client or is it something else? --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 losing connection
by Quanah Gibson-Mount 02 Mar '17

02 Mar '17

--On Thursday, March 02, 2017 7:59 AM -0800 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Thursday, March 02, 2017 1:08 PM +0200 Nick Milas > <nick(a)eurobjects.com> wrote: > > >> Since "only some systems support the customization of these values; the >> keepalive parameter is ignored otherwise", how can I make sure that this >> parameter has been configured successfully and is enabled on my system >> (CentOS 7)? I enabled "loglevel config stats sync"but I don't see any >> mention of configured syncrepl parameters during OpenLDAP start. > > Hi Nick, > > The keepalive parameter was added after the initial 2.4 release, and > after the current sections on replication in the admin guide were > written. It was created because I kept encountering issues at customer > sites where load balancers & packet shapers were closing the syncrepl > connection. Oh, and to answer your other question -- "keepalive" works on linux, but not necessarily other *nixes or Windows. So CentOS7 would be fine. --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 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 01 Mar '17

01 Mar '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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical