Re: narrowing down profession

[Jeff Licquia <jeff@licquia.org>]

On Wed, 2002-06-05 at 13:30, Kara Pritchard wrote:
> On Wed, 5 Jun 2002, Bob Castleberry wrote:
> 
> > After getting my first sun cert this last week I've been thinking of
> > trying to narrow down my working fields from (knowing a reasonable chunk
> > of) Micro$oft/Novell/Linux/Unix to (being an expert in) Linux/Unix, more
> > specifically learning naming/directory services (nis,ldap,x.500), does
> > anyone know of any good material on name/directory services (web, books,
> > ect.) other than the standard oreilly books and searches on
> > google/amazon,  I would really like some feedback on books/articles you
> > have read or have heard to be really good, I appreciate the help, thanks
> 
> LUCI co-founder, Jeff Licquia, will be the best authoritative source on 
> this topic that I know. If he's not on silug-discuss already, I've cc'd 
> him on this message.

I'm not on the list; please CC on replies.

I got started by learning about directory services in general, and the
problems inherent in a DS.  DS isn't just about NIS vs. LDAP/x.500;
every server system with any concept of "multiple servers working
together" has a DS of some sort.  The old Novell bindery and Windows
NT/MS LanMan domains are both DSes just as much as NDS and Active
Directory are.  DNS is a directory service too, if you think about it;
besides generic naming services, everyone knows that "www.foo.com" is
"the main Web server at foo.com".  See RFC 2168 for information on using
DNS as a generic service resolver.

The next thing to learn is "why x.500 is generally better".  Most new
DSes are at least partially based on x.500.  Part of the reason for that
is political (all the top thinkers in directory services came over from
the OSI networking areas), but another reason is that x.500 is really
better.  This is especially true of the extended x.500 used by LDAP;
"dc=foo, dc=com" is a lot more distributed and scalable than "o=Foobar
Industries, c=us".

After that, it's a really good idea to learn LDAP and figure out how it
ticks.  Unfortunately, here I don't have much to tell you.  One source
for information is the book _LDAP: Programming Directory-Enabled
Applications with the Lightweight Directory Access Protocol_, by Tim
Howes and Mark Smith (Macmillan), but that book is more focused on
people writing brand-new applications for LDAP.  The rest I learned
online.

Probably the next thing you should do is play around with using a DS for
its traditional main application: as a user/service/whatever information
service for shared multiple machines.  For this, you'll probably want to
unify a bunch of Linux boxes to use LDAP for user authentication, etc. 
Read up on how PAM and glibc's nsswitch stuff works, and read the
documentation for the LDAP PAM and nsswitch modules usually provided by
modern distributions.  The people who wrote both of these are at
www.padl.com; their site has lots of good docs, including the RFC for
how to store standard POSIX-required data in LDAP (2307).

When thinking about network user databases, you should also become aware
of the problem of secure remote user authentication.  This would be a
good time to learn about systems like Kerberos.

Beyond that, developing with LDAP becomes more relevant.  That book I
mentioned above becomes more useful at this level.  It's useful to learn
how other systems use LDAP to store configuration information, so look
for and learn about how other apps store info in LDAP.  (The Postfix
mailer does this in a very interesting way; that might be a good place
to start.)  By now, you will probably have learned about the sorry state
of easy-to-use LDAP tools; if you have a thing for developing new
software, you could try your hand at improving the situation.  (I've had
a project in the back of my head for years to write a GTK-based clone of
Novell's NWADMIN for LDAP, with a plugin API for extending it to new
data types.)  The main thing is to expand your horizons; LDAP is much
more than a glorified NIS, and you can do some amazing things with it.

Once you know LDAP, you can learn the multiple ways that Microsoft
breaks it.  To my knowledge, only older Exchange Server products were
truly x.500/LDAP compatible.  Active Directory is intentionally broken
on the Kerberos side.  Their "x.500" style service they use for
NetMeeting is broken too; the protocol for finding other people to chat
with on NetMeeting is vaguely LDAP-like and somewhat like x.500, and
there is actually a proxy for Linux that translates broken
NetMeeting-x.500 into something a real LDAP server can handle.  I
learned a lot of my cynicism about Microsoft over the sad state of DS
interoperability, and will inevitably discuss the situation as ammo when
people try to tell me that MS is "really serious about standards
compliance".

This is also a good time to learn why it's not necessarily a good idea
to migrate NT Domains to Active Directory, so you can oppose such a move
if your IT guys haven't made the switch yet.  If you do this, be sure to
learn about the available alternatives, such as NDS.

Something I'm delving into now is alternate directory services that are
intended to be more dynamic.  LDAP is great for finding services, but
poor at discovering them.  On LDAP, adding a new system involves
manually creating a new record for it; on NT Domains, you can in many
cases see new systems in Network Neighborhood with no configuration.  A
new protocol, SLP, aims to cover this deficiency in traditional DSes by
providing a scalable dynamic registration system.  As you can imagine,
it works completely differently from LDAP, although it can cooperate
with LDAP and DNS.

Hope that helps.


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