Learning Center
Plans & pricing Sign in
Sign Out

Linux Project for students

VIEWS: 613 PAGES: 60

									               Diskless Booting In Linux

                         A Project Report

Table of Contents
    Contents                                       Page Number

 ● Acknowledgment                                       4
  Company profile                                      5
  What is Linux                                        8
  What is diskless workstation                         9
       Introduction                                    9
       A diskless workstation                          10
       A Linux diskless workstation                    10
       Booting the diskless workstation                11
  How to install packages in Linux                     14
       How to Download Software                        16
       Getting Software Using Web-Based FTP            17
       Getting Software Using wget                     20
       Installing Software From RPM Files              21
       How To Install RPMs Manually                    21
       Using CD-ROMs                                   22
       How to Install Source RPMs                      23
  RPM Installation Errors                              24
       Failed Dependencies                             24
       How to List Installed RPMs                      26
       Listing Files for Already Installed RPMs        27
  Uninstalling RPMs                                    28
  Main Steps for Make Diskless Workstations            31
  NFS Introduction                                     32
       Installing NFS                                  36
       Configuring NFS on The Server                   37
       Starting NFS on the Server                      37
       Configuring NFS on The Client                   38
       Starting NFS on the Client                      38
       Making NFS Mounting Permanent                   40
  TFTP-server                                          41

         Installing The TFTP Server Software           41
         Configuring The TFTP Server                   41
   Introduction to DHCP                                43
         Linux as a DHCP Server                        44
         Download and Install the DHCP Package         46
         How to Get DHCP Started                       48
   Diskless Environments                               50
         Start the tftp Server                         51
         Configuring the DHCP Server                   52
         Configuring the NFS Server                    53
         Finish Configuring the Diskless Environment   54
         Adding Hosts                                  55
         Booting the Hosts                             56
   Diskless booting operation overview                 57
     Obtaining IP parameters                           58
     Loading the kernel                                58
     Mounting the root file system                     58
     Terminating the boot process                      58
     Building the kernel                               58
   Bibliography                                        61

                “Outstanding achievements are not possible in vacuums. It needs a lot of
help and assistance beside a healthy environment, luckily I have.”

                I express my deep sense of gratitude and indebtedness to this great
institution D.A.V. Institute OF ENGG. AND TECHNOLOGY, JALANDHAR that
provided me an opportunity to fulfill the most cherished desire of reaching my goal.

              I am highly indebted and express my gratitude to Mr. Sanjeev Bhalla the
training and placement officer for his encouragement, feedback, support and
suggestions. With the help of his blessings and guidance I stand here today.

            I am very grateful to Mr. Jagdeep Singh, Centre Head, Netmax
Technologies for giving me the opportunity to carry out my training in their esteemed

               I deem it a pleasant duty to place on record my sincere and heartfelt
gratitude to my training guide Mr. Navdeep Mangal for his long sightedness, wisdom
and co-operation which helped me in tackling crucial aspects of the training in very
logical and practical way.

               I then want to extend my word of thanks and admiration to all the
employees of Netmax Technologies who made me feel so comfortable in the whole
tenure of the training.

                                                          PARMINDER SINGH
                                                          Roll no: - L-42608003

                      COMPANY PROFILE

                     NAME OF THE ORGANISATION

                       SCO 198-200,SEC 43-A

                     ABOUT THE ORGANISATION

Advance Networking and Embedded Systems solutions

"Netmax technologies is an organisation which was established in 2001 in the field of
network training ,support and Embedded systems design solutions. Our mission is "To
provide world class solutions in advance networking, security, embedded systems design
and career services for information system professionals as well as electronic system

NETMAX TECHNOLOGIES provide network training and solutions for corporate
technologies like CISCO, LINUX, MICROSOFT,SUN, CHECKPOINT and other
We also offer the state of art solutions to many companies.
We have strategic alliance with RedHat Linux, SUSE LINUX ,
with which we provide RedHat Linux,NOVELL, SUSE LINUX
Solutions and Education. We alsoconduct online examinations for International
Certifications.NetMax Technologies is a leader in development of innovative embedded
solutions to meet the demands of Post PC era. NetMax Technologies Embedded
Electronics division provides design solutions, consultancy and commercial R&D
support to various companies. Areas of expertise include Analog electronics, Switching
supplies, Power electronics, Microcontrollers/Processors .

Redhat linux :-
Linux one of the fastest emerging Operating System in the world is predicted to grow at a
rate of 27% in next 3 yrs. This growth is expected to be almost 80% in India in next 3 -4
yrs. The industry is in need for professionals who are well qualified who can take a
different positions in this space. Linux is gaining wider requirement in different industry
segments, besides being a popular platform in ISP, Engineering, Institutes, Banking ,
Financial, Insurance sectors etc. it is slowly making its roads into Manufacturing,

Gaming, Multimedia & Telecommunication as well. So career is definitely there in Linux
Administration .The job requirement for Linux Administrator is increasing day by day.
So this is the right time to enter in the field of Linux Administration .At netmax we will
cover most popular flavour of Linux REDHAT. At Netmax live scenarios will be
implemented on all kinds network servers like Mail, DNS, Apache, FTP. After
completion of this course candidate can implement a Linux based network independently.
For certification point of view candidate can appear for RHCE, SCLP, LPI or any other
Linux certification.

Cisco Systems, Inc :-

is the worldwide leader in networking for the Internet. Cisco's Internet Protocol-based
(IP) networking solutions are the foundation of the Internet and most corporate,
education, and government networks around the world.

Cisco creates leading products and key technologies to make the Internet more useful and
dynamic. These technologies include: advanced routing and switching, voice and video
over IP, optical networking, wireless, storage networking, security, broadband, and
content networking.

Microsoft's Windows Server 2003 MCSE certification (Microsoft Certified Systems
Engineer) is "for professionals who analyze the business requirements and design and
implement the infrastructure for business solutions based on the Microsoft Windows®
2000 platform and Microsoft Windows Server System?."
 There are no specific prerequisites for the MCSE, although Microsoft says: "candidates
should also have at least one year of experience implementing and administering network
operating systems and desktop operating systems." As soon as candidates pass their first
qualifying exam for the MCSE program, they achieve a Microsoft Certified Professional
(MCP) certification.
Job roles of those pursuing this MCSE certification typically include: systems engineers,
technical support engineers, systems analysts, network analysts, and technical
To achieve the MCSE certification, a candidate must pass a total of seven exams.

Sun Solaris:-

Validate your skills as an IT professional
Getting Sun-certified is a great way to invest in your professional development. Skills
verified during the certification process can help lead to increased productivity, decreased
time to market, reduced risk of system failure, greater employee satisfaction and
enhanced staff credibility.

Sun Certified System Administrator I :-
System Administrator I for Solaris 9 Operating System, Part I exam is geared towards
those candidates with a minimum of six months experience working as a system
administrator. This exam presumes the test candidate has an indepth knowledge of basic
UNIX and Solaris Operating System (Solaris OS) commands, such as those commands
covered in the SA-239 courseware. The examination will include multiple choice
scenario-based questions, drag and drop and fill-in questions. It is a prerequisite to the
Sun Certified System Administrator for Solaris 9 Operating System, Part II exam. Test
candidates must pass this exam before proceeding to the Sun Certified System
Administrator for Solaris 9 Operating System, Part II exam. Reseller exam to not apply as

Sun Certified System Administrator II:-
The Sun Certified System Administrator for Solaris 9 Operating System, Part II exam is
geared toward those candidates with one or more years of experience working as a
system administrator. This exam will test the candidate on the new features of the Solaris
9 Operating System (Solaris 9 OS) and on the more advanced system admininistration
skills. The examination will include multiple choice scenario-based questions and fill-in
questions. The Sun Certified System Administrator for Solaris 9 Exam, Part I (310-014)
is a prerequisite to this examination. Reseller exam to not apply as prerequisites.

What is Linux:-
Linux is an operating system that was initially created as a hobby by a young student,
Linus Torvalds, at the University of Helsinki in Finland. Linus had an interest in Minix, a
small UNIX system, and decided to develop a system that exceeded the Minix standards.
He began his work in 1991 when he released version 0.02 and worked steadily until 1994
when version 1.0 of the Linux Kernel was released. The kernel, at the heart of all Linux
systems, is developed and released under the GNU General Public License and its source
code is freely available to everyone. It is this kernel that forms the base around which a
Linux operating system is developed. There are now literally hundreds of companies and
organizations and an equal number of individuals that have released their own versions of
operating systems based on the Linux kernel. More information on the kernel can be
found at our sister site, LinuxHQ and at the official Linux Kernel Archives. The current
full-featured version is 2.6 (released December 2003) and development continues.

Apart from the fact that it's freely distributed, Linux's functionality, adaptability and
robustness, has made it the main alternative for proprietary Unix and Microsoft operating
systems. IBM, Hewlett-Packard and other giants of the computing world have embraced
Linux and support its ongoing development. More than a decade after its initial release,
Linux is being adopted worldwide as a server platform primarily. Its use as a home and
office desktop operating system is also on the rise. The operating system can also be
incorporated directly into microchips in a process called "embedding" and is increasingly
being used this way in appliances and devices.

Throughout most of the 1990's, tech pundits, largely unaware of Linux's potential,
dismissed it as a computer hobbyist project, unsuitable for the general public's computing
needs. Through the efforts of developers of desktop management systems such as KDE
and GNOME, office suite project and the Mozilla web browser project,
to name only a few, there are now a wide range of applications that run on Linux and it
can be used by anyone regardless of his/her knowledge of computers. Those curious to
see the capabilities of Linux can download a live CD version called Knoppix . It comes
with everything you might need to carry out day-to-day tasks on the computer and it
needs no installation. It will run from a CD in a computer capable of booting from the CD
drive. Those choosing to continue using Linux can find a variety of versions or
"distributions" of Linux that are easy to install, configure and use. Information on these
products is available in our distribution section and can be found by selecting the
mainstream/general public category.

