openldap-technical

openldap-technical@openldap.org

7 participants
9864 discussions

Re: synrepl error 69
by Quanah Gibson-Mount 15 Mar '17

15 Mar '17

--On Wednesday, March 15, 2017 2:17 PM +0100 Sami <s.aitalioulahcen(a)cnrst.ma> wrote: > Hello Openldap community, > > I have an openldap syncrepl consumer that started producing this error: > > Mar 15 11:52:47 ldap-replic.domain.local slapd[27770]: syncrepl_entry: > rid=xxx be_add uid=xxxxx,ou=myou,dc=domain,dc=xx failed (69) > Mar 15 11:52:47 ldap-replic.domain.local slapd[27770]: do_syncrepl: > rid=xxx rc 69 retrying decimal 69 is hex 45. Hex 45 is: LDAP_NO_OBJECT_CLASS_MODS which is: Indicates that the modify operation attempted to modify the structure rules of an object class. Generally, it sounds like you're attempting to change the structural makeup of the object in question (say, changing from an "inetOrgPerson" to an "account" or similar action). It may also indicate that the schema between the master and replica do not match. Hope that helps! Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

synrepl error 69
by Sami 15 Mar '17

15 Mar '17

Hello Openldap community, I have an openldap syncrepl consumer that started producing this error: Mar 15 11:52:47 ldap-replic.domain.local slapd[27770]: syncrepl_entry: rid=xxx be_add uid=xxxxx,ou=myou,dc=domain,dc=xx failed (69) Mar 15 11:52:47 ldap-replic.domain.local slapd[27770]: do_syncrepl: rid=xxx rc 69 retrying I have a simple provider/consumer replication configured: olcSyncrepl: {0}rid=xxx provider=ldap://<provider>:389 bindmethod=simple b inddn="uid=<replicator>,ou=myou,dc=domain,dc=xx" credentials=secret se archbase="dc=domain,dc=xx" scope=sub schemachecking=on type=refreshAndPersis t retry="5 10 300 +" I couldn't find the error code on search engines. I'd like to know the possible causes/solutions to this. Thank you !

1 0

Re: unique values
by Howard Chu 07 Mar '17

07 Mar '17

Quanah Gibson-Mount wrote: > --On Monday, March 06, 2017 4:37 PM +0100 "A. Schulze" <sca(a)andreasschulze.de> > wrote: > >> >> 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. >> > > entryUUID is defined in RFC4530, as an internal LDAP attribute. Personally, if > you need a UUID for tracking, I would create your own specific to your > application/needs. For example, when I was at Stanford, we used suRegID > (stanford university registry ID) and when I was at zimbra, we used zimbraID > (zimbra identifier). There have been format changes in the past that required > wiping out some of the generated attributes when going between releases. This is bad advice. If you actually want a UUID then use entryUUID. As noted, it is defined in RFC4530 which means it isn't going to change. The format of UUIDs is well-established in internet standards. When an existing attribute has *exactly* the syntax and semantics that you want, use it. suRegID and zimbraID are not UUIDs are they? > Using your own identifier ensures that will not be an issue. Also, if you do > things like allow backing up/restoring user entries that have gotten deleted, > a restored entry (depending on the method use) may end up with a new entryUUID. Yes, you should only use the recommended backup procedures. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 2

dds overlay on mirrored master
by Dirk Kastens 07 Mar '17

07 Mar '17

Hi, I'm running a mirrored master server and several read-only replicas. Now I want to deal with dynamic objects, so I enabled the dds overlay. Because the config is mirrored, the dds-state is TRUE on both master servers. In my syncrepl statement I set schemachecking=off and exattrs=entryTtl,entryExpireTimestamp. The replication of dynamic objects is working. My question is: will there be a conflict when both master servers are trying to delete expired objects at the same time? What's the best way to configure the dds overlay on a mirrored master? Thanks in advance. Dirk

1 0

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

07 Mar '17

--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. I use the following: keepalive=240:10:30 The 240 because most of the hardware causing problems used a 5 minute timeout, so 240 was nicely under that. If setting this resolves your problem, then you have something in your network monitoring and severing connections. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: unique values
by Quanah Gibson-Mount 06 Mar '17

06 Mar '17

--On Monday, March 06, 2017 4:37 PM +0100 "A. Schulze" <sca(a)andreasschulze.de> wrote: > > 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. > entryUUID is defined in RFC4530, as an internal LDAP attribute. Personally, if you need a UUID for tracking, I would create your own specific to your application/needs. For example, when I was at Stanford, we used suRegID (stanford university registry ID) and when I was at zimbra, we used zimbraID (zimbra identifier). There have been format changes in the past that required wiping out some of the generated attributes when going between releases. Using your own identifier ensures that will not be an issue. Also, if you do things like allow backing up/restoring user entries that have gotten deleted, a restored entry (depending on the method use) may end up with a new entryUUID. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

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

06 Mar '17

--On Saturday, March 04, 2017 6:39 PM -0800 "Paul B. Henson" <henson(a)acm.org> wrote: > It seems like this has something to do with duplicated operations? The > first time this operation was applied, the eduPersonAffiliation > attribute did exist, with a single value that was removed. Then for some > reason it's like it tried to remove it again and went boom? But there > was no operation that *actually* failed. Everything that the client > tried to do was done. > > BTW, I opened the ITS for tracking, it's #8609. Thanks... Great, thanks! Trying to get to a point where I can focus working on this. Can you follow up to the ITS with the notes about the method being used by your perl script to do the deletes as well as the link to the schema? Just so it's all in one spot :) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical