LPI Linux Certification/Print Version

From Wikibooks, the open-content textbooks collection

< LPI Linux Certification
Jump to: navigation, search



LPI Linux Certification
Current, editable version of this book is available in Wikibooks, collection of open-content textbooks at URL:

http://en.wikibooks.org/wiki/LPI_Linux_Certification

The whole text is available under GNU Free Documentation License.


[edit] LPI Linux Certification






[edit] Introduction

This book covers the Linux Professional Institute™ family of certifications. There are three levels of LPI™ certification

  • Level 1: Junior Level Linux Professional.
  • Level 2: Advanced Level Linux Professional.
  • Level 3: Senior Level Linux Professional.

To obtain a certification a candidate is required to pass exams and, for Level 2 and Level 3, to hold a lower-level certification from the LPI™. All LPIC candidates are encouraged to browse the documentation at the LPI™ website. The resources there will familiarize the candidate with many things that are outside the scope of this book (e.g. exam cost, testing centers, other training resources) you are also encouraged to register with the LPI™ so that you can access the candidate area.
The Detailed Objectives listed within each of the modules in this book has been reproduced from the LPI™ website with kind Permission. We are however, to make it clear that the Linux Professional Institute™ does not endorse the work contained within this book in any way whatsoever.

[edit] Audience

This book is written specifically for the LPIC candidate, It is based as indeed is the exam around a community driven documentation project known as "The Linux Documentation Project". Each module in the book however, is organized around a particular subject. It is hence feasible for the casual reader to pick one particular module and study the material, with a view to gain a better understanding. However, many of the modules and in particular the Advanced modules will assume a certain skill level. It is also feasible for a new Linux user to come here with a view to learn Linux. However, although such readers are very welcome, they may be better served by studying the following material Linux For Newbies. The modules on the LPI Linux certification are heavily slanted towards up and coming sys-admins.

[edit] About this book

This book is organized so that each and every module can be accessed via the front page, this will be useful for readers who just wish to study or quickly gain information about one aspect of the exam syllabus. For exam candidates we have created an exam page which also has a table of contents that covers only the modules required for you to study for the various levels of the LPI™ . It is the hope of the contributors that the exam candidates will use the exam pages and their accompanying discussion pages to leave advice, tips and gotchas etc for other exam candidates.
The Module pages will contain detailed objectives followed by an overview which in turn will be followed by section headings covering the modules syllabus. At the beginning of each section will be a list of prequisite reading (hopefully all nicely formated) it is advisable to read them although the linked articles may not be required knowledge to pass the exam. However, they should relate to the individual sections they are contained within.

Lastly, we are obviously looking for Authors, We encourage all positive edits even if it is just to correct a simple spelling mistake or fix a link in short. "Every addition is very welcome."

[edit] Table of Contents

Wikibook Development Stages
Sparse text Image:00%.svg Developing text Image:25%.svg Maturing text Image:50%.svg Developed text Image:75%.svg Comprehensive text: Image:100%.svg


[edit] External links


[edit] Junior Level Linux Profesional

[edit] Introduction

Welcome! If you are here, then you are considering or have decided to take the Junior Level Linux Professional Exam. This page and its accompanying discussion page are specifically for you, and will explain your overall objectives for each exam (there are two exams you must complete before being certified). It is a good idea to come back here and perform a sanity check on your understanding against the overall objectives presented here. All that remains is for the authors and contributors of this book to wish you good luck.

Please note DO NOT contribute actual exam questions you may have been presented with in the past ANYWHERE in this book

[edit] LPI 101 Exam Objectives