What is diskless workstation:-

Not so long ago computers were either large machines housed in carefully controlled
rooms accessed via serial terminals, or smaller home machines which booted from ROM.
The PC revolution has brought a computer to each desk, along with the noisy fans and
disks a modern PC requires, the maintenance nightmare of hundreds of different
computers installations to maintain, and the never ending cycle of faster and faster
computers being required.

Diskless workstations offer an opportunity to avoid these problems (in exchange for a
different set of problems of course ). This article describes how Linux can be used in the
construction of a diskless workstation that can serve as a remote X terminal for a central
server, and indicates other uses for diskless workstations.

While this article is based around PC hardware, because of the relatively low price and
ease of access to PC hardware, much of strategy described in the article is also
appropriate to other hardware supported by Linux.

The following sections describe what a diskless workstation is, how Linux is relevant, the
theory behind using a Linux diskless workstation, and a gives practical example based on
the author's setup. The article ends with a brief discussion of related projects, and
references to available resources.

A diskless workstation:-
A "diskless workstation" is a computer without a hard drive in it, and generally without a
CD-ROM drive or a floppy drive either, that is used interactively by someone. The
workstation has a network card and video card, and may also have other expansion cards
such as a sound card.

A diskless workstation inherently relies on services provided on the network for most of
its operation, including booting and running applications. Generally the workstation will
be operated as a thin client using a central server to provide access to files and run
applications, but given sufficient resources of its own, some applications can be run

When operated in a thin client mode the resource requirements for the diskless
workstation are relatively modest, making it quite feasible to use older computers (eg,
Pentium 150-200) for the workstations. This offers a considerable benefit in reusing
existing hardware.

A Linux diskless workstation:-
Linux makes a good choice for a diskless workstation operating system because it offers
good support for a wide range of PC hardware (network and video support is particularly
relevant here), and the Linux 2.2 kernel series includes support for network booting and
several network file systems. It is also available relatively cheaply, and the source code is
available easing the task of diagnosing or fixing problems.

Also relevant is the fact that a number of people are actively using Linux in the
construction of diskless workstations and thus support in getting things going is readily

Theory of operation:-
A diskless PC offers several challenges, including initial boot up, and then running an
operating system which is generally expecting access to a hard drive of some sort. This
section describes the theory behind how a diskless workstation operates, focusing on a
Linux based diskless workstation.

Booting the diskless workstation:-
In a PC without a hard drive an alternative means of booting the machine must be found.
Depending on the hardware being used there are several options for booting the machine.

   1.   Network boot from the BIOS (eg, PXE, RPL)
   2.   Network boot from network card boot rom (eg, Etherboot, Netboot)
   3.   Disk on chip (eg, M-Systems DoC)
   4.   Disk-like device (eg, floppy drive, CD-ROM drive)

Increasingly modern computers include a BIOS option to boot from the network using
either PXE (the Preboot Execution Environment, a DHCP extension promoted by Intel
Corporation), or RPL (Remote Program Loading, a Novell Netware based boot method).
For those that don't, most network cards include a socket for a small boot rom which can
be programmed to load an operating system over the network. The Etherboot, and the
older Netboot project provide the ability to build suitable ROM images for many widely
used network cards. The boot process is similar in all of these cases, and will be
discussed further below.

Some PCs, particularly single board PCs and smaller PCs intended for embedded
applications include a socket for a Disk-on-Chip chip. These are available in various sizes
from approximately 4MB up to about 32MB. They appear to the BIOS as another disk,
and thus fairly standard disk-booting methods can be used. The approach often taken is to
boot a version of DOS (eg, FreeDOS), and then use syslinux or loadlin or similar to boot
from DOS into another operating system.

If the computer is not completely without disks, and includes a floppy drive or a CD -
ROM drive, then these can be used in booting the machine. They can be used to directly
load the operating system into memory (either just the kernel or the entire runtime
environment from a small Linux distribution), or just enough code to boot from the
network. The latter is particularly useful when testing the network booting setup. In
particular Etherboot includes the option to create a DOS .COM file which can be run to
start the network booting process. Using a floppy that can boot some version of DOS and
an Etherboot .COM file, the network booting can be tested from a floppy disk.

Network booting:-
Network booting a PC workstation on an IP based network requires a server on the
network that supports both DHCP (or in some cases just bootp) and TFTP (the Trivial
File Transfer Protocol), to provide configuration information and allow transfer of initial
boot files. (RPL requires a slightly different setup, but the underlying principles are the
same.) DHCP (the Dynamic Host Configuration Protocol) is an address discovery (or
allocation) protocol with the ability to also pass other initial configuration information to
the booting host. TFTP is a UDP based protocol which allows the client to request a file
one block at a time. PXE booting requires a PXE server, which is essentially a DHCP
server on steroids -- the PXE server offers all the information usually set through DHCP
as well as additional configuration services. Most PXE clients can be "faked out" with a
DHCP server configured to return some additional information in the responses. The
following discussion assumes an IP based network and booting with PXE, Etherboot or
Netboot. RPL booting is similar, but uses a Netware based network.

The network boot code gets control after the basic POST checks have been performed
and the basic hardware initialisation has been performed. When the network booting is
included in the BIOS, a BIOS setup option will generally enable transfer of control to the
network boot code, either instead of booting from the hard drive or before hard drive
booting is tried. In the case of a network card boot ROM, the boot ROM will be found
during the BIOS scan for card initialisation ROMs and the ROM initialisation code will
hook into the BIOS boot code to take control as soon as the booting process begins.

Once the network booting code has control, it first sends out either a DHCP or a bootp
request to the network to obtain (a) an IP address to use, and other network card setup
information, and (b) the pathname of the boot file to load. PXE booting is similar, except
that PXE expects to get some PXE-specific information back in the DHCP query,
including the PXE version in use. Having obtained this information it initialises the
network card, and then uses TFTP (the Trivial File Transfer Protocol) to download the
boot file, block by block.

The first file retrieved over the network is generally either a second stage boot loader (eg,
pxelinux in the case of a PXE boot), or a specially tagged kernel (Etherboot/Netboot). A
second stage boot loader will generally load a configuration file over the network (eg, a
file from the pxelinux.cfg subdirectory in the case of pxelinux) to control what it does
next. Typically after that it will use TFTP to download a kernel image, and optionally an
initial ram disk image.

Once the kernel has been retrieved, and uncompressed, control will be transfered to it,
and the booting process can continue.

Operating System startup:-
Startup with other operating systems or kernel versions will be similar but not identical.

When the kernel receives control it starts by detecting and initialising the hardware,
including the CPU, memory, and network card. After this, if it has an initial ram disk, it
mounts the ram disk as the root file system, and transfers control to the init process on
that ram disk, which continues the boot process. If there is no initial ram disk, and the
root file system is to be mounted over the network using NFS, then the kernel performs a
DHCP (or bootp) request to get its IP address, and possibly the location to mount (it can
also come from the kernel boot flags), and then performs a NFS mount of the root file
system from that location. Once mounted it transfers control to the init process on the
NFS-mounted root file system, to continue booting.

From here the boot process is basically identical to that of a machine booting from a hard
drive. That is init will run some startup scripts which set various things up on the
machine, and then start up various daemons and applications. Generally the programs
started will include a user-mode DHCP daemon (to look after renewing the DHCP lease
on the IP address), as well an X server to allow access to applications through the X
Window System (X11).

When the X server is started it will send out a XDMCP broadcast to locate XDM servers.
Once an XDM server is located, the XDM server ask the X server to display a login
window on the screen, and wait for a user to log in. When a user logs in their login scripts
will run on the XDM server, and any applications they run will (by default) run on the
XDM server, displayed over the network to the X server on the workstation, using the
native remote display support in the X Window System protocol.

How to install packages in linux :-
You'll frequently need to install additional software on your Linux server that you didn't
think you'd need when you first installed the operating system. This could be because of
new business requirements for additional packages or the need to install new
administrative tools to make your job easier.

When Linux developers create their software they typically bundle all the executable and
data files into a single file that is often called a "package" file. Package files have
different formats and contain different control files that determine where the rest of the
files should be placed, the permissions they should have and a list of prerequisite
packages that are required for the package to function correctly. Some of this information
may also be stored in a database on your system by the package management software
used to install the software and is used to speed up some of the administrative functions
of the package manager.

Redhat, Centos and Fedora Linux software is primarily available in RedHat Package
Manager (RPM) files. Regular RPM package files are used for installations in which the
kernel, or master program, hasn't been customized in any way. This is the usual scenario
for most departmental servers. Source RPMs are used when the kernel has been
customized to add or drop support selectively for various devices or features for the sake
of performance or functionality. The procedure for installing source RPMs involves
recompiling source code to fit the needs of these kernel customizations. This makes life
easier for the software developer who wrote the package as he or she now has only to
create a single package to support all types of customizations. Both package types use
standardized commands for installing the software contained inside making RPMs
relatively easy to use.

Debian and Ubuntu versions of Linux use the Debian Package format in which the
filenames all end with ".deb". It is for this reason that they are frequently called DEB

