On Tuesday 29 January 2008, G. Matthew Rice wrote: > > Add something to topic 109 about secure passwords: cracklib, > > password aging, The concept that via PAM you could use other > > methods. But not HOW to do this: Should be in LPIC 2 by extending > > 210.3) > > Password aging is part of 107.1 but I was kind of hoping to keep the > PAM and cracklib type topics to LPIC-2. If enough people disagree > (and you'll have to speak up for me to know that you disagree ;)), > I'll put it in.
I agree. PAM is a devil of a thing to get through people's skulls - it's complex and very abstract in it's configuration and syntax. In practice I find people initially just go with whatever the distro provides and by the time they get up to fiddling with PAM they are pretty much at LPIC-2 competence levels on many other topics already > I'm also a little hesitant to 'mention' a topic on LPIC-1 that is > covered in depth in LPIC-2. It's lead to a lot of confusion on how > much of the topic to put into LPIC-1 courseware with the result > usually being too much information for the student (Reinier, wasn't > that your comment in Utrecht?). Again, I'll bow to pressure if > people think I'm offbase. Good point and one worth remembering as a guiding principle. It's not always possible or desirable, a prime example is Apache - the objective wording is such that's it's very obvious there is a basic and an advanced level. For the many topics that are now taken care of by the distro (eg PAM, compiling from source, custom kernels, udev) I would definitely be looking at having such topics in LPIC-2 and not in LPIC-1 at all > > * 101.1 Determine and Configure Hardware Settings* > > > > Should this topic not include a conceptual knowledge of sysfs -> > > udev -> hald -> dbus. Not test all low level configs that can be > > made here. But an understanding how modules get loaded, device > > files are created and the GUI get a signal to display extra desktop > > icons? At least the concept of it all. > > I agree and it was hinted at but I've put these in explicitly. I'm imagining myself writing items for that at LPIC-1 level and having visions of retreating from it in terror to seek out low hanging fruit instead :-) Maybe I'm putting the horse before the cart here, but I feel that in general if I would have trouble generating items for an objective at a certainlevel, then I should question why the objecyive is in the level at all. Example: Stuff like udev, dbus and hal is covered briefly by Red Hat just so that the student gets the picture as to how it all fits together, but it doesn't get any more coverage than that and there's only one very brief lab to edit a udev rule. The obvious intention is to show that editing these rule files does do stuff in /dev but one is not really required to know *what* it all does, > > Another topic to add: > > When to choose for 7+ partition system and a single partition > > (Desktop v.s. Server setup). Concept of: Flexibility vs easy to > > maintain. > > We had questions like these on the existing exams and they cause no > end of complaints. I dropped this sort of wording to get away from > the more 'subjective' topics. Agreed. I've even taken to avoiding this topic in classes as it leads to endless unneccessary discussions where the eventual answer is always "It depends". I doubt that such concepts are reliably examinable > > * 102.3 Make and install programs from source* > > > > Drop this topic. Should this whole topic be in the LPIC 1 exam at > > all. Working with Linux today can be done very professionally > > without fiddeling with source code. We actually warn students *NOT* > > to introduce source code that bypasses the package system in our > > courses! > > I propose to have a LPIC 2 exam topic about generating (rpm or deb) > > packages from source. Automatically you test the students ability > > to perform the configure / make / install cycle. Ordinary Linux > > users should not play with source code. This is something that > > should be left to packagers working with distributors or senior > > administrators within an organization. Clearly all LPIC 2 stuff.... > > This isn't a tough sell on me. I have already 'dumbed' it down (the > original objectives included compiling SRPMs and src debian packages > plus editting Make files, etc) but would feel better about dropping > it altogether and putting it in LPIC-2. > > Any naysayers? Not from me. I find two groups of people these days by and large that actually do compilations: a. Someone needs something new and does "./configure && make && sudo make install", and b. Gentoo users. It's out of place in modern LPIC-1 I feel > > * 108.2 Basic Network Configuration* > > > > Maybe NetworkManager should be tested as well. > > Nah, that'd be too easy on them :) lol! is iwconfig/iwlist covered at this level anywhere? I find those tools indispensible on getting notebooks up and running after install. I'd also expect an LPIC-1 junior to do it instead of me doing it :-) -- Alan McKinnon alan dot mckinnon at gmail dot com _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
