September 2006


heads=32 cylinders=827 partition=/dev/hda1 start=63 partition=/dev/hda2 start=153216 partition=/dev/hda3 start=219744 This example defines the geometry for the first disk drive, which normally has the BIOS address of hexadecimal 80. The sectors, heads, and cylinders of the disk are defined. In the example, the linear address for the start of each partition is also given. This is an extreme example of defining the disk drive for the system; I have never had to do this. The append command is another LILO option related to defining hardware. (I have used this one.) The append option passes a configuration parameter to the kernel. The parameter is a kernel-specific option used to identify hardware that the system failed to automatically detect. For example: append = “ether=10,0×210,eth0″ This sample command tells the kernel the nonstandard configuration of an Ethernet card. This particular option line says that the Ethernet device eth0 uses IRQ 10 and I/O port address 210. (The format of the parameters that can be passed to the kernel is covered in “The Linux Boot Prompt,” later in this chapter.) Linux is very good at detecting the configuration of Ethernet hardware, and software-configurable cards are good at reporting their settings. Additionally, new PCI cards do not require all of these configuration values. By and large, kernel parameters are not needed to boot the system. However, this capability exists for those times when you do need it. LILO Boot Security Two LILO configuration commands enhance the security of a network server. If the server is in an unsecured area, it is possible for an intruder to reboot the system and gain unauthorized access. For example, an intruder could reboot the server into single-user mode and essentially have password-free root access to part of the system. (More about single-user mode later. For now, just take my word that this can be done.) To prevent this, add the password and the restricted options to the lilo.conf file. The password option defines a password that must be entered to reboot the system. The password is stored in the configuration file in an unencrypted format, so make sure the lilo.conf file can be read only by the root user. The restricted option softens the security a little. It says that the password is required only when passing parameters to the system during a boot. For example, if you attempt to pass the parameter single to the system to get it to boot into single-user mode, you must provide the password. Always add the restrict option when using the password option in a server’s lilo.conf file. Using password without restrict can cause the server to hang during the boot until the password is entered. If the server console is unattended, the boot can hang for an extended period of time. Using restrict with the password option ensures that the system reboots quickly after a crash, while providing adequate protection from unauthorized access through the console. 20
Note: If you are looking for cheap and inexpensive provider to host and run your tomcat application check Actions tomcat hosting services

This protects the root filesystem during the boot and ensures that the filesystem check (fsck) runs reliably. Later in the startup process, the root will be re-mounted as read/write after fsck completes. See the discussion of rc.sysinit later in this chapter. The root=/dev/hda3 option is also kernel-specific. It defines the location of the root filesystem for the kernel. The lilo.conf file should have a root option associated with the kernel image. If it is not defined here, the root filesystem must be defined separately with the rdev command. However, don’t do that; define the root in the LILO configuration. The last three lines in the sample file define the other operating system that LILO is able to boot. The other OS is located in partition 1 of the first IDE drive, other=/dev/hda1. As the label=dos entry indicates, it is Microsoft Windows. The optional command tells /sbin/lilo, which is called the mapper, that when it builds the map file, it should consider this operating system optional. That means that /sbin/lilo should complete building the map file, even if this operating system is not found. Whenever you modify the LILO configuration, invoke /sbin/lilo to install the new configuration. Until /sbin/lilo is run and maps the new configuration options, they have no effect. The grub.conf file, on the other hand, does not require any special processing. Changes to the GRUB configuration take effect immediately. Only Linux and one other operating system appear in the sample file, which is the most common case for desktop clients. However, LILO can act as the boot manager for up to 16 different operating systems. It is possible to see several other and image options in a lilo.conf file. Multiple image options are used when testing different Linux kernels. The most common reason for multiple other options is a training system in which users boot different OSs to learn about them. In an average operational environment, only one operating system is installed on a server, and no more than two operating systems are installed on a client. lilo.conf Hardware Options There are many more lilo.conf configuration options than those described previously, but you won’t need to use most of them. The sample configuration file in Listing 1.2 is almost identical to the one built by the installation program on any other system. Basically, the small subset of options just described includes the options used to build 99 percent of all LILO configuration files. The one percent of systems that cannot be configured with the usual commands are often those systems with hardware difficulties. The lilo.conf file provides several options for dealing with hardware problems. The lba32 option is used when the boot partition is placed above the 1024-cylinder limit. This option requires a BIOS that supports 32-bit Logical Block Addresses (LBA32) for booting. The Red Hat installation program displays a “Force use of LBA32″ check box in the boot loader installation screen. If this is available in your BIOS, it is the simplest way to boot from beyond the 1024-cylinder barrier. The linear option forces the system to use linear sector addresses sequential sector numbers instead of traditional cylinder, head, and sector addresses. This is sometimes necessary to handle large SCSI disks. It is even possible to manually define the disk geometry and linear addresses of the partitions directly in the LILO configuration file. For example: disk=/dev/hda bios=0×80 sectors=63 19
Note: If you are looking for cheap and inexpensive provider to host and run your tomcat application check Actions tomcat hosting services

