Everything about DMESG....

1.About dmesg

Print or control the kernel ring buffer. The program helps users to print out their bootup messages. Instead of copying the messages by hand and mail the boot.messages file to whoever can debug their problem.

Syntax

dmesg [ -c ] [ -n level ] [ -s bufsize ]

-c Clear the ring buffer contents after printing.

-sbufsize Use a buffer of size bufsize to query the kernel ring buffer. This is 16392 by default. (The default kernel syslog buffer size was 4096 at first, 8192 since 1.3.54, 16384 since 2.1.113.) If you have set the kernel buffer to be larger than the default then this option can be used to view the entire buffer.

-nlevel Set the level at which logging of messages is done to the console. For example, -n 1 prevents all messages, expect panic messages, from appearing on the console. All levels of messages are still written to /proc/kmsg, so syslogd(8) can still be used to control exactly where kernel messages appear. When the -n option is used, dmesg will not print or clear the kernel ring buffer.

When both options are used, only the last option on the command line will have an effect.

Examples

dmesg

Display the kernel ring buffer to the screen.

dmesg > boot.messages

Send the kernel ring buffer to the boot.messages file, which could then be sent to another person.

2.dmesg (for "display message") is a command on Unix-like operating systems that prints the message buffer of the kernel.

dmesg (for "display message") is a command on Unix-like operating systems that prints the message buffer of the kernel.

When the computer system is initially booted the kernel is loaded into memory. At this stage each device driver present in the kernel probes the system for the existence of relevant hardware. If the hardware is located, a diagnostic message is produced documenting precisely what was found. Other elements within the kernel may also produce similar output reporting both the presence of that particular module, and the values of any parameters adopted. This process typically happens at a speed where individual messages scroll off the top of the screen before they can be read. The dmesg command allows these messages to be reviewed in a controlled manner after the system has started.

Even after the system has fully booted, the kernel may occasionally produce further diagnostic messages. Common examples of when this might happen are when I/O devices encounter errors, or USB devices are hot-plugged. dmesg provides a mechanism to review these messages at a later time. When first produced they will be directed to the system console: if the console is in use then these messages may be confused with or quickly overwritten by the output of user programs.

The output of dmesg can amount to several complete screens. For this reason, this output is normally reviewed using standard text-manipulation tools such as more, tail, or grep. The output is often captured in a permanent system logfile via a logging daemon, such as syslog.

Many commercial operating systems display an animated splash screen during this stage of the boot process, so the user does not see these messages. However, there is frequently a mechanism to disable the splash screen and view the messages. This is an important diagnostic capability if the system fails to boot. There is also usually a method of reviewing these messages subsequent to start up in a manner equivalent to dmesg.

3.

Abstract

Often someone will write to a Linux help list asking for help with a particular device they want to get working under Linux, and a standard reply is "check the output of the dmesg command". This leaves a lot of new users will be confused, and this document is here to hopefully help them navigate this powerful debugging tool. Two sets of kernel boot messages are presented and annotated, from an i386 system and a Linux-Pmac system.

Introduction

The Linux kernel is the central interface between the user and the hardware. As such, it has to incorporate support for hardware if you are to use it. Often, though, cryptic device names are used by the system, making it difficult at first inspection to determine if some particular hardware is supported. The command 'dmesg', which is used to print kernel messages, is very useful in determining if a piece of hardware has been found, and if so, what the system is referring to it as.

This artcle, including the title and format of the dmesg comments, were directly inspired and copied from the OpenBSD Explained article by the same name. I felt one on Linux would be useful for people.

The manpage for dmesg is quite simple:

DMESG(8) DMESG(8)

NAME

dmesg - print or control the kernel ring buffer

SYNOPSIS

dmesg [ -c ] [ -n level ] [ -s bufsize ]

DESCRIPTION

dmesg is used to examine or control the kernel ring

buffer.

Upon boot, the dmesg output is from the kernel booting, showing the devices it has found and if it has been able to configure them at all (aside from userland configuration). This log is also available in the file /var/log/dmesg.

Kernel output on an i386 system

Shown below is a dmesg from an x86 system immediately after boot. The output is indented by several space, and comments and descriptions are left justified.

Linux version 2.2.14-5.0 (root@porky.devel.redhat.com) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Tue Mar 7 20:53:41 EST 2000

First up is the kernel version (2.2.14) and build (5), along with who built it, with what compile it was built, and when it wass built. This can be some inportant information, as some kernel versions and the GCC project don't interact correctly.

Detected 300683434 Hz processor.

My K6/2-300 processor running at 300 MHz.

Console: colour VGA+ 80x25

A standard PC console screen (15 inch monitor).

Calibrating delay loop... 599.65 BogoMIPS

The useless benchmark of BogoMIPS. They're bogus (hence the name), but are often used as a relative processor speed indicator.

Memory: 63008k/65536k available (1084k kernel code, 412k reserved, 968k data, 64k init, 0k bigmem)

My memory statistics. My machine has 64MB of real memory.

Dentry hash table entries: 262144 (order 9, 2048k)

The dentry cache (dcache) represents the kernel's view of the namespace of mounted filesystems. There's pretty good documentation of it in Documentation/filesystems/vfs.txt in the kernel source tree.

Buffer cache hash table entries: 65536 (order 6, 256k)

In 2.2, the buffer cache is used for caching and aggregating data for writes to block devices. After 2.3.6, it is used for caching fs metadata, such as inode information.

Page cache hash table entries: 16384 (order 4, 64k)

In 2.2, the page (VM) cache is used for caching swap, read and mmap data (which was bad, because shared writable mappings were ugly). After 2.3.6, it also is used for write data (i.e., the buffer and page caches are mostly unified), and all became happiness and light (sorta like BSD).

VFS: Diskquotas version dquot_6.4.0 initialized

