"Bryan J. Smith" <[EMAIL PROTECTED]> writes: > But I do very much have a problem if we do a Samba-only exam, and don't > integrate Samba components into the greater auth/dir/name aspects, as > well as show where NFS also uses them.
The intent wasn't Samba-only. Just Samba focused. The original wiki page listed: Samba, NFS I had listed AFS when we were talking but it got "marketed" out. Same with Kerberos :( It seems that some enterprise clients just don't use it. I'm a little surprised but... Actually, let me write down the main points from the research: - linux in a mission critical and mixed environment - core network services - Samba, NFS, LDAP - capacity planning these were the areas of of interest for the first exam. I agree that the auth vs. file/print makes a sensible breakdown. > Got busy with a client all weekend, but sans one day this week, I should > have some good hours to devote to the outline and areas I believe need > to be covered. Again, from there, I'll let others decide -- but I want > to make sure people are aware of where I'm driving it. Sounds good to me. > In reality, we can call it whatever. My point has been, and continues > to be, whatever is used by virtually everything should be LPI 301. In > my experience, that's basic naming, that's centralized (possibly > distributed) authentication, and that's also how you publish resources > (be it broadcast, legacy resource listings, newer directory schema, > whatever). Take the most common details and practices and focus on > those. You got it. All of that should be in the 'LDAP' exam. Perhaps, we should rename the pages to the more generic titles of 'auth' and 'file/print', ... to help avoid the confusion? > I'm kinda shocked my viewpoint is not understood. But I'm commonly > known for not getting my point across in e-mail (far better in person, Yeah, I've noticed that :) > even better in presentation with charts). Or maybe I'm not seeing it > right. I really don't know at this point, just kinda shocked. It just seems that a few of you are starting at opposite ends. You are approaching it from the the top-down and others want to start getting at the details. We need a balance between the two. > I know everyone is concerned that we'll get "too generic." But in > reality, there's not too much that is commonly used. I hit on most of > them in one of my earlier posts. Those capabilities are used for so > many things, not just Samba. You keep working on the generic and others can do the details. There's room for both. > In fact, I'm kinda scared of putting just a few things in the Samba > exam, because they are really only used for standalone departmental > servers or, worse yet, when your enterprise is run by ADS. We really > need to be documenting how you built an enterprise with UNIX/Linux as > your authority on your network (and not just standalone). Well, they should be put in. This exam is part 'the ideal Linux-centric' setup but it's also part 'what is common practice today'. And I think that I mentioned the JTA helping with the weighting of importance on these tasks. > > The reason that we're picking things like Samba and LDAP is because they > > are big, complex and important technologies. We want people that pass > > these exams to be knowledgable about these complexities. > > Again, if we want to call the sames LDAP and Samba, so be it. > > But I'm definitely not in favor of making the LDAP exam only LDAP, and > the Samba exam only Samba. You have to not only address so much UNIX > filesystem and authorization detail in the Samba exam (which instantly > and simultaneously touches on NFS), but non-file services provided by > Samba like winbindd and nmbd also deal with clear auth/dir/name aspects > that are not independent of other network and system services. We're getting to that violent agreement stage. > "Availability and Redundancy" is where I had many things go ... > - Storage, organization (disk labels, filesystems, LVM2, DM2, MD, > etc...) > - Redundant network filesystems (shared/multi-target, GFS, etc...) > - Network-based availability > - Etc... I like that one. > It's now going into the Wiki. Just haven't had time to fill it in. But > I will get some things in this week. I had to track down my lawyer > today for other events (long story -- and not my current client ;-). Heh. That reminds me of this lady I heard of that introduces her second husband as her 'current husband'. > The proposal covered a lot of management aspects that are irrelevant. > And I had only gotten into the first 3 sets of objectives -- > auth/dir/name, file/print and security. Sounds okay to me. The first two are our focus this year. I think that security makes a smart focus next year. Although, I'm hearing rumblings of some embedded stuff being talked about. I should also point out that a major focus on the LPIC-3 development is to build up the tools to make exam development easier. That means we could actually start oodles of exams in various areas. The main problem will be cost of publishing with the test networks (let alone that whole hands-on issue ;). > > Agreed. Keep in mind guys, that when it comes time to do the JTA, all > > the tasks will be lumped together. It'll be up to us, in the early fall, > > to combobulate them back into two real sets of objectives/exams. We > > still have lots of wiggle room provided that we come up with an > > encompassing list of tasks for people to vote on. > > And that's what I do agree is a good plan. > > I still think it will come out into separating them out in how I'm > laying out the "8 domains" EL model, with many subdomains of concepts, > practices and tasks under each. > > I'll fill those in shortly on-line. -- g. matthew rice <[EMAIL PROTECTED]> starnix, toronto, ontario, ca phone: 647.722.5301 x242 gpg id: EF9AAD20 http://www.starnix.com professional linux services & products _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/mailman/listinfo/lpi-examdev
