On Mon Jun 23 20:41:33 GMT 2008 Jeremy Allison wrote:
>On Mon, Jun 23, 2008 at 04:28:30PM -0400, simo wrote:
>>
>> I think both cases make sense, and we can easily support both by adding
>> a new parameter called something like "machines search suffix", if set
>> this would activate a path similar to Jeremy's patch, otherwise the
>> current behavior would be maintained.

>
>Nope. No New Parameters (tm). This is a special case for a broken
>LDAP tree. If it works for that site then they'll have to use it
>as an out-of-tree patch (IMHO).


Jeremy, I think it's grossly incorrect to characterize my LDAP tree as
"broken". I would say it does not conform to the tortured arrangement
that Microsoft's activities have forced onto the Samba Team. I
personally consider netBEUI to be broken by design, and I've heard you
express similar sentiments. My LDAP tree works perfectly for all
our other operating systems - just not for Windows, and with older
versions of samba it works there too.

My LDAP tree was designed to optimally reflect the human economic and
social structures that it serves; it is intended to bring maximal ease
of use to the staff here and maximum reliability to everyone who must
rely on it. The past failures of the Microsoft corporation to design
a scalable and reliable network infrastructure do not make me want to
segment my user authentication data into subtrees based on volatile
location information. I want my users to be able to sit down
anywhere, any time at any one of our sites and have the systems behave
in a way comprehensible to mere mortals regardless of how many WAN
lines are currently down (since I have an office in the Katrina zone,
the T1s are not particularly reliable). Making the humans serve the
needs of the computers always reminds me of the "Moloch" scene in
Fritz Lang's "Metropolis", so I prefer to force our computers to
submit to human wishes whenever possible.

>> I wouldn't like to break the current behavoir by default if possible.

>
>Then let's just leave it alone.


I agree. I have a workaround, and once samba 4 is ready, I won't need
WINS - so I will just collapse the separate domains into one and all
will be well. I do think it ought to be documented that the LDAP
suffix parameters do not control samba 3's LDAP query construction in
any intuitive manner. I believe there are thousands of sites still
running RHEL3 that may be in for a big surprise when they upgrade, and
more documentation could help them avoid some pain.

Thank you very much for writing the patches, Jeremy; I really
appreciate the time that you've taken to address this issue! I am
leaving a half-dozen file servers on older versions of samba because
the greater flexibility provided by dynamically generated SIDs is
useful to me. My PDCs are all running Simo's latest Red Hat 5 builds,
and they work OK with the OpenLDAP ACL hack I've previously explained.

Thanks also to Simo & Volker for their assistance with RHEL5's domain
trust problems, and most especially to John T. for being an advocate
for all of us with multiple windows domains in a single DIT.

--Charlie