My kernel support quotas (though I'm not using them).

CPU: AMD AMD-K6(tm) 3D processor stepping 00

A quick identification of the processor.

Checking 386/387 coupling... OK, FPU using exception 16 error reporting.

Checking 'hlt' instruction... OK.

I seem to recall there being some Intel processor issues, which the kernel has to know about if it's to invoke corrections.

POSIX conformance testing by UNIFIX

PCI: PCI BIOS revision 2.10 entry at 0xfb490

And we start the probing of the PCI bus for peripherals.

PCI: Using configuration type 1

PCI: Probing PCI hardware

PCI: 00:38 [1106/0586]: Work around ISA DMA hangs (00)

Activating ISA DMA hang workarounds.

Linux NET4.0 for Linux 2.2

This kernel supports the Net4 networking codebase, which has a lot of features yet to be fully utilized.

Based upon Swansea University Computer Society NET3.039

NET4: Unix domain sockets 1.0 for Linux NET4.0.

NET4: Linux TCP/IP 1.0 for NET4.0

IP Protocols: ICMP, UDP, TCP, IGMP

My core IP protocols supported. While not needed, IGMP can be fun. Note that some networks do not support muticasting.

TCP: Hash tables configured (ehash 65536 bhash 65536)

Initializing RT netlink socket

Starting kswapd v 1.5

Detected PS/2 Mouse Port.

Should be quite obvious...

Serial driver version 4.27 with MANY_PORTS MULTIPORT SHARE_IRQ enabled

ttyS00 at 0x03f8 (irq = 4) is a 16550A

ttyS01 at 0x02f8 (irq = 3) is a 16550A

The information about my serial ports.

pty: 256 Unix98 ptys configured

apm: BIOS version 1.2 Flags 0x07 (Driver version 1.9)

My motherboard supports the APM standard for sleeping.

Real Time Clock Driver v1.09

RAM disk driver initialized: 16 RAM disks of 4096K size

My kernel supports RAM disks. While I'm not using any most days, sometimes I do use them; if you have the memory, they make a real fast filesystem (like /tmp or, for a webserver, the main pages loaded).

VP_IDE: IDE controller on PCI bus 00 dev 39

VP_IDE: not 100% native mode: will probe irqs later

ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:DMA

ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA, hdd:DMA

My IDE controllers.

hda: Maxtor 51369U3, ATA DISK drive

My hard drive in the machine.

hdb: IDE/ATAPI CD-ROM 32X, ATAPI CDROM drive

My CDROM drive.

ide0 at 0x1f0-0x1f7,0x3f6 on irq 14

hda: Maxtor 51369U3, 12949MB w/2048kB Cache, CHS=6577/64/63

hdb: ATAPI 16X CD-ROM drive, 128kB Cache

Disk information.

Uniform CDROM driver Revision: 2.56

Floppy drive(s): fd0 is 1.44M

FDC 0 is a post-1991 82077

Floppy drive information.

md driver 0.90.0 MAX_MD_DEVS=256, MAX_REAL=12

raid5: measuring checksumming speed

raid5: MMX detected, trying high-speed MMX checksum routines

pII_mmx : 761.238 MB/sec

p5_mmx : 726.567 MB/sec

8regs : 447.675 MB/sec

32regs : 308.610 MB/sec

using fastest function: pII_mmx (761.238 MB/sec)

A bunch of RAID and MD (used in multiple device devices, like disk arrays) information, again not used.

scsi : 0 hosts.

scsi : detected total.

While the kernel supports SCSI, I'm not using any on this host.

md.c: sizeof(mdp_super_t) = 4096

Partition check:

hda: hda1 hda2 < hda5 hda6 >

My disk partition information. The brackets indicate extended partitions.

autodetecting RAID arrays

autorun ...

... autorun DONE.

Like I said above, I'm using not using any RAID arrays.

VFS: Mounted root (ext2 filesystem) readonly.

At this point we're almost done with the kernel and ready to start the system.

Freeing unused kernel memory: 64k freed

Adding Swap: 66488k swap-space (priority -1)

ne2k-pci.c:vpre-1.00e 5/27/99 D. Becker/P. Gortmaker http://cesdis.gsfc.nasa.gov/linux/drivers/ne2k-pci.html

ne2k-pci.c: PCI NE2000 clone 'RealTek RTL-8029' at I/O 0xe800, IRQ 11.

eth0: RealTek RTL-8029 found at 0xe800, IRQ 11, 00:80:AD:41:22:10.

My ethernet device is a PCI NE2000 based device. (A real cheap NIC, but almost every OS supports it.)

VFS: Disk change detected on device fd(2,0)

At this point, the kernel is done booting and we're ready to start /sbin/init (unless we supplied some information about init upon boot). The system then starts rc.sysinit and begins normal boot operations. The kernel has finished booting.

Kernel output on a Linux-Pmac system

And, for comparison's sake, this is the output of Linux 2.2 on a PowerPC system. Again, the dmesg output is indented and the description and comments are left justified. For this system I was using BootX, which loads the kernel into memory from within the MacOS, then completes bootstrapping it after ditching the MacOS. Options can be passed to the kernel, as you would with LILO on an Intel based PC, from within the app.

device tree used 17860 bytes

PowerPC systems use what is known as OpenFirmware, rather than a PC like BIOS, and it has a 'device tree', which is arranged a bit like a UNIX filesystem. This one uses about 16kb.

Total memory = 72MB; using 512kB for hash table (at c0280000)

Again, total physical RAM available.

Linux version 2.2.6-15apmac (root@video.linuxppc.org) (gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)) #1 Mon May 31 03:54:09 EDT 1999

Kernel version (2.2.6 build 15 on a Pmac), who built it (root@video.linuxppc.org), what version of gcc (or egcs), and when it was built. This can be diagnostic as some versions of the Linux kernel don't play well with some versions of GCC.

PCI bus 0 controlled by bandit at f2000000

PCI bus 1 controlled by chaos at f0000000

Two PCI busses. OpenFirmware (OF) calls their controllers bandit and chaos.

System has 32 possible interrupts

via_calibrate_decr: decrementer_count = 100001 (600010 ticks)

Console: colour dummy device 80x25

Calibrating delay loop... 239.21 BogoMIPS

Ahh... sweet BogoMIPS, which mean pretty much nothing.

Memory: 69900k available (1532k kernel code, 2184k data, 112k init) [c0000000,c4800000]

After the initial bootstrap, about 68 MB of memory is left, having reserved some for the kernel and core system.

VFS: Diskquotas version dquot_6.4.0 initialized

POSIX conformance testing by UNIFIX

PCI: Probing PCI hardware

Let the PCI probing begin!

USB: Universal USB Driver v$Revision: 1.2 $

USB-OHCI: USB Open Host Controller Interface Driver

USB-HUBD: UUSBD Hub Driver v$Revision: 1.2 $

USB-HIDD: USB Human Interface Devices Driver v$Revision: 1.2 $

USB-HIDBP: USB HID Boot Protocol Driver v$Revision: 1.2 $

USB support is in the kernel, though I have no USB devices on the system.

adb devices: [2]: 2 2 [3]: 3 1

ADB, or Apple Desktop Bus, has two devices, the keyboard and the mouse. We'll see them detected below.

