On Mon, May 6, 2013 at 5:38 PM, Alessandro Selli <alessandrose...@linux.com>wrote:
> I would agree, however a similar proposal was already turned down on the > grounds that Upstart > is too specific to just one major distribution, Ubuntu, and even there it's > future is not granted to > be long term. As LPI has to be vendor/distribution neutral, mention of > Upstart was frowned upon. > Interesting. From 2007-2011, Fedora was Upstart. RHEL6 (2010-2016, if we only look at Phases I & II) is Upstart as well. Yes, Fedora/RHEL doesn't make full use of Upstart as Ubuntu, but you still have to understand its service init and events for almost half of the system (especially spawning several things). It's probably too late now, I agree. But I'm still a bit dumbfounded the "Ubuntu only" argument was used, at least 2007-2011, when Fedora adopted it, and when it went into RHEL6. This was before Fedora started the move to a complete, DBus/Socket system manage framework (i.e., systemd et al.), circa late 2011. In reality, init and system management aspects should be rolled into one. Figuring out what is the init program, where are its configuration files for init, events, etc... for services, etc... I think that gets pretty non-specific. Especially the event-based stuff, that's not really Upstart-specific. I.e., I still have to go over this too many times with sysadmins, both RHEL6 and Ubuntu, with Upstart. We should have LPI professionals who understand these details. We're 3+ years in now. ;) > Well, LiLO too is still being maintained. Should everything in this > situation be part of LPI's objectives? > I absolutely don't see why we're covering LILO today. It's way too small of the installed base now. Way too small. I read the informative post exchange you had with David Evans about this. > I personally think LPI-1,2 ought > to have no topic that is only relevant to legacy installations, even if > they are on an artificially prolonged life-span. > I think when an Enterprise vendor declares something deprecated and only included for purposes of migrating, it's a good sign that it's going away. In the case of ReiserFS, that was 2009. And we have to seriously consider if an Enterprise Linux distro with such support is even still in "Active" enhancement phases. As I understand it, only SLES 11 and RHEL 6 (with 5 Phase II Last time I checked, only SLES 11, RHEL 5 (until 2014Q1) and RHEL 6 are the only ones actively taking enhancements. SLES 12 and RHEL 7 are possibly due within the next year, although both vendors do not pre-announce products. I think topics should be covered that are default selections in at least a > few of the major distributions. > What about having an LPI-3xx exam devoted to maintaining legacy > installations/packages? > Considering SuSE and Red Hat have their own programs, I think that would be redundant and wouldn't get much consideration. > While that is actually a good idea, to cover basic storage targets like > iSCSI, we may wish to seriously consider creating a new Storage-specific > level 300 exam instead. > > +1 > > [...] > > Just my $0.02, software-based storage is really a broad topic that could > easily justify it's own exam, and it's getting to be of major importance > that many sysadmins will soon be software-based storage admins as well. > > I agree here. > > [...] > This is the new frontier. Traditional storage cannot keep up. At the same time, application stack-designed storage has its limitations. Hence why software platform is the new innovator. Summing things up, you're proposing basic file-sharing only in LPIC-2 > (SAMBA & NFS), > and authentication, id-remapping, Domain Controller stuff and the like in > LPIC-3. > Sounds reasonable to me. > Yepper. In my view, 200 level is how to pass the Domain/REALM in /etc/samba/smb.conf, /etc/idmapd.conf, etc..., plus the gss entry required in /etc/exports, and that's about it. LPIC-2 sysadmins should understand what Domains/REALMs are, how IDs basically work (including MS UPN / KRB Principals nomenclature), but not how to configure the services. What about having now SSSD in LPIC-3 > Totally apples-and-oranges. You don't have the same objectives at different levels for "staging." ;) SSSD is 100% client-side. It's not a server. It's a set of local services for the local system iteslf. Think of SSSD, loosely, as the Linux equivalent to NT's Local Security Authority Subsystem Service (LSASS) with Security Service Provider Interfaces (SSPI). Linux has never really had one, it's been piecemeal, with a lot holes and/or not integrated with one another. Now SSSD adds that, augmenting a lot of existing libraries, still piecemeal, but designed to work together (finally) -- benefits of both flexbility and integration now. Windows, instead has opposite problem. They've always had an integrated one, and it's not very flexible, to the point even Domain models break down (trusts so tightly woven into transitive trusts into global roles and other things that don't always have the same schema). Even Integrated Windows Authentication (IWA) falls back to old NTLMv2 hashes via the NTLMSSP in some cases. E.g., virtually all of Microsoft's own "Federation" solutions aren't to solve cross-platform issues, but cross AD-forest issues. ;) Now let's look at the details. Take SSSD's LDAP module to start. Most of the configuration file settings in sssd.conf are almost the same as ldap.conf. Beyond the augmented features, there are just some security default differences (e.g., CA validation is required by default in SSSD). Most of these are regulatory/compliance requirements any way, and good to know. Heck, the reason why the pam_ldap options and defaults differ is largely because it's based on an older, deprecated defaults of the OpenLDAP libraries. Then you have the PAM aspects. But then SSSD actually _simplifies_ that. And then the NSSwitch ... oh yeah, SSSD actually _simplifies_ that too. You don't have to get into the advance feature of SSSD to cover its equivalents to various modules. It's easy. I don't know how else to say it, SSSD is easier to cover than the endless, separate modules. In fact, what trips most people up when they first tackle SSSD is that they keep using legacy components that have been replaces. It's really a matter of recognizing SSSD is the only open source solution out there, and re-writing the objectives for it. Then cover the few, legacy options for systems where SSSD isn't used for those functions. I.e., the power of SSSD is that you can _by-pass_ its modules if you want. You _can_ turn off its LDAP module and use legacy LDAP modules and their configuration. Again, why other distros have been (redacted) on anything related to Red Hat is beyond me, the upstream is really wanting distros to be involved, and are trying to write code that works on anything (even beyond Linux, although PAM and other dependencies are involved). It's really sad, because SSSD (let alone IPA for department-level IdM/auditing) is really something every single network, from SMBs to Enterprises, want. and the older pam_ldap/nss_ldap in LPIC-2 > The problem is that it's more than just two (2) modules that it replaces. There's Winbindd to start, and that's look LPIC-2, even if advanced aspects on the "services" side (Samba DC, OpenLDAP or even IPA) are 300 level. Again, I'd honestly re-write the sucker to be SSSD, and then contrast to the legacy. But that's just me. ;) with provisions of moving the older stuff out of LPIC-2 when SSSD > eventually becomes a widely > adopted default solution > Well ... if you want to go there ... ;) Because there are so many "holes" and/or complicated configuration requirements for enterprise with open source solutions, much the Linux world just uses _proprietary_ solutions, many with costly CAL licenses (and their "Free" versions are often quite inferior to SSSD), instead. Why? There is no open source option before SSSD. E.g., there wasn't even a good, easy-to-configure solution if your AD had IdM for UNIX installed and the IETF RFC2307 POSIX attributes populated _until_ SSSD came along. Now there is. So I think you're looking at this wrong. There's no "equivalent" to SSSD in the open source world. Heck, even most of the proprietary solutions out there are either AD-centric, or the vendor's own LDAP store-centric. That's it. SSSD is the killer subsystem. It does everything. And it's just using existing open source libraries and features, but augmenting with centralize caching, migration, replacements where existing stuff doesn't work well (several aspects of pam/nss_ldap, winbindd let alone it's caching, etc...). This scheme could be used for other things as well, like GRUB 0.97, > As I mentioned, drop GRUB 0.97 in the next rev. SysV init, some filesystems (EXT3, NFS<4), Desktop Managers (XDM)... > SysV init concepts will _always_ be around. Both Upstart and systemd support SysV init scripts. Heck, systemd can even monitor SysV init forked processes by Socket dependencies (it automagically detects) without any configuration. NFSv3 will remain. You cannot avoid it. NFSv3 and NFS4 are easily covered side-by-side. X Display Managers (XDM) are all basically the same, as far as access and other things. Their spawning is the only thing that gets init-specific, and differs, but that's related to init/service/system management. -- 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
