On Fri, 2005-03-25 at 08:33, Craig White wrote:
> I'm sort of through with this topic since you ask all these questions
> without taking the time to understand the technology - but are focused
> in on what you think you want and what you think that you know.
The *how* of the technology isn't the point - I can make a server
start and add and search records. The question you haven't
answered is *why* anyone would ever want to make their system
unique and unworkable with any others, and the related question
of why, given one system configured for linux and windows
authentication you can't just duplicate that setup for any
number of similar networks?
> there isn't a bizarre syntax for searching...there is only the syntax.
> In the way that computer languages look bizarre until I learn them, then
> I guess this is bizarre.
OK, it's a religious issue I guess. But I am not interested in
inventing any new attributes and searches - I just want something
that answers the already-done query that you get if you pick ldap
in authconfig and the already-done queries that are included with
samba.
> and yes, it does tell you why what the 'clients' are going to request
> but I suppose you would have to understand the technology to understand
> the technology. How does someone tell Postfix which filters to use if
> they can't run a search from the command line?
How do I tell the kernel what drivers to load when it boots? There
is a remarkable amount of technology in the distribution that
you don't need to understand to use. If your argument is that
LDAP isn't ready for prime time, just say so.
> If I am setting DSA up to be a samba domain controller, that changes my
> DSA substantially from those instances where I don't. Samba has this
> need to find 'Computers' as people and I don't want 'Computers' in with
> my 'People'.
There are lots of things I don't like to see. If that's what it takes
to make it work, I just won't look there. It doesn't have to be
pretty.
> Windows has an entirely different concept of Groups, where
> one group can contain another group (aka nested groups) but Posix
> doesn't have a clue what that is about. Windows has 'domain' groups and
> 'local' groups but Posix has only 'local' groups. So the answer to your
> question about why your setup might be different than mine or one setup
> might be different than another should be evident.
No. If yours is going to work with windows and linux and mine is going
to work with windows and linux (and I think I said that was a
requirement long ago), then the schema has to include both Posix and
samba stuff. If that isn't true, please clarify what the other
workable choices would be.
> Lastly - and it's obvious that I haven't made this point clear but I
> will try one last time...
>
> LDAP is entirely flexible - it is a database with teeth. It has been
> given other tools to make it useful for things like authentication
> systems.
Now you are sounding like a database admin that insists that all
programming tasks have to be re-invented as stored procedures
just because it is possible to do in his favorite language (and
it gives him a lot of job security). My goal is to avoid doing
anything unique or that would not work in any mixed linux/
windows network. Given that the client queries are already
built into the distribution I still don't see why that is
impossible.
> If some distribution or project comes up with an LDAP turnkey
> facility, it will be an entirely limiting, their concept, their
> implementation, their vision.
Yes, that's exactly what I want. Something that provides the
functionality to make the distribution work, and to whatever
extent other distributions follow the same standards, include
them.
> You will find it useful while you have no
> concept, little understanding of the implementation and no vision of
> your own. The only thing that will let you escape from that concept,
> that implementation and that vision is to learn the technology.
Yes, useful is what I want. There are plenty of other databases
for visions. Postgresql would probably be my first choice.
--
Les Mikesell
les@xxxxxxxxxxxxxxxx
