On Mon, 2006-06-19 at 13:15 -0300, Fernando Lozano wrote: > I agree with most you said, but I think your proposal for > auth/dir/naming has too much wide scope and that it is a step too big > from the level-2 certification.
I honestly think some of the more "elementary" auth/name can be done in the next LPIC-2 rev. We need to "step it up" on LPIC-3 IMHO -- "enterprise." > I think LPIC should build a progression such as candidates have benefits > from intermediate steps on the certification process. I think we both agree on that, but not the level of challenge. > That's the reason I don't think the "naming/auth" exam should include > winbind, nbns and ldap. Why? Winbindd is just another tool to map select Windows SAM attributes (either old NTLM as well as newer ADS) into the UNIX realm and vice-versa. It's a basic interoperability function. Where it applies to tying UNIX-Windows in that regard, it would go in the auth/dir/naming exam. When it applies to UNIX filesystem and Samba shares, it would be on the file/print exam. > I think it should create a solid ground on the concepts and basic > tools such as dhcp and pam, and following exams whould build and expand > on those. DHCP and PAM are already in some LPIC-1/2 stuff, and only those concepts with regards to enterprise auth/dir/name should be in LPIC-3. It's not that difficult. > NFS would be covered on LPI-301 because it doesn't add too > much and it could help tie everything together. NFS in _legacy_ IP-based authentication and then ID-based "sys" authorization mode does not add much. That's already covered in LPIC-1/2. NFS in "krb" and other, advanced authentication/authorization modes -- let alone the new NFS v3/v4 RPC services (e.g., for GSSAPI support) adds a crapload! Even not including the newer RPC services, there are some _key_ details. Now these NFS support details are already based on network and system-level details, so they aren't too much beyond covering auth/dir/name already -- and then the file/print as appropriate. Especially once you consider you are already covering many of these existing net/sys details for Samba. In other words, if we separate these things, we're have 2 options: 1. Recover the same stuff, redundantly, in each exam 2. Just chuck a lot of it out All I'm suggestion is option #3 -- don't tie non-Samba specific stuff to a Samba exam. > Basic security was already covered by LPIC-1 and LPIC-2 Oh hell no it ain't. It didn't even cover DAC, much less MAC/RBAC, which I understood from the meeting in April was pretty important in LPI-Japan. And that's just "Access Controls." If we want a joke of a Security exam like Microsoft's -- where over half of the 7 SSCP domains (I'm not talking about the full, and more conceptual 10 domains of the CISSP -- the 7 of the SSCP map _well_ to Linux security tasks) are ignored and everything is just "firewall and file permissions," then so be it. But understand what that says. > and there should also be some on the maming/auth exam. "Access control," "authentication," "transfer" and possibly even a tad bit of "crypto" (that's *4* domains) basics _will_ have to be be covered on that exam. I'm not saying otherwise. Please understand that. > Advanced logging would be split betweeen the auth/naming exam and > the security one. There's _more_ than just "advanced logging." ;-> > So a candidate could apply for LPI-301 (naming/auth) then LPI-302 > (Samba), then LPI-303 (LDAP) and endup with LPI-304 (security -- port > scan, ids, cas). I really think you can put auth/name in with basic directory concepts. Again, it doesn't need to be full LDAP -- just basic directory concepts -- including basic system/user/group object synchronization. As far as Samba, when you start dealing with file/print services, you're going to be covering native net/sys-level UNIX concepts anyway. So NFS makes sense at the same time. And the Security exam should cover _all_ tasks in the 7 domains of the SSCP that were not completely covered in other exams. That includes things like elementary SELinux -- which I understand is a "big deal" to LPI-Japan (someone correct me if I'm wrong). > LPI-301 plus any other would qualify for a "labeled" LPICP-3 > certification, for example LPICP-3-Samba or LPICP-3-Directory, > and employees could ask for someone who is both LPICP-3-Samba and > LPICP-3-Security, for example. I don't care how you market it. Have an "advanced" LDAP exam if you wish. But you can't ignore basic enterprise system/user/group object synchronization, or shove it off to another exam. > The only thing I don't have an opinion yet is if the LDAP exam would > cover samba-specific stuff or there should be a LPI-305 (samba+ldap), > because it's possible to build samba, ldap and security exams that are > standalone, but there's a strong intesection beteen samba and ldap, that > is, the specific issues of using samba with and ldap-based back-end. Just make sure we're not testing Samba to OpenLDAP cookbook methods. That's why I'd rather put that junk in an auth/dir/name exam when it deals with network-wide object synchronization. If people don't see what I'm doing yet, let me show you yet another angle: 1. We can test _more_ on Samba by splitting the auth/dir/name and file/print sections -- we've got 2 exams for complementary "Samba" foci 2. By having the auth/dir/name exam, we can _avoid_ being redundant in re-hashing the same auth/dir/name concepts used for Samba with those for Apache/Internet, other file/print, Database, etc... > I don't see a need for a general file services exam, because I see the > demand here is for samba-specific knowledge, not for nfs or afs or gfs > specific knowledge, And that's the common attitude, but not reality. Again, if you ask HP, IBM, Red Hat and many others, they will tell you their integrations are heavily Sun shops -- _not_ just Windows ones. NFS is not "optional" for enterprises running Linux and UNIX systems. As far as AFS, you can't discuss it alongside NFS or Samba, since it uses virtualized filesystems. I.e., while you can take local files and export them via NFS, share via SMB, etc..., you cannot export them via AFS. That's why AFS would _not_ be included. But the auth/dir/name concepts could be reused for an AFS/DCE exam if there was critical mass (I'd argue probably not), or the Apache/Internet exam, or various other exams. ;-> Hence why it _should_ be separate. Especially since many things from AFS/DCE now augment other enterprise capabilities. As far as GFS, it's an entirely _different_ beast. It would best to put it in an "Availability and Redundancy" (clustering) exam. I.e., GFS is _not_ an "exported" network filesystem -- but I know most people don't know that. ;-> > but if there's such a perceived need outside Brazil I'd propose a > LPI-306 (file services) that covers everything except samba, At some point I hope people realize that basic UNIX filesystem-level concepts are _integrated_ with NFS, and their consideration with regards to Samba is _no_different_ than talking about basic UNIX filesystem-level concepts. That includes POSIX ACLs, GSSAPIs, etc... It's like talking about Ford trucks and then solely focusing on the F150 and F350 (Samba and related services) when use most of the same parts as the F250 (UNIX/POSIX kernel and user-space support services including kernel NFS and its user-space support services). And then we have the general "Ford car" exam to start -- parts used by _everything_. > and would add things like rsync to regular network/distributed file > system stuff. Unfortunately that's not a RPC service like NFS or SMB are. You can add some notes in there for general "file services" -- but I'm talking about RPC services. NFS and SMB are a collection of RPC services. NFS uses native UNIX auth/dir/file capabilities and is built right atop of the native UNIX inode dentry/file structure. That includes NFS' services using the _exact_same_ auth/dir/file capabilities of the underlying OS with little to no reconfiguration. SMB uses a set of emulations -- one in how to tie into UNIX auth/dir/file capabilities such as NTLM, SAM, etc... that Windows Networking expects, and then another for the emulation of the SMB file services into a UNIX inode filesystem for what the Windows map expects. When you cover the UNIX inode filesystem emulation portion of Samba, you're basically covering NFS' detail too. When you cover the UNIX auth/dir/file tie-in for Windows Networking, you're basically covering native UNIX (and NFS) auth/dir/file mechanisms. I'm suggesting we actually _recognize_ this fact, instead of building an initial exam set that acts like people are *ONLY* using Linux file servers, *0* UNIX/Linux clients, and only tie into native ADS for any enterprise support. Especially when we're going to trip ourselves and say, "oh crap, we've already covered this on the Samba exam -- why didn't we just put this all in one?" when it comes to Internet, Database, NFS, etc... > That would be the place to add things like extended attributes and > posix acls, Whoa! Whoa! Whoa! Are you saying the initial Samba exam would _not_ cover advanced authorization? POSIX EAs/ACLs are _not_ optional in the Samba exam. Dealing with EAs/ACLs in _general_ are _not_ optional in _any_ exam AFAIAC. That's why we need to make a generic "network filesystem" exam -- to cover these *CORE* UNIX filesystem level concepts for _all_ possible network filesystems. And then we have a complementary auth/dir/name exam that is how you _map_ those objects across the enterprise. I think you just made my point for me! ;-> > and maybe lvm and raid. Storage, clustering, GFS, etc... and other "availability and redundancy" concepts should be covered in a dedicated exam, I agree. > But maybe this stuff would be better placed as a revision to the > current level-2 certification. Yes! We agree! For elementary system-level auth/name, yes, LPIC-2! For enterprise network auth/dir/name synchronization, that's LPIC-3. > I also think in a short time there will be a need for a > LPIC-3-Virtualization certification. Wait for the new AMD and Intel processors to hit, and then we can cover it. They will generalize virtualization at the hardware level far better than right now -- which is rather implementation-specific. But that too can go into an "availability and redundancy" exam. ;-> > I see there are proposals for developer level-3 certifications, and > those would not need the naming/auth exam, but could build on a general > autoconf/cvs/make or something similar before entering perl, php, java, > database and other specific exams. Let's deal with "sysadmin" for now. At most, that would possibly mean an eventually "DBA" exam. "Developer" could come later with critical mass. > Taki, is all I said in this message coherent with LPI plans for level 3? > I'd love to hire someone with all skill for all LPIC-3-* I proposed, but > I recognize employees would most of the time be interested in a subset > of those qualifications, or would want to know who is a security expert, > or a samba expert, or a whatever expert, and so a fragmented (I called > "labeled") approach would serve better than an all-on-one "enterprise" > level-3 certification. Enterprise auth/dir/name concepts are pretty useful for _everything_. Internet, Network file/print, Database, etc... That's why I am _strongly_ "pig-headed" on this. ;-> -- Bryan J. Smith Professional, technical annoyance mailto:[EMAIL PROTECTED] http://thebs413.blogspot.com ---------------------------------------------------------- The existence of Linux has far more to do with the breakup of AT&T's monopoly than anything Microsoft has ever done. _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/mailman/listinfo/lpi-examdev