Linux NET4.0 for Linux 2.2

Based upon Swansea University Computer Society NET3.039

NET4: Unix domain sockets 1.0 for Linux NET4.0.

NET4: Linux TCP/IP 1.0 for NET4.0

IP Protocols: ICMP, UDP, TCP, IGMP

Core networking protocols (NET4) built into the kernel. The IGMP comes from multicast support (see Stevens for more info).

Starting kswapd v 1.5

MacOS display is /bandit/IMS,tt128mb8

Recall that bandit is the PCI controller (bus0). I use an IMS Twin Turbo 8 MB video chipset.

Console: switching to colour frame buffer device 80x30

fb0: IMS TT (TVP) frame buffer; 8MB vram; chip version 2

Monitor sense value = 0x73f, using video mode 6 and color mode 0.

fb1: control display adapter

Some video settings. On PowerMac hardware, sometimes this can be important if you've loaded a kernel level video driver, which can cause havoc on some systems. This is useful stuff to check on a PPC that has some video problems (ie in X).

ADB mouse at 3, handler set to 4

ADB keyboard at 2, handler set to 5

PowerMac Z8530 serial driver version 1.01

tty00 at 0xc900e020 (irq = 15) is a Z8530 ESCC, port = modem

tty01 at 0xc9011000 (irq = 16) is a Z8530 ESCC, port = printer

It found the ADB devices and also the two serial ports. It's useful to know which ones are which. Recall that Macintosh machines have one labeled modem and one labeled printer, so this is useful info to know.

pty: 256 Unix98 ptys configured

Macintosh ADB mouse driver installed.

DMA sound driver installed, using 4 buffers of 32k.

RAM disk driver initialized: 16 RAM disks of 4096K size

loop: registered device at major 7

fd0: SWIM3 floppy controller

fd0, or the floppy drive 0, on PowerMacs uses a controller called 'SWIM3'. Unfortunately, in this instance of the kernel, it's broken.

md driver 0.90.0 MAX_MD_DEVS=256, MAX_REAL=12

USB-HUBM: Starting kusbdd (pid 2)

USBD: No USB hosts found

linear personality registered

raid0 personality registered

raid1 personality registered

raid5: measuring checksumming speed

If I had RAID controllers, this would be neat. As such, it's just sucking up space in my kernel.

8regs : 140.970 MB/sec

32regs : 122.301 MB/sec

using fastest function: 8regs (140.970 MB/sec)

scsi0 : MESH

scsi1 : 53C94

scsi : 2 hosts.

I have two SCSI controllers, both onboard, with one being internal (the MESH one) and one being external (the 53C94 controller).

mesh: target 0 synchronous at 10.0 MB/s

Vendor: IBM Model: DPES-31080 Rev: S31S

Type: Direct-Access ANSI SCSI revision: 01 CCS

Detected scsi disk sda at scsi0, channel 0, id 0, lun 0

Vendor: QUANTUM Model: CTS80S Rev: 4.05

Type: Direct-Access ANSI SCSI revision: 02

Detected scsi disk sdb at scsi0, channel 0, id 1, lun 0

mesh: target 3 synchronous at 5.0 MB/s

Vendor: MATSHITA Model: CD-ROM CR-8005A Rev: 4.0i

Type: CD-ROM ANSI SCSI revision: 02

Detected scsi CD-ROM sr0 at scsi0, channel 0, id 3, lun 0

mesh: target 4 synchronous at 10.0 MB/s

Vendor: SEAGATE Model: ST31200N Rev: 8648

Type: Direct-Access ANSI SCSI revision: 02

Detected scsi disk sdc at scsi0, channel 0, id 4, lun 0

Vendor: QUANTUM Model: FIREBALL_TM2110S Rev: 300X

Type: Direct-Access ANSI SCSI revision: 02

Detected scsi disk sdd at scsi1, channel 0, id 2, lun 0

scsi : detected 1 SCSI cdrom 4 SCSI disks total.

Uniform CDROM driver Revision: 2.54

SCSI device sda: hdwr sector= 512 bytes. Sectors= 2118144 [1034 MB] [1.0 GB]

SCSI device sdb: hdwr sector= 512 bytes. Sectors= 166200 [81 MB] [0.1 GB]

SCSI device sdc: hdwr sector= 512 bytes. Sectors= 2061108 [1006 MB] [1.0 GB]

SCSI device sdd: hdwr sector= 512 bytes. Sectors= 4124736 [2014 MB] [2.0 GB]

Disk detection. I'm not a big fan of how Linux names its disks (in the order it finds them), but it found all of my devices.

PPP: version 2.3.3 (demand dialling)

TCP compression code copyright 1989 Regents of the University of California

PPP line discipline registered.

Kernel PPP support. Compressed TCP headers in PPP is a great feature, by the way, in keeping message overhead low.

eth0: MACE at 00:05:02:10:e6:6d, chip revision 9.64

Good old eth0, the ethernet device. It's MACE on a PowerMac. If this had been a modular driver, it wouldn't have shown up here but only after the module had been inserted.

Partition check:

sda: sda1 sda2 sda3 sda4 sda5 sda6

sdb: sdb1

sdc: sdc1 sdc2 sdc3 sdc4

sdd: sdd1 sdd2 sdd3 sdd4

The partition check is useful for knowing what the disks are laid out as.

md.c: sizeof(mdp_super_t) = 4104

autodetecting RAID arrays

autorun ...

... autorun DONE.

VFS: Mounted root (ext2 filesystem) readonly.

Freeing unused kernel memory: 112k init 32k prep

Adding Swap: 131428k swap-space (priority -1)

And we're done booting.

Concluding remarks

