[lpi-discuss] Some Objective Feedback

[Alan McKinnon]

On Thursday 08 September 2005 03:22, Ian Shields wrote:
> I ahppened to run across this thread at
> http://list.lpi.org/pipermail/lpi-discuss/2005-August/001871.html
> this afternoon. I apologize for the fact that I was not subscribed
> to htis list when Mark posted my original comments (with my
> permission) to this list. I also apologize if the headers for this
> message wil prevent it being threaded properly and for my manual
> simulated markup of the history. That siad, I'd laike to reply to
> some important issues.

Hi Ian,

Most of your replies are to my last comments, so here goes:

> >On Friday, 12 August 2005 18:29, Mark Miller wrote:
> >> We received some good objectives feedback from Ian Shields of
> >> IBM. Feel free to add your comments!
> >
> >Ian's comments are perfectly valid, when looked at from the
> > desktop user's perspective. Linux is used in many other
> > environments, so the exam needs to test and validate the
> > candidate's ability to provide server-side admin and desktop
> > support.
>
> This is good, but it isn't the stated objective.
> Check:http://www.lpi.org/en/lpic.html. where the stated
> requirements for LPIC-1 include:
>
> Overview of Tasks: To pass Level 1 someone should be able to
>
>     * Work at the Linux command line
>     * Perform easy maintenance tasks: help out users, add users to
> a larger system, backup & restore, shutdown & reboot
>     * Install and configure a workstation (including X) and connect
> it to a LAN, or a stand-alone PC via modem to the Internet.
>
> There is no *server* requirement for LPIC-1. I'm not saying there
> shouldnt' be, merely reporting what the *stated* objectives are.

I wouldn't like to see "server" and "workstation" aspects to the 
objectives. There are different aspects to the same thing (the OS) so 
any separation will be needlessly complex and repetitive. What is 
true is that admins work with both aspects - he will maintain his own 
servers and also support his desktop users for example. The Overview 
you quote above does it for me. Mark replied elsewhere that there may 
be an implied server-side bent to the exam, and I agree with that. 
The desktop aspects are best covered with objectives that apply to 
desktops - USB, X, DVD writing etc

> >Also, the exam can only test mature stable technologies because of
> >relevance and problems generating exams items. Take /dev - a while
> >back we could have said that devfs should be tested. Not so, as we
> >now have udev instead. So the exam cycle must lag far behind the
> >technology development cycle. Keeping all that in mind, here goes;
>
> I agree with this and with the problem of keeping exam relevance in
> a fast-moving environemnt. Unfortunately, LPIC-1 hardware
> objectives are now quite back-level compared with current
> state-of-the-art.

<snip>

> >> - If we drop ISA stuff, how many folks actually configure IRQ,
> >> DMA or IO ports for PCI. PCI is inherently PnP, so you shouldn't
> >> need to do it. Is ti appropriate to LPIC-1?
> >
> >Operative word is "shouldn't". PCI mostly works, but what when it
> >doesn't? IRQ, DMA and IO ports are so fundamental to hardware that
> > I feel a candidate should know how they work and what they are.
> > Not knowing this removes a huge chunk of fundamental knowledge.
>
> I agree that IRQ, DMA and I/O ports are fundamental to computer and
> particularly PC operations. However, I just checked my ASUS A8N-E
> motherboard and the *only* PCI related thing I can configure is to
> reserve and IRQ for legacy devices. I can reboot a few other
> machines to check what options they have, but I don't recall too
> many that even allow anything but IRQ config for PCI. PCI was
> designed to solve this problem and it has largely accomplished its
> task. I once drove a 1926 Chevy with straight cut gears and no
> synchromesh that needed double clutching to shift gears, but that
> particular knowledge of transmissions is no longer required on a
> driving test. LPI certification should target what admins should
> reasonably be expected to know.

After a good long hard think I find that the only time I recently 
needed to fiddle with this stuff was 24 months ago - Mandrake 8 on an 
old PI and I needed to state the card's PCIID to get X to start. It's 
been 10 years since I even heard of a modem/mouse/sound card IRQ 
conflict.

There are valid reasons to both keep and drop this objective. Perhaps 
we need some feedback from an admin that still does use this 
knowledge frequently.

> >> - What's the goal of configuring a system without a keyboard?
> >> Are we assuming rack mounted servers, blades ro somethign
> >> similar? Are we assuming that access for initial setup will be
> >> via serial port? Or a management interface that emulates telnet?
> >
> >All the above. Racks and blades are a very important deployment
> >server-side and should be tested.
>
> See above. Objectives dont' specify server-side. As a tutorial
> writer, what shoudl I be targeting here?

Hmm, I have an easy answer to that one but I can't state it here as I 
might give away what would be a good exam item. For your needs as a 
tutorial writer I would say keep it simple and describe what one has 
to do to get any system to start that doesn;t have a keyboard

> >> - Should we consider SATA drives as well as SCSI and IDE? how
> >> about USB drives? configuring BIOS to boot from a USB key?
> >
> >The question is more "Are SATA and USB mature enough yet to
> > warrant the effort to generate items?" SATA shows up as SCSI so
> > if the time is right, examining them involves adding one more
> > element to the existing objective. Booting from USB isn't really
> > any different to booting from CD (BIOS-wise)
>
> SATA shows up as SCSI but has ATA in the name and hardware legacy.
> A user/admin needs to know what SCSI restrictions apply and what
> ATA restrictions? For example, how many partitions can a Linux
> system have on a SATA drive? Is it gated by the ATA limit or the
> SCSI limit? I *think* it's the SCSI limit of 15, but I don't have
> an SATA drive, so I'm not sure.

