openldap-technical

openldap-technical@openldap.org

3 participants
9937 discussions

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

16 Mar '17

--On Thursday, March 16, 2017 9:08 AM +0100 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: >> It may also indicate that the >> schema between the master and replica do not match. > Can you explain? See above. Without knowledge of the schema on both servers, nor the knowledge of what the entry looked like on the master pre-modification and the entry on the replica as it exists, and what the entry is now, everything is all speculation. The fact the master accepted the operation would generally indicate that there is a serious mismatch in some way between the master and the replica. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: ldapsearch - unexpected behavior with "-h URI -p PORT"
by Quanah Gibson-Mount 15 Mar '17

15 Mar '17

--On Thursday, March 16, 2017 8:29 AM +0900 Alexandre Rosenberg <alex(a)r42.ch> wrote: > Hello, > > I run into some unexpected behavior using ldapsearch today and believe it > is a bug. It all started with following command: Hi Alex, This definitely appears to be a bug. Please open an ITS at http://www.openldap.org/its/ Thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

ldapsearch - unexpected behavior with "-h URI -p PORT"
by Alexandre Rosenberg 15 Mar '17

15 Mar '17

Hello, I run into some unexpected behavior using ldapsearch today and believe it is a bug. It all started with following command: ldapsearch -x -LLL -h ldap://localhost -p 10636 -b ${BASEDN} \ uid=${USER} -D ${BINDINGUSER} -W After checking the man page, it became clear that: 1. '-h' should take a *hostname* as argument (not "ldap://...") 2. Using '-H' (+ URI) is recommended instead of '-h'/'-p' And sure enough following command works as expected: ldapsearch -x -LLL -H ldap://localhost:10636 (...) The actual issue is what happens when running the fist command. - The "-h" option takes a hostname. As "ldap://localhost" is *not* a valid hostname, I would expect the command the fail - What happens instead is that ldapsearch connect to localhost on port 389 (!) $ ldapsearch -x -d 255 -h ldap://localhost -p 10389 ldap_create ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:389 Note this *only* happens when both '-h' and '-p' are used. When only '-h' is used, following happens which seem fine: $ ldapsearch -x -d 255 -h ldap://localhost ldap_create ldap_url_parse_ext(ldap://ldap:%2F%2Flocalhost) ldap_err2string Could not create LDAP session handle for URI=ldap://ldap: %2F%2Flocalhost (-9): Bad parameter to an ldap routine Bellow are some more example: 1. $ ldapsearch -x -d 255 -h example.org -p 10636 -> Connects to example.org on port 10636 (as expected) 2. $ ldapsearch -x -d 255 -h /example.org -p 10636 -> Connects to localhost on port 389 (!) - note the added "/" 3. $ ldapsearch -x -d 255 -h /example.org -> Fails as "/example.org" is not resolvable (as expected) Running the command will give you the debug output (which I omitted here). Note I am using openldap 2.4.44. I hope the explanation is clear. The behavior must definitely looks like a bug to me and got me very confused. Best, Alex

1 0

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical