LPI Linux Certification in a Nutshell (60 page)
Read LPI Linux Certification in a Nutshell Online
Authors: Adam Haeder; Stephen Addison Schneiter; Bruno Gomes Pessanha; James Stanger
Tags: #Reference:Computers
ping
pinghostname
The
ping
command is used to send
an ICMP echo request to a host and report on how long it takes to
receive a corresponding ICMP echo reply. Much as sonar systems send
a pulse (or “ping”) to a target and measure transit time,
ping
sends a network packet to test the
availability of a network node. This technique is often used as a
basic debugging technique when network problems arise.
- -c
count Send and receive
countpackets.- -q
Quiet output. Display only summary lines when
ping
starts and finishes.
Ping a remote host and terminate using Ctrl-C after five
packets are transmitted:
$ping lpi.orgPING lpi.org (24.215.7.162) 56(84) bytes of data.
64 bytes from clark.lpi.org (24.215.7.162): icmp_seq=1 ttl=52 time=68.2 ms
64 bytes from clark.lpi.org (24.215.7.162): icmp_seq=2 ttl=52 time=65.8 ms
64 bytes from clark.lpi.org (24.215.7.162): icmp_seq=3 ttl=52 time=63.2 ms
64 bytes from clark.lpi.org (24.215.7.162): icmp_seq=4 ttl=52 time=65.8 ms
64 bytes from clark.lpi.org (24.215.7.162): icmp_seq=5 ttl=52 time=65.8 ms
64 bytes from clark.lpi.org (24.215.7.162): icmp_seq=6 ttl=52 time=63.6 ms
64 bytes from clark.lpi.org (24.215.7.162): icmp_seq=7 ttl=52 time=56.8 ms
--- lpi.org ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6016ms
rtt min/avg/max/mdev = 56.894/64.230/68.202/3.374 ms
telnet
telnet [host] [port]
Establish a connection to ahost(either a system name or IP address)
usingport. If a specific port is
omitted, the default port of 23 is assumed. Ifhostis omitted,
telnet
goes into an interactive mode similar to
FTP.
traceroute
traceroutehostname
Attempt to display the route over which packets must
travel to reach a destinationhostname.
It is included here because it is mentioned in this Objective, but
Objective 3 also requires
traceroute
. See
Chapter 21
for more
information.
whois
whoistarget[@server]
Pronounced, “who is,”
whois
is a
query/response protocol used to determine information about Internet
resources. The information returned includes contact information,
domain names, IP addresses, and DNS servers. Note that many websites
are available for
whois
searches as well,
particularly for checking on domain name availability.
$whois lpi.orgNOTICE: Access to .ORG WHOIS information is provided to assist persons in
determining the contents of a domain name registration record in the
Public Interest Registry registry database. The data in this record is provided
by Public Interest Registry for informational purposes only, and Public Interest
Registry does not guarantee its accuracy. This service is intended only for
query-based access. You agree that you will use this data only for lawful
purposes and that, under no circumstances will you use this data to:
(a) allow, enable, or otherwise support the transmission by e-mail, telephone,
or facsimile of mass unsolicited, commercial advertising or solicitations to
entities other than the data recipient's own existing customers; or (b) enable
high volume, automated, electronic processes that send queries or data to
the systems of Registry Operator or any ICANN-Accredited Registrar,
except as reasonably necessary to register domain names or modify existing
registrations. All rights reserved. Public Interest Registry reserves the right
to modify these terms at any time. By submitting this query, you agree
to abide by this policy.
Domain ID:D3725290-LROR
Domain Name:LPI.ORG
Created On:18-Feb-1999 05:00:00 UTC
Last Updated On:31-Oct-2008 17:00:45 UTC
Expiration Date:18-Feb-2011 05:00:00 UTC
Sponsoring Registrar:Tucows Inc. (R11-LROR)
Status:CLIENT TRANSFER PROHIBITED
Status:CLIENT UPDATE PROHIBITED
Registrant ID:tuIqxUrdqeRMHH1m
Registrant Name:DNS Admin
Registrant Organization:Linux Professional Institute Inc.
Registrant Street1:161 Bay Street, 27th Floor
Registrant Street2:
Registrant Street3:
Registrant City:Toronto
Registrant State/Province:ON
Registrant Postal Code:M5J2S1
Registrant Country:CA
Registrant Phone:+1.9163576625
Registrant Phone Ext.:
Registrant FAX:
Registrant FAX Ext.:
Registrant Email:[email protected]
Admin ID:tujWL5NRmQ4MqjwW
Admin Name:DNS Admin
Admin Organization:Linux Professional Institute Inc.
Admin Street1:161 Bay Street, 27th Floor
Admin Street2:
Admin Street3:
Admin City:Toronto
Admin State/Province:ON
Admin Postal Code:M5J2S1
Admin Country:CA
Admin Phone:+1.9163576625
Admin Phone Ext.:
Admin FAX:
Admin FAX Ext.:
Admin Email:[email protected]
Tech ID:tursNOD6OBDmUsSl
Tech Name:DNS Admin
Tech Organization:Linux Professional Institute Inc.
Tech Street1:161 Bay Street, 27th Floor
Tech Street2:
Tech Street3:
Tech City:Toronto
Tech State/Province:ON
Tech Postal Code:M5J2S1
Tech Country:CA
Tech Phone:+1.9163576625
Tech Phone Ext.:
Tech FAX:
Tech FAX Ext.:
Tech Email:[email protected]
Name Server:NS.STARNIX.COM
Name Server:SERVER1.MOONGROUP.COM
Network Configuration (Topics 109.2 and 109.4)
A Linux system that is not connected to a network is a rare sight.
Configuring a system for network access is one of the first things done
within the normal installation process. This chapter covers the following
Objectives:
- Objective 2: Basic Network
Configuration Candidates should be able to view, change, and verify
configuration settings and operational status for various network
interfaces. This Objective includes manual and automatic configuration
of interfaces and routing tables. This would include steps to add,
start, stop, restart, delete, or reconfigure network interfaces by
modifying the appropriate configuration files. It also means to
change, view, or configure the routing table and to correct an
improperly set default route manually. Candidates should be able to
configure Linux as a DHCP client and a TCP/IP host and to debug
problems associated with the network configuration. Weight: 4.- Objective 4: Configuring Client Side
DNS Candidates should be able to configure DNS on a client host.
Weight: 2.
Configuring
Client Side DNS
Linux distributions offer various automation and startup
techniques for networks, but most of the essential commands and concepts
are not distribution-dependent. The exam tests fundamental concepts and
their relationships to one another as well as to system problems. These
Objectives cover the configuration of IPv4 TCP/IP on common network
interfaces, such as Ethernet.
On the Exam
One of the reasons Linux is so popular as a server operating
system is its ability to operate on many different kinds of networks
utilizing many different kinds of interfaces. Protocols such as
AppleTalk, IPX, and even NetBEUI are available to Linux machines, as
well as interfaces such as Token Ring, FDDI, and many others. However,
the LPI exams focus on the TCP/IP protocol on Ethernet interfaces, so
in-depth knowledge of the other networking options is not necessary in
order to become LPI certified.
A computer must contain at least one
network
interface
to be considered part of a network. The network
interface provides a communications link between the computer and
external network hardware. This could mean typical network adapters such
as Ethernet or Token Ring, point-to-point dial-up connections, parallel
ports, wireless, or other networking forms.
The following files contain important information about
your system’s network configuration:
- /etc/hosts
This file contains simple mappings between IP addresses
and names and is used for name resolution. For very small
private networks,
/etc/hosts
may be
sufficient for basic
name resolution. For example, this file associates
the local address 192.168.1.30 with the system
smp
and also with
smp.mydomain.com
:127.0.0.1 localhost localhost.localdomain
192.168.1.1 gate
192.168.1.30 smp smp.mydomain.com- /etc/nsswitch.conf
This file controls the sources used by various system
library lookup functions, such as name resolution. It allows the
administrator to configure the use of traditional local files
(
/etc/hosts
,
/etc/passwd
), an NIS server, or DNS.
nsswitch.conf
directly affects network
configuration (among other things) by controlling how hostnames
and other network parameters are resolved. For example, this
fragment shows that local files are used for password, shadow
password, group, and hostname resolution; for hostnames, DNS is
used if a search of local files doesn’t yield a result:passwd: files nisplus nis
shadow: files nisplus nis
group: files nisplus nis
hosts: files dns nisplus nisFor more information, view the manpage with
man
5 nsswitch
. The
nsswitch.conf
file supersedes
host.conf
. In the majority
of setups, this file does not need to be modified, as the
defaults are usually sufficient.- /etc/host.conf
This file controls name resolution sources for
pre-
glibc2
systems. It should
contain
:order hosts,bind
multi onThis configuration has the resolver checking
/etc/hosts
first for name resolution, then
DNS.multi onenables
multiple IP addresses for hosts. Newer Linux system libraries
use
/etc/nsswitch.conf
instead of
/etc/host.conf
.- /etc/resolv.conf
This file controls the client-side portions of the DNS
system, which is implemented in system library functions used by
all programs to resolve system names. In particular,
/etc/resolv.conf
specifies the IP addresses
of DNS servers. For example:nameserver 192.168.1.5
nameserver 192.168.250.2Additional parameters are also available. For more
information, view the manpage with
man 5
resolver
.- /etc/networks
Like
/etc/hosts
, this file sets up
equivalence between addresses and names, but here the addresses
represent entire networks (and thus must be valid network
addresses, ending in 0). The result is that you can use a
symbolic name to refer to a network just as you would a specific
host. This may be convenient (though not required) in NFS or
routing configuration, for example, and will be shown in
commands such as
netstat
. For
example:loopback 127.0.0.0
mylan 192.168.1.0It’s not unusual for
/etc/networks
to
be left blank.
You’ll notice most of the previous configuration files concern
themselves with mapping an IP address to aliases or names. This is not
required for most network-enabled applications to work, as the
operating system and network-enabled applications are really only
concerned with the IP address for this level of data communication.
The name lookups are there for us humans, who find it easier to
remember names rather than numbers. Here is an example of what is
going on “behind the scenes” when a web browser requests a web page
from a remote server:
A user types
http://www.oreilly.com
into the browser
address bar and hits Enter.The system needs to resolve this hostname to an IP address
in order to make the request. The file
/etc/nsswitch.conf
(
/etc/host.conf
in pre-glibc2 systems) is
consulted to determine what subsystems to ask and in what order to
resolve this hostname. The default entry for hosts in
/etc/nsswitch.conf
is usually:hosts: files dns
This tells the system to first look in files
(
/etc/hosts
) and then query DNS.If there is an entry in the file
/etc/hosts
for
www.oreilly.com
, that IP address will
be used to make this HTTP request. If not, then the second option
is to query DNS.The file
/etc/resolv.conf
is consulted
to determine the primary DNS to query. A DNS request is made to
the primary DNS server. If a response is received (in the form of
an IP address), that IP address is used to make the HTTP request.
If a response is not received (either because the DNS server did
not have an entry for that hostname or the DNS server did not
respond to the request), then the next name server listed in
/etc/resolv.conf
is queried. This process
repeats until all name servers have been queried.If all attempts at name resolution fail, the web browser
will return an error.
As you can see, something as simple to the end user as typing a
hostname into a web browser requires a number of steps behind the
scenes. It’s important to understand these steps and the order in
which they occur for troubleshooting situations. It’s an all too
common occurrence for an end user to report, “The network is down!”
when it’s really just a matter of a bad entry in
/etc/hosts
or a misconfigured DNS server.
On the Exam
Be familiar with all the files listed in this section; each
contains specific information important for network setup. Watch for
questions on
/etc/host.conf
, which is not used
in newer
glibc2
libraries.
The commands listed in this section are used to
establish, monitor, and troubleshoot a network configuration under
Linux.
The Dynamic Host Configuration Protocol (DHCP) is a
protocol extension of the BOOTP protocol, which provides automated IP
address assignment (among other things) to client systems on a network.
It handles IP address allocation in one of three ways:
- Dynamic allocation
In this scheme, a DHCP server maintains a preset
list of IP addresses designated by the system administrator. IP
addresses are assigned as clients request an address from the
available addresses in the pool. The address can be used, or
leased
, for a limited period of time. The
client must continually renegotiate the lease with the server to
maintain use of the address beyond the allotted period. When the
lease expires, the IP address is placed back into the pool for use
by other requesting clients and a new IP address is
assigned.- Manual allocation
The system administrator may wish to designate
specific IP addresses to specific network interfaces (for example,
to an Ethernet MAC address) while still using DHCP to deliver the
address to the client. This allows the convenience of automated
address setup and assures the same address each time.- Automatic allocation
This method assigns a permanent address to a client.
Typically DHCP is used to assign a temporary address (either
dynamically or statically assigned) to a client, but a DHCP server
can allow an infinite lease time.
DHCP can be configured to assign not only the IP address to the
client but also such things as name servers, gateways, and
architecture-specific parameters. Here’s an overview of how it
works:
A DHCP client sends a broadcast message to the network to
discover a DHCP server.One or more DHCP servers respond to the request via their own
broadcast messages, offering an IP address to the client.The client chooses one of the servers and broadcasts an
acknowledgment, requesting the chosen server’s identity.The selected server logs the connection with the client and
responds with an acknowledgment and possibly additional information.
All of the other servers do nothing, because the client declined
their offer.
Because DHCP communications are initiated using
broadcasts, they are normally confined to a single subnet. To
accommodate DHCP clients and servers separated by one or more routers,
a DHCP
relay
system can be established on subnets
without DHCP servers. A relay system listens for DHCP client
broadcasts, forwards them to a DHCP server on another subnet, and
returns DHCP traffic back to the client. This configuration can
centralize DHCP management in a large routed environment.
As already mentioned, when a client receives a
dynamically assigned IP address from a DHCP server, the address is
said to be
leased
for a finite duration. The
length of a DHCP lease is configurable by the system administrator and
typically lasts for one or more days. Shorter leases allow for faster
turnover of addresses and are useful when the number of available
addresses is small or when many transient systems (such as laptops)
are being served. Longer leases reduce DHCP activity, thus reducing
broadcast traffic on the network.
When a lease expires without being renegotiated by the client,
it as assumed that the client system is unavailable, and the address
is put back into the free pool of addresses. A lease may also be
terminated by a client that no longer needs the IP address, in which
case it is
released
. When this occurs, the DHCP
server immediately places the IP address back in the free pool.
The DHCP server process is called
dhcpd
. It is typically started at boot time and
listens for incoming DHCP request broadcasts.
dhcpd
can serve multiple subnets via multiple
interfaces, serving a different pool of IP addresses to each.
dhcpd
is configured using the text
configuration file
/etc/dhcpd.conf
, which
contains one or more subnet declarations. These are text lines of the
following form:
subnet network-address netmask subnet-mask {parameter...parameter......
}
Each subnet declaration encloses parameters for each subnet
between curly braces. Parameters include one or more ranges of IP
addresses to serve, lease times, and optional items such as gateways
(routers), DNS servers, and so forth. Each parameter line is
terminated with a semicolon. For example:
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.200 192.168.1.204;
default-lease-time 600;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.1;
option domain-name-servers 192.168.1.25;
}
In this example, the private class C network 192.168.1.0 is
served five IP addresses, 200 through 204. The default DHCP lease is
600 seconds (10 minutes). Options are also set for the subnet mask,
broadcast address, router (or gateway), and DNS server. For full
information on
dhcpd.conf
, see related manpages
for
dhcpd(8)
and
dhcpd.conf(5)
.
The preceding option lines are not required to create a minimal
DHCP setup that simply serves IP addresses. Details on the daemon
follow.