Software developers who want to use a universally recognizable file format across all
flavors of Linux also will make their products available as TAR packages. TAR packages
are generally more difficult to work with than RPM packages because the archived files
within them may or may not need to be compiled and the commands to install the
software may vary from package to package. Instructions are usually contained within a
file inside the TAR package to help guide the installation.

The Perl programming language is often used by Linux software developers to create
their programs. Perl relies on the presence of certain libraries, or "modules", to work
correctly and many Linux distributions install Perl with only the most commonly used
ones. There will be times when you will be required to install additional prerequisite Perl
modules prior to the installation of your packages. Knowledge of how to install Perl
modules is a valuable component of a Linux systems administrators' skill set.

This chapter focuses on the RPM and DEB formats, which are used by a majority of
installed distributions. There are smaller sections on TAR packages and Perl modules
near the end to cover these less frequently used, but important software installation tools.

Where to Get Commonly Used Packages:-
There are three commonly used sources for packages; distribution CDs; packages
manually downloaded via a browser, File Transfer Protocol (FTP) client, or the wget
utility; and automated downloads. Each of these methods is introduced here, but is
covered in greater detail in sections to follow.

Packages on Your Installation CDs
Installing from your distribution CDs is usually easier than having to download files from
a remote Web site, but they are never up to date for very long. We discuss using this
method in more detail later.

Manually Downloaded Packages
The two most common ways of getting packages are by manually using FTP or a Web
browser. Table 6-1 lists some common download sites that can be used. Remember to
match the RPM to the distribution and version of Linux your system is running.

Table :-Popular Package Download Sites

Distribution                                     Location

Automated Package Download

The disadvantage of manual downloads is that the packages often won't install unless
certain prerequisite packages have been installed beforehand. This can lead to the
download and installation of several packages which can become tedious.

All the major Linux distributions have automated download and update utilities. For
example, Fedora uses yum and Ubuntu and Debian use apt. These are all covered in
greater detail in sections to follow.

How to Download Software:-
One of the most universally performed tasks by Linux systems administrators is the
downloading of software. It is usually very simple to do and the most commonly used
methods are covered in this section.

Getting Software Using Web-Based FTP
There are numerous Web sites that provide links to software you can download. The
methodology to get the software is usually the same for all:

      Browse the desired Web site until you find the link to the software package you
      Click on the link for the desired software package.
      Save the file to your hard drive

Some web browsers, such as Firefox, will automatically download the file to your
desktop, but where is the desktop? In Linux, your desktop is usually a sub-directory
named Desktop located in your home or ~ directory. Here we see that the root user's
desktop already contains a downloaded RPM file.

 [root@bigboy tmp]# cd ~/Desktop/
 [root@bigboy Desktop]# ls
 [root@bigboy Desktop]# pwd
 [root@bigboy Desktop]#

Getting RPMs Using Command-Line Anonymous FTP
The Web based method above transparently uses anonymous File Transfer Protocol
(FTP). Anonymous FTP allows you to log in and download files from a FTP server using
the username anonymous or the shorter username ftp and a password that matches your e-
mail address. This way anyone can access the data. Let's illustrate this with an example of
using anonymous FTP to download the SSH package from

1) First we issue the FTP command targeting at the
command line.

[root@bigboy tmp]# ftp


Connected to (
220 Fedora FTP server ready. All transfers are logged.
Name ( anonymous
331 Please specify the password.
230 Login successful. Have fun.
ftp> pwd
257 "/"
ftp> ls
227 Entering Passive Mode (66,187,232,35,57,155)
150 Here comes the directory listing.
drwxr-xr-x    3 ftp      ftp          4096 Oct 29 15:59 pub
226 Directory send OK.

2) After we've logged in, we can use the help command to see what options we have at
our disposal.

ftp> help
Commands may be abbreviated.         Commands are:
!               cr                     mdir                 proxy               send
$               delete                 mget                 sendport            site
account         debug                  mkdir                put                 size
append          dir                    mls                  pwd                 status
ascii           disconnect             mode                 quit                struct
bell            form                   modtime              quote               system
binary          get                    mput                 recv                sunique
bye             glob                   newer                reget               tenex
case            hash                   nmap                 rstatus             trace
ccc             help                   nlist                rhelp               type
cd              idle                   ntrans               rename              user
cdup            image                  open                 reset               umask
chmod           lcd                    passive              restart             verbose
clear           ls                     private              rmdir               ?
close           macdef                 prompt               runique
cprotect        mdelete                protect              safe

Table :- FTP Commands

Command                             Description
binary      Copy files in binary mode
cd          Change directory on the FTP server
dir         List the names of the files in the current remote directory
exit        Bye bye
get         Get a file from the FTP server
lcd         Change the directory on the local machine
ls          Same as dir
mget        Same as get, but you can use wildcards like "*"
mput        Same as put, but you can use wildcards like "*"
passive     Make the file transfer passive mode
put         Put a file from the local machine onto the FTP server
pwd         Give the directory name on the local machine

3) By using the Web browsing feature on the Web site ahead of time, I know that the
Fedora Core 2 RPMs are located in the pub/fedora/linux/core/2/i386/os/Fedora/RPMS/
directory and will use the cd command to change my directory to there. We can use the ls
command to get a listing of files in this directory.

ftp> cd pub/fedora/linux/core/2/i386/os/Fedora/RPMS/
250 Directory successfully changed.
ftp> ls open*
227 Entering Passive Mode (66,187,232,35,58,3)
150 Here comes the directory listing.
-rw-r--r--   ... ... 184281 Oct 28 23:29 openssh-3.6.1p2-34.i386.rpm
226 Directory send OK.

4) Next we get the file we need and place it in the local directory /usr/rpm. The hash
command will print "#" hash signs on the screen during the download.

ftp> hash
Hash mark printing on (1024 bytes/hash mark).
ftp> lcd /usr/rpm
Local directory now /usr/rpm

ftp> get openssh-3.6.1p2-34.i386.rpm
 local: openssh-3.6.1p2-34.i386.rpm remote: openssh-3.6.1p2-34.i386.rpm
 227 Entering Passive Mode (66,187,232,35,58,25)
 150 Opening BINARY mode data connection for openssh-3.6.1p2-
34.i386.rpm (184281 bytes).

 226 File send OK.
 184281 bytes received in 3.41 secs (53 Kbytes/sec)

Note: You can also use wildcards to download the RPMs you need using the mget
command. You'll be prompted for each of the matching RPM files. In the next example,
we just aborted this download by typing n.

ftp> mget openssh-3.6*
mget openssh-3.6.1p2-34.i386.rpm? n

5) Finally we use the exit command to leave FTP.

ftp> exit
221 Goodbye.
root@bigboy tmp]#

Getting Software Using wget :-
The wget command can be used to download files quickly when you already know the
URL at which the RPM is located. This is especially convenient if you are logged into
your Linux box from another machine running a Web browser. You can browse the
download site for the RPM you need, right click on the desired link and select copy
shortcut (Windows) or Copy Link Location (Linux). After you have done this, you can
then select your SSH/telnet/Linux Terminal login window and type in the command wget
URL. Here is an example downloading a DHCP update from Fedora.

[root@bigboy tmp]# wget
           => `dhcp-3.0pl2-6.16.i386.rpm.5'
Resolving done.
Connecting to[]:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done. ==> CWD
/pub/mirrors/fedora/linux/core/2/i386/os/Fedora/RPMS ... done.
==> PASV ... done.    ==> RETR dhcp-3.0pl2-6.16.i386.rpm ... done.
Length: 529,890 (unauthoritative)

100%[===============================>] 529,890               889.12K/s       ETA

17:38:36 (889.12 KB/s) - `dhcp-3.0pl2-6.16.i386.rpm.5' saved [529890]

[root@bigboy tmp]#

Installing Software From RPM Files:-
The Fedora, Redhat and Centos versions of Linux rely heavily upon the use of software
packages in the RPM format. This section covers some of the most important topics
required for you to master their use.

How To Install RPMs Manually
There are generally two ways to install RPM files manually. The first method is by using
a file previously downloaded to your hard drive, and the other is to install the RPM from
some sort of removable media such as a CD-ROM drive.

Using Downloaded Files
Download the RPMs (which usually have a file extension ending with .rpm) into a
temporary directory, such as /tmp. The next step is to issue the rpm -Uvh command to
install the package.

The -U qualifier is used for updating an RPM to the latest version, the -h qualifier gives a
list of hash # characters during the installation and the -v qualifier prints verbose status
messages while the command is run. Here is an example of a typical RPM installation
command to install the MySQL server package:

[root@bigboy tmp]# rpm -Uvh mysql-server-3.23.58-9.i386.rpm
Preparing...        ####################### [100%]
  1:mysql-server   ####################### [100%]
[root@bigboy tmp]#

Using CD-ROMs
The underlying steps to install RPMs from CDs are similar to those used when installing
from your hard disk. The main difference is that you have to access your CD-ROM drive
by mounting it first to the mnt/cdrom directory. Your RPMs will then be located in the
CD-ROM's Fedora/RPMs subdirectory. The procedure is as follows:

1) Insert the CD-ROM, check the files in the /mnt/cdrom/Fedora/RPMS directory and
then install the RPM.

[root@bigboy tmp]# mount /mnt/cdrom
[root@bigboy tmp]# cd /mnt/cdrom/Fedora/RPMS
[root@bigboy RPMS]# ls filename*
[root@bigboy RPMS]# rpm -Uvh filename.rpm
 Preparing...         ####################### [100%]
   1: filename       ####################### [100%]
 [root@bigboy RPMS]#

2) When finished, eject the CD-ROM

[root@bigboy RPMS]# cd /tmp
[root@bigboy tmp]# eject cdrom
[root@bigboy tmp]#