loader. Comments in the lilo.conf file start with a sharp sign (#). The first active line of the global section in the sample file identifies the device that contains the boot sector. The option boot=/dev/hda3 says that LILO is stored in the boot sector of the third partition of the first IDE disk drive. This tells us two things: where LILO is installed and where it isn’t installed. LILO is not installed in the MBR of this system; it is installed in hda3, which must be the active partition. The configuration option map=/boot/map defines the location of the map file, which contains the physical locations of the operating system kernels in a form that can be read by the LILO boot loader. (GRUB does not require a map file because it can read Linux filesystems directly.) /boot/ map is the default value for the map option, so, in this case, it does not really need to be explicitly defined in the sample configuration file. The install=/boot/boot.b line defines the file that /sbin/lilo installs in the boot sector. (boot.b is the LILO boot loader.) In this case, the line is not actually required because /boot/boot.b is the default value for install. The prompt option causes the boot prompt to be displayed. If the prompt option is not included in the lilo.conf file, the user must press a Shift, Ctrl, or Alt key; or set the Caps Lock or Scroll Lock key to get the boot prompt. The message displayed at the boot prompt is contained in the file identified by the message option. In the example, message points to a file named /boot/ message that contains a full-screen display. If the message option is not used, the default boot prompt boot: is used. The timeout entry defines how long the system should wait for user input before booting the default operating system. The time is defined in tenths of seconds. Therefore, timeout=50 tells the system to wait five seconds. Warning Don’t use prompt without timeout. If the timeout option is not specified with the prompt option, the system will not automatically reboot. It will hang at the boot prompt, waiting for user input, and will never time out. This could be a big problem for an unattended server. If the timeout is reached, the default kernel is booted. The default option identifies the default kernel. In Listing 1.2, the operating system that has the label “linux”is the one that will be started by default. To boot Microsoft Windows as the default operating system, simply change the default option to default=dos. The remainder of this configuration file provides the information that LILO needs to find and boot either Linux or Windows. The image statement specifies the location of the Linux kernel, which is /boot/vmlinuz-2.4.7-10 in this example. The image option allows you to put the Linux kernel anywhere and name it anything. The ability to change the name of the kernel comes in very handy when you want to do a kernel upgrade, which is discussed in Chapter 13, “Troubleshooting.” There are several “per-image” options used in the configuration file, some of which are specific to kernel images. The label=linux option defines the label that is entered at the boot prompt to load this image. Every image defined in the sample file has an associated label entry; if the operator wants to boot an image, they must enter its label. The next option, read-only, is also kernel-specific. It applies to the root filesystem described previously. The read-only option tells LILO that the root filesystem should be mounted read-only. 18
Note: If you are looking for best quality webspace to host and run your tomcat application check Vision tomcat hosting services

with Linux or even the most popular Linux boot loader. Red Hat, prior to 7.2, used LILO, and most other versions of Linux still do. The next section takes a close look at LILO configuration. Loading the Kernel with LILO Although GRUB is a newer tool, LILO, the Linux loader, is still a versatile tool that can manage multiple boot images; and can be installed on a floppy disk, in a hard disk partition, or as the master boot record. As with GRUB, this power and flexibility comes at the price of complexity, which is illustrated by the large number of LILO configuration options. LILO Configuration Options Most of the time, you don’t need to think about the complexity of LILO; the installation program will lead you through a simple LILO installation. It is for those times when the default installation doesn’t provide the service you want that you need to understand the intricacies of LILO. LILO is configured by the /etc/lilo.conf file. Listing 1.2 is the lilo.conf file created by a Linux installation program on a desktop client that is configured to dual-boot. Its function is very similar to the GRUB sample shown in Listing 1.1. Listing 1.2: A Sample lilo.conf File # global section boot=/dev/hda3 map=/boot/map install=/boot/boot.b prompt timeout=50 message=/boot/message default=linux # The Linux boot image image=/boot/vmlinuz-2.4.7-10 label=linux read-only root=/dev/hda3 # additional boot image other=/dev/hda1 optional label=dos With this configuration, the user has five seconds to select either dos to boot Microsoft Windows or linux to boot Linux. If the user does not make a selection, LILO boots Linux after the five seconds have expired. The following section examines each line in this file to see how LILO is configured. A Sample lilo.conf File A lilo.conf file starts with a global section that contains options that apply to the entire LILO process. Some of these entries relate to the installation of LILO by /sbin/lilo, and are only indirectly related to the boot process. Note The program /sbin/lilo is not the boot loader. The LILO boot loader is a simple loader stored in a boot sector. /sbin/lilo is the program that installs and updates the LILO boot 17
Note: If you are looking for best quality webspace to host and run your tomcat application check Vision tomcat hosting services

kernel /boot/vmlinuz-2.4.7-10 ro root=/dev/hda3 initrd /boot/initrd-2.4.7-10.img title DOS rootnoverify (hd0,0) chainloader +1 The first title command defines the menu text Red Hat Linux (2.4.7 10). The next three lines define the operating system that is booted when that item is selected from the GRUB menu: root (hd0,2) Defines the physical location of the filesystem root for this operating system. The values defined for the root command are the disk device name and the partition number. Notice that GRUB device names are slightly different from normal Linux device names. GRUB calls the first hard disk hd0. Additionally, GRUB counts partitions differently than Linux does. GRUB counts from 0, whereas Linux counts from 1. Thus, the GRUB value hd0,2 on a Linux system that boots from an IDE drive is the same as the Linux value hda,3 partition number 3 on the first IDE drive. kernel /boot/vmlinuz-2.4.7-10 ro root=/dev/hda3 Identifies the file that contains the operating system that is to be started, and defines any arguments passed to that operating system at run time. In this case, GRUB will load the Linux kernel stored in vmlinuz-2.4.7-10, and it will pass the Linux kernel the arguments ro root=/dev/hda3, which tell the kernel where the filesystem root is located, and that it should be mounted as read-only. The ro option causes Linux to mount the root read-only during the initial phase of the boot. (Later, the rc.sysinit script changes it to read-write after successfully completing the filesystem checks.) initrd /boot/initrd-2.4.7-10.img Identifies a ramdisk file for Linux to use during the boot. Red Hat uses the ramdisk to provide Linux with critical modules that the kernel might need to access the disk drives. The last title command defines the DOS menu entry. Two commands define the operating system loaded when DOS is selected from the menu: rootnoverify (hd0,0) Like the root command, defines the physical location of the filesystem root for this operating system. But rootnoverify tells GRUB that the filesystem found at this location does not comply with the multiboot standards, and thus cannot be validated. chainloader +1 Emulates the function of the DOS MBR by simply loading the specified sector and passing boot responsibilities to the loader found there. The value +1 is a blocklist value, which defines the sector address of the loader relative to the partition defined by the rootnoverify command. +1 means the first sector of the partition. Taken together, the rootnoverify command and the chainloader command from our sample mean that GRUB will pass control to the loader found in the first sector of the first partition on the first IDE drive when DOS is selected from the GRUB menu. In this example, that partition contains the DOS boot loader that will be responsible for loading DOS. The grub.conf file on your system will be very similar to the one in this example. The location of files may be different, and a server system’s configuration usually won’t define multiple operating systems, but the commands will be essentially the same. GRUB is used with several different flavors of UNIX. It is not, however, the only boot loader used 16
Note: If you are looking for best quality webspace to host and run your tomcat application check Vision tomcat hosting services

password –md5 $1$L CX $qgeIevUEDvvQAmrm4jCd31 title Red Hat Linux (2.4.7-10) root (hd0,2) kernel /boot/vmlinuz-2.4.7-10 ro root=/dev/hda3 initrd /boot/initrd-2.4.7-10.img title DOS rootnoverify (hd0,0) chainloader +1 The GRUB configuration is stored in grub.conf, which is a simple text file. Lines that begin with # are comments, and the Red Hat installation program inserts several comments at the beginning of the file. The first active command line in this configuration is default=0. This command identifies which operating system should be booted by default in a dual-boot configuration. The operating systems that are available to GRUB are defined at the end of the configuration. Each operating system is assigned a number, sequentially starting from 0. Thus, the first operating system defined is 0, the second is 1, the third is 2, and so on. This configuration defines two operating systems: Red Hat Linux and DOS. Red Hat Linux is listed first; therefore, it is operating system 0, and it is the operating system that will be booted by default. In this case, the command default=0 is not really required because default is set to 0 whenever the default command is not included in the configuration. However, including the command makes a clean, self-documenting configuration. The second active line, timeout=10, also relates to the default boot. The timeout command sets the number of seconds the operator has to interrupt the boot process before GRUB automatically loads the default operating system. In this example, the operator has 10 seconds to select the alternate operating system before Red Hat Linux is automatically booted. Even for systems that do not dual-boot, set a value for timeout because this allows the operator to interrupt the boot process if it is necessary to pass arguments to the kernel. Providing kernel input at the boot prompt is covered later in this chapter. The splashimage command points to a file that contains the background image displayed by GRUB. During the timeout period, GRUB displays a boot menu. The splashimage file is the background displayed behind that menu. During the initial installation of Red Hat Linux 7.2, you have an opportunity to enter a GRUB password. The password entered at that time is stored in the grub.conf file using the password command. The password “Wats?Watt?” was entered during the installation of our sample system. Note that the password is not stored as clear text. The password is encrypted, and the –md5 option on the password command line lets us know that the password is encrypted with the Message Digest 5 (MD5) algorithm. The operator must enter the correct password to gain access to the full range of GRUB features. The operator can boot any of the operating systems listed in the GRUB menu without entering the password; however, optional input, such as kernel parameters, cannot be entered without the correct password. If the password command is not included in the grub.conf file, a password is not required to access any GRUB features. The title command defines the exact text that will be displayed in the GRUB menu to identify an operating system. The commands that follow a title command and occur before the next title command describe an operating system to the boot loader. The sample configuration defines the following two operating systems: title Red Hat Linux (2.4.7-10) root (hd0,2) 15
Note: If you are looking for cheap and reliable provider to host and run your servlet application check Vision servlet hosting services

Install the Linux boot loader in the MBR of the first disk, and install the Linux boot partition in the first 1024 cylinders of the second disk. Use LOADLIN, SYSLINUX, System Commander, or a similar product to boot Linux from DOS instead of booting the system directly to Linux. Make a complete backup of Microsoft Windows, and repartition the disk so that both Windows and Linux are in the first 1024 cylinders. This, of course, requires a complete reinstallation of Windows. Create a Linux boot directory within the Windows directory structure that contains the Linux kernel and all of the files from the /boot directory. Upgrade the BIOS. This is not as difficult as it may sound. Most systems allow the BIOS to be upgraded, and many motherboard manufacturers and BIOS manufacturers have BIOS upgrades on their websites. However, don’t undertake this lightly! A problem during the upgrade can leave the system unusable, and send you scurrying to the computer store to buy a replacement BIOS chip. Make a boot floppy or CD-ROM, and use that to start Linux. This is frequently the easiest option. Don’t be overly concerned about this potential problem. It is not a concern for servers, and even on clients it is rare. I have installed many Linux systems and have only had this problem once. In that case, it was a very old system that could directly address only 504MB per disk drive. My solution was to give the user a 250MB drive from my junk drawer as a second disk. (I never throw anything away.) I installed LILO in the MBR of his first disk and Linux on the second disk. The user was happy, Linux was installed, and I had less junk in my drawer. Even though there are several options for loading Linux, only a few are widely used. Most systems use the Linux loader LILO. The Red Hat Linux 7.2 system defaults to using GRUB. This chapter covers both of these commonly used loaders. We start with a close look at the default GRUB configuration generated by the Red Hat installation program. Loading Linux with GRUB During the installation of Red Hat Linux 7.2, you’re asked to select which boot loader should be used. By default, Red Hat uses the Grand Unified Bootloader (GRUB), and creates a GRUB configuration based on the values you select during the installation. Listing 1.1 shows the GRUB configuration generated by the Red Hat installation program for a desktop client. A dual-boot client configuration is used as an example because it is slightly more complex than a server configuration (servers do not usually dual-boot). Listing 1.1: The Default GRUB Configuration [root]# cat /etc/grub.conf # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You do not have a /boot partition. This means that # all kernel and initrd paths are relative to /, eg. # root (hd0,2) # kernel /boot/vmlinuz-version ro root=/dev/hda3 # initrd /boot/initrd-version.img #boot=/dev/hda default=0 timeout=10 splashimage=(hd0,2)/boot/grub/splash.xpm.gz 14
Note: If you are looking for cheap and reliable provider to host and run your servlet application check Vision servlet hosting services

Floppy disks have only one boot sector, but hard disks may have more than one because each partition on a hard drive has its own boot sector. The first boot sector on the entire hard disk is called the master boot record (MBR). It is the only boot sector loaded from the hard drive by the ROM BIOS. The MBR contains a small loader program and a partition table. If the standard DOS MBR is used, it loads the boot sector from the active partition and then passes control to the boot sector. Thus, both the MBR and the active partition’s boot sector are involved in the boot process. Figure 1.1 shows how the boot process flows from the BIOS to the MBR and then to the partition’s boot sector. This figure assumes a DOS MBR and a Linux loader in the boot sector of the active partition. Alternatively, the Linux loader can be installed in the MBR to eliminate one step in the boot process. Figure 1.1: The boot process flow Note Appendix A, “Installing Linux,” discusses the pros and cons of placing the Linux loader in the MBR. The BIOS may introduce some limitations into the Linux boot process. The Linux kernel can be installed anywhere on any of the disks available to the system, but if it is outside of those limits, the system might not be able to boot. The Linux loader depends on BIOS services. Some versions of BIOS only permit the loader to access the first two IDE hard drives: /dev/hda and /dev/ hdb. Additionally, in some cases, only the first 1024 cylinders of these disks can be used when booting the system. These limitations are at their worst on old systems. New systems have two IDE disk controllers that provide access to four disk drives, and these controllers address up to 8GB of disk storage within the 1024-cylinder limit. A very old system might address only 504MB in 1024 cylinders! For a server installation, this is not a real problem. Because servers do not dual-boot, everything can be removed from the disk, and the Linux boot files can be installed in the first partition without difficulty. A desktop client is a different matter. Most desktops have Microsoft Windows installed in the first partition. If there is available space within the first 1024 cylinders on the first disk drive, use fips to create empty space and install the Linux boot partition there. (Partitioning is discussed in detail in Appendix A.) Otherwise, a client system that dual-boots is forced to use one of the following methods: 13
Note: If you are looking for cheap and reliable provider to host and run your servlet application check Vision servlet hosting services

Part I: The Basics Chapter List Chapter 1: The Boot Process Chapter 2: The Network Interface Part Overview Featuring: The role that the ROM BIOS, MBR, and loader play in booting the system GRUB and LILO configuration How and why the kernel is passed parameters at boot time System runlevels and how they are configured by the inittab file The chkconfig and tksysv tools that control the startup scripts Loadable kernel modules and the tools that manage them How Ethernet device drivers are loaded and configured Configuring a network interface with ifconfig and the Red Hat Network Configuration tool How serial ports function and how they are used for networking PPP configuration and security Creating chat scripts 11
Note: If you are looking for cheap and quality provider to host and run your java application check Astra java hosting services

Chapter 1: The Boot Process Overview This chapter looks at what happens during a Linux boot. It examines the processes that take place and the configuration files that are read. Booting is a critical part of the operation of a server. The boot process brings all of the network hardware online and starts all of the network daemon processes when the system is powered-up. If the server will not boot, it is unavailable to all of the users and computers that depend on it. For this reason, it is essential that the administrator of a network server understand the boot process and the configuration files involved in that process. After all, you’re the person who maintains those configuration files and who is responsible for recovering the system when it won’t boot. The term boot comes from bootstrap loader, which in turn comes from the old saying “pull yourself up by your bootstraps.” The meaning of this expression is that you must accomplish everything on your own without any outside help. This is an apt term for a system that must start from nothing and finish running a full operating system. When the boot process starts, there is nothing in RAM no program to load the system. The loader that begins the process resides in non-volatile memory. On PC systems, this means that the loader is part of the ROM BIOS. Booting a Linux PC is a multistep procedure. It involves basic PC functions as well as Linux processes. This complex process begins in the PC ROM BIOS; it starts with the ROM BIOS program that loads the boot sector from the boot device. The boot sector either contains or loads a Linux boot loader, which then loads the Linux kernel. Finally, the kernel starts the init process, which loads all of the Linux services. The next few sections discuss this process in detail. Note Two Linux loaders, LILO and GRUB, are covered in this chapter. LILO is given the bulk of the coverage because it is the default for most Linux distributions. GRUB is covered because it is the default loader for Red Hat Linux 7.2. Loading the Boot Sector The ROM BIOS is configured through the BIOS setup program. Setup programs vary among different BIOS versions, but all of them allow the administrator to define which devices are used to boot the system and the order in which those devices are checked. On some PC systems, the floppy drive and the first hard drive are the boot devices, and they are checked in that order. Systems that permit booting from the CD-ROM usually list the CD-ROM as the first boot device, followed by the first hard drive. For an operational Linux server, set the ROM BIOS to check the floppy first and then the hard drive, even if you used a bootable CD-ROM for the initial installation. The reason for this is simple: The floppy is used to reboot an operational system when the hard drive is corrupted; the CD-ROM is only booted to install or upgrade the system software. During an installation, the system is offline, and you have plenty of time to fiddle with a BIOS setup program. But during an outage of an operational server, time is critical. You want to be able to reboot Linux and fix things as quickly as possible. The first 512 bytes of a disk contain a boot sector. The ROM BIOS loads the boot sector from the boot device into memory, and transfers control to it. The bootstrap program from the boot sector then loads the operating system. 12
Note: If you are looking for cheap and quality provider to host and run your java application check Astra java hosting services

« Previous PageNext Page »