openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Re: (ITS#6367) syncprov ... changed by peer, ignored
by hyc＠symas.com 13 Nov '09

13 Nov '09

olivier.chirossel(a)sfr.com wrote: > Full_Name: olivier chirossel > Version: 2.4.17 and 2.4.19 > OS: linux > URL: http://86.64.145.174:8080/ > Submission from: (NULL) (62.39.9.251) > > > in refreshend persist mode, the replication is incorrect for an entry which be > delete/add after master restart and before the reconnection of the slave. > 2) master set up > > on /etc/openldap tar xvf slapd_master.tar (get on the url ) The URL you provided always times out for me, so I've been unable to set up this test. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6365) Bad slapcat output when slapd running
by hyc＠symas.com 13 Nov '09

13 Nov '09

apm(a)mutex.dk wrote: > Pierangelo Masarati wrote: >> You appear to be using back-hdb. > > Yes. > >> My guess is that if this can fail, e.g. because entries are being >> sync'ed out of order, the DN does not get fixed. If this is the case (I >> couldn't inspect code deep enough to make sure), I'd expect that the DN >> get fixed anyway, though, because missing entries should exist as "glue" >> objects. > > yes. But if you plan to use slapcat as a backup mechanism, then it's > still a problem. Sounds like a low priority issue at best. Taking backups of a replica while it is initializing is pointless, just take a backup of the provider instead. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6365) Bad slapcat output when slapd running
by apm＠mutex.dk 13 Nov '09

13 Nov '09

Pierangelo Masarati wrote: > You appear to be using back-hdb. Yes. > My guess is that if this can fail, e.g. because entries are being > sync'ed out of order, the DN does not get fixed. If this is the case (I > couldn't inspect code deep enough to make sure), I'd expect that the DN > get fixed anyway, though, because missing entries should exist as "glue" > objects. yes. But if you plan to use slapcat as a backup mechanism, then it's still a problem. /Peter

1 0

