Remote Linux Explained

The basics in booting a workstation remotely, the requirements on the network boot kernel and how to configure remote Linux for various applications.

What Is My IP Information? (RARP, BOOTP and
DHCP)

When the client boots over the network, whether using PXE or
from diskette, it will broadcast its MAC address over the LAN,
looking for a server that is conditioned to provide the client's IP
information. This is so the client can configure its Ethernet
adaptor with the correct IP information and continue the rest of
the boot conversation using TCP/IP. There are several methods of
providing the IP information to a broadcasting node: RARP, BOOTP
and DHCP.

RARP

RARP (Reverse Address Resolution Protocol) is the method by
which an adaptor's unique 48-bit Ethernet address (its MAC) is
associated with an IP address. When a client attempts to boot
remotely, it will broadcast its MAC address to all workstations on
the physical network. One or more of the workstations will be
running the RARPD dæmon, which reads /etc/ethers to make the
association between the 48-bit Ethernet address and an IP address
and responds to the broadcasting client with its shiny new IP
address. After receiving an IP address, the client should initiate
a TFTP (Trivial File Transfer Protocol) request to get its image
(more about that later). The biggest drawbacks to RARP are that it
works only on the local physical network (it's not rebroadcast),
and it supplies only a small bit of information, the client's IP
address.

BOOTP

BOOTP (Bootstrap Protocol) is a distinct improvement over
RARP in that it provides gateway support (booting over a router)
and provides far more information to the booting client. In
addition to the client's IP address, BOOTP provides the address of
the gateway (router), the address of the server, the subnet mask
and the boot file (the bootable image for the client). Note that
there can be one, and only one, IP address assigned to a particular
hardware address.

The biggest drawback to BOOTP is that it assigns IP addresses
to MAC addresses in a one-to-one relationship—a specific MAC
address always will be assigned the same IP address. If you think
about the requirements presented by a mobile office and traveling
laptops, this one-to-one relationship proves to be somewhat
limiting. In the mobile office scenario, users travel with their
laptops and need to log in to a central server only occasionally,
to pick up mail or whatever. The rest of the time, their IP address
remains unassigned, which is a terrible waste of an IP address. The
problem of underused IP addresses is addressed nicely by
DHCP.

DHCP

DHCP (Dynamic Host Configuration Protocol) is a logical
successor to BOOTP. In fact, BOOTP is considered somewhat obsolete
and has been largely replaced by DHCP. One reason DHCP has
surpassed BOOTP in popularity is that DHCP supports dynamic address
range assignment, while BOOTP only supports static IP assignment (a
single MAC is always assigned the same IP address). The dynamic IP
assignment facility of DHCP allows IP addresses to be reused among
many nodes. In the mobile office scenario, a node connects to its
network and broadcasts its MAC. The server, running the dhcpd
dæmon, has allocated a range of IP addresses for mobile nodes
and simply assigns the next IP address in the range to the
broadcasting node. DHCP also manages the longevity of the
IP-address assignment via a DHCP leases file.

The options to DHCP are myriad and beyond the scope of this
article. For further investigation, consult The DHCP
Handbook by Ralph Droms and Ted Lemon (Pearson Higher
Education, 1999).

Transferring the Kernel and Network
Loader

After getting its IP information and configuring the adaptor
for TCP/IP, the node BIOS typically requests an image over the
network. This clear division of IP assignment and image serving is
deliberate; it allows for IP assignment and image serving to be
potentially served by different machines. TFTP (Trivial File
Transfer Protocol) is just the right tool to transfer the image
from server to client, since TFTP, unlike its heavier-weight cousin
FTP (File Transfer Protocol), does not require a user to log in to
get a file. The primitive security built into TFTP is that, by
default, TFTP only permits transfer of files from the server's
/tftpboot directory. Since this security scheme is fairly well
known among system administrators, only public files are put in
/tftpboot. In the latest version of tftp-hpa, file-access security
was added as well.

Notice that we've been talking about transferring an
image—this is because the image can be either a tagged kernel
(Etherboot) or a network loader (PXE). If you use Etherboot, the
diskette boot method, then BOOTP or DHCP should point to a tagged
kernel. If you use true PXE, then BOOTP or DHCP should point to a
network loader. In the PXE case, the network loader is loaded into
memory and then brings over an untagged kernel via TFTP. To use
PXE, the TFTP server must support the “tsize” TFTP option (RFC
1784, RFC 2349). tftp-hpa, by H.
Peter Anvin, supports this option and can be obtained at
www.kernel.org/pub/software/network/tftp.

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.