[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ITS#6439
--Apple-Mail-21-951114980
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On Jan 5, 2010, at 12:56 , Hallvard B Furuseth wrote:
> j@telepaths.org writes:
>> For compatibility reasons, It may well be in OpenLDAP's best interest =
to
>> provide options such as the ones I described previously, for "broken" =
or
>> "substandard" clients such as the ones I am using.
>=20
I do not program.
> If someone (you?) cares enough, they can write an overlay to
> the OpenLDAP slapd frontend which intercepts searches with
> (baseObject=3D"", scope=3DwholeSubtree) and changes the scope of
> the operation to baseObject. That shouldn't be much code.
>=20
Thats an interesting idea nonetheless, thanks.
> A server using this overlay must not have a database with suffix "",
> since this would break subtree searches in that database.
>=20
>> I will point out that Solaris 11 doesn't exhibit these issues ---- =
But
>> my company wants to use Solaris 10, which leaves me in the middle of =
a
>> finger pointing party between OPENLDAP and SUN. So you can =
understand
>> why I might be asking for something as strange as this ....
>>=20
>> SUN says OpenLDAP's standard/methods are questionable & strange.=20
>> OpenLDAP says Sun's client is broken and that we should hack it. I =
say
>> screw Solaris 10.
>=20
No this is a commercial support issue I am working on. I doubt its being =
publicized anywhere.
> Are they saying it somewhere public? I'm sure there are some OpenLDAP
> things they disagree with (I do too), but on this, RFC 4512 section =
5.1
> is quite clear, not to say loud:
>=20
> "The root DSE SHALL NOT be included if the client performs a subtree
> search starting from the root."
>=20
I appreciate what you're trying to say, but let me be clear about =
something. USERS do not care about RFCs. Even some Administrators, =
like me, don't care! We are too busy trying to make stuff work, rather =
that having a debate with the makers of software as to what rules they =
should be following.
Fortunately, I have a solution. I was surgical in whom I was going to =
argue with. I chose to argue with SUN and denounce their crappy =
software. They too touted RFC this and RFC that. I told them to shove =
their RFCs somewhere long and narrow. As a result, they ADMIT that its =
wrong and they're going to issue a BACKPORT for my situation. Which =
should have been done to begin with.
Nevertheless, as I said earlier, OpenLDAP (like many other high and =
mighty open source systems) should continue to follow RFCs like always. =
But it won't kill anyone to offer alternatives that do NOT involve =
reaching deep into the bowels of code we don't understand. Even if the =
solutions are bizarre, someone out there is wasting hours and hours =
trying to make his own solution work, and would be delighted to find =
something native had been implemented.
> (Onelevel search is not relevant in this context since it wouldn't
> return the baseobject anyway.)
>=20
Thanks for your input.
> --=20
> Hallvard
--Apple-Mail-21-951114980
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Jan 5, 2010, at 12:56 , Hallvard B Furuseth =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div><a href=3D"mailto:j@telepaths.org";>j@telepaths.org</a> =
writes:<br><blockquote type=3D"cite">For compatibility reasons, It may =
well be in OpenLDAP's best interest to<br></blockquote><blockquote =
type=3D"cite">provide options such as the ones I described previously, =
for "broken" or<br></blockquote><blockquote type=3D"cite">"substandard" =
clients such as the ones I am =
using.<br></blockquote><br></div></blockquote><div><br></div><div>I do =
not program.</div><br><blockquote type=3D"cite"><div>If someone (you?) =
cares enough, they can write an overlay to<br>the OpenLDAP slapd =
frontend which intercepts searches with<br>(baseObject=3D"", =
scope=3DwholeSubtree) and changes the scope of<br>the operation to =
baseObject. That shouldn't be much =
code.<br><br></div></blockquote><div><br></div><div>Thats an interesting =
idea nonetheless, thanks.</div><br><blockquote type=3D"cite"><div>A =
server using this overlay must not have a database with suffix =
"",<br>since this would break subtree searches in that =
database.<br><br><blockquote type=3D"cite">I will point out that Solaris =
11 doesn't exhibit these issues ---- But<br></blockquote><blockquote =
type=3D"cite">my company wants to use Solaris 10, which leaves me in the =
middle of a<br></blockquote><blockquote type=3D"cite">finger pointing =
party between OPENLDAP and SUN. So you can =
understand<br></blockquote><blockquote type=3D"cite">why I might be =
asking for something as strange as this ....<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">SUN says =
OpenLDAP's standard/methods are questionable & strange. =
<br></blockquote><blockquote type=3D"cite">OpenLDAP says Sun's client is =
broken and that we should hack it. I =
say<br></blockquote><blockquote type=3D"cite">screw Solaris =
10.<br></blockquote><br></div></blockquote><div><br></div><div>No this =
is a commercial support issue I am working on. I doubt its being =
publicized anywhere.</div><br><blockquote type=3D"cite"><div>Are they =
saying it somewhere public? I'm sure there are some =
OpenLDAP<br>things they disagree with (I do too), but on this, RFC 4512 =
section 5.1<br>is quite clear, not to say =
loud:<br><br></div></blockquote><blockquote =
type=3D"cite"><div> "The root DSE SHALL NOT be included if =
the client performs a subtree<br> search starting from the =
root."<br><font class=3D"Apple-style-span" color=3D"#000000"><font =
class=3D"Apple-style-span" =
color=3D"#144FAE"><br></font></font></div></blockquote><div><br></div><div=
><div>I appreciate what you're trying to say, but let me be clear about =
something. USERS do not care about RFCs. Even some =
Administrators, like me, don't care! We are too busy trying to make =
stuff work, rather that having a debate with the makers of software as =
to what rules they should be =
following.</div><div><br></div><div>Fortunately, I have a solution. =
I was surgical in whom I was going to argue with. I chose to argue =
with SUN and denounce their crappy software. They too touted RFC =
this and RFC that. I told them to shove their RFCs somewhere long =
and narrow. As a result, they ADMIT that its wrong and they're =
going to issue a BACKPORT for my situation. Which should have been =
done to begin with.</div><div><br></div><div>Nevertheless, as I said =
earlier, OpenLDAP (like many other high and mighty open source systems) =
should continue to follow RFCs like always. But it won't kill =
anyone to offer alternatives that do NOT involve reaching deep into the =
bowels of code we don't understand. Even if the solutions are =
bizarre, someone out there is wasting hours and hours trying to make his =
own solution work, and would be delighted to find something native had =
been implemented.</div><div><br></div></div><blockquote =
type=3D"cite"><div>(Onelevel search is not relevant in this context =
since it wouldn't<br>return the baseobject =
anyway.)<br><br></div></blockquote><div><br></div><div>Thanks for your =
input.</div><br><blockquote type=3D"cite"><div>-- =
<br>Hallvard<br></div></blockquote></div><br></body></html>=
--Apple-Mail-21-951114980--