Re: narrowing down profession

[Kara Pritchard <kara@luci.org>]

See, I told ya he was the best :-)

-Kara

On 6 Jun 2002, Jeff Licquia wrote:

> 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.
> 

-- 
Kara Pritchard                          Phone: 618-398-7360
Director of Exam Development            http://www.lpi.org/
--



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