>> - which version of OpenLDAP? The ones on CentOS/RedHat6 and Debian 7?
Okay, I've remained silent on this over the years. But since we're
now looking to put LDAP fundamentals into LPIC-2 (which is an
admirable effort I agree with), and people are already talking Red Hat
Enterprise Linux, let me point out a few details.
1) Red Hat does _not_ support OpenLDAP _Server_ under Enterprise Linux
2) 389 Server (Red Hat Directory Server entitlement**) lineage
continues to be extremely popular
3) 389 Server is also the basis for the increasingly popular, and Red
Hat supported, IPA (IdM)
So ... and keep in mind my "scope" is LPIC-2 -- _not_ LPIC-3 -- might
I suggest (this is the portion that is 100% my opinion) ...
A) LDAP fundamentals into the OpenLDAP Library/Client sections (which
all distros use)
B) Limit "Server" in LPIC-2 (again, differnt for LPIC-3) to where 389
and OpenLDAP match
C) Look hard at covering popular IPA (IdM) aspects -- e.g., SSSD and
Windows AD Forest Trusts
After the obvious aspect that LDAP fundamentals should be covered in
the OpenLDAP Library/Client sections, as all distros use them ...
I want to begin by re-emphasizes ... Red Hat does _not_ support
OpenLDAP Server. It ships it. It updates it. But that's largely for
the OpenLDAP Client/Libraries, _not_ the Server. So if you call Red
Hat with an OpenLDAP Server support ticket, you're going to be
redirected towards purchasing a Red Hat Directory Server (389 Server)
entitlement.** Why? One part is the sheer lineage from iPlanet and
enterprise usage, including multi-master replication that has been
around a long time. Red Hat looked at OpenLDAP a dozen years ago, and
decided to just purchase iPlanet Directory and Certificate from
AOL-Netscape instead, and open source it. The other part is the sheer
support costs.**
Secondly, since this is LPIC-2 -- I'm not talking LPIC-3 (which can be
OpenLDAP Server deep) -- I would really focus on where 389 Server and
OpenLDAP match. This includes the basic IETF 2307 POSIX schema and
other concepts that are crucial, basic concepts for admins, even AD
admins (e.g., even AD admins should know what "IdM for UNIX" is for in
AD). The more we proliferate this "commonality" at LPIC-2, the better
off we are as a Linux adminbase.
Lastly, SSSD is mentioned in LPIC-2 v3. Now it's time to expand on
it. I haven't met a single distro userbase in any enterprise that
didn't love SSSD once they took the time to learn it, and never wanted
to deal with any legacy *_ldap or *_krb modules again. Slowly but
surely more and more distros are building it correctly, along with the
IPA Client (Red Hat Enterprise IdM**), even if the IPA Server is
difficult to build on anything but a Fedora-lineage (although not due
to lack of Upstream desire).
We're also at the point that the features in SSSD, like multi-domain
support, along with how IPA's Windows AD Forests Trusts work, and how
it will solve real issues for real, multi-domain AD Enterprises with
the (external) Trust model -- including to Samba Servers in an IPA
domain for access by external AD principals (instead of being inside
an AD Forest that is only designed for Windows) -- that it's probably
not a bad detail to look at in LPIC-2. IPA (IdM) is the reason why
Red Hat's RH423 (Directory Server) class long became its least taken
class, and RH413 (Server Hardening) finally replaced it, along with
retiring the first, post-RHCE class ever created, RHS333 (Systems
Security).
**There's also a reason why Red Hat _includes_ IPA (IdM) support with
RHEL, while 389 Server (RHDS) is a separate, low 5-figures ("list
price") entitlement (with unlimited records though -- so a lot cheaper
than CAL solutions), even though IPA encompasses more than 389. I.e.,
it costs a lot of money to provide users support on "general
LDAP/Kerberos/Certificate knowledge, including flexible schema," while
IPA (IdM) is a "canned" solution that doesn't require sysadmins to
understand LDAP, Kerberos, DNS, Certificate, etc... internals (also
the reason why RHS333 was nix'd with RH423). If that sounds like AD
for POSIX, it is.**
-- bjs
**P.S. Keep in mind that Windows systems don't do POSIX attributes,
and Linux systems don't do Windows attributes (they can
enumerate/translate a few -- don't confuse otherwise), and to
centrally manage such, they must be different attributes. Which is
why the external AD Trust model is leveraged, because even Windows
admins don't all always agree on what Windows attributes should be
used either. Part of the problem with trying to use Linux systems
inside of an AD domain, let alone a full AD Forest. Better to emulate
an external one that has very fixed, negotiated communication, where
schema and object enumeration is separate and maintained externally.
;)
--
Bryan J Smith - http://www.linkedin.com/in/bjsmith
_______________________________________________
lpi-examdev mailing list
[email protected]
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
