--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--
-
j＠gropefruit.com