Good question, I also don't have a SATA drive. I also see posts from 
experienced admins on LUGs about SATA, indicating that they don't 
know it well either. Which raises a good underlying point: how 
prevalent does a technology have to be before we pull it into the 
objectives? SATA might be the next great thing with a great future, 
but including it in the objectives while only 10% of admins currently 
use it would be an error. If half the candidates use it in one form 
or another, it should be included.

I see SATA as something that will make it into the objectives, but I 
don't know when.

> Booting from USB is usually somewhat diffeent to booting from CD or
> DVD. On all my systems I have to reconfigure this almost every time
> I boot if I want to boot from USB. CD drives (except for USB ones)
> have a tendency to always show up at the same address in the device
> hierarchy. USB drives don't.. Also, GRUB sees them as hd devices,
> so booitng from a USB key may result in hd0 being the USB key while
> hd1 and hd2 are the real hard drives. If I happen to have two USB
> keys plugged in, then the keys become hd0 and hd1 and the hard
> drives hd2 and hd3. Compare that with booting from a CD where the
> drives would be hd0 and hd1 regardless. Try to write the GRUB
> config file to deal with *that*.

It's an annoyance in real life, but in terms of objectives I observe 
the following: admins think that a rescue system on a USB key is a 
good thing to have. So the objective would be "Configuring the system 
to boot from a USB key", and I'd vote for including it. I thought up 
two exam items while typing this para but can't include them here. 
Suffice to say that an item writer could focus on getting the bios 
settings right, or getting the boot loader config right

<snip modem and SLIP stuff>

> >Testing kppp as opposed to testing pppd is contrary to what the
> > LPI exams are trying to do. kppp is a gui front-end to pppd and
> > we expect the sysadmin to know how pppd works, both at the user
> > and the ISP ends of the link. GUI front ends to basic commands
> > like pppd do not feature on the LPI exams
>
> Agreed, but it's the way that most folks will configure a
> *workstation*. Does anyone still use this on a server? I mean, who
> even has a modem on server. In a rack? On a blade server? On a z9
> mainframe? With the size of packages these days, who can even
> afford to maintain a Linux system at current levels of software
> over dialup?

Do you have a First World point of view? The real scene in the Third 
World is very very different - a significant chunk of users are still 
on dial-up due to the cost of broadband. Somebody is maintaining 
those modem pools and the machines behind them. I see posts almost 
daily on local LUGS about servers with modems - they are used as 
fallback for that all too frequent case when our beloved broadband 
monopoly provider's ADSL service just ... stops. Or the 3G per month 
limit is exceeded and your international bandwidth drops to a level 
where a 9600 modem seems fast in comparison. A script-based solution 
with wvdial, pppd, et al is what works here and is in frequent use.

> >> What's our goal here? - How much are we expecting folks to do
> >> for sound (particulalry if we drop ISA)? Ditto for PC expansion
> >> cards.
> >
> >The 1.101.x objectives are clear on this - the focus is getting
> > the hardware to work at a hardware level (DMA, IRQ, IO port) and
> > avoiding conflicts at this level.
>
> The 1.101.3 objectives talk about PnP and  running isapnp and
> sndconfig. This is all effectively obsolete. Anythign that isn't
> obsolete is not unique to sound cards. Take a hard look at *all*
> the requirements that talk abotu ISA, PnP, isapnp, etc and see if
> they shouldn't all be in one seciton convering IRQs, IO ports, DMA
> and configuration in general. then see what's left.

I did look into this to see if I could come up with a better split, 
and I do have some thoughts on it. But nothing yet that I can put on 
list - I still have a ways to go

> >> - SCSI section need to consider that USB, and SATA drives show
> >> up as SCSI. We should also consider the impact of scsi generic
> >> (sg). FC2 dropped scsi_info altogether.
> >
> >See above.
>
> Yes. Ditto.
>
> >I see that Slackware, Knoppix and Xandros ship scsi_info. SuSE,
> > SLES and nld call it scsiinfo. It's not on my Debian, Gentoo or
> > LFS distros only because I didn't put it there. Mandrake 10.1
> > community is missing heaps of stuff anyway and FC as mentioned
> > does not ship scsi_info. Neither does Ubuntu, which focuses on
> > the desktop and is a niche product for purposes of LPI exams.
> >
> >I don't see scsi_info being retired anytime soon. I also don't see
> > FC as being a measure of what LPI should test - it's a
> > bleeding-edge, let's-prove-if-this-works distro. RHEL perhaps, FC
> > not.
> >
> >SCSI is a fundamental technology, if we remove scsi_info from the
> > list of key terms for objective 1.101.4, it will need to be
> > replaced with something.
>
> Take a look at sg (or read my tutorial). This is changing. If we
> want ot keep scsi-info then it's clear that we shoudl add scsiinfo
> since you've enumerated several distros that use it instead. One
> might wonder why it's packaged with PCMCIA utilities and why we
> aren't doign anythign for PCMCIA, wireless or any of the other
> technologies that are more likely to be on current workstations.

Strangely enough I never noticed the lack of PCMCIA in LPIC1 before. 
Logically I think pcmcia, hotplug and maybe udev belong together 


-- 
Alan McKinnon
alan at linuxholdings.co.za
+27 82 337 1935