The LPI 101 exam objectives:

  • Hardware & Architecture
    • Candidates should have a clear understanding of the concept of a BIOS and what role it performs, from the initial computer power-on to the services it provides to the Linux kernel. Furthermore, candidates should be able to identify all the options presented to them in a standard BIOS interface and further be able to gather basic information about the system from the BIOS (Menu navigation). Candidates should also be able to navigate a BIOS and make changes that will enable or disable peripherals, and compare the information provided to them from the BIOS with the information provided from the kernel. Candidates should also be able to determine compatible modems, configure those modems for outbound dial up and set specific port speeds from the command line. Candidates should have an understanding of the term SCSI (Small Computer System Interface) and how SCSI devices work (this includes the terms termination & SCSI ID). Candidates should also have an understanding of the terms Coldplug and Hotplug and be able to determine via BIOS and kernel methods the resources used for any given device that is attached. Candidates should be able to identify a Sound Card, and be able to determine if the kernel recognizes the sound card, as well as determine if the device has an issue/conflict pertaining to IRQ, DMA, or I/O. Candidates should also be able to understand USB devices and demonstrate a knowledge of the USB layer architecture.
  • Linux Installation & Package Management
    • Candidates should be able to design a disk layout that takes into account your system requirements and its purpose. Candidates should also be able to setup various boot locations such as a floppy or cdrom, install a bootloader and interact with that bootloader. Further, the candidate should be able to install, remove and query programs from both the RPM and DPKG commands. Using both RPM and DPKG distributions, candidates should be able to obtain package versions, installed package content, installation status and find any files or libraries that may or may not be installed on the system. Candidates should also be able to install programs from source via the make program, which generally includes the use of the tar, gzip, and bz2 compression utilities. Finally candidates should be able to identify shared libraries, load them and identify where the shared libraries should be located.
  • GNU & Unix Commands
    • Candidates should be able to understand the shell environment and how to change its behavior by modifying the .profile file, which is located in home directories. Candidates should also be able to send text files and output streams through utility filters to modify the output. Candidates will be expected to know how to move, copy, delete, find, create files and directories, and use recursion to delete and create both files and directories. Candidates should understand the use of redirects, pipes and sending your output to stdout (Standard Output) and to a file. Candidates should be able to list, create and kill processes as well as understand the "&" option and what it does. The candidate should also be able to monitor processes in real time, and be able to modify the priority of any given process. Candidates should be able to create simple regular expressions and use regular expression tools to search through filesystems or file content. Lastly, candidates should know the basic commands for vi.
  • Devices, Linux Filesystems, Filesystem Hierarchy Standard
    • Candidates should be able to set-up partitions and create filesystems, namely ext2, ext3, reiserfs, vfat and xfs. Candidates will know the tools that help maintain those filesystems and keep them in good working order, and use those tools to perform simple filesystem repairs. candidates will be able to mount and unmount filesystems manually and configure the system to mount them automatically during the boot process.Candidates will be able to implement a disk quota solution for your users. The candidate will understand file permissions and what tools to use to modify those permissions, as well as the concept of file ownership and how to modify file ownership attributes. The candidate will be introduced to both hard & symbolic linking, why it is used, and the usage of the ln command. Finally the candidate will understand the FHS standard and be able to determine where files should be located in FHS-based distributions.
  • The X Window System
    • Candidates should be able to install and configure an X Server, install fonts and configure an X font server, and determine if your hardware is suitable for an X server. Candidates will be introduced to the display managers gdm kdm and xdm, and will be able to configure any of these three display managers. Candidates will then be introduced to the Window Manager Environment and GUI. Lastly the candidate will be introduced to the usage of the DISPLAY environment variable, as well as the various files used for customization.

[edit] LPI 101 Table of Contents

Exam last Modified (31st December 2005)
Maintainer: Dimitrios "Taki" Bogiatzoules, Product Developer
Detailed Objectives webpage last updated (1st August 2007)

[edit] Hardware & Architecture

[edit] Linux Installation & Package Management

[edit] GNU & Unix Commands

[edit] Devices, Linux Filesystems, Filesystem Hierarchy Standard

[edit] The X Window System


[edit] LPI 102 Exam Objectives

