On Fri, Jun 7, 2013 at 6:49 PM, Fernando Lozano <ferna...@lozano.eti.br>wrote:
> I understood you proposed OpenLDAP (including least LDAP client for PAM > and NSS) out of LPIC-2. > I think you're mixing my posts. So let me summarize ... A) LDAP Client-only (200-level) Real simple ... - OpenLDAP client tools (e.g., ldapsearch, ldapmodify, SASL usage, etc...) - SSSD for PAM/NSS/etc... (deprecate old PAM and NSS LDAP) - [Optional] Kerberos client (e.g., /etc/krb5.conf) In a nutshell, I was unsure prior, but now it's looking like SSSD is broadly catching on. Even SSSD still uses OpenLDAP libraries for its LDAP modules, and newer than the ones in pam_ldap I might add. ;) B) AD Client + Samba DC (30x exam) Straight-forward ... - AD Infrastructure - SSSD for various AD Client support (replace Winbindd, SSSD does more now) - Samba 3/4 for smb services - Samba4 for DC - _Yank_ OpenLDAP services entirely - [Optional] Cross-forest AD Trusts with IPAv3 I don't see the reason for OpenLDAP in this exam, and it should be deprecated in a future revision. Yes, some people use it, but they are more legacy. It's easier to setup Samba4 with it. C) POSIX Client w/POSIX Infrastructure (30y exam) More complex ... (not a complete list) - OpenLDAP and 389 (I'm not going to say which to favor) - SASL certificates and other setup - Advanced SSSD configurations - Kerberos KDC configurations and setup - [Optional] IPA Server and Client (in addition to or replaces SASL/KDC setup) - NFS4 w/GSSAPI authentication/authorization/encryption I think that's simple enough. > I agree with two tracks for LPIC-3, one pure Posix, other Windows > integration, but think some openldap should be kept in LPIC-2. > I don't disagree. Again, I think you mixed my prior with more recent posts. And remember, SSSD uses OpenLDAP libraries. It uses more up-to-date ones, especially for compliance, than those in legacy PAM and NSS modules. I can dig to find the specific thread, please allow me some time. Maybe it > was actually a Fedora list. But you can see today the "technology preview" > packages for samba4 on RHEL and Fedora are file-server only, without DC > funcionality. > Incorrect assumption, as I'll explain ... > That's because Red Hat dosen't want to support two Kerberos libraries: > MIT for IPA, and Heindal for Samba4. I'm writing from memoy, may have > misnamed some package. > Red Hat builds with MIT, which presents some current limitations with AD DC, since upstream Samba4 is using Heindal. The DC functionality is _still_ there though. But there are limitations. I.e., the package "samba-dc" still provides DC functionality, just not fully AD compatible. > People from sernet built complete samba4 packages for rhel and centos 6, > but they bundle the heindal libs (statically linked?), instead of packaging > them as a dependency and "kerberos" provider as it would be the usual. > There are many issues with having both Heindal and MIT. Again, Red Hat continues to develop a full MIT stack, end-to-end, for IPAv3 (RHE IdM) and Samba4. People on Samba list are having success mixing Windows and Samba DCs, both > on domains started from Windows and domains started from samba4. I'm toying > with that on my vm lab. And samba developer's goal is supporting this kind > of mixed environment. > And yet ... if you just want a "DC" for Windows clients, Samba4 works very well. But the AD aspects have their limitations. > But so far without support for custom schemas, > IPA doesn't like custom schemas either. And they are disliked in the AD world too. But even putting that aside, because POSIX and Windows schema differ, they will never be the same. And given how AD works, that means a different Forest in virtually all cases. So the "best strategy going forward" has been to put Samba4 servers in an IPA Forest, and then that IPA forest has a Cross-Forest Trust with an AD Forest. There is this farce out there that AD can accommodate POSIX platforms. AD doesn't accommodate Linux well at all, and non-Linux even worse. In reality, what most people want is "Trusts." This approach does that, allowing AD users to access IPA resources, and vice-versa. Most of the limitations are all on the AD end. Windows client systems make a lot of assumptions, and aren't as flexible as POSIX. Just how it is. If someone needs something more flexible, then they have a full-up, flexible LDAP. In fact, this is how most Enterprises work "on-the-backend," even if their users only see AD at the "department-end." There are a lot of Red Hat Directory Server (RHDS -- upstream, 389) installations out there running _much_ of the world, many of which that started out as iPlanet lineage (either Netscape or Sun). and so doesn't support many windows apps that want to include their own > objects classes into the AD schema. > Didn't I basically say that with ... bjs> Samba4 cannot emulate every ISV add-on or specific services in AD, bjs> many of which have external Win32 run-time and other requirements. It goes _beyond_ just schema. ;) You see, samba4 is too important to be out of the current LPIC revisions, > but is also too imature to "depreciate" samba3 for many sysadmin. > I disagree. Again, and I'll re-quote myself ... bjs> I don't know why people keep equating Samba4 Win32-AD compatible DC functionality bjs> to Samba4 general DC functionality. Samba4 is release quality. Samba4 works very well for DC functionality. Agreed. :-) And I may be guilt of replicating some of it. ;-) > I have the tire tracks on my back over the last 6 years to prove it. ;) On the other side, speculation drives perception, and a certification that > has to say relevant for a few years before the next refresh has to include > a little of it, i guess. > Speculation definitely drives perception. Again, as I said ... "Red Hat doesn't care about the desktop" I was trying to say (pardon if my english skills are not very good) that > for a few years many shops will continue running samba3 so it should be > covered on LPIC, not assuming that if you know samba4 you can manage most > samba3 deployments. > I'm sure shops that have already made a huge investment into setting up OpenLDAP, Kerberos and Samba 3.x won't change any time soon. Many companies still have ReiserFS deployed too. ;) But I don't think it's worth LPI's bother to cover how to setup OpenLDAP for Samba 3.x. They should instead focus on Samba4 DC setup. For example, samba4 CANNOT act as a NT PDC. This code was pruned, AFAIK, > kept only on the samba3 tree. > What is a "PDC"? That is the question, isn't it? It's like saying NIS v. LDAP+Kerberos (or NIS+ for that matter) -- they are radically different. And because of this we can expect samba3 updated to come for some time, in > paralled to samba4. Also Samba4 cannot use an external LDAP server, like > samba3 can do (and sometimes need), which is a problem for some shops. > But do we want LPI covering an external LDAP server? I have this same discussion with people over IPA. They go, "oh, I don't like IPA because it's not flexible like LDAP." There's no reason they can't have LDAP exchange with an IPA server like many do AD as well. So I think LPIC should include both samba3+openldap and samba4. > I would drop Samba3+OpenLDAP like I would drop ReiserFS. In its place, I would focus on Samba4+IPAv3 instead, especially since you have the option of Cross-Forest Trusts. Remember, Samba is really about Windows clients and protocols. So any time you say Samba, you're immediately talking about Windows as well. IPA was designed to support POSIX attributes _and_ interoperate with Windows Infrastructure that uses Windows attributes. But that's just me. IPA is much easier to cover than OpenLDAP in this regard. However, LDAP services in general should still be covered, but just on a different exam (along with IPA). > I don't agree, pardon if I'm incorrect. AFAIK they are different code > trees (maybe branches). Someday improvements to samba4 smbd and etc may > stop being added to samba3 smbd and etc. > Samba4 smbd uses Samba 3.x smbd. I've never heard anyone say otherwise. Samba4 DC and Samba 3.x DC are different codebases, yes. But the former can do anything the latter can. No, it's not a "PDC." It wasn't designed to be. I know quite a few RHEL and CentOS shops that won't migrate to Samba4 DC > because they have both Samba LDAP schema and other app schemas on OpenLDAP, > Not just OpenLDAP, but even RHDS (389) as well. That's always going to be the case with any technology. Some people won't migrate. But the complexity of those setups are heavy. So do we want to cover those? Or do we want to cover the newer technologies that are 10x easier to administer? That's the question. I pick the latter. That just my opinion. ;) and they rely on the same user/group objects for Windows, Posix and other > apps. > And that's why SSSD will be covered for connecting to an AD Infrastructure -- especially if the AD Domain has IdM for UNIX installed and RFC2307 attributes populated. But if not, SSSD also does what Winbindd does, plus more. > They can't move to a samba4 dc because of AD schema restrictions. > Which is where the IPA-AD Cross-Forest Trusts come in. You keep POSIX tree separate from Windows tree, but you allow the two to use each other's resources. I.e., it's not much different than AD-AD Cross-Forest Trusts. Most AD admins don't like the schema changes other AD admins do in their Forests either. So it's no different than AD conversations. IPA just becomes "a different AD Forests." Trying to "unify schema" is already difficult for AD domains already. ;) For other shops, I agree samba4 is a real possibility and I recomend > everyone at least try a pilot. > I think you're looking past what IPA offers in this regard. > If this become true, I'm fine with removing openldap from lpicp. But not > on the current revision. That's despite the fact I'm eager to move my > current customer from openldap to ipa. > You're not the only one. The biggest problem with IPA is that people see the "services" as Fedora / Red Hat-only. Distros could have been "IPA ready" by adopting all of the open source Red Hat started releasing early last decade, but they kept seeing OpenLDAP as the "only" open source option (which was utterly false). So now everyone is playing "catch-up," and really only offering SSSD with IPA client, no services. I think LPIC has to deal with a little legacy. It's not about the latest > and the best, it's about what's actually deployed or not. > I see a lot of things that can't be covered, and would take extensive coverage to "get right." OpenLDAP integration with Samba is not something you do on-a-whim. LDAP in general is very, very extensive. That's why I think Samba4 DC is the solution that should be covered in the "Mixed Environments" exam, optionally with the IPA trust feature (and only that feature of IPA covered). And that's why I think _all_ LDAP should only be in the "POSIX Environments" exam, along with IPA, NFS4 w/GSSAPI, Kerberos, etc... But that's just my view. I think OpenLDAP with Samba easily dominates the exam. -- Bryan J Smith - Professional, Technical Annoyance b.j.smith at ieee.org - http://www.linkedin.com/in/bjsmith
_______________________________________________ lpi-examdev mailing list lpi-examdev@lpi.org http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
