For instance, looking at my own user record with dscl, there are
four properties specifying my home directory and two specifying
my user shell.
Actually there are 2 for home and one for shell. WGM / dscl etc
don't speak LDAP.. they talk to DirectoryService (the primary
daemon behing Open Directory). You're seeing the DirectoryService
(Open Directory, Standard, the terminology is messy) name in
addition to the LDAP (aka native) name.
NFSHomeDirectory and homeDirectory are the same thing (a unix file
system path). The former is Open Directory's name, the latter LDAP.
Oh yes, I had thought that the multiple representations were
capable of taking on independent values but I must have been
looking at a cached representation. Using WGM to code on one host
and dscl to observe on another, some of the properties are indeed
different keys to the same value.
It's not cached per-se. It's a translation.
In WGM's inspector, click options and un-check any check box that has
the word native in it. Or if you're interested in the LDAP names un-
check anything that has Standard.
NetInfo is represented in the same way. NFSHomeDirectory there is
home.. HomeDirectory (which is apple-homeurl in LDAP) is home_loc
in NetInfo*.
On my system, in /NetInfo/root/Users/<username> there's only the
"Apple" variety of any key listed. I suppose that's because
NetInfo's only going to be accessed by systems expecting something
which looks a bit like a passwd file, like OS X, NeXTSTEP, SunOS
and so on. I've never tried Jaguar's Netinfo-to-LDAP service to
see what that offers up.
lookupd still talks to NetInfo because it's faster than lookupd-
>DirectoryService->NetInfo
But it's still abstraction.. the same data is named different things:
This abstraction allows Mac OS X to interoperate with a wide set
of directory services.. like Active Directory or SunOne. This is
arguably the most important feature of Mac OS X to IT-centric
markets.
Despite the cross-platform nature of LDAP it's actually quite
hard to get a bunch of different systems talking, because as soon
as any client wants to write back you have to guess not only
which attributes you need to change but which ones everyone else
expects you to change for them.
That's the whole point of Open Directory.
Does it work that seamlessly when you've got non-Apple clients
connecting? That's what I'm trying to discover, and don't think
currently works well.
It's not something Apple does a good job of documenting. But it's
something that works petty well with modern Solaris and Linux
clients.. using nss_ldap for identification, and pam_krb5 for
authentication.
The biggest challenge is getting all the automount daemons on various
platforms to mount at the somewhat weird NFSHomeDirectory path Apple
uses (most nss_ldap configs seek out homeDirectory.. ).
For instance I have a few NeXTs and a Sun on my otherwise Mac
network; they connect via NFS to the homedir server while
everything else uses AFP. I've never let the Sun write into the
directory because while WGM more-or-less gets things right when
updates are made, from the perspective of making sure the
interdependent but unconnected properties all match each other,
there'd be extra work if I were using some arbitrary client which
connects straight to one of the directory services.
Why would the sun box need to -write- into the dir?
Of course the NeXTs don't use LDAP at all but a few hacked copies
of passwd mean that various directory services can keep their
passwords in sync...
NeXT's have a lookupd agent that will allow them to use LDAP. I
haven't tried to make it do LDAP bind authentication though.. NeXT
was bad about assuming that authentication and identification data
was all jumbled up together.
-mb
standard
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwinos-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwinos-users/email@hidden
This email sent to email@hidden