Note: You can use the rpm command's --aid switch to make it search the CD-ROM for
any other RPM dependencies and install them automatically.

How to Install Source RPMs :-
Sometimes the packages you want to install need to be compiled in order to match your
kernel version. This requires you to use source RPM files:

      Download the source RPMs or locate them on your CD collection. They usually
       have a file extension ending with (.src.rpm)
      Run the following commands as root:

Compiling and installing source RPMs with Fedora can be done simply with the
rpmbuild command

[root@bigboy tmp]# rpmbuild --rebuild filename.src.rpm

Here is an example in which we install the tacacs plus package.

[root@bigboy rpm]# rpmbuild --rebuild tac_plus-4.0.3-2.src.rpm
Installing tac_plus-4.0.3-2.src.rpm
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.61594
+ umask 022
+ cd /usr/src/redhat/BUILD
+ cd /usr/src/redhat/BUILD
+ rm -rf tac_plus-4.0.3
+ /usr/bin/gzip -dc /usr/src/redhat/SOURCES/tac_plus-4.0.3.tgz
+ tar -xvvf -
+ umask 022
+ cd /usr/src/redhat/BUILD
+ rm -rf tac_plus-4.0.3
+ exit 0
[root@bigboy rpm]#

The compiled RPM file can now be found in one of the architecture subdirectories under
/usr/src/redhat/RPMS directory. For example, if you compiled an i386 architecture
version of the RPM it will placed in the i386 subdirectory.

You will then have to install the compiled RPMs found in their respective subdirectories
as you normally would.

RPM Installation Errors :-
Sometimes the installation of RPM software doesn't go according to plan and you need to
take corrective actions. This section shows you how to recover from some of the most
common errors you'll encounter.

Failed Dependencies
Sometimes RPM installations will fail giving Failed dependencies errors which really
mean that a prerequisite RPM needs to be installed. In the next example we're attempting
to install the MySQL database server application, which fails because the mysql MySQL
client RPM, on which it depends, needs to be installed beforehand:

[root@bigboy tmp]# rpm -Uvh mysql-server-3.23.58-9.i386.rpm
error: Failed dependencies: is needed by mysql-server-3.23.58-9
        mysql = 3.23.58 is needed by mysql-server-3.23.58-9
[root@bigboy tmp]#

Installing the MySQL client also fails because it requires the perl-DBD-MySQL package.

[root@bigboy tmp]# rpm -Uvh mysql-3.23.58-9.i386.rpm
error: Failed dependencies:
        perl-DBD-MySQL is needed by mysql-3.23.58-9
[root@bigboy tmp]# rpm -Uvh perl-DBD-MySQL-2.9003-4.i386.rpm
error: Failed dependencies: is needed by perl-DBD-MySQL-2.9003-4
[root@bigboy tmp]#

Strangely enough, the installation of the perl-DBD-MySQL package fails because it
needs the mysql client package. To get around this problem you can run the rpm
command with the --nodeps option to disable dependency checks. In the next example we
install the MySQL client ignoring dependencies, followed by successful installation of
perl-DBD-MySQL and mysql-server.

[root@bigboy tmp]# rpm -Uvh --nodeps mysql-3.23.58-9.i386.rpm
Preparing...        ####################### [100%]
   1:mysql          ####################### [100%]
[root@bigboy tmp]# rpm -Uvh perl-DBD-MySQL-2.9003-4.i386.rpm
Preparing...        ####################### [100%]
   1:perl-DBD-MySQL ####################### [100%]
[root@bigboy tmp]# rpm -Uvh mysql-server-3.23.58-9.i386.rpm
Preparing...        ####################### [100%]
   1:mysql-server   ####################### [100%]
[root@bigboy tmp]#

Note: If all the installation RPMs are located in the same directory, the rpm command
can automatically install all the prerequisite RPMs using the --aid option. One of the
advantages of using the yum facility is that you don't have to worry about this
dependency process as much because the dependency RPMs are always downloaded and
installed automatically also.

Signature Keys
Fedora digitally signs all its RPM files, so it's best to import their public encryption key
beforehand so that the RPM installation program will be able to verify the validity of the
RPM file. This can be done using the rpm command as seen in the next example. It is a
good idea to import both the RedHat and Fedora keys:

[root@bigboy tmp]# rpm --import /usr/share/rhn/RPM-GPG-KEY
[root@bigboy tmp]# rpm --import /usr/share/rhn/RPM-GPG-KEY-fedora
[root@bigboy tmp]#

If you don't install the keys you'll get a DSA signature warning that alerts you to the fact
that the RPM file might be bogus:

[root@bigboy tmp]# rpm -Uvh dhcp-3.0pl2-6.16.i386.rpm
warning: dhcp-3.0pl2-6.16.i386.rpm: V3 DSA signature: NOKEY, key ID
Preparing...           #################################### [100%]
   1:dhcp              #################################### [100%]
[root@bigboy tmp]#

It is always good to install the key files. If they are not there, the RPMs will install with
only a warning message. If the RPM's digital signature doesn't match that in the key file,
the rpm installation program also alerts you and fails to install the RPM package at all:

[root@bigboy tmp]# rpm -Uvh dhcp-3.0pl2-6.16.i386.rpm
error: dhcp-3.0pl2-6.16.i386.rpm: V3 DSA signature: BAD, key ID
error: dhcp-3.0pl2-6.16.i386.rpm cannot be installed
[root@bigboy tmp]#

Signatures are therefore useful because they help protect you against tampered and
otherwise corrupted RPMs being installed.

How to List Installed RPMs :-
The rpm -qa command will list all the packages installed on your system

[root@bigboy tmp]# rpm -qa
[root@bigboy tmp]#

You can also pipe the output of this command through the grep command if you are
interested in only a specific package. In this example we are looking for all packages
containing the string ssh in the name, regardless of case (-i means ignore case)

[root@bigboy tmp]# rpm -qa | grep -i ssh
[root@bigboy tmp]#

Note: You could use the rpm -q package-name command to find an installed package
because it is much faster than using grep and the -qa switch, but you have to have an
exact package match. If you are not sure of the package name and its capitalization, the
latter method is probably more suitable.

Listing Files Associated with RPMs :-
Sometimes you'll find yourself installing software that terminates with an error requesting
the presence of a particular file. In many cases the installation program doesn't state the
RPM package in which the file can be found. It is therefore important to be able to
determine the origin of certain files, by listing the contents for RPMs in which you
suspect the files might reside.

Listing Files for Already Installed RPMs
This can be useful if you have to duplicate a working server that is already in a
production environment. Sometimes the installation of an application fails on the new
server due to the lack of a file that resides on the old one. In this case you need to know
which RPM on the old server contains the file.

You can use the -ql qualifier to list all the files associated with an installed RPM. In this
example we test to make sure that the NTP package is installed using the -q qualifier, and
then we use the -ql qualifier to get the file listing.

[root@bigboy tmp]# rpm -q ntp
[root@bigboy tmp]# rpm -ql ntp
[root@bigboy tmp]#

Listing Files in RPM Files
Sometimes you make a guess and download what you think is the RPM with the missing
file. You can use the -qpl qualifier to list all the files in an RPM archive to make sure
before installing it:

[root@bigboy updates]# rpm -qpl dhcp-3.0pl1-23.i386.rpm

[root@bigboy updates]#

Listing the RPM to Which a File Belongs
You might need to know the RPM that was used to install a particular file. This is useful
when you have a suspicion about the function of a file but are not entirely sure. For
example, the MySQL RPM uses the /etc/my.cnf file as its configuration file, not a file
named /etc/mysql.conf as you'd normally expect. The following example confirms the
origin of the /etc/my.cnf file.

[root@zippy tmp]# rpm -qf /etc/my.cnf
[root@zippy tmp]#

Uninstalling RPMs :-
The rpm -e command will erase an installed package. The package name given must
match that listed in the rpm -qa command because the version of the package is

[root@bigboy tmp]# rpm -e package-name

Which RPMs Will Start Up At Boot Time?

The best way to view and configure which RPMs will start at boot time is by using the
chkconfig command with the --list switch.

Installing Software Using tar Files :-
Another popular software installation file format is the tar file, which can frequently be
obtained from the Web sites of software developers, and online software libraries such as

The Linux tar command is used to archive files and typically have a .tar file extension in
the file name. These files are also frequently compressed in the gzip format, and when
they do, their file extensions will end with .tar.gz or .tgz. The commands to extract the
data from either type are similar. When a tar file is uncompressed, the command to
extract the data is tar -xvf filename.tar. When the archive is compressed, the command to
use is tar -xzvf filename.tar.gz.

The tar file installation process usually requires you first to uncompress and extract the
contents of the archive in a local subdirectory, which frequently has the same name as the
tar file. The subdirectory will usually contain a file called README or INSTALL, which
outlines all the customized steps to install the software.

Here are the initial steps to take to install tar-based software:

1) Issue the tar command to extract the files.

[root@bigboy tmp]# tar -xvzf linux-software-1.3.1.tar.gz
[root@bigboy tmp]#

This creates a subdirectory with the installation files inside.

[root@bigboy tmp]# ls
linux-software-1.3.1 linux-software-1.3.1.tar.gz
[root@bigboy tmp]#

2) Use the cd command to enter the subdirectory and follow the directions listed in the

[root@bigboy tmp]# cd linux-software-1.3.1
[root@bigboy linux-software-1.3.1]# ls
COPYING    install-sh   missing                                   plugins
depcomp    LEGAL        mkinstalldirs                             plugins-scripts
FAQ        lib          linux-software.spec                       README                      REQUIREMENTS
INSTALL NEWS                             
[root@bigboy linux-software-1.3.1]#

Software installation with tar files can be frustrating, frequently requiring the installation
of other supporting tar files, each with its own customized installation commands. RPMs,
with the single standardized command format, are usually easier to use and may be the
better method to use for newer Linux users.

This is just the beginning. If the software you install is intended to make your Linux
machine permanently run an application such as a Web server, mail server, or any other
type of server you have to know how to get the software activated when the system

Main Steps for Make Diskless Workstations:-

    1. Install Red Hat Enterprise Linux on a system so that the files can be copied to
       the NFS server. Any software to be used on the clients must be installed on
       this system and the busybox-anaconda package must be installed.
    2. Create a directory on the NFS server to contain the diskless environment such
       as /diskless/i386/RHEL4-AS/.
    3. Start the tftp server
    4. Configure the DHCP server
    5. Finish creating the diskless environments
    6. Configure the diskless clients
    7. Configure each diskless client to boot via PXE and boot them.

NFS Introduction :-
Samba is usually the solution of choice when you want to share disk space between
Linux and Windows machines. The Network File System protocol (NFS) is used when
disks need to be shared between Linux servers. Basic configuration is fairly simple, and
this chapter will explain all the essential steps.

NFS Operation Overview:-
Linux data storage disks contain files stored in filesystems with a standardized directory
structure. New disks are added by attaching, or mounting, the directories of their
filesystems to a directory of an already existing filesystem. This in effect makes the new
hard disk transparently appear to be a subdirectory of the filesystem to which it is

NFS was developed to allow a computer system to access directories on remote
computers by mounting them on a local filesystem as if they were a local disk. The
systems administrator on the NFS server has to define the directories that need to be
activated, or exported, for access by the NFS clients, and administrators on the clients
need to define both the NFS server and the subset of its exported directories to use.

General NFS Rules
You should follow some general rules when configuring NFS.

   1. Only export directories beneath the / directory.
   2. Do not export a subdirectory of a directory that has already been exported. The
      exception being when the subdirectory is on a different physical device. Likewise,
      do not export the parent of a subdirectory unless it is on a separate device.
   3. Only export local filesystems.

Keep in mind that when you mount any filesystem on a directory, the original contents of
the directory are ignored, or obscured, in favor of the files in the mounted filesystem.
When the filesystem is unmounted, then the original files in the directory reappear

Key NFS Concepts
Data access over a network always introduces a variety of challenges, especially if the
operation is intended to be transparent to the user, as in the case of NFS. Here are some
key NFS background concepts that will help in your overall understanding.

The virtual filesystem (VFS) interface is the mechanism used by NFS to transparently
and automatically redirect all access to NFS-mounted files to the remote server. This is
done in such a way that files on the remote NFS server appear to the user to be no
different than those on a local disk.

VFS also translates these requests to match the actual filesystem format on the NFS
server's disks. This allows the NFS server to be not only a completely different operating
system, but also use different naming schemes for files with different file attribute types.

Stateless Operation:-
Programs that read and write to files on a local filesystem rely on the operating system to
track their access location within the file with a pointer. As NFS is a network -based file
system, and networks can be unreliable, it was decided that the NFS client daemon would
act as a failsafe intermediary between regular programs running on the NFS client and the
NFS server.

Normally, when a server fails, file accesses timeout and the file pointers are reset to zero.
With NFS, the NFS server doesn't maintain the file pointer information, the NFS client
does. This means that if an NFS server suddenly fails, the NFS client can precisely restart
the file access once more after patiently waiting until the server returns online.

NFS clients typically request more data than they need and cache the results in memory
locally so that further sequential access of the data can be done locally versus over the
network. This is also known as a read ahead cache. Data that's to be written to the NFS
server is cached with the data being written to the server when the cache becomes full.
Caching therefore helps to reduce the amount of network traffic while simultaneously
improving the speed of some types of data access.

The NFS server caches information too, such as the directory information for the most
recently accessed files and a read ahead cache for recently read files.

NFS And Symbolic Links:-
You have to be careful with the use of symbolic links on exported NFS directories. If an
absolute link points to a directory on the NFS server that hasn't been exported, then the
NFS client won't be able to access it.

Unlike absolute links, relative symbolic links are interpreted relative to the client's
filesystem. Consider an example where the /data1 directory on the server is mounted on
the /data1 directory. If there is a link to the ../data2 directory on the NFS server and a

directory corresponding to ../data2 doesn't exist on the NFS client, then an error will

Also, mounting a filesystem on a symbolic link actually mounts the filesystem on the
target of the symbolic link. You'll have to be careful not to obscure the contents of this
original directory in the process. Plan carefully before doing this.

NFS Background Mounting:-
NFS clients use the remote procedure call (RPC) suite of network application helper
programs to mount remote filesystems. If the mount cannot occur during the default RPC
timeout period, then the client retries the mount process until the NFS number of retires
has been exceeded. The default is 10,000 minutes, which is approximately a week. The
difficulty here is that if the NFS server is unavailable, the mount command will hang for
a week until it returns online. It is possible to use a bg option spawn the retries off as a
subprocess so that the main mount command can continue to process other requests.

Hard and Soft Mounts:-
The process of continuous retrying, whether in the background or foreground, is called a
hard mount. NFS attempts to guarantee the consistency of your data with these constant
retries. With soft mounts, repeated RPC failures cause the NFS operation to fail not hang
and data consistency is therefore not guaranteed. The advantage is that the operation
completes quickly, whether it fails or not. The disadvantage is that the use of the soft
option implies that you are using an unreliable NFS server, if this is the case it is best not
to place critical data that needs to be updated regularly or executable programs in such a

NFS Versions:-
Three versions of NFS are available currently: versions 2, 3, and 4. Version 1 was a
prototype. This chapter focuses on version 2, which:

      Supports files up to 4GB long
      Requires an NFS server to successfully write data to its disks before the write
       request is considered successful
      Has a limit of 8KB per read or write request.

The main differences with version 3 are that it

      Supports extremely large file sizes of up to 264 - 1 bytes
      Supports the NFS server data updates as being successful when the data is written
       to the server's cache
      Negotiates the data limit per read or write request between the client and server to
       a mutually decided optimal value.

Version 4 maintains many of version 3's features, but with the additions that

      File locking and mounting are integrated in the NFS daemon and operate on a
       single, well known TCP port, making network security easier
      File locking is mandatory, whereas before it was optional
      Support for the bundling of requests from each client provides more efficient
       processing by the NFS server.

It is important to match the versions of NFS running on clients and server to help ensure
the necessary compatibility to get NFS to work predictably.

Important NFS Daemons:-
NFS isn't a single program, but a suite of interrelated programs that work together to get
the job done.

      portmap: The primary daemon upon which all the others rely, portmap manages
       connections for applications that use the RPC specification. By default, portmap
       listens to TCP port 111 on which an initial connection is made. This is then used
       to negotiate a range of TCP ports, usually above port 1024, to be used for
       subsequent data transfers. You need to run portmap on both the NFS server and

      nfs: Starts the RPC processes needed to serve shared NFS file systems. The nfs
       daemon needs to be run on the NFS server only.

      nfslock: Used to allow NFS clients to lock files on the server via RPC processes.
       The nfslock daemon needs to be run on both the NFS server and client.

      netfs: Allows RPC processes run on NFS clients to mount NFS filesystems on the
       server. The nfslock daemon needs to be run on the NFS client only.

Now take a look at how to configure these daemons to create functional NFS client/server

Installing NFS:-
RedHat Linux installs nfs by default, and also by default nfs is activated when the system
boots. You can determine whether you have nfs installed using the RPM command in
conjunction with the grep command to search for all installed nfs packages.

[root@bigboy tmp]# rpm -qa | grep nfs
[root@bigboy tmp]#

A blank list means that you'll have to install the required packages.

You also need to have the RPC portmap package installed, and the rpm command can tell
you whether it's on your system already. When you use rpm in conjunction with grep,
you can determine all the portmap applications installed:

[root@bigboy tmp]# rpm -q portmap
[root@bigboy tmp]#

A blank list means that you'll have to install the required packages.

If nfs and portmap are not installed, they can be added fairly easily once you find the nfs-
utils and portmap RPMs. Remember that RPM filenames usually start with the software's
name and a version number, as in nfs-utils-1.1.3-1.i386.rpm.

A small office has an old Linux server that is running out of disk space. The office cannot
tolerate any down time, even after hours, because the server is accessed by overseas
programmers and clients at nights and local ones by day.

Budgets are tight and the company needs a quick solution until it can get a purchase order
approved for a hardware upgrade. Another Linux server on the network has additional
disk capacity in its /data partition and the office would like to expand into it as an interim
expansion NFS server.

Configuring NFS on The Server:-
Both the NFS server and NFS client have to have parts of the NFS package installed and
running. The server needs portmap, nfs, and nfslock operational, as well as a correctly
configured /etc/exports file. Here's how to do it.

The /etc/exports File

The /etc/exports file is the main NFS configuration file, and it consists of two columns.
The first column lists the directories you want to make available to the network. The
second column has two parts. The first part lists the networks or DNS domains that can
get access to the directory, and the second part lists NFS options in brackets.

For the scenario you need:

      Read-only access to the /data/files directory to all networks
      Read/write access to the /home directory from all servers on the /24
       network, which is all addresses from to
      Read/write access to the /data/test directory from servers in the DNS
      Read/write access to the /data/database directory from a single server

In all cases, use the sync option to ensure that file data cached in memory is
automatically written to the disk after the completion of any disk data copying operation.

