On Fri, 2006-06-16 at 23:19 -0400, ross brunson wrote: > As much as I agree that all of this is integrated, I think that > widening the scope to encompass all the possible permutations and > inter-relationships between these topics is a bit beyond this > format.
Quite the opposite! I'm trying to save the format. As of right now, by putting authentication, directory and naming into a Samba exam -- many services and capabilities that also service _outside_ of Samba -- we are going to have redundancy in exams. At the same time, there are additional services that also service Samba that may not be included. The fundamentals of how UNIX/Linux clients and servers handle network authentication, basic directory and resource lists and name and object services is pretty set to a _finite_ number of configuration files and services for each. You put all those in one exam -- because authentication, directory and naming is _basic_ to _all_ network services. Even if you don't use a seemingly discrete "directory service" with Samba, you are _still_ providing "resource lists" with nmbd either via broadcast or WINS. That factors in. I have this same discussion with Windows administrators too -- you still "publish" resources whether you just let broadcast or default SMB shares "show up" or you "publish them" in ActiveDirectory. These are very, very important considerations in an enterprise network. > You're talking about having someone answer a multiple-choice > question, it can't be THAT complex if it's going to be conveyed in a > single screen or even a couple of screens worth of text and pictures. Sigh, I just need to detail my ELResource site and people will see the obviousness of the truth. There's a lot of overlap, but the separations can be drawn. By attempting to put everything in a Samba exam, not only will be cram in a lot of concept that are _not_ Samba specific, not only will be _ignoring_ a lot of seemingly non-Samba details that real enterprises use with Samba, but we'll have a lot of redundancy in other exams too. Winbindd _can_ is _is_ used to map user/group to IIS or Apache. Winbindd can also be _left_ out and other mechanisms used to map user/group between Windows to UNIX/Linux systems. That's just one example -- something that should _not_ be in an exam that boils down to largely network file/print services that is already going to be jammed with authorization, DAC and other details -- including DFS and other administration. > I guess you've probably gone on about this enough to make the point, > so how do you propose to make all of this into objectives that won't > bloat up into something that takes us 2-3 years? Quite easily! Trust me, if we don't do it now, we're _really_ going to be kicking ourselves in the rear with lots of work later! And most of my peers will consider LPIC-3 to be a _joke_ as a result. It does require a number of experts who understand all the details -- at least for the objective portion. I have volunteered myself to write a lot of "all-inclusive" concepts and practices on the ELResources wiki -- and I hope to garner some support from other experienced consultants. E.g., weeks ago I tried to get some people who were experienced with both major OpenLDAP and Netscape Directory Server deployments -- the two GPL directory infrastructures out there. I need to ping those resources again. >From that, we can focus on the objectives that we can fit in the format -- and then _anyone_ can help write the tasks based on those. Lots of people understand most of the software, it's the greater Enterprise architecture that is lesser known. Again, it's really a matter of getting objectives that do _not_ "pigeon-hole" the entire 300 series for the next 5 years. We need to recognize what enterprise details make up general auth/dir/name that are then used by various file/print, by various Internet/web, etc... We don't have to define every exam today, but what is "common" among many services. Again, if we merely build an exam like Samba that is for a departmental server and doesn't give the faintest clue of integrating into an enterprise network, then it's going to be a joke. > I think that the farthest we should be going is to have a Networked File > Systems exam instead of just a Samba one, That's just my 2nd suggestion, because NFS as a file services protocol is _little_different_ than the underlying UNIX/Linux filesystem. There are _more_ issues with maintaining access and DAC consistency with Samba than anything. In fact, one way I commonly find Samba mis-configurations is because the files are also NFS exported (again, don't get me started). The concepts of file v. share are _sound_, and adding NFS into the mix is _nothing_. But that's not my #1 concern/suggestion ... > but I can't see making this into a full-blown directory services > integrated file system with various authentication modules exam, > unless everyone decides together that it should be reworked or > revised. STOP! That's _not_ what I'm saying! We're not talking about going to the ultra-anal depth of Directory Services. Even Microsoft doesn't get into that on the MCSE! Or Novell on the CNE! In fact, that's why Novell has the CDE! And Microsoft has introduced the MC Architect as well. We merely give 1) _basic_ objectives on elementary object naming -- that's largely DNS with SysV records with the addition of DHCP, dynamic DNS and a few issues that you run into. Maybe a little subdomain/subnet issues. Next is 2) _basic_ local and select network-based authentication. You're not much beyond files, PAM, NSS as well as "MD5 in store" such as NIS or LDAP. Then you mix in the network authentication like GSSAPI, Kerberos, NTLM/Winbindd and a few others. It's _not_ that complicated. Lastly is 3) _basic_ object directories -- how you map systems, groups and user in a networked-environment. How Winbindd can be used to access the SAM, storing the Samba schema with its SAM inside LDAP, or basic LDAP to LDAP synchronization for _basic_ system/group/user objects, etc... > Is that the goal? Are you asking the team to consider reworking the > current Level 3 plan? How do we come to a consensus about this, and > is it even open to a vote, as it were? Taki? What is the "current Level 3 plan"? I don't see much *EXCEPT* I'm the allegedly the "lead" on LDAP. > Never have said we don't care about client support, but at this level > it almost has to be a Services play and set of tasks, with a light > dusting of clients, we're TESTING them, not teaching them. They need to _know_ this stuff. I have seen _too_many_ Linux projects _fail_ because 95% of Linux consultants out there don't know the first thing about enterprise network design. If we are going to test on how to built _any_ network file services, we need to do it right. Otherwise LPIC-3 is just another Q&A and "I can learn this in a HOWTO" exam. And we're going to be certifying people who know how to build a SOHO or departmental network, and _not_ an enterprise one. In fact, that has been my #1 issue with the threads on the discuss lists in the past. I get tired of people saying, "oh, I never had to do that" and almost _everytime_ it boils down to, "oh, well, I've never worked in an enterprise environment -- I just had my departmental server and we were separate" (or worse, they had only a SOHO or tiny network). We should not be certifying people who can follow a HOWTO or Cookbook on merely setting up Samba. We need to be certifying them on an enterprise integration solution -- which _includes_ Samba as a core component. If we want Linux in the enterprise, we have to do this. It's not that hard people. It won't add any time. We just need to recognize this focus _now_. > And the main point you didn't mention is that you don't think we can > just have a Samba exam that addresses everything that Samba touches > or employs in it's inter-relationships. What I'm saying is that we need ... 1) To _separate_ out any authentication, directory and naming details that SMB uses from those that involve file, print, access control, locking, etc... for SMB. The auth/dir/name stuff is typically _not_ SMB-specific, and sometimes even "limiting" if you don't. 2) Consider the fact that there is _major_ overlap of SMB and NFS file service concepts. With the other "crap" moved out, you can move in the few NFS details -- many of which involve SMB anyway. If we're going to "pigeon-hole" this level 3 program to setting up Samba departmental file servers that aren't integrated, then we're already going to _bypass_ the enterprise focus. We will then have the same redundancy in every other exam -- re-focusing on common auth/dir/name concepts that were also covered in the Samba exam. And we might as well _not_ even have a NFS exam then. > I think the risk is that suddenly we are testing in very complex > scenarios that are going to be extremely difficult to fit into the > question format that we employ with VUE and Prometric. What "complex" scenarios? This is _open_source_! We use _open_standard_. Standard interfaces. It's modular in the first place! In fact, with my approach, we _avoid_ the "scenarios." In the "Samba is on its own," we are nothing *BUT* scenarios! We are making _assumptions_ on the scenario! In fact, that's why 95% of Linux projects I've seen fail (and I've come in to "clean up"). In fact, I'm fighting a big mess in Melbourne right now! > This is going to make for a lot of "scenario" style questions *NO*! Quite the opposite! It's very "piecemeal"! A Samba exam that attempts to address just a _few_ scenarios will quickly be that problem. And then you'll have the scenario questions on any Apache exam -- some same with a _lot_ of redundancy. I'm arguing that we tackle _all_basic_ authentication, directory and naming on *1* exam -- _avoiding_ the "scenario" non-sense we _will_ get with putting them into other exams. Again, if we try to address this on the Samba exam, we'll _only_ get a _few_ things in, and we'll miss a lot -- or we'll end up sucking up too much of the exam with auth/dir/name. Stuff that will then be partially replicated and redundant in another exam, such as Apache. > and those will be by necessity very complex to read, understand and > then pick an answer from a set list of single lines or sentences. Sigh, I honestly give up. No one is seeing the organization I'm talking about. I'm trying to _remove_ the complexity and _eliminate_ the scenarios from each exam. > Agreed, but again is the proposal that we chuck the current exam > layout, or alter the exams to better incorporate what you envision as > being needed? Where are we with the exam layout? I don't see much yet in the way of objectives. > Ah yeah, but it has to be doable, not be such a mass of > interdependent complexity that we can't write the exams. The way I see it, you're either going to have a complex Samba-only exam, or a Samba-only exam with maybe *2* common setups. -- 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
