Re: narrowing down profession

[Jeff Licquia <jeff@licquia.org>]

On Thu, 2002-06-06 at 12:15, Bob T. Kat wrote:
> Thought I'd slide this over here since your not in silug
> 
> I have been dealing with directory services for quite some time by means
> of netware 3.x (bindery)/4.x/5.x and nt 3.51/4/2k. oh and also dns
> administration.  Accept as I mentioned I'm now focusing down to the
> world of unix/linux. So I do understand the concepts of DS and name
> services (although I will check out that rfc on dns). 

Cool.  Just covering the bases.

> I hadn't thought
> about researching Kerberos as being part of this, thanks.

Strictly speaking, Kerberos isn't a DS issue.  However, having networked
user databases implies a lot of problems with secure networked
authentication.

> I currently
> use ddns with dhcp to do all of my name automatic name resolution (on
> non-static systems, it does tie in well with my slave 2k server), how
> does this compare with something like SLP?  I'll hop on a search engine
> and check that out.  

SLP doesn't replace ddns; it's an adjunct to it.

Here's an example I'm familiar with: Imagine you're using CUPS to manage
all your printers.  Now imagine buying a new printer, plugging it in to
a print server, and configuring a CUPS queue for it.  Now imagine being
able to immediately walk over to a random print client and print to the
new printer with zero setup - just "lpr -Pnew_printer ..." or, for the
GUI equivalent, having the new queue show up in a drop-down for a print
dialog.  This is possible today with CUPS, both via a CUPS-specific
broadcast announce system and via SLP.

The main idea is to have automatic updates of information for particular
types of resources that can change, where it's more of a pain to enter
into a directory manually.  SLP has a lot of advanced features this way;
you can advertise custom services, and can even attach location
information so, for example, clients automatically pick the closest
printer available as the default printer.

> You did throw me with something though. I have always been under the
> impression that LDAP was a smaller subset of the x.500 (being that it
> was developed to access an x.500 server from a weak client) and was
> missing a lot of the server replication and redundancy features of a
> full x.500 directory server. When you said that LDAP uses extended x.500
> would that be in relation to schema and the way it handles information
> or are there other extensions?  This has been a dilemma for me in trying
> to figure out why everyone would want to use LDAP servers when you (as I
> understood it) get more power and benefits from running a full x.500 and
> can still access it with an LDAP client. 

You're confusing content with protocol.  Not that you can be blamed;
it's not made clear enough in most of the docs.

x.500 got its start with OSI.  You're familiar with the OSI layered
network model; what you may not be familiar with is that there is a
complete alternate networking system associated with it called the OSI
protocol.  OSI was supposed to be "the" global network protocol,
perfectly scalable, fast, and useful for all known purposes; TCP/IP was
considered by lots of people to be a "stopgap" until OSI was ready. 
Unfortunately, as often happens, OSI was way overengineered, and was so
unwieldy and top-heavy that no one saw any benefit in using it; it was
also late, and was unable to stop TCP/IP's momentum when it did finally
arrive.  It was deployed at one time, but I don't know if it's still
alive.

Anyway, one of the protocols in OSI was DAP, the Directory Access
Protocol.  It required lots of the rest of the OSI stack, and was very
complicated (as befitted the whole OSI way).  The data model for DAP was
x.500; it dictated the form that directory entries would take, how the
namespace was laid out, and so on.

When it became clear that OSI was a dead end, some of the engineers for
the OSI directory service reimplemented DAP on top of TCP/IP, stripping
out most of the complicated parts.  The result was LDAP.  As I
understand it, they used the x.500 data model pretty much as is, to the
extent that it was possible to use a real OSI directory server on the
Internet via a LDAP gateway.  In fact, I believe that some of the first
public LDAP servers were really DAP servers with LDAP proxies.

So, the protocol is stripped down, but the data model is pretty much the
same - a little extended, actually, with the "domain component" concept
in the namespace replacing the top-down "organization, country"
concept.  I don't think they dropped anything from x.500, with the
possible exceptions of specific objectClasses that were OSI-specific and
made no sense on the Internet.  Running a full DAP server means that you
have to run an OSI network stack, which isn't an option for most systems
today; that's why no one uses DAP now.

Incidentally, one of the few real-world implementations of DAP was
Exchange 5.x; MS actually implemented enough of OSI for NT to support
DAP.  The only software capable of using NT's OSI stack was Exchange,
though; not many people used it, and I have no idea if it's still
implemented in Exchange 2000 and following.


-
To unsubscribe, send email to majordomo@luci.org with
"unsubscribe luci-discuss" in the body.