/data/files    *(ro,sync)
/data/test     *,sync)

After configuring your /etc/exports file, you need to activate the settings, but first make
sure that NFS is running correctly.

Starting NFS on the Server:-
Configuring an NFS server is straightforward:

1) Use the chkconfig command to configure the required nfs and RPC portmap daemons
to start at boot. You also should activate NFS file locking to reduce the risk of corrupted

[root@bigboy tmp]# chkconfig --level 35 nfs on
[root@bigboy tmp]# chkconfig --level 35 nfslock on

[root@bigboy tmp]# chkconfig --level 35 portmap on

2) Use the init scripts in the /etc/init.d directory to start the nfs and RPC portmap
daemons. The examples use the start option, but when needed, you can also stop and
restart the processes with the stop and restart options.

[root@bigboy tmp]# service portmap start
[root@bigboy tmp]# service nfs start
[root@bigboy tmp]# service nfslock start

3) Test whether NFS is running correctly with the rpcinfo command. You should get a
listing of running RPC programs that must include mountd, portmapper, nfs, and

[root@bigboy tmp]# rpcinfo -p localhost
  program vers proto port
   100000 2 tcp 111 portmapper
   100000 2 udp 111 portmapper
   100003 2 udp 2049 nfs
   100003 3 udp 2049 nfs
   100021 1 udp 1024 nlockmgr
   100021 3 udp 1024 nlockmgr
   100021 4 udp 1024 nlockmgr
   100005 1 udp 1042 mountd
   100005 1 tcp 2342 mountd
   100005 2 udp 1042 mountd
   100005 2 tcp 2342 mountd
   100005 3 udp 1042 mountd
   100005 3 tcp 2342 mountd
[root@bigboy tmp]#

Configuring NFS on The Client:-
NFS configuration on the client requires you to start the NFS application; create a
directory on which to mount the NFS server's directories that you exported via the
/etc/exports file, and finally to mount the NFS server's directory on your local directory,
or mount point. Here's how to do it all.

Starting NFS on the Client:-
Three more steps easily configure NFS on the client.

1) Use the chkconfig command to configure the required nfs and RPC portmap daemons
to start at boot. Activate nfslock to lock the files and reduce the risk of corrupted data.

[root@smallfry tmp]# chkconfig --level 35 netfs on
[root@smallfry tmp]# chkconfig --level 35 nfslock on
[root@smallfry tmp]# chkconfig --level 35 portmap on

2) Use the init scripts in the /etc/init.d directory to start the nfs and RPC portmap
daemons. As on the server, the examples use the start option, but you can also stop and
restart the processes with the stop and restart options.

[root@smallfry tmp]# service portmap start
[root@smallfry tmp]# service netfs start
[root@smallfry tmp]# service nfslock start

3) Test whether NFS is running correctly with the rpcinfo command. The listing of
running RPC programs you get must include status, portmapper, and nlockmgr.

[root@smallfry root]# rpcinfo -p
  program vers proto port
   100000 2 tcp 111 portmapper
   100000 2 udp 111 portmapper
   100024 1 udp 32768 status
   100024 1 tcp 32768 status
   100021 1 udp 32769 nlockmgr
   100021 3 udp 32769 nlockmgr
   100021 4 udp 32769 nlockmgr
   100021 1 tcp 32769 nlockmgr
   100021 3 tcp 32769 nlockmgr
   100021 4 tcp 32769 nlockmgr
   391002 2 tcp 32770 sgi_fam
[root@smallfry root]#

The NFS client must have a matching pair of forward and reverse DNS entries on the
DNS server used by the NFS server. In other words, a DNS lookup on the NFS server for
the IP address of the NFS client must return a server name that will map back to the
original IP address when a DNS lookup is done on that same server name.

[root@bigboy tmp]# host domain name pointer
[root@bigboy tmp]# host has address
[root@bigboy tmp]#

This is a security precaution added into the nfs package that lessens the likelihood of
unauthorized servers from gaining access to files on the NFS server. Failure to correctly
register your server IPs in DNS can result in "fake hostname" errors:

Nov    7 19:14:40 bigboy rpc.mountd: Fake hostname for - forward lookup doesn't exist

Making NFS Mounting Permanent:-
In most cases, users want their NFS directories to be permanently mounted. This requires
an entry in the /etc/fstab file in addition to the creation of the mount point directory.

The /etc/fstab File:-
The /etc/fstab file lists all the partitions that need to be auto-mounted when the system
boots. Therefore, you need to edit the /etc/fstab file if you need the NFS directory to be
made permanently available to users on the NFS. For the example, mount the /data/files
directory on server bigboy (IP address 192.16801.100) as an NFS-type filesystem using
the local /mnt/nfs mount point directory.

#Directory             Mount Point   Type Options      Dump FSCK /mnt/nfs     nfs soft,nfsvers=2 0 0

Definition: tftp-server: The Trivial File Transfer Protocol (TFTP) is normally used only
for booting diskless workstations. The tftp-server package provides the server for TFTP,
which allows users to transfer files to and from a remote machine. TFTP provides very
little security, and should not be enabled unless it is expressly needed. The TFTP server
is run from/etc/ xinetd.d/tftp, and is disabled by default on Red Hat Linuxsystems.

Many networking equipment manufacturers allow you to backup live configurations of
their devices to centralized servers via the TFTP protocol. TFTP can be used with great
versatility as a network management tool and not just for saving files. TFTP servers can
be used to upload new configurations to replacement devices after serious hardware
failures. They also can be used for uploading new versions of software to be run as
network devices. Finally, they can be used to upload even partial configurations such as
files containing updated access control lists (ACLs) that restrict access to networks and
even the regular application of new passwords.
TFTP may not be an application used regularly in a home, but it will become increasingly
important in an expanding small office/home office (SOHO) environment which is why
the topic is covered here. The provided TFTP examples use equipment from Cisco
Systems, a leading networking hardware manufacturer.

Installing The TFTP Server Software:-
Most RedHat and Fedora Linux software products are available in the RPM format.
Downloading and installing RPMs isn't hard.
When searching for the file, remember that the TFTP server RPM's filename usually
starts with the word "tftp-server" followed by a version number like this: tftp-server-0.33-

Configuring The TFTP Server:-
     The procedure to set up a TFTP Server is straightforward.
     By default, the TFTP application expects files to be located in the /tftpboot
     directory. Change this in the /etc/xinetd.d/tftp file via the server_args option, or
     create your own directory just for this purpose and create a /tftpboot symbolic link
     to it.
     It is usually best to place the TFTP files in a partition other than the root partition.
     TFTP files of increasing size could eventually fill the partition affecting your ability
     to install new software or even the overall performance of your system. This

example creates a new tftpboot directory in the /var partition, and then creates a
symbolic link that makes this directory appear to also be the /tftpboot directory.

 [root@bigboy tmp]# mv /tftpboot /var
 [root@bigboy tmp]# ln -s /var/tftpboot /tftpboot

You must restart xinetd for the new configuration to take effect.

 [root@bigboy tmp]# chkconfig tftp on

Each device must have a configuration file in the /tftpboot directory. Here's an
example of what to do for a SOHO firewall named pixfw and a configuration
filename that matches Cisco's standard naming scheme of devicename-config.

 [root@bigboy tmp]# touch /tftpboot/pixfw-config
 [root@bigboy tmp]# chmod 666 /tftpboot/pixfw-config
 total 1631
 -rw-rw-rw- 1 root root 3011 Oct 29 14:09 pixfw-config
 [root@bigboy tmp]#

You can test whether the TFTP process is running with the netstat command which
is used to check the TCP/UDP ports on which your server is listening. If it isn't
running then there will be no response.

 [root@bigboytmp]# netstat-a|greptftp udp        0    0 *:tftp        *:*

    An Introduction to DHCP:-
    DHCP stands for dynamic host configuration protocol. What it does is dynamically
    assign network settings from a server. In other words, instead of having to configure the
    parameters related to how your computer communicates with a network, it happens

    Assigning an IP address dynamically is the most basic piece but there is a lot more to
    DHCP. This includes the netmask, host name, domain name, gateway and name servers.
    In addition, DHCP can supply other information such as a time server.

    Many people are anti-DHCP, because they see it as a way that an ISP offers you an IP
    address that changes. This, of course, makes it difficult to advertise a server. On the other
    hand, DHCP can save you a lot of ongoing configuration work within your company or

    Besides the ISP-provided DHCP servers, they commonly exist in inexpensive router
    boxes. Netgear, Linksys and other vendors offer these systems with multiple LAN ports,
    an 802.11b wireless interface or both. The Netgear RP114 is an example of a wired LAN,
    while the Linksys WAP11 is an 802.11b type. Many other product choices are available.
    When you use one, the router box becomes the system that the ISP knows about, and all
    of your real computers hide behind this box.

    Hide? Effectively, yes. What is visible to the public Internet is the router. The LAN has
    private IP addresses and uses network address translation (NAT) to handle connections
    from the internal systems to the Internet. Although this isn't really a firewall, NAT offers
    a basic level of protection.

    Most routers in this class allow you to:

   Clone the MAC (hardware) address of one of your computers. This allows you to make
    the ISP think it is talking to a computer system you previously identified rather than to a
    router with possibly multiple machines connected to it.
   Handle static IP addresses. This means you could pick a local network address
    (192.168.1.x, for example) and assign specific addresses in this range.
   Dynamically assign IP addresses from a specified range. For example, the router could be
    configured to offer DHCP for 20 different addresses, say thru

    That is the basics of "DHCP for Beginners". If you simply are trying to decide between
    using DHCP or a static IP address, this may be enough information. On the other hand,
    you could decide to run a DHCP server on a Linux system. In that case, there are more