Re: (ITS#6365) Bad slapcat output when slapd running
by masarati＠aero.polimi.it 13 Nov '09

13 Nov '09

apm(a)mutex.dk wrote: > Full_Name: Peter Mogensen > Version: 2.4.19 > OS: Debian Lenny > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (95.166.36.16) > > > Using openldap 2.4.17 and 2.4.19 linked with libdb4.6 and libdb4.8 in a > mirrormode setup: > > * Load the database with slapadd on server-1, start server-1 > The LDIF being loaded is generated with slapcat from a slapd 2.3.30-5+etch2 > Running on Debian Etch. I have no reason to suspect that it is not loaded > correctly into server1 > > * Start server-2 and monitor the progress of replication with slapcat, for > example: > > # for ((I=1;I<=20;I++)); do slapcat > out-$I; done > > * Look at the output: > > # for ((I=1;I<=20;I++)); do wc -l out-$I; done > > I would expect the generated files to be strictly increasing in size. > However, some times there's a file which is smaller than the previous. > In it I see LDIF entries like this: > > dn: > objectClass: top > objectClass: NamedObject > objectClass: simpleSecurityObject > uid: rieke > userPassword:: e1NBU0x..... > structuralObjectClass: NamedObject > entryUUID: e46b680e-e5f5-102b-93c9-79162adc1d46 > creatorsName: dc=admin,dc=example,dc=com > createTimestamp: 20070823185333Z > entryCSN: 20070823185333.000000Z#000002#000#000000 > modifiersName: dc=admin,dc=example,dc=com > modifyTimestamp: 20070823185333Z > > ... with an empty DN line. You appear to be using back-hdb. I note that in bdb_tool_entry_get() there is code specific to back-hdb that tries to lookup the parent of the current entry and, if found, "fixes" its DN. My guess is that if this can fail, e.g. because entries are being sync'ed out of order, the DN does not get fixed. If this is the case (I couldn't inspect code deep enough to make sure), I'd expect that the DN get fixed anyway, though, because missing entries should exist as "glue" objects. I apologize for the rather incomplete analysis, I can't dig further right now. I hope this provides some hint to others, unless completely wrong. p.

1 0

ITS#6375
by masarati＠aero.polimi.it 13 Nov '09

13 Nov '09

The ITS is to track software bugs. Please direct software usage questions to <openldap-solftware(a)openldap.org> and software interoperation questions to <openldap-technical(a)openldap.org>. This ITS will be closed. p.

1 0

(ITS#6375) Master Replica Synchronization
by jose.oliveira＠mailondemand.com.pt 13 Nov '09

13 Nov '09

Full_Name: Jose Vicente Fonseca de Oliveira Version: 2.4.11-1 OS: Debian 5.03 URL: ftp://mailondemand.com.pt Submission from: (NULL) (81.193.248.175) Dear Team, We have a PineApp antispam appliance that can authenticate users with our LDAP master server but cannot authenticate users with our LDAP replica server. For us everything seems OK but PineApp appliance just can't authenticate with our replica. PineApp refuses to give us further help saying that something is wrong in LDAP replication. Please, could you help us with that issue: the replica has the same information that master server has? We thank OpenLDAP Team in advance. Best regards, Jose Oliveira

1 0

Re: (ITS#6374) LDAP
by michael＠stroeder.com 13 Nov '09

13 Nov '09

atzig(a)mail2tim.com wrote: > Full_Name: Tim > Version: ? > OS: Win2003 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.62.17.129) > > > "Error 10: Referral" > > Unable to perform LDAP search - Error 10: Referral > This error means that the user's record in Active Directory was located on some > other server. > A "referral" in LDAP is simply a pointer or redirection to some other location > (or server). The "Error 10: Referral" error is usually caused by a misconfigured > LDAPBaseDN setting > > > LDAP was working correctly...started to receive this error after upgrading from > win2003 AD to Win2008. Could you please elaborate on what's the issue is with OpenLDAP client libs and/or tools? Ciao, Michael.

1 0

(ITS#6374) LDAP
by atzig＠mail2tim.com 12 Nov '09

12 Nov '09

Full_Name: Tim Version: ? OS: Win2003 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.62.17.129) "Error 10: Referral" Unable to perform LDAP search - Error 10: Referral This error means that the user's record in Active Directory was located on some other server. A "referral" in LDAP is simply a pointer or redirection to some other location (or server). The "Error 10: Referral" error is usually caused by a misconfigured LDAPBaseDN setting LDAP was working correctly...started to receive this error after upgrading from win2003 AD to Win2008.

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by pitpalme＠gmail.com 12 Nov '09

12 Nov '09

--001636988beae98b80047830ba81 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable pitpalme(a)gmail.com wrote: > masarati(a)aero.polimi.it wrote: > > pitpalme(a)gmail.com wrote: >> >> I do see attributes reflecting state after "modify" (which changes >>> "sn" attribute). >>> Where exactly should I expect to see a note about "glue state"? >>> Is output from "-d Any" helpful to figure what's going on (or wrong)? >>> >> >> My understanding of your previous message was that you got a positive >> result from delete, but an "Already exists" from a subsequent add. >> > > That=92s korrekt. > > > I inferred that you checked about the existence of the object and you go= t >> a negative result. >> > > In my current test scenario I do not check. > I assume a non-error on =84delete=93 in fact =84deletes=93, so I just che= ck if > response > code success (in Perl: '$res->code =3D=3D Net::LDAP::LDAP_SUCCESS=91). > > > Apparently, my guess was wrong. In that case, you probably hit >> ITS#6097 <http://www.openldap.org/its?findid=3D6097>. >> > > *hmmm* Good idea, thanks. > But after reading ITS description I don=92t think it=92s what troubles m= e. > We don=92t actually neither have =84multi master mode=93, but =84mirror m= ode=93 and > writes are done only on exactly one server, so there should not be a prob= lem > with second server producing a concurrent write/modify. > I=92d expect the delete to be correctly propagated, but I can=92t check i= t is > is, simply because I have to little knowledge to read debug log correctly= . Follow up: I modified my test Perl script to do a 'ldapSearch' after deleting and it returns zero as number of found entries. Sadly I have no idea, how to emulate '-MM' when using 'Net::LDAP' and it's search function, so I can't check for 'glue' entries this way. --=20 Regards, Peter --001636988beae98b80047830ba81 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote"><span dir=3D"ltr"><a href=3D"mailto:pitpalme@gma= il.com">pitpalme(a)gmail.com</a></span>=A0wrote:<br><blockquote class=3D"gmai= l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left= :1ex;"><div class=3D"im"> <a href=3D"mailto:masarati@aero.polimi.it" target=3D"_blank">masarati(a)aero.= polimi.it</a> wrote:<br> <br> </div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <a href=3D"mailto:pitpalme@gmail.com" target=3D"_blank">pitpalme(a)gmail.com<= /a> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I do see attributes reflecting state after "modify" (which change= s<br> "sn" attribute).<br> Where exactly should I expect to see a note about "glue state"?<b= r> Is output from "-d Any" helpful to figure what's going on (or= wrong)?<br> </blockquote> <br> My understanding of your previous message was that you got a positive<br> result from delete, but an "Already exists" from a subsequent add= .<br> </blockquote> <br></div> That=92s korrekt.<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I inferred that you checked about the existence of the object and you got<b= r> a negative result.<br> </blockquote> <br></div> In my current test scenario I do not check.<br> I assume a non-error on =84delete=93 in fact =84deletes=93, so I just check= if response<br> code success (in Perl: '$res->code =3D=3D Net::LDAP::LDAP_SUCCESS=91= ).<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Apparently, my guess was wrong. =A0In that case, you probably hit<br> ITS#6097 <<a href=3D"http://www.openldap.org/its?findid=3D6097" target= =3D"_blank">http://www.openldap.org/its?findid=3D6097</a>>.<br> </blockquote> <br></div> *hmmm* Good idea, thanks.<br> But after reading ITS description I don=92t think it=92s =A0what troubles m= e.<br> We don=92t actually neither have =84multi master mode=93, but =84mirror mod= e=93 and writes are done only on exactly one server, so there should not be= a problem with second server producing a concurrent write/modify.<br> I=92d expect the delete to be correctly propagated, but I can=92t check it = is is, simply because I have to little knowledge to read debug log correctl= y.</blockquote></div><div><br></div>Follow up:<div><br></div><div>I modifie= d my test Perl script to do a 'ldapSearch' after deleting and it re= turns zero as number of found entries.</div> <div>Sadly I have no idea, how to emulate '-MM' when using 'Net= ::LDAP' and it's search function, so I can't check for 'glu= e' entries this way.</div><div>-- <br>Regards, <div>Peter</div></div> --001636988beae98b80047830ba81--

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by pitpalme＠gmail.com 12 Nov '09

12 Nov '09

masarati(a)aero.polimi.it wrote: > pitpalme(a)gmail.com wrote: > >> I do see attributes reflecting state after "modify" (which changes >> "sn" attribute). >> Where exactly should I expect to see a note about "glue state"? >> Is output from "-d Any" helpful to figure what's going on (or wrong)? > > My understanding of your previous message was that you got a positive > result from delete, but an "Already exists" from a subsequent add. That=92s korrekt. > I inferred that you checked about the existence of the object and =20 > you got > a negative result. In my current test scenario I do not check. I assume a non-error on =84delete=93 in fact =84deletes=93, so I just = check if =20 response code success (in Perl: '$res->code =3D=3D Net::LDAP::LDAP_SUCCESS=91). > Apparently, my guess was wrong. In that case, you probably hit > ITS#6097 <http://www.openldap.org/its?findid=3D6097>. *hmmm* Good idea, thanks. But after reading ITS description I don=92t think it=92s what troubles = me. We don=92t actually neither have =84multi master mode=93, but =84mirror = mode=93 =20 and writes are done only on exactly one server, so there should not be =20= a problem with second server producing a concurrent write/modify. I=92d expect the delete to be correctly propagated, but I can=92t check = it =20 is is, simply because I have to little knowledge to read debug log =20 correctly. =97 Regards, Peter

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs