Re: (ITS#6374) LDAP
by michael＠stroeder.com
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.
13 years, 6 months
(ITS#6374) LDAP
by atzig＠mail2tim.com
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.
13 years, 6 months
Re: (ITS#6368) Bug in deleting entry in MirrorMode
by pitpalme＠gmail.com
--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--
13 years, 6 months
Re: (ITS#6368) Bug in deleting entry in MirrorMode
by pitpalme＠gmail.com
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
13 years, 6 months
Re: (ITS#6368) Bug in deleting entry in MirrorMode
by masarati＠aero.polimi.it
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. I
inferred that you checked about the existence of the object and you got
a negative result. Apparently, my guess was wrong. In that case, you
probably hit ITS#6097 <http://www.openldap.org/its?findid=6097>.
p.
13 years, 6 months
Re: (ITS#6368) Bug in deleting entry in MirrorMode
by pitpalme＠gmail.com
masarati(a)aero.polimi.it wrote:
> pitpalme+openldap(a)gmail.com wrote:
>> [...]
>> When adding, modifying and deleting an entry it can happend I do
>> get a positive
>> return from delete, but a subsequent "add" fails with "code=68:
>> Already
>> exists".
>
> Can you check whether the entry actually exist, although in "glue"
> state? You can do this by searching (e.g. with ldapsearch) as the
> rootdn, to bypass access checking, and using the manageDSAit control
> (-MM).
I modified my test perl script to exit if adding the entry failed,
albeit a preceding delete should have removed it.
Then I manually ran
ldapsearch -D "rootdn" ... -b "TestBaseDN" -MM "cn=TestEntry"
I got
==== 8>< ==========================
[...]
# with manageDSAit critical control
[...]
dn: cn=TestEntry,TestBaseDN
objectClass: inetOrgPerson
description: oldValue
[...]
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
==== 8>< ==========================
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)?
--
Regards,
Peter
13 years, 6 months
Re: (ITS#6300) Add kqueue support to slapd
by bduncan＠apple.com
On Nov 11, 2009, at 9:45 AM, Quanah Gibson-Mount wrote:
> --On Wednesday, November 11, 2009 9:36 AM -0800 Bryan Duncan =
<bduncan(a)apple.com> wrote:
>=20
>>=20
>> On Nov 11, 2009, at 9:04 AM, Quanah Gibson-Mount wrote:
>>=20
>>> --On Tuesday, September 22, 2009 2:40 PM -0700 Bryan Duncan
>>> <bduncan(a)apple.com> wrote:
>>>=20
>>>=20
>>>> It was tested on OS X 10.6. Should work on all BSDs; nothing
>>>> OSX-specific about the kqueue usage in the patch. As far as kqueue
>>>> support in OS X 10.5, from what I see, most everything is there.
>>>> Certainly all of the kqueue features in this patch are supported in =
OS X
>>>> 10.5.
>>>=20
>>> Hi Bryan,
>>>=20
>>> The URL to the patch you submitted with this ITS doesn't work. Can =
you
>>> please put the patch somewhere accessible and let us know where it =
is?
>>>=20
>>> Thanks,
>>> Quanah
>>=20
>> Hi Quanah,
>>=20
>> My apologies for the bad URL.
>>=20
>> The new URL is:
>> http://public.me.com/bryan.duncan/bryan-duncan.kqueue.090922.patch If =
you
>> use a web browser to get it, there are extra steps: select the file
>> "bryan-duncan.kqueue.090922.patch" and click download. ftp & curl =
can
>> pull it down directly with no extra steps.
>=20
> Hi Bryan,
>=20
> Thanks for the quick response. Hopefully we can get this incorporated =
for OpenLDAP 2.5 series, and I'm interested in playing with it against =
2.4 to see how things change when used with Mac.
>=20
> Thanks!
>=20
> --Quanah
Awesome! I look forward to seeing it OpenLDAP. If there's anything I =
can do to help, please let me know.
Thanks.=20
-- Bryan
13 years, 6 months
Re: (ITS#6300) Add kqueue support to slapd
by quanah＠zimbra.com
--On Wednesday, November 11, 2009 9:36 AM -0800 Bryan Duncan
<bduncan(a)apple.com> wrote:
>
> On Nov 11, 2009, at 9:04 AM, Quanah Gibson-Mount wrote:
>
>> --On Tuesday, September 22, 2009 2:40 PM -0700 Bryan Duncan
>> <bduncan(a)apple.com> wrote:
>>
>>
>>> It was tested on OS X 10.6. Should work on all BSDs; nothing
>>> OSX-specific about the kqueue usage in the patch. As far as kqueue
>>> support in OS X 10.5, from what I see, most everything is there.
>>> Certainly all of the kqueue features in this patch are supported in OS X
>>> 10.5.
>>
>> Hi Bryan,
>>
>> The URL to the patch you submitted with this ITS doesn't work. Can you
>> please put the patch somewhere accessible and let us know where it is?
>>
>> Thanks,
>> Quanah
>
> Hi Quanah,
>
> My apologies for the bad URL.
>
> The new URL is:
> http://public.me.com/bryan.duncan/bryan-duncan.kqueue.090922.patch If you
> use a web browser to get it, there are extra steps: select the file
> "bryan-duncan.kqueue.090922.patch" and click download. ftp & curl can
> pull it down directly with no extra steps.
Hi Bryan,
Thanks for the quick response. Hopefully we can get this incorporated for
OpenLDAP 2.5 series, and I'm interested in playing with it against 2.4 to
see how things change when used with Mac.
Thanks!
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
13 years, 6 months
Re: (ITS#6300) Add kqueue support to slapd
by bduncan＠apple.com
On Nov 11, 2009, at 9:04 AM, Quanah Gibson-Mount wrote:
> --On Tuesday, September 22, 2009 2:40 PM -0700 Bryan Duncan =
<bduncan(a)apple.com> wrote:
>=20
>=20
>> It was tested on OS X 10.6. Should work on all BSDs; nothing
>> OSX-specific about the kqueue usage in the patch. As far as kqueue
>> support in OS X 10.5, from what I see, most everything is there.
>> Certainly all of the kqueue features in this patch are supported in =
OS X
>> 10.5.
>=20
> Hi Bryan,
>=20
> The URL to the patch you submitted with this ITS doesn't work. Can =
you please put the patch somewhere accessible and let us know where it =
is?
>=20
> Thanks,
> Quanah
Hi Quanah,
My apologies for the bad URL.
The new URL is: =
http://public.me.com/bryan.duncan/bryan-duncan.kqueue.090922.patch
If you use a web browser to get it, there are extra steps: select the =
file "bryan-duncan.kqueue.090922.patch" and click download. ftp & curl =
can pull it down directly with no extra steps.
-- Bryan=
13 years, 6 months
Re: (ITS#6300) Add kqueue support to slapd
by quanah＠zimbra.com
--On Tuesday, September 22, 2009 2:40 PM -0700 Bryan Duncan
<bduncan(a)apple.com> wrote:
> It was tested on OS X 10.6. Should work on all BSDs; nothing
> OSX-specific about the kqueue usage in the patch. As far as kqueue
> support in OS X 10.5, from what I see, most everything is there.
> Certainly all of the kqueue features in this patch are supported in OS X
> 10.5.
Hi Bryan,
The URL to the patch you submitted with this ITS doesn't work. Can you
please put the patch somewhere accessible and let us know where it is?
Thanks,
Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
13 years, 6 months