Linux as a DHCP Server:-
Dhcpd from ISC is the most common DHCP server shipped with Linux systems. When
started, it takes its directions from a configuration file usually found at /etc/dhcpd.conf.
Here is a sample configuration file:

# Sample configuration file for ISC dhcpd
# option definitions common to all supported networks...
option domain-name "";
option domain-name-servers,;
default-lease-time 600;
max-lease-time 7200;
# if you do not use dynamical DNS updates:
# this statement is needed by dhcpd-3 needs at least this statement.
# you have to delete it for dhcpd-2, because it does not know it.
# if you want to use dynamical DNS updates, you should first read
# read /usr/share/doc/packages/dhcp-server/DDNS-howto.txt
ddns-update-style none; ddns-updates off;
# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;
# This is a very basic subnet declaration.
subnet netmask {
  option routers,;
# A slightly different configuration for an internal subnet.
subnet netmask {
  option domain-name-servers;
  option domain-name "";
  option routers;
  option broadcast-address;
  default-lease-time 600;
  max-lease-time 7200;
# Hosts which require special configuration options can be listed in
# host statements. If no address is specified, the address will be
# allocated dynamically (if possible), but the host-specific information
# will still come from the host declaration.

host passacaglia {
  hardware ethernet 0:0:c0:5d:bd:95;
  filename "vmunix.passacaglia";
  server-name "";
# Fixed IP addresses can also be specified for hosts. These addresses
# should not also be listed as being available for dynamic assignment.
# Hosts for which fixed IP addresses have been specified can boot using
# BOOTP or DHCP. Hosts for which no fixed address is specified can only
# be booted with DHCP, unless there is an address range on the subnet
# to which a BOOTP client is connected which has the dynamic-bootp flag
# set.
host fantasia {
  hardware ethernet 08:00:07:26:c0:a5;

The man page associated with this file, dhcpd.conf(5) is quite thorough, and I am not
going to attempt to reproduce all that information here. Simply typing man
dhcpd.conf| will display it. It runs over 25 printed pages, but should you want to print
it for off-line study, the following commands should suffice:

cd /usr/share/man/man5
zcat dhcpd.conf.5.gz | groff -man | lpr

The file is divided into two types of statements. Parameter statements say how dhcpd
should do something. Declaration statements describe the network. Thus, parameters
establish things that declarations may depend upon. In the example above, default-
lease-time is an example of a parameter. The block beginning with host
fantasia { is a declaration. The option statements appearing outside of any block are
global parameters, meaning they are global in scope. Those within declarations have a
local scope.

Download and Install the DHCP Package:-
 Most RedHat and Fedora Linux software products are available in the RPM format.
 Downloading and installing RPMs aren't hard.
 When searching for the file, remember that the DHCP server RPM's filename usually
 starts with the word dhcp followed by a version number like this: dhcp-3.0.1rc14-

The /etc/dhcpd.conf File:-

 When DHCP starts, it reads the file /etc/dhcpd.conf. It uses the commands here to
 configure your network. The standard DHCP RPM package doesn't automatically
 install a /etc/dhcpd.conf file, but you can find a sample copy of dhcpd.conf in the
 following directory which you can always use as a guide.


 You have to copy the sample dhcpd.conf file to the /etc directory and then you'll have
 to edit it. Here is the command to do the copying for the version 3.0p11 RPM file:

  [root@bigboy tmp]# cp /usr/share/doc/dhcp-3.0pl1/dhcpd.conf.sample \

 Here is a quick explanation of the dhcpd.conf file: Most importantly, there must be a
 subnet section for each interface on your Linux box.

  ddns-update-style interim
  ignore client-updates

  subnet netmask {

    # The range of IP addresses the server
    # will issue to DHCP enabled PC clients
    # booting up on the network


    # Set the amount of time in seconds that

# a client may keep the IP address

default-lease-time 86400;
max-lease-time 86400;

# Set the default gateway to be used by
# the PC clients

option routers;

# Don't forward DHCP requests from this
# NIC interface to any other NIC
# interfaces

option ip-forwarding off;

# Set the broadcast address and subnet mask
# to be used by the DHCP clients

option broadcast-address;
option subnet-mask;

# Set the DNS server to be used by the
# DHCP clients

option domain-name-servers;

# Set the NTP server to be used by the
# DHCP clients

option nntp-server;

# If you specify a WINS server for your Windows clients,
# you need to include the following option in the dhcpd.conf file:

option netbios-name-servers;

# You can also assign specific IP addresses based on the clients'
# ethernet MAC address as follows (Host's name is "laser-printer":

host laser-printer {

         hardware ethernet 08:00:2b:4c:59:23;
   # List an unused interface here
   subnet netmask {

There are many more options statements you can use to configure DHCP. These include
telling the DHCP clients where to go for services such as finger and IRC. Check the
dhcp-options man page after you do your install:

         [root@bigboy tmp]# man dhcp-options

Note: The host statement seen in the sample dhcpd.conf file can be very useful. Some
devices such as network printers default to getting their IP addresses using DHCP, but
users need to access them by a fixed IP address to print their documents. This statement
can be used to always provide specific IP address to DHCP queries from a predefined a
NIC MAC address. This can help to reduce systems administration overhead.

How to Get DHCP Started:-

To get DHCP started:

1. Some older Fedora/RedHat versions of the DHCP server will fail unless there is an
existing dhcpd.leases file. Use the command touch /var/lib/dhcp/dhcpd.leases to create
the file if it does not exist.

         [root@bigboy tmp]# touch /var/lib/dhcp/dhcpd.leases

2. Use the chkconfig command to get DHCP configured to start at boot:

         [root@bigboy tmp]# chkconfig dhcpd on

 3. Use the service command to instruct the /etc/init.d/dhcpd script to start/stop/restart
     DHCP after booting

         [root@bigboy tmp]# service dhcpd start

     [root@bigboy tmp]# service dhcpd stop
     [root@bigboy tmp]# service dhcpd restart

4. Remember to restart the DHCP process every time you make a change to the conf
    file for the changes to take effect on the running process. You also can test whether
    the DHCP process is running with the following command; you should get a
    response of plain old process ID numbers:

     [root@bigboy tmp]# pgrep dhcpd

5. Finally, always remember to set your PC to get its IP address via DHCP.

Diskless Environments:-
Some networks require multiple systems with the same configuration. They also require
that these systems be easy to reboot, upgrade, and manage. One solution is to use a
diskless environment in which most of the operating system, which can be read-only, is
shared from a central server between the clients. The individual clients have their own
directories on the central server for the rest of the operating system, which must be
read/write. Each time the client boots, it mounts most of the OS from the NFS server as
read-only and another directory as read-write. Each client has its own read-write
directory so that one client can not affect the others.The following steps are necessary to
configure Red Hat Enterprise Linux to run on a diskless client:
       1. Install Red Hat Enterprise Linux on a system so that the files can be copied to
          the NFS server. Any software to be used on the clients must be installed on
          this system and the busybox-anaconda package must be installed.
       2. Create a directory on the NFS server to contain the diskless environment such
          as /diskless/i386/RHEL4-AS/. For example:

      mkdir -p /diskless/i386/RHEL4-AS/

       3. This directory is referred to as the diskless directory.
       4. Create a subdirectory of this directory named root/:

      mkdir -p /diskless/i386/RHEL4-AS/root/

       5. Copy Red Hat Enterprise Linux from the client system to the server using
          rsync. For example:

      rsync -a -e ssh /diskless/i386/RHEL4-AS/root/

       6. The length of this operation depends on the network connection speed as well
          as the size of the file system on the installed system. Depending on these
          factors, this operation may take a while.
       7. Start the tftp server
       8. Configure the DHCP server
       9. Finish creating the diskless environments
       10. Configure the diskless clients
       11. Configure each diskless client to boot via PXE and boot them.

Start the tftp Server:-
On the DHCP server, verify that the tftp-server package is installed with the command
rpm -q tftp-server. If it is not installed, install it via Red Hat Network or the Red Hat
Enterprise Linux CD-ROMs. For more information on installing RPM packages.

tftp is an xinetd-based service; start it with the following commands:

/sbin/chkconfig --level 345 xinetd on
/sbin/chkconfig --level 345 tftp on

These commands configure the tftp and xinetd services to immediately turn on and
also configure them to start at boot time in runlevels 3, 4, and 5.

Configuring the DHCP Server:-
If a DHCP server does not already exist on the network, configure one. for details. Make
sure the configuration file contains the following so that PXE booting is enabled for
systems which support it:

Subnet network

  default-lease-time 21600;
  max-lease-time 43200;
host host1
  hardware Ethernet 00:0e:92:3W:9k:H6

allow booting;
allow bootp;
class "pxeclients" {
  match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
  next-server <server-ip>;
  filename "linux-install/pxelinux.0";

where <next-server> option should be replaced with the IP address of the tftp server.

Configuring the NFS Server:-
The shared read-only part of the operating system is shared via NFS.

Configure NFS to export the root/ and snapshot/ directories by adding them to
/etc/exports. For example:

/diskless/i386/RHEL4-AS/root/ *(ro,sync,no_root_squash)
/diskless/i386/RHEL4-AS/snapshot/ *(rw,sync,no_root_squash)

Replace * with one of the hostname formats .Make the hostname declaration as specific
as possible, so unwanted systems can not access the NFS mount.

If the NFS service is not running, start it:

service nfs start

If the NFS service is already running, reload the configuration file:

service nfs reload

Finish Configuring the Diskless Environment:-
To use the graphical version of the Network Booting Tool, you must be running the X
Window System, have root privileges, and have the system-config-netboot RPM
package installed. To start the Network Booting Tool from the desktop, go to
Applications (the main menu on the panel) => System Settings => Server Settings =>
Network Booting Service. Or, type the command system-config-netboot at a shell
prompt (for example, in an XTerm or a GNOME terminal).

If starting the Network Booting Tool for the first time, select Diskless from the First Time
Druid. Otherwise, select Configure => Diskless from the pull-down menu, and then click

A wizard appears to step you through the process:

       1. Click Forward on the first page.
       2. On the Diskless Identifier page, enter a Name and Description for the diskless
          environment. Click Forward.
       3. Enter the IP address or domain name of the NFS server configured as well as
          the directory exported as the diskless environment. Click Forward .
       4. The kernel versions installed in the diskless environment are listed. Select the
          kernel version to boot on the diskless system.
       5. Click Apply to finish the configuration.

After clicking Apply, the diskless kernel and image file are created based on the kernel
selected. They are copied to the PXE boot directory /tftpboot/linux-install/<os-
identifier>/. The directory snapshot/ is created in the same directory as the root/
directory (for example, /diskless/i386/RHEL4-AS/snapshot/) with a file called
files in it. This file contains a list of files and directories that must be read/write for
each diskless system. Do not modify this file. If additional entries must be added to the
list, create a files.custom file in the same directory as the files file, and add each
additional file or directory on a separate line.

Adding Hosts:-
Each diskless client must have its own snapshot directory on the NFS server that is used
as its read/write file system. The Network Booting Tool can be used to create these
snapshot directories.

After completing the steps in Finish Configuring the Diskless Environment, a window
appears to allow hosts to be added for the diskless environment. Click the New button. In
the dialog shown in Figure, provide the following information:

          Hostname or IP Address/Subnet — Specify the hostname or IP address of a
           system to add it as a host for the diskless environment. Enter a subnet to
           specify a group of systems.
          Operating System — Select the diskless environment for the host or subnet of
          Serial Console — Select this checkbox to perform a serial installation.
          Snapshot name — Provide a subdirectory name to be used to store all of the
           read/write content for the host.
          Ethernet — Select the Ethernet device on the host to use to mount the diskless
           environment. If the host only has one Ethernet card, select eth0.

Ignore the Kickstart File option. It is only used for PXE installations.

Figure:- Add Diskless Host

In the existing snapshot/ directory in the diskless directory, a subdirectory is created
with the Snapshot name specified as the file name. Then, all of the files listed in
snapshot/files and snapshot/files.custom are copied copy from the root/
directory to this new directory.

Booting the Hosts:-
Consult the documentation for your PXE card to configure the host to boot via PXE.

When the diskless client boots, it mounts the remote root/ directory in the diskless
directory as read-only. It also mounts its individual snapshot directory as read/write. Then
it mounts all the files and directories in the files and files.custom files using the
mount -o bind over the read-only diskless directory to allow applications to write to the
root directory of the diskless environment if they need to.

Diskless booting operation overview:-

Obtaining IP parameters:-
One could wonder how a station may boot over an IP network if it doesn't even know its
own IP address. In fact, three protocols enable the client to obtain this information and
some additional configuration parameters:

      RARP: this is the simplest of these protocols. However I guess it does not enable
       the server to specify how the client should download the kernel, so we won't use it
       (In fact, there is a convention that uses the IP address of the workstation as
       filename, e.g. a client getting the address by RARP might ask for
       /tftpboot/ by TFTP, as the linux kernel does. The filename
       might also be the hex form of the IP address, this is implementation dependant,
       and is not mandatory.).
      BOOTP: this protocol allows a server to provide the client (identified by its
       hardware MAC address) with much information, in particular its IP address,
       subnet mask, broadcast address, network address, gateway address, host name,
       and kernel loading path. This is the one we will use.
      DHCP: this is an extension of BOOTP.


Loading the kernel:-
When the client has got its IP parameters, if the kernel is not on a local support (like a
floppy, a cdrom, or a hard drive), the client will start to download it via TFTP. Its
location is given by the BOOTP/DHCP server. A server (not necessarily the
BOOTP/DHCP server) will also have to run a TFTP daemon for non local kernels. The
kernel one obtains after compilation can not be used "as is" for BOOTP/DHCP operation,
its binary image has to be modified with the mknbi utility (and then modified again with
the imggen utility if you use LanWorks EPROMs). The mknbi utility should also be used
to modify kernels that will be written in a ROM.

Mounting the root file system:-
After the kernel has started, it will try to mount its root filesystem. The location of this
filesystem is also obtained through BOOTP/DHCP, and it is mounted via NFS. It means a
client may use BOOTP twice for booting: the first time to get its kernel, and the second
time to learn the location of the root filesystem (which may be on a third server).

Another solution is to use a ramdisk as root filesystem. In this case, the ramdisk image is
obtained with the kernel via TFTP.

Terminating the boot process:-
When the root filesystem is mounted, you can start breathing: you can at least use your
swiss army knife with its sh, sed, and awk blades. In fact, you will have to customize the
initialization scripts of the client's filesystem: for instance, you will have to remove all
hard drive, floppy or cdrom related stuff from /etc/fstab (when your stations are not
equipped with these devices), you may also have to inhibit swap partitions activation
(note there is a way to swap over NFS or network block devices). You also will have to
automagically generate all network configuration files at boot time if several clients use
the same remote root filesystem.

Building the kernel:-
First of all, build a kernel for the clients. I suggest you build it on the server, this will be
useful later for modules installation. Use a zImage to reduce its size. Include everything
you need, but try to use as many modules as possible, because many BOOTP client
implementations are unable to load very large kernels (at least on intel x86 architectures).
Also include iramdisk support, NFS protocol support, root filesystem on NFS support,
support for your NIC, kernel level IP autoconfiguration via BOOTP; do not use modules
for these! Then, if you plan to use the same remote root filesystem for several clients, add
support for ext2fs or some other filesystem and ramdisks (16 Megabytes ramdisks will do
fine on most systems). You can then modify the kernel arguments as usual (see the
BootPrompt-HOWTO for information on this topic), but you will have another
opportunity to modify kernel arguments later.

Then, if you plan to use BOOTP, copy the kernel zImage on the server. We will assume it
resides in /tftpboot, its name is zImage, the name of the image you want to create from
this zImage for BOOTP operation is kernel, and the nfs root filesystem will reside in

Issue the following commands on the server (the mknbi package should be installed):

  # cd /tftpboot
  # chmod 0555 zImage
  # chown root:root zImage
  # mknbi-linux zImage --output=kernel --rootdir=/nfsroot

If you are using LanWorks EPROMs, also issue the following commands (you need the
imggen utility):

  # mv -f kernel tmpkernel
  # imggen -a tmpkernel kernel
  # rm -f tmpkernel

Your kernel is ready for BOOTP/DHCP/ROM operation. You of course don't need to do
this if you plan to use a local drive.

When the root file system is on a ram disk:-
It is possible to use a ramdisk for the root filesystem. In this case, the command used to
modify the kernel's binary image is slightly different. If you choose to do so, you have to
enable support for initial ramdisk (initrd), and you probably don't need NFS support, or
you probably can compile it as a module.

Its time to give an overview of what happens when you use initrd. The full
documentation for this is in your kernel source tree, in the Documentation/initrd.txt
file. I have to warn you I did never try this :).

When initrd is enabled, the boot loader first loads the kernel and the inital ramdisk into
memory. Then, the ramdisk is mounted read-write as root filesystem. The kernel looks
for a /linuxrc file (a binary executable or a script beginning with #!). When /linuxrc
terminates, the traditionnal root filesystem is mounted as /, and the usual boot sequence
is performed. So, if you want to run your box entirely from ramdisk, you just have to
create a link from /linuxrc to /sbin/init, or to write there a shell script to perform
any action you like, and then shutdown the computer.

After the kernel has been compiled, you have to build a root filesystem for your
installation. This is explained in the "Clients setup, creation of the root filesystem"
section. I will assume here that this is already done and that the root filesystem for your

clients temporarily resides in /tmp/rootfs. You now have to create a ramdisk image. A
simple way to do so is the following:

      Make sure the computer you are working on has support for ramdisks and has
       such a device (/dev/ram0).
      Create an empty filesystem with the appropriate size on this ramdisk:

                      # mke2fs -m0 /dev/ram0 300

      Mount it somewhere:

                      # mount -t ext2 /dev/ram0 /mnt

      Copy what you need for your new root filesystem, and create your future
       /linuxrc if you did not create it in /tmp/rootfs/linuxrc:

                      # cp -a /tmp/rootfs/* /mnt

      Unmount the ramdisk:

                      # umount /mnt

      Save the ramdisk image to some file and free it:

                      # dd if=/dev/ram0 of=initrd bs=1024 count=300
                      # freeramdisk /dev/ram0

What was toled above about LanWorks PROMs is also true if you use initrd.

Then, you have to modify the kernel image, as was told above, with the mknbi-linux
utility. Its invocation will slightly differ from the above, though (I will assume your just
compiled zImage resides in /tftpboot/zImage and your initial ramdisk image resides in

   # cd /tftpboot
   # chmod 0555 zImage
   # chown root:root zImage
          # rdev zImage /dev/ram0
   # mknbi-linux zImage --output=kernel --rootdir=/dev/ram0 /tmp/initrd

     3.   RHCE Training Book 1
     4.   RHCE Training Book 2
     5.   RHCE Training Book 3


To top