The LPI 102 exam tests basic capabilities in the following areas:

  • Kernel
    • Candidates should be able to build, install, configure, manage and query a Linux kernel. This includes using the command line to get information about the running kernel as well as any kernel modules. The candidate should also be able to understand how to manually load and unload modules and to further understand when those commands are safe to perform. The candidate should be able to determine what parameters you can pass to any given module and how to load those modules with a name other than the file name that represents the module. The candidate should understand at a basic level the difference between monolithic and modular kernels with regards kernel module management.
  • Boot, Initialization, Shutdown & Runlevels
    • Candidates should be able to boot the system level by level, This starts with passing commands to the bootloader that will define kernel location and pass parameters to the kernel in order to solve problems with the boot process. The candidate will know how to locate and gather information from log files pertaining to the boot process. The candidate will understand the runlevel process and be able to set the default runlevel, as well as shutdown and restart the system from the command prompt this will include being able to terminate individual processes. The candidate will understand how to alert connected users that a major event is about to occur.
  • Candidates should be able to install/configure printers, print files, and manage printers both local and remote.
  • Candidates should be able to find and use man pages, internet documentation.
  • Candidates should be able to customize the shell environment, write and administrate simple shell scripts.
  • Candidates should be able to Administrate users, groups, basic security, implement backups, and the use of cron.
  • Candidates should be able to understand/configure/troubleshoot the TCP/IP stack, as well as configure a PPP client.
  • Candidates should be able to manage NFS and Samba daemons, administrate MTA's and the Apache webserver, configure DNS and SSH.
  • Candidates should be able to implement user level security, basic host security, and perform basic security administration tasks.

[edit] LPI 102 Table of Contents

Exam last Modified (31st December 2005)
Maintainer: Dimitrios "Taki" Bogiatzoules, Product Developer
Detailed Objectives webpage last updated (3rd August 2007)

[edit] Kernel

[edit] Boot, Initialization, Shutdown & Runlevels

[edit] Printing

[edit] Documentation

[edit] Shells, Scripting, Programming, & Compiling

[edit] Administrative Tasks

[edit] Networking Fundamentals

[edit] Networking Services

[edit] Security

[edit] External links


[edit] Hardware & Architecture

[edit] Configure Fundamental BIOS Settings

[edit] Detailed Objective

Weight: 1

Description
Candidates should be able to configure fundamental system hardware by making the correct settings in the system BIOS in x86 based hardware.
  • Key knowledge area(s):
    • Enable and disable integrated peripherals.
    • Configure systems with or without external peripherals such as keyboards.
    • Correctly set IRQ,DMA and I/O addresses for all BIOS administrated ports and settings for error handling.
  • The following is a partial list of the used files, terms and utilities:
    • /proc/ioports
    • /proc/interrupts
    • /proc/dma
    • /proc/pci

[edit] BIOS

BIOS Tips & Tricks
Familiarize yourself with
BIOS settings in equipment
that you support.
Know your beeps: You may
not have access to the
internet when things go wrong.
Change control: Always
make sure you can reverse
any change you make in a
BIOS.
BIOS updates: Keep informed.
Don't roll them out as soon
as they hit the mirrors wait
a couple of months then check
manufacturer forums for
problems with the update.
Once you are happy, update
one system, monitor it and then
roll out to the rest of your
systems. Document the
change, BIOS updates are
normally a nightmare to
reverse.
Be aware of the F1 key to
continue, particularly when
rebooting remote servers.
Lights Out Management
if it is available, utilize it.
Think long and hard about
implementing BIOS security.
Can the same level of
security be implemented
elsewhere? Normally it can.
Understand the limitations
of BIOS date and time.
Can system date and time
be better maintained by
other means?

[edit] Introduction

The BIOS (Basic Input / Output System) can be thought of as a suite of small programs that operate between the operating system and the hardware on any given computer. It provides a number of services that enable the computer to boot any given operating system. The BIOS can also provide or present other services to the operating system depending on the operating system and / or the type of hardware installed. It is also wise to note that a modern-day computer may have multiple BIOS chips interfacing the various different hardware components that combine to build the whole computer. These include Disk Array Controllers, Graphic Cards, Sound Cards, and possibly a few others. Firstly lets look at the services the BIOS provides regardless of which operating system is installed: these being the POST (Power On Self Test), Hardware Management, Security and Date & Time.