Like I noted above at the end of the i386 dmesg output, the kernel, once finished, then moves on to /sbin/init unless an argument poiting it elsewhere has been passed to the kernel at boot time. An example would be telling the kernel "init=/bin/sh", such that it would execute a shell upon boot, rather than /sbin/init (and what follows). Note that the kernel only mounts the root filesystem read-only, so if all you do is boot the kernel you have to mount your disks read-write in order to affect changes on them (ie editing /etc/passwd to rescue root's password).

While this isn't the most thorough of jobs, I hope that this little tour has been enjoyable for everyone, and educational.

Free Books..........on unix and linux

http://freecomputerbooks.com/unixLinuxBooks.html

System Logs

• There are three main reasons for logging system activities:

1. to monitor for security intrusions or attempts,
2. to tweak performance based on historical system use,
3. and to diagnose problems by checking the system state just before the problem occurred.

• Most Linux log files will be stored in /var/log. Certain programs may store logs elsewhere, but can typically be configured to use /var/log as well.
• The log files are all written with the same fields: date and time, host name, program name, and the message itself.
• Logs can also be stored on remote machines. This is useful for the following reasons: consolidates all of the logs into one place for easy monitoring, safeguard log entries from fatal disk failures on the local machine, and add an additional impediment to crackers who will typically want to change the log files to cover their tracks.
• For most programs, logging is managed by two daemons: klogd (kernel log daemon) and syslogd (system log daemon). These two daemons accept log messages from the kernel, and all other programs, respectively, and write them to the appropriate log file/device/remote machine, as directed by the /etc/syslog.conf configuration file.
• The kernel also logs boot-time messages. Because these messages are generated before the rc scripts have a chance to start either the klogd or syslogd daemons, the kernel writes these messages to the "kernel ring buffer". The kernel ring buffer is usally about 8K and size, and overwrites old messages as new ones are added. The dmesg command displays the contents of the kernel ring buffer. The Red Hat distribution also stores the contents of the kernel ring buffer as it exists immediately after system startup in the /var/log/dmesg file. This is so that an administrator can diagnose any boot-time problems even if the kernel ring buffer has long since overwritten all of those messages.
• The /etc/syslog.conf file has its own particular syntax. Each logging decision is phrased as "selector action" where the selector is made up of "facility.priority". The facility and priority codes are described in the syslog Facilities and Priorities handout. Multiple selectors can be placed on a single line, separated by semicolons. The action is either a device file name, a log file name, a remote machine designation, or the * character which means display the message on all user terminals.
• Either the facility code or the priority code can be replaced with a * which means match any facility or priority, respectively.
• The priority may also be "none" which means that no messages for the specified facility will be logged. This syntax is typically used to filter out certain facilities from an encompassing selector on the same line.
• When a priority is specified, it means that all priorities of that level and higher will be logged.
• A comma may be used to list multiple facilities for a single priority. This is just a notational shorthand.
• There are other ways to narrow down the exact priority level, but this won't be covered in the course.

syslog Facilities

A facility is a process category. The syslogd and klogd daemons may take different logging actions based on the facility of the process attempting to write a log entry.

Facility

Description

auth, security

User authentication messages.

auth-priv

Private user authentication messages.

cron

crond daemon messages.

daemon

Generic daemon messages.

kern

Kernel messages.

lpr

Printer daemon messages.

mail

Mail daemon messages.

news

News daemon messages.

syslog

System logging daemon messages.

user

User-process messages.

uucp

Unix-to-Unix-Copy networking messages.

localN

Special-purpose messages defined by certain applications or Linux distributions. N can be between 0 and 7.

syslog Priorities

Each log message is assigned a priority. The following table describes all of the defined priority, in order from lowest to highest (most important).

Priority

Description

debug

Debugging messages used by programmers during software development.

info

Informational messages written during normal program execution.

notice

Noteworthy information messages.

warning, warn

Warnings about potential problems.

err, error

Notices of errors.

crit

Notices of errors that are serious enough to abnormally terminate the program.

alert

Notices of errors that may cause other processes to terminate, in addition to the process logging the message.

emerg, panic

Notices of errors that could potentially crash the kernel.

System Startup and the Kernel

System Startup

* The Linux System Startup handout covers the sequence of startup steps in detail. The important parts to keep in mind are: the bootloader (LILO or GRUB), kernel messages (visible using dmesg), the init process and the rc scripts, and the roles of /etc/profile, .bash_profile, and .bashrc.

Bootloaders

* LILO (LInux LOader) is the most common bootloader and the one installed in the lab.

* The configuration file for LILO is /etc/lilo.conf.

* The bootloader's job is to select an operating system/kernel version to load.

* Typically the OS will be Linux but it is possible to use LILO to boot MS-DOS or Windows 9x on dual-boot machines.

* LILO can also boot different versions of kernels that are installed on the machine.

* LILO is responsible for the Red Hat logo screen that appears while the machine is starting up. It can be configured to allow the user to choose an operating system and/or kernel version. There is usually a default option as well if the user doesn't make a selection in a given period of time.

* LILO cannot be used to dual-boot OS/2, Windows NT/2000/XP. Those operating systems have to be installed in the MBR (Master Boot Record) and so conflict with LILO if it too is installed in the MBR.

* It is possible to use WinNT/2K/XP as the "master" bootloader which in turn can call LILO on a Linux partition, but this can be tricky to configure. See the articles: Linux + Windows 95 mini-HOWTO, and NT OS Loader + Linux mini-HOWTO in the Resources section of this site for more information.

* GRUB (GRand Unified Bootloader) is another bootloader. It's part of the GNU Project.

* GRUB is much more flexible than LILO, but in most respects does exactly the same thing as LILO.

The init Process

* The init process is the master process in Linux. It has Process ID 1 (PID). init is responsible for launching all other processes.

* init is configured through the /etc/inittab file.

* init's job during startup is the following: set the default runlevel, run the rc.sysinit script (usually in /etc/rc.d), run the rc script (usually in /etc/rc.d), install an interrupt handler to catch Ctrl+Alt+Del sequences, and launch the tty processes that handle each of the virtual terminals. Each of these tty processes in turn runs the login process that is responsible for accepting the user's login name and password, and then launching the user's shell and running the /etc/profile script for global settings.

Runlevels

* A runlevel is a "mode of operation that provides a particular set of services."

* Linux has 7 runlevels: 0 through 6.

* Runlevels 0, 1, and 6 are standardized across distributions, but the meanings of the other runlevels can vary considerably.

* Runlevel 0: halts the system

* Runlevel 1: single-user text mode. Usually used to diagnose and repair serious problems.

* Runlevel 2: multi-user text mode without networking (Red Hat). Rarely used.

* Runlevel 3: multi-user text mode with networking (Red Hat). The usual runlevel for servers that don't use the X Windows GUI.

* Runlevel 4: not used (Red Hat)

* Runlevel 5: multi-user X Windows mode with networking (Red Hat). The usual runlevel for graphical workstations (as in the lab).

* Runlevel 6: reboots the system

* The runlevel program (in /sbin) displays the current and previous runlevels.

The rc Script

* The rc script (usually in /etc/rc.d) is called by init to launch the services depending on the current runlevel (also set by init).

* Simply put, rc runs all of the scripts in one of the /etc/rc.d/rcN.d directories (N = runlevel) in alphabetical order.

* In each rcN.d directory, there will be a number of files beginning with "K" (Kill) and "S" (Start). Following the K or S, a two digit number is used to precisely order the files. These files are usually symbolic links to scripts in the /etc/rc.d/init.d directory. Links are used so that multiple copies of script files don't have to be copied amongst the various runlevel directories. Each of these scripts is responsible for starting or stopping (killing) a service: printer daemons, web servers, databases, email, firewalls, etc.

* rc first runs all of the Kill scripts in order. This can be thought of as a "clean-up" operation for runlevels other than 0 and 6. As expected, the scripts listed in the rc0.d and rc6.d directories are mostly Kill scripts since there is very little that needs to be started when the system is shutting down.

* rc then runs all of the Start scripts in order.

* For runlevels 2 through 5, the last Start script is usually /etc/rc.d/rc.local. The rc.local script is a handy place to put any of your own service initialization for which you don't have a full startup script like those in the /etc/rc.d/init.d directory.

* The green "OK" messages that appear during startup (or shutdown) are produced as the rc scripts iterates through the rcN.d directory.

The Shell rc Scripts

* The /etc/profile script contains global settings for all users (including root). This is the place to put any special settings that apply to everyone (e.g. "safe" versions of rm, mv, and cp).

* The .bash_profile script (in the user's home directory) contains any settings that only apply to that particular user. .bash_profile is only run once when the user first logs in. It usually calls the .bashrc script to do most of the work.

* The .bashrc script (in the user's home directory) also contains user-specific settings, but it is run for every new shell the user opens. This is usually the best place to put personal settings.

Kernel

/boot

* The kernel is typically located in the /boot directory.

* The compressed version of the kernel is called "vmlinuz" ("vm" = Virtual Machine, "z" = Compressed/Zipped). This is usually a symbolic link to the full name of the compressed kernel which may include the kernel version number.

* Many different kernel versions may be in /boot. The vmlinuz link will usually point to the most recent one, but LILO can still be used to select any particular kernel during startup.

Compiling the Kernel

* While not common, it is possible to compile the kernel itself from source.

* The main reason for doing so is to trim away any unnecessary code, thereby producing a lean 'n' mean kernel that consumes less memory. This may be necessary to run Linux on a machine with limited hardware (esp memory).

* The sorts of things that can be pruned out of the kernel include: device drivers, floating-point emulation, SMP (multi-CPU) support, loadable modules, networking, PCI support, parallel port support, Plug 'n' Play card support, ISDN, sound, SCSI, etc.

Kernel Modules

* While Linux is thought of as a "monolithic" kernel (meaning that it is one big program with all of the device drivers built-in), recent versions of the kernel support loadable modules.

* These modules, usually device drivers, can be manually or automatically loaded as needed, rather than having to re-compile the kernel each time a new piece of hardware is added to the machine.

* The modules themselves are stored in the /lib/modules/kernel_version directory.

* The /boot/module-info file contains short descriptions of the modules installed on the system.

* The kerneld (replaced by kmod in more recent distributions) daemon process can automatically load or remove modules as they are needed.

* The /etc/modules.conf file (this used to be called conf.modules) lists the modules that should be loaded by the system during startup.

* The lsmod command lists modules currently loaded in the kernel. Non-root users can run this command, but may have to run it as /sbin/lsmod since it won't be in the user's path.

Shell

Environent Variables

* Linux makes extensive use of environment variables for configuration or personalization settings.

* By convention, environment variable names are always fully capitalized.

* When referring to an environment variable, the variable is prefixed with "$".

The Path

* Linux has the concept of a "path" very much like in Windows/MS-DOS. The path is a set of directories that the shell searches though to locate a command you enter on the command line.

* The current path is stored in the $PATH environent variable. Directories are separated by colons (:).

* Unlike MS-DOS, Linux does not consider the current working directory part of the path unless the "." directory is explicitly included in $PATH.

* To run a program or script in the current directory, the program name must be prefixed with "./" to indicate to the shell that you mean to execute the program in this directory.

* The current directory (.) is not usually included in $PATH for security reasons.

Aliases

* Aliases are handy synonyms for commands, or specific versions of commands.

* The current aliases can be listed by running the alias command without any parameters.

* Aliases can be deleted using the unalias command.

Quotes

* Single quotes (') and double quotes (") have slightly different meanings to the shell.

* Use single quotes to specify literal strings (i.e. the shell won't evaluate anything within the string).

* Use double quotes if you want environment variables within the string to be evaluated.

Redirection

* Most Linux programs can be thought of as possessing one input and two outputs. The input is called Standard Input. The outputs are called Standard Output and Standard Error.

* By default, both Standard Output and Standard Error are sent to the terminal screen.

* By using the output redirection operators, the output can be diverted to files, or elsewhere.

* > redirects Standard Output

* 1> also redirects Standard Output

* 2> redirects Standard Error

* &> redirects both Standard Output and Standard Error

* The output of programs can be redirected to a file, or perhaps /dev/null which just throws out anything it's given.

* If redirecting to a file, the file will be overwritten using the above operators. Use >> to append to the file.

Tarballs

* Large groups of files are usually distributed in what is called a compressed tarball format.

* A "tarball" is a file created using the tar command (Tape ARchiver) which can group together many files into a single archive file.

* The tar command does not compress its contents.

* Tarballs are usually identified by the filename suffix ".tar".

* The gzip (and gunzip) programs are used to compress (and uncompress) individual files or tarballs.

* A gzip-ed tarball usually has the suffix ".tar.gz", or ".tgz" for short.

* Examine the commands in the handout, or the man pages, for more details.

Introduction to System Calls (I/O System Calls)

System Calls for I/O

The way that programs talk to the operating system is via ``system calls.'' -- it is a request to the operating system to perform some activity.

There are 5 basic system calls that Unix provides for file I/O.

       1.  int open(char *path, int flags [ , int mode ] );
       2.  int close(int fd);
       3.  int read(int fd, char *buf, int size);
       4.  int write(int fd, char *buf, int size);
       5.  off_t lseek(int fd, off_t offset, int whence);

Open makes a request to the operating system to use a file

Close() tells the operating system that you are done with a file descriptor

Read() tells the operating system to read "size" bytes from the file opened in file descriptor "fd", and to put those bytes into the location pointed to by "buf".

Write() is just like read(), only it writes the bytes instead of reading them. It returns the number of bytes actually written, which is almost invariably "size".

/*

I/O Operations: U may be thinking What the hell this I/O operation is rite?????

Following are the five services provided by an operating systems to the convenience of the users.

1. Program Execution



2. I/O Operations



3. File System Manipulation



4. Communications



5. Error Detection

yeah!!!!!11 U got it now I/O is one of the services provided by the OS.The operating systems by providing I/O makes it convenient for the users to run programs. Becoz as Each program requires an input The same way it produces output also,so without an an i/o service how will u see ur o/p.?

This giving the input and taking o/p from computers ivloves lot of jagularies inside which we are not aware as os is providing it as a service to us. The reason the operating system controls I/O is for safety -- the computer must ensure that if my program has a bug in it, then it doesn't crash the system, and it doesn't mess up other people's programs that may be running at the same time or later. Thus, whenever you do disk or screen or network I/O, you must go through the operating system and use system calls.For efficiently and protection users cannot control I/O so this service cannot be provided by user-level programs.

*/

Open

Open makes a request to the operating system to use a file. The 'path' argument specifies what file you would like to use, and the 'flags' and 'mode' arguments specify how you would like to use it. If the operating system approves your request, it will return a ``file descriptor'' to you. This is a non-negative integer. If it returns -1, then you have been denied access, and you have to check the value of the variable "errno" to determine why.

All actions that you will perform on files will be done through the operating system. Whenever you want to do file I/O, you specify the file by its file descriptor. Thus, whenever you want to do file I/O on a specific file, you must first open that file to get a file descriptor.

Close

Close() tells the operating system that you are done with a file descriptor. The OS can then reuse that file descriptor. The file c1.c (say)shows some examples with opening and closing the file in1. You should look at it carefully, as it opens the file multiple times without closing it, which is perfectly legal in Unix.

Linux kernel release 2.0.xx

 Linux kernel release 2.0.xx

These are the release notes for linux version 2.0.  Read them carefully,
as they tell you what this is all about, explain how to install the
kernel, and what to do if something goes wrong.

WHAT IS LINUX?

Linux is a Unix clone written from scratch by Linus Torvalds with
assistance from a loosely-knit team of hackers across the Net.
It aims towards POSIX compliance.

It has all the features you would expect in a modern fully-fledged
Unix, including true multitasking, virtual memory, shared libraries,
demand loading, shared copy-on-write executables, proper memory
management and TCP/IP networking.

It is distributed under the GNU General Public License - see the
accompanying COPYING file for more details.

ON WHAT HARDWARE DOES IT RUN?

Linux was first developed for 386/486-based PCs.  These days it also
runs on DEC Alphas, SUN Sparcs, M68000 machines (like Atari and Amiga),
MIPS and PowerPC.

DOCUMENTATION:

- there is a lot of documentation available both in electronic form on
 the internet and in books, both Linux-specific and pertaining to
 general UNIX questions.  I'd recommend looking into the documentation
 subdirectories on any Linux ftp site for the LDP (Linux Documentation
 Project) books.  This README is not meant to be documentation on the
 system: there are much better sources available.

- There are various readme's in the kernel Documentation/ subdirectory:
 these typically contain kernel-specific installation notes for some
 drivers for example. See ./Documentation/00-INDEX for a list of what
 is contained in each file.

INSTALLING the kernel:

- If you install the full sources, do a

 cd /usr/src
 gzip -cd linux-2.0.XX.tar.gz | tar xfv -

 to get it all put in place. Replace "XX" with the version number of the
 latest kernel.

- You can also upgrade between 2.0.xx releases by patching.  Each
 patch that is released for 2.0.xx contains only bugfixes.  No
 new features will be added to the Linux kernel until the 2.1.xx
 development effort begins.  To install by patching, get all the
 newer patch files and do

 cd /usr/src
 gzip -cd patchXX.gz | patch -p0

 (repeat xx for all versions bigger than the version of your current
 source tree, _in_order_) and you should be ok.  You may want to remove
 the backup files (xxx~ or xxx.orig), and make sure that there are no
 failed patches (xxx# or xxx.rej). If there are, either you or me has
 made a mistake.

 Alternatively, the script patch-kernel can be used to automate this
 process.  It determines the current kernel version and applies any
 patches found.

 cd /usr/src
 linux/scripts/patch-kernel

 The default directory for the kernel source is /usr/src/linux, but
 can be specified as the first argument.  Patches are applied from
 the current directory, but an alternative directory can be specified
 as the second argument.

- make sure your /usr/include/asm, /usr/include/linux, and /usr/include/scsi
 directories are just symlinks to the kernel sources:

 cd /usr/include
 rm -rf asm linux scsi
 ln -s /usr/src/linux/include/asm-i386 asm
 ln -s /usr/src/linux/include/linux linux
 ln -s /usr/src/linux/include/scsi scsi

- make sure you have no stale .o files and dependencies lying around:

 cd /usr/src/linux
 make mrproper

 You should now have the sources correctly installed.

CONFIGURING the kernel:

- do a "make config" to configure the basic kernel.  "make config"
 needs bash to work: it will search for bash in $BASH, /bin/bash and
 /bin/sh (in that order), so hopefully one of those is correct.

- Alternate configuration commands are:
"make menuconfig"  Text based color menus, radiolists & dialogs.
"make xconfig"     X windows based configuration tool.

NOTES on "make config":
- having unnecessary drivers will make the kernel bigger, and can
  under some circumstances lead to problems: probing for a
  nonexistent controller card may confuse your other controllers
- compiling the kernel with "Processor type" set higher than 386
  will result in a kernel that does NOT work on a 386.  The
  kernel will detect this on bootup, and give up.
- A kernel with math-emulation compiled in will still use the
  coprocessor if one is present: the math emulation will just
  never get used in that case.  The kernel will be slightly larger,
  but will work on different machines regardless of whether they
  have a math coprocessor or not.
- the "kernel hacking" configuration details usually result in a
  bigger or slower kernel (or both), and can even make the kernel
  less stable by configuring some routines to actively try to
  break bad code to find kernel problems (kmalloc()).  Thus you
  should probably answer 'n' to the questions for a "production"
  kernel.

- Check the top Makefile for further site-dependent configuration
 (default SVGA mode etc).

- Finally, do a "make dep" to set up all the dependencies correctly.

COMPILING the kernel:

- make sure you have gcc-2.6.3 or newer available.  It seems older gcc
 versions can have problems compiling newer versions of linux.  If you
 upgrade your compiler, remember to get the new binutils package too
 (for as/ld/nm and company).

- do a "make zImage" to create a compressed kernel image.  If you want
 to make a bootdisk (without root filesystem or lilo), insert a floppy
 in your A: drive, and do a "make zdisk".  It is also possible to do
 "make zlilo" if you have lilo installed to suit the kernel makefiles,
 but you may want to check your particular lilo setup first.

- if your kernel is too large for "make zImage", use "make bzImage"
 instead.

- if you configured any of the parts of the kernel as `modules', you
 will have to do "make modules" followed by "make modules_install".
 Read Documentation/modules.txt for more information.  For example,
 an explanation of how to use the modules is included there.

- keep a backup kernel handy in case something goes wrong.  This is
 especially true for the development releases, since each new release
 contains new code which has not been debugged.

- In order to boot your new kernel, you'll need to copy the kernel
 image (found in /usr/src/linux/arch/i386/boot/zImage after compilation)
 to the place where your regular bootable kernel is found.

 For some, this is on a floppy disk, in which case you can "cp
 /usr/src/linux/arch/i386/boot/zImage /dev/fd0" to make a bootable
 floppy.  Note that as of Linux 2.0.0, a kernel copied to a 720k
 double-density 3.5" floppy disk no longer boots.  In this case,
 it is highly recommended that you install LILO on your
 double-density bootfloppy or switch to high-density floppies.

 If you boot Linux from the hard drive, chances are you use LILO which
 uses the kernel image as specified in the file /etc/lilo.conf.  The
 kernel image file is usually /vmlinuz, or /zImage, or /etc/zImage.
 To use the new kernel, copy the new image over the old one (save a
 backup of the original!).  Then, you MUST RERUN LILO to update the
 loading map!! If you don't, you won't be able to boot the new kernel
 image.

 Reinstalling LILO is usually a matter of running /sbin/lilo.
 You may wish to edit /etc/lilo.conf to specify an entry for your
 old kernel image (say, /vmlinux.old) in case the new one does not
 work.  See the LILO docs for more information.

 After reinstalling LILO, you should be all set.  Shutdown the system,
 reboot, and enjoy!

 If you ever need to change the default root device, video mode,
 ramdisk size, etc.  in the kernel image, use the 'rdev' program (or
 alternatively the LILO boot options when appropriate).  No need to
 recompile the kernel to change these parameters.

- reboot with the new kernel and enjoy.

IF SOMETHING GOES WRONG:

- if you have problems that seem to be due to kernel bugs, please check
 the file MAINTAINERS to see if there is a particular person associated
 with the part of the kernel that you are having trouble with. If there
 isn't anyone listed there, then the second best thing is to mail
 them to me (Linus.Torvalds@Helsinki.FI), and possibly to any other
 relevant mailing-list or to the newsgroup.  The mailing-lists are
 useful especially for SCSI and NETworking problems, as I can't test
 either of those personally anyway.

- In all bug-reports, *please* tell what kernel you are talking about,
 how to duplicate the problem, and what your setup is (use your common
 sense).  If the problem is new, tell me so, and if the problem is
 old, please try to tell me when you first noticed it.

- if the bug results in a message like

unable to handle kernel paging request at address C0000010
Oops: 0002
EIP:   0010:XXXXXXXX
eax: xxxxxxxx   ebx: xxxxxxxx   ecx: xxxxxxxx   edx: xxxxxxxx
esi: xxxxxxxx   edi: xxxxxxxx   ebp: xxxxxxxx
ds: xxxx  es: xxxx  fs: xxxx  gs: xxxx
Pid: xx, process nr: xx
xx xx xx xx xx xx xx xx xx xx

 or similar kernel debugging information on your screen or in your
 system log, please duplicate it *exactly*.  The dump may look
 incomprehensible to you, but it does contain information that may
 help debugging the problem.  The text above the dump is also
 important: it tells something about why the kernel dumped code (in
 the above example it's due to a bad kernel pointer). More information
 on making sense of the dump is in Documentation/oops-tracing.txt

- You can use the "ksymoops" program to make sense of the dump.  Find
 the C++ sources under the scripts/ directory to avoid having to do
 the dump lookup by hand:

- in debugging dumps like the above, it helps enormously if you can
 look up what the EIP value means.  The hex value as such doesn't help
 me or anybody else very much: it will depend on your particular
 kernel setup.  What you should do is take the hex value from the EIP
 line (ignore the "0010:"), and look it up in the kernel namelist to
 see which kernel function contains the offending address.

 To find out the kernel function name, you'll need to find the system
 binary associated with the kernel that exhibited the symptom.  This is
 the file 'linux/vmlinux'.  To extract the namelist and match it against
 the EIP from the kernel crash, do:

 nm vmlinux | sort | less

 This will give you a list of kernel addresses sorted in ascending
 order, from which it is simple to find the function that contains the
 offending address.  Note that the address given by the kernel
 debugging messages will not necessarily match exactly with the
 function addresses (in fact, that is very unlikely), so you can't
 just 'grep' the list: the list will, however, give you the starting
 point of each kernel function, so by looking for the function that
 has a starting address lower than the one you are searching for but
 is followed by a function with a higher address you will find the one
 you want.  In fact, it may be a good idea to include a bit of
 "context" in your problem report, giving a few lines around the
 interesting one.

 If you for some reason cannot do the above (you have a pre-compiled
 kernel image or similar), telling me as much about your setup as
 possible will help.

- alternately, you can use gdb on a running kernel. (read-only; i.e. you
 cannot change values or set break points.) To do this, first compile the
 kernel with -g; edit arch/i386/Makefile appropriately, then do a "make
 clean". You'll also need to enable CONFIG_PROC_FS (via "make config").

 After you've rebooted with the new kernel, do "gdb vmlinux /proc/kcore".
 You can now use all the usual gdb commands. The command to look up the
 point where your system crashed is "l *0xXXXXXXXX". (Replace the XXXes
 with the EIP value.)

 gdb'ing a non-running kernel currently fails because gdb (wrongly)
 disregards the starting offset for which the kernel is compiled.

Source :

Installing RHEL

http://docs.sun.com/source/820-4893-13/rhel.html

Executing Remote Commands on Demand with SSH

Executing Remote Commands on Demand with SSH

[root@smallfry tmp]# ssh 192.168.1.100 "uname -a"
root@192.168.1.100's password:
Linux bigboy 2.6.8-1.521 #1 Mon Aug 16 09:01:18 EDT 2004 i686 i686 i386 GNU/Linux
[root@smallfry tmp]#

Mounting_NFS_File_Systems-Using_TCP

https://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/en-US/System_Administration_Guide_/Mounting_NFS_File_Systems-Using_TCP.html

Redhat system admin guide

https://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/en-US/System_Administration_Guide_/index.html

Using the ssh command(to execute a command on the remote machine)

Using the ssh Command

The ssh command is a secure replacement for the rlogin, rsh, and telnet commands. It allows you to log in to a remote machine as well as execute commands on a remote machine.

Logging in to a remote machine with ssh is similar to using telnet. To log in to a remote machine named penguin.example.net, type the following command at a shell prompt:

ssh penguin.example.net

The first time you ssh to a remote machine, you will see a message similar to the following:

The authenticity of host 'penguin.example.net' can't be established.
DSA key fingerprint is 94:68:3a:3a:bc:f3:9a:9b:01:5d:b3:07:38:e2:11:0c.
Are you sure you want to continue connecting (yes/no)?

Type yes to continue. This will add the server to your list of known hosts (~/.ssh/known_hosts/) as seen in the following message:

Warning: Permanently added 'penguin.example.net' (RSA) to the list of known hosts.

Next, you will see a prompt asking for your password for the remote machine. After entering your password, you will be at a shell prompt for the remote machine. If you do not specify a username the username that you are logged in as on the local client machine is passed to the remote machine. If you want to specify a different username, use the following command:

ssh username@penguin.example.net

You can also use the syntax ssh -l username penguin.example.net.

The ssh command can be used to execute a command on the remote machine without logging in to a shell prompt. The syntax is ssh hostname command. For example, if you want to execute the command ls /usr/share/doc on the remote machine penguin.example.net, type the following command at a shell prompt:

ssh penguin.example.net ls /usr/share/doc

After you enter the correct password, the contents of the remote directory /usr/share/doc will be displayed, and you will return to your local shell prompt.

Source:https://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/en-US/System_Administration_Guide_/Configuring_an_OpenSSH_Client-Using_the_ssh_Command.html

What is the difference between Swapping and Paging?

Swapping occurs when whole process is transferred to disk,while paging is when some part of process is transferred to disk while rest is still in physical memory. There are two utilities to onitor memory, called vmstat (for bsd, etc),sar( for system V, etc). Page-ins and page-outs are pages
moved in and out from physical memory to disk, swap-ins and swap-outs are processes moved in and out of disk.

Details about the RHCE new exam pattern.

Many of you might know that the RHCE exam pattern have changed, If any one is wondering watz the new pattern is like? Here are some of the details of the new pattern.

Recently from 1st May 2009 RHCE (Red Hat Certified Engineer) exam pattern has been changed. Some of the high lights are as follows. The examination time has been reduced to 3.5 hours from 5.5 hours as it was previously.

1. Previously, there will be two sessions one with 2.5hour (for basic troubleshooting) session and 3hours session (for server and security configurations).

2. But this time the content has be consolidated and reorganized into a single section.

3. Every thing will be installed and given along with Visualization, the candidate should complete that exam is one stretch that is 3.5hrs.

4. As you know RHCE5 SElinux is enabled so prepare along that lines.

5. Main thing to pass this exam is just practice practice practice.

Get counseling on how to pass RHCE, just fill this form for any quires don’t hesitate its totally free.

Study Points for the RHCE Exam

Prerequisite skills for RHCT and RHCE

Candidates should possess the following skills, as they may be necessary in order to fulfill requirements of the RHCT and RHCE exams:

• Use standard command line tools (e.g., ls, cp, mv, rm, tail, cat, etc.) to create, remove,

view, and investigate files and directories

• Use grep, sed, and awk to process text streams and files

• Use a terminal-based text editor, such as vim or nano, to modify text files

• Use input/output redirection

• Understand basic principles of TCP/IP networking, including IP addresses, netmasks,

and gateways for IPv4 and IPv6

• Use su to switch user accounts

• Use passwd to set passwords

• Use tar, gzip, and bzip2

• Configure an email client on Red Hat Enterprise Linux

• Use text and/or graphical browser to access HTTP/HTTPS URLs

• Use ftp to access FTP URLs

RHCT skills

Troubleshooting and System Maintenance

RHCT’s should be able to:

• Boot systems into different run levels for troubleshooting and system maintenance

• Diagnose and correct misconfigured networking

• Diagnose and correct hostname resolution problems

• Configure the X Window System and a desktop environment

• Add new partitions, file systems, and swap to existing systems

• Use standard command-line tools to analyze problems and configure system

Installation and Configuration

RHCT’s must be able to:

• Perform network OS installation

• Implement a custom partitioning scheme

• Configure printing

• Configure the scheduling of tasks using cron and at

• Attach system to a network directory service, such as NIS or LDAP

• Configure autofs

• Add and manage users, groups, quotas, and File Access Control Lists

• Configure filesystem permissions for collaboration

• Install and update packages using rpm

• Properly update the kernel package

• Configure the system to update/install packages from remote repositories using yum.

• Modify the system bootloader

• Implement software RAID at install-time and run-time

• Use /proc/sys and sysctl to modify and set kernel run-time parameters

• Use scripting to automate system maintenance tasks

• Configure NTP for time synchronization with a higher-stratum server

RHCE skills

Troubleshooting and System Maintenance

RHCE’s must demonstrate the RHCT skills listed above, and should be able to:

• Use the rescue environment provided by first installation CD

• Diagnose and correct boot failures arising from bootloader, module, and filesystem

errors

• Diagnose and correct problems with network services (see Installation and

Configuration below for a list of these services)

• Add, remove, and resize logical volumes

• Diagnose and correct networking services problems where SELinux contexts are interfering with proper operation.

Installation and Configuration

RHCE’s must demonstrate the RHCT-level skills listed above, and they must be capable of configuring the following network services:

• HTTP/HTTPS

• SMB

• NFS

• FTP

• Web proxy

• SMTP

• IMAP, IMAPS, and POP3

• SSH

• DNS (caching name server, slave name server)

• NTP

For each of these services, RHCEs must be able to:

• Install the packages needed to provide the service

• Configure SELinux to support the service

• Configure the service to start when the system is booted

• Configure the service for basic operation

• Configure host-based and user-based security for the service

RHCEs must also be able to:

• Configure hands-free installation using Kickstart

• Implement logical volumes at install-time

• Use iptables to implement packet filtering and/or NAT

• Use PAM to implement user-level restrictions

Source:http://www.redhat.com/certification/rhce/prep_guide/

Please comment on your experience of RHCE.