Intel and other manufacturers have developed another standard called EFI (Extensible Firmware Interface), which performs a similar function to BIOS, but does the job in a different manner. EFI is far more flexible and powerful than BIOS, but it has not enjoyed as much commercial success. Exploration of EFI is beyond the scope of this document for now.

[edit] POST - Power On Self Test

  • The POST process involves a small diagnostic program that checks system hardware such as RAM or motherboard components. If a particular piece of hardware is present, a basic test is performed to check for faults. More advanced tests such as a long memory test may be performed, but normally these features need to be manually enabled in the BIOS.
  • If the POST process finds errors it will usually sound beeps on the motherboard speaker and / or show some visual message via LEDs on the motherboard and / or messages on the screen. This is known as an "Irregular POST Condition".
  • The number (and in some cases the pattern) of the beeps, lights, or messages will aid you in diagnosing the problem; however, different motherboard models (even Mobo's from the same manufacturer) have different implementations of these signals, so it is always wise to have a printed reference manual for each model you support or internet access on another machine for a quick look-up.

[edit] Hardware Management

  • During the POST process, the BIOS allows you great flexibility to customize certain aspects of the system via settings stored in CMOS (Complementary Metal Oxide Semiconductor) memory. CMOS memory is volatile memory, but your motherboard has a backup battery to preserve any customized system configurations that you have made. This battery will eventually die. If you find that your computer is not retaining BIOS settings from one power cycle to another, the usual reason is that you need to replace this battery.
  • Useful BIOS settings often edited by users and system administrators may include:
    • Boot device priority
    • Enable / disable motherboard features like integrated video, LAN, or sound
    • Setting preferred memory addresses or IRQ vectors for PCI (or older) cards
  • On older motherboards these configurations were done by positioning certain jumpers or dip switches to the hardware manufacturer's specifications. Modern CMOS menus have replaced nearly all of these devices, with the exception of setting SCSI ID or resetting a BIOS password. There are still some "old school" motherboards in operation, so always keep the possibility of jumpers in mind.

[edit] Security

  • Most BIOSs allow the user to set a password. The computer will require this password to be input before completing the boot process. Often this BIOS password adds inconvenience without any real security: information on how to get around these passwords is freely available on the internet. If the user forgets this password, the computer will not proceed to load an operating system. It's not hard to see why BIOS Passwords are rarely invoked at the business level.
  • Many modern computers have the ability to detect configuration changes such as memory size changes and even if the case has been removed. The BIOS will often report these changes and prompt the user to press a key (usually the F1 key) to continue if this change is acceptable. Users may be required to hit another key to enter the BIOS configuration screens to change parameters depending on the particular BIOS manufacturer.

[edit] Date and Time

  • Setting the time and date are options within any modern BIOS. This is a "real-time" clock that runs constantly, powered by the same battery that preserves the CMOS settings. It's not very accurate, even compared to a wrist-watch, but it's better to have this poor clock than to require users to enter the time manually at every reboot. (That's how it was done in the early days of computers.)
  • Linux (like other operating systems) maintains its own clock in software by counting interrupts generated by an oscillator circuit in your computer. This clock only functions while the operating system is running.
  • The BIOS provides the date and time to the operating system upon booting. After the operating system has gathered this information, the BIOS clock and the Operating System clock continue to run independently. This means that the BIOS clock will soon differ from the operating system clock, even if it is only in milliseconds.
  • Linux has a command called hwclock which can be used to synchronize the operating system clock with the BIOS. Once synchronized, they will drift apart again, however. (This is due to the Hardware nature of the BIOS clock and the Software nature of the OS clock.)
  • Further on in the course, you will start to look at ntp and how important it is to maintain a consistent "Network Time". Knowing that the BIOS and operating system maintain separate clocks will aid you in setting out a solution.
  • The BIOS does not handle time zone or daylight savings time adjustments. These are handled by the operating system. For this reason, some administrators may choose to set their BIOS clocks to UTC rather than the local time.

[edit] Disk Drives

Most computers use Hard Disk Drives to hold an operating system and users' data. Some newer computers use Solid State Disk Drives instead. Though the physical devices vary greatly, there is little difference from the standpoint of configuring Linux or other operating systems.

[edit] Attachment Interfaces

Firstly let's address the confusion that often comes around from disk drive terminology such as IDE/ATA (Integrated Drive Electronics / Advanced Technology Attachment) and SATA (Serial Advanced Technology Attachment) and indeed PATA (Parallel Advanced Technology Attachment) which all use the ATA (Advanced Technology Attachment) standard to communicate with the device. The first part of the acronym can be thought of simplistically as a revision. For instance IDE, Fast IDE, EIDE, etc these revisions had changes made to the physical cables or ribbons that connect the disk drives to the computer that enabled certain features. This could be to address more disk space or speed up communications with the device. SATA was like a rewrite, once SATA came into being it was decided that all historical ATA devices that predated SATA, like IDE etc be grouped under the terminology PATA.

SCSI is another popular attachment interface that has undergone several generations of revision over the years: SCSI, SCSI-2, SCSI-3, U160, U320, and SAS. Click on the link at the head of this paragraph for more details, if desired. The SCSI family of attachment interfaces is not hardware-compatible with the ATA family, nor do they use the same software command set, so you cannot mix SCSI drives with ATA controllers or ATA drives with SCSI controllers. Because they use different commands, Linux will enumerate them with different labels. This will be handled in more detail when it becomes important later.

[edit] A Brief History

To get an understanding of modern hard drives, it helps to have some background. The BIOS traditionally uses INT13h as an interface to the hard drive. INT13h, from a historical stand-point, had certain limitations such as: hard drive size, limit, etc. Now on the other side of the interface that being the drive which used the IDE/ATA also had restrictions. We can see these restrictions easily if we lay out a table as below.

Specification Max Cylinders Max heads Max sectors Max Size
IDE/ATA 65,536 16 256 138GB
INT13h 1,024 256 63 528MB







Clearly you can see that because of the limitations of INT13h and IDE/ATA (which we have highlighted) under the above scenario, the largest drive your average computer could handle was 528MB. We call this specification CHS (Cylinders Heads Sectors). You may recall that to calculate the total size of a hard drive use the following formula:

  • Cylinders * Heads * Sectors * 512 = Capacity


To get around this a new specification was implemented called ECHS (Extended Cylinders Heads Sectors) some times also referred to as "Large Mode". This introduced a translation layer between the BIOS and INT13h. The translation layer then allowed a computer to handle disk drives upto 8.4GB in size we can see this with a following modification to the table above which we have set out below and highlighted the relevant row.

Specification Max Cylinders Max heads Max sectors Max Size
IDE/ATA 65,536 16 256 138GB
ECHS 620 128 63 2.5GB
INT13h 1,024 256 63 8.4GB








To see how the translation works, lets take a 2.5GB hard drive with the following specs: Cylinders = 4960, Heads = 16, Sectors = 63. The translation program looks at the number of cylinders and makes a "Best fit" with the INT13h limitation of 1,024 cylinders. The translation program does this by division normally; It divides the number of cylinders by one of the following numbers: 2,4,6,8 and in some cases 16. In our case, 4960 / 8 = 620, which does not break the limitation of INT13h. Now the translation program multiplies the number of heads by 8, so 16 * 8 = 128. In this way, the translation program maintains the INT13h standard and provides a way in which the computer can see the whole disk. We can see this by calculating the disk space at both points previous translation and after.

  • Native 4660 * 16 * 63 * 512 = 2.5GB
  • Translation 620 * 128 * 63 * 512 = 2.5GB

The Table above needs a little more clarification. You will note that the Heads for the ECHS (Translation Layer) = 128, which is incompatible with the IDE/ATA Layer, which specifies a limit of 16. We get away with this, because the translation layer is only concerned wit