|
 |
|
| |
31.6 Configuring a Network Connection Manually
Manual configuration of the network software should always be the last
alternative. Using YaST is recommended. However, this background
information about the network configuration can also assist your work with
YaST.
All built-in network cards and hotplug network cards
(PCMCIA, USB, some PCI cards) are detected and configured via
hotplug.
The system sees a network card in two different ways:
first as a physical device and second
as an interface. The insertion or detection of a device triggers
a hotplug event. This hotplug event triggers the initialization
of the device with the script hwup.
When the network card is initialized as a new network interface,
the kernel generates another hotplug event that triggers the
setup of the interface with ifup.
The kernel numbers interface names according to the temporal
order of their registration. The initialization sequence is
decisive for the assignment of names. If one of several
network card fails, the numbering of all subsequently
initialized cards is shifted. For real hotpluggable
cards, the order in which the devices are connected is
what matters.
To achieve a flexible configuration, the configuration of the device
(hardware) and the interface has been separated and the mapping
of configurations to devices and interfaces is no longer managed
on the basis of the interface names. The device configurations
are located in /etc/sysconfig/hardware/hwcfg-*.
The interface configurations are located in
/etc/sysconfig/network/ifcfg-*. The names of the
configurations are assigned in such a way that they describe the
devices and interfaces with which they are associated. Because the
former mapping of drivers to interface name required
static interface names, this mapping can no longer
take place in /etc/modprobe.conf. In the new
concept, alias entries in this file would cause undesirable
side effects.
The configuration names—everything
after hwcfg- or
ifcfg-—can describe the devices by means of
the slot, a device-specific
ID, or the interface name. For example, the configuration name
for a PCI card could be bus-pci-0000:02:01.0
(PCI slot) or vpid-0x8086-0x1014-0x0549 (vendor
and product ID). The name of the associated interface could be
bus-pci-0000:02:01.0 or
wlan-id-00:05:4e:42:31:7a (MAC address).
To assign a certain network configuration to any card
of a certain type (of which only one is inserted at a time)
instead of a certain card, select less specific configuration
names. For example, bus-pcmcia would be
used for all PCMCIA cards. On the other hand, the names can
be limited by a preceding interface type. For example,
wlan-bus-usb would be assigned to WLAN
cards connected to a USB port.
The system always uses the configuration that best describes
an interface or the device providing the interface. The search
for the most suitable configuration is handled by
getcfg.
The output of getcfg delivers all information
that can be used for describing a device. Details regarding the
specification of configuration names are available in the manual
page of getcfg.
With the described method, a network interface is configured
with the correct configuration even if the network devices
are not always initialized in the same order.
However, the name of the interface
still depends on the initialization sequence. There are
two ways to ensure reliable access to the interface of
a certain network card:
-
getcfg-interface configuration
name
returns the name of the associated network interface. Therefore,
the configuration name, such as firewall,
dhcpd, routing, or
various virtual network interfaces (tunnels), can be entered in
some configuration files instead of the interface name, which is
not persistent.
-
Persistent interface names are assigned to each interface automatically.
You may adjust them to suit your needs. When creating interface names,
proceed as outlined in
/etc/udev/rules.d/30-net_persistent_names.rules.
However, the persistent name pname should not be
the same as the name that would automatically be assigned by the kernel.
Therefore, eth*, tr*,
wlan*, qeth*,
iucv*, and so on are not permitted. Instead,
use net* or descriptive names like
external, internal, or
dmz. Make sure that the same interface name is not used
twice. Allowed characters in interface names are restricted to
[a-zA-Z0-9]. A persistent name can only be assigned to
an interface immediately after its registration, which means that the
driver of the network card must be reloaded or
hwup device
description must be executed. The command
rcnetwork restart is not sufficient for
this purpose.
IMPORTANT: Using Persistent Interface Names
The use of persistent interface names has not
been tested in all areas. Therefore, some applications
may not be able to handle freely selected interface names.
ifup requires an existing interface, because it does not
initialize the hardware. The initialization of the hardware is handled by the
command hwup (executed by hotplug or
coldplug). When a device is initialized,
ifup is automatically executed for the new interface via
hotplug and the interface is set up if the start mode is
onboot, hotplug, or
auto and the network service was
started. Formerly, the command
ifup interfacename
triggered the hardware initialization. Now the procedure has been reversed.
First, a hardware component is initialized then all other actions follow. In
this way, a varying number of devices can always be configured in the best
way possible with an existing set of configurations.
Table 31-5 summarizes the most important
scripts involved in the network configuration.
Where possible, the scripts are distinguished
by hardware and interface.
Table 31-5 Manual Network Configuration Scripts
|
Hardware |
hw{up,down,status} |
The hw* scripts are executed by the hotplug
subsystem to initialize a device, undo the initialization, or
query the status of a device. More information is available in
the manual page of hwup.
|
|
Interface |
getcfg |
getcfg can be used to query the interface
name associated with a configuration name or a hardware description.
More information is available in the manual page of
getcfg.
|
|
Interface |
if{up,down,status} |
The if* scripts start existing network
interfaces or return the status of the specified
interface. More information
is available in the manual page of ifup.
|
More information about hotplug and persistent device names is available
in Section 25.0,
Dynamic Kernel Device Management with udev.
31.6.1 Configuration Files
This section provides an overview of the network configuration files and
explains their purpose and the format used.
/etc/syconfig/hardware/hwcfg-*
These files contain the hardware configurations
of network cards and other devices. They contain the
needed parameters, such as the kernel module, start
mode, and script associations. Refer to the manual
page of hwup for details. Regardless
of the existing hardware, the hwcfg-static-*
configurations are applied when coldplug is started.
/etc/sysconfig/network/ifcfg-*
These files contain the configurations
for network interface. They include information
such as the start mode and the IP address.
Possible parameters are described in the
manual page of ifup.
Additionally, all variables from the files
dhcp, wireless,
and config can be used in
the ifcfg-* files
if a general setting should be used for only
one interface.
IBM System z do not support USB.
The names of the interface files and network
aliases contain System z-specific elements
like qeth.
/etc/sysconfig/network/config, dhcp, wireless
The file config contains general settings for the
behavior of ifup, ifdown, and
ifstatus. dhcp contains settings
for DHCP and wireless for wireless LAN cards. The
variables in all three configuration files are commented and can also be
used in ifcfg-* files, where they are treated with
higher priority.
/etc/sysconfig/network/routes,ifroute-*
The static routing of TCP/IP packets is determined
here. All the static routes
required by the various system tasks can be entered in the
/etc/sysconfig/network/routes file: routes to a host,
routes to a host via a gateway, and routes to a network. For each interface
that needs individual routing, define an additional configuration file:
/etc/sysconfig/network/ifroute-*. Replace
* with the name of the interface. The entries in the
routing configuration files look like this:
# Destination Dummy/Gateway Netmask Device
#
127.0.0.0 0.0.0.0 255.255.255.0 lo
204.127.235.0 0.0.0.0 255.255.255.0 eth0
default 204.127.235.41 0.0.0.0 eth0
207.68.156.51 207.68.145.45 255.255.255.255 eth1
192.168.0.0 207.68.156.51 255.255.0.0 eth1
The route's destination is in the first column. This column may contain the
IP address of a network or host or, in the case of
reachable name servers, the fully qualified network or
hostname.
The second column contains the default gateway or a gateway through which a
host or network can be accessed.
The third column contains the netmask for networks or hosts behind a
gateway. For example, the mask is 255.255.255.255 for a
host behind a gateway.
The fourth column is only relevant for networks connected to the local host
such as loopback, Ethernet, ISDN, PPP, and dummy device. The device name
must be entered here.
An (optional) fifth column can be used to specify the type of a route.
Columns that are not needed should contain a minus sign
- to ensure that the parser correctly interprets the
command. For details, refer to the routes(5) man
page.
/etc/resolv.conf
The domain to which the host belongs is specified in this file (keyword
search). Also listed is the status of the name
server address to access (keyword nameserver).
Multiple domain names can be specified. When resolving a name that is not
fully qualified, an attempt is made to generate one by attaching the
individual search entries. Use multiple
name servers
by entering several lines, each beginning with
nameserver. Precede comments with
# signs. YaST enters the specified
name server in this file. Example 31-5
shows what /etc/resolv.conf could look like.
Example 31-5
/etc/resolv.conf
# Our domain
search example.com
#
# We use sun (192.168.0.20) as nameserver
nameserver 192.168.0.20
Some services, like pppd (wvdial),
ipppd (isdn), dhcp
(dhcpcd and dhclient),
pcmcia, and hotplug, modify
the file /etc/resolv.conf by means of the
script modify_resolvconf.
If the file /etc/resolv.conf has been temporarily
modified by this script, it contains a predefined comment giving
information about the service that modified it, the
location where the original file has been backed up, and how to
turn off the automatic modification mechanism.
If /etc/resolv.conf is modified several times, the
file includes modifications in a nested form. These can be reverted in
a clean way even if this reversal takes place in an order different from
the order in which modifications were introduced. Services that may need
this flexibility include isdn,
pcmcia, and
hotplug.
If a service was not terminated in a normal, clean way,
modify_resolvconf can be used to restore the original
file. Also, on system boot, a check is performed to see whether there
is an uncleaned, modified resolv.conf, for
example, after a
system crash, in which case the original (unmodified)
resolv.conf is restored.
YaST uses the command modify_resolvconf
check to find out whether
resolv.conf has been modified and subsequently
warns the user that changes will be lost after restoring the file.
Apart from this, YaST does not rely on
modify_resolvconf, which means that the impact of
changing resolv.conf through YaST is the same as
that of any manual change. In both cases, changes have
a permanent effect. Modifications requested by the
mentioned services are only temporary.
/etc/hosts
In this file, shown in Example 31-6, IP addresses
are assigned to hostnames. If no name server is implemented, all hosts to which an IP
connection will be set up must be listed here. For each host,
enter a line consisting of the IP address, the fully qualified hostname, and
the hostname into the file. The
IP address must be at the beginning of the line and the entries
separated by
blanks and tabs. Comments are always preceded by the #
sign.
Example 31-6
/etc/hosts
127.0.0.1 localhost
192.168.0.20 sun.example.com sun
192.168.0.0 earth.example.com earth
/etc/networks
Here, network names are converted to network addresses. The format is
similar to that of the hosts file, except the network
names precede the addresses. See Example 31-7.
Example 31-7
/etc/networks
loopback 127.0.0.0
localnet 192.168.0.0
/etc/host.conf
Name resolution—the translation of host and network names via the
resolver library—is controlled by this file.
This file is only used for programs linked to libc4 or libc5. For
current glibc programs, refer to the settings in
/etc/nsswitch.conf. A parameter must always stand
alone in its own line. Comments are preceded by a #
sign. Table 31-6 shows
the parameters available. A sample /etc/host.conf is shown in
Example 31-8.
Table 31-6 Parameters for /etc/host.conf
|
order hosts,
bind
|
Specifies in which order the services are accessed
for the name
resolution. Available arguments are (separated by blank spaces or
commas):
|
|
hosts: Searches the
/etc/hosts file |
|
bind: Accesses a name
server |
|
nis: Uses NIS
|
|
multi on/off
|
Defines if a host entered in
/etc/hosts can
have multiple IP addresses.
|
|
nospoof on spoofalert
on/off
|
These parameters influence the name server
spoofing, but, apart from that, do not exert any
influence on the network configuration.
|
|
trim domainname
|
The specified domain name is separated from the hostname after
hostname resolution (as long as the hostname includes the domain
name).
This option is useful if only names from the local domain are in the
/etc/hosts file, but should still be recognized
with the attached domain names.
|
Example 31-8
/etc/host.conf
# We have named running
order hosts bind
# Allow multiple addrs
multi on
/etc/nsswitch.conf
The introduction of the GNU C Library 2.0 was accompanied by the
introduction of the Name Service Switch (NSS). Refer
to the nsswitch.conf(5) man page and
The GNU C Library Reference Manual for details.
The order for queries is defined in the file
/etc/nsswitch.conf. A sample
nsswitch.conf is shown
in Example 31-9.
Comments are introduced by # signs.
In this example, the entry under the hosts
database means that a request is
sent to /etc/hosts (files)
via DNS (see Section 34.0,
The Domain Name System).
Example 31-9
/etc/nsswitch.conf
passwd: compat
group: compat
hosts: files dns
networks: files dns
services: db files
protocols: db files
netgroup: files
automount: files nis
The databases available over NSS are listed in
Table 31-7. In addition,
automount, bootparams,
netmasks, and publickey are
expected in the near future.
The configuration options for NSS databases are listed in
Table 31-8.
Table 31-7 Databases Available via /etc/nsswitch.conf
|
aliases
|
Mail aliases implemented by sendmail; see
man 5 aliases.
|
|
ethers
|
Ethernet addresses.
|
|
group
|
For user groups, used by getgrent. See
also the man page for group.
|
|
hosts
|
For hostnames and IP addresses, used by
gethostbyname and similar functions.
|
|
netgroup
|
Valid host and user lists in the network for the purpose of
controlling access permissions; see
the netgroup(5) man page.
|
|
networks
|
Network names and addresses, used by
getnetent. |
|
passwd
|
User passwords, used by getpwent; see
the passwd(5) man page.
|
|
protocols
|
Network protocols, used by getprotoent;
see the protocols(5) man page.
|
|
rpc
|
Remote procedure call names and
addresses, used by getrpcbyname
and similar functions.
|
|
services
|
Network services, used by getservent.
|
|
shadow
|
Shadow passwords of users, used by
getspnam;
see the shadow(5) man page.
|
Table 31-8 Configuration Options for NSS Databases
|
files |
directly access files, for example,
/etc/aliases
|
|
db
|
access via a database |
|
nis, nisplus
|
NIS, see also Section 36.0,
Using NIS |
|
dns
|
can only be used as an extension for hosts
and networks
|
|
compat
|
can only be used as an extension for passwd,
shadow, and group
|
/etc/nscd.conf
This file is used to configure nscd
(name service cache daemon). See
the nscd(8) and
nscd.conf(5) man pages.
By default, the system entries of passwd and
groups are cached by nscd.
This is important for the performance of
directory services, like NIS and LDAP,
because otherwise the network connection needs to be used
for every access to names or groups.
hosts is not cached by default, because the mechanism
in nscd to cache hosts makes the local
system unable to trust forward and reverse lookup checks. Instead
of asking nscd to cache names, set up
a caching DNS server.
If the caching for passwd
is activated, it usually takes about fifteen seconds
until a newly added local user is recognized. Reduce this waiting
time by restarting nscd
with the command
rcnscd restart.
/etc/HOSTNAME
This contains the hostname without the domain name attached. This
file is read
by several scripts while the machine is booting. It may only contain one
line in which the hostname is set.
31.6.2 Testing the Configuration
Before you write your configuration to the configuration files, you
can test it. To set up a test configuration, use the ip
command.
To test the connection, use the ping command.
Older configuration tools, ifconfig and
route, are also available.
The commands ip, ifconfig, and
route change the network configuration
directly without saving it in the configuration file. Unless you enter your
configuration
in the correct configuration files, the changed network configuration is
lost on reboot.
Configuring a Network Interface with ip
ip is a tool to show and configure routing, network
devices, policy routing, and tunnels. It was designed as a replacement for
the older tools ifconfig and route.
ip is very complex tool.
Its common syntax is
ip options
object command.
You can work with the following objects:
- link
-
This object represents a network device.
- address
-
This object represents the IP address of device.
- neighbour
-
This object represents a ARP or NDISC cache entry.
- route
-
This object represents the routing table entry.
- rule
-
This object represents a rule in the routing policy database.
- maddress
- This object represents a multicast address.
- mroute
-
This object represents a multicast routing cache entry.
- tunnel
-
This object represents a tunnel over IP.
If no command is given, the default command is used,
usually list.
Change the state of a device with the command
ip link set device_name command.
For example, to deactivate device eth0, enter
ip link seteth0 down.
To activate it again, use ip link seteth0
up.
After activating a device, you can configure it. To set the IP address, use
ip addr
add ip_address + dev
device_name. For example, to
set the address of the interface eth0 to 192.168.12.154/30 with standard
broadcast
(option brd), enter
ip addr add 192.168.12.154/30 brd + dev eth0.
To have a working connection, you must also configure the default gateway.
To set gateway for your system, enter
ip route get gateway_ip_address.
To translate one IP address to another, use nat:
ip route add
nat ip_address via other_ip_address.
To display all devices, use ip link ls.
To display only running interfaces, use ip link ls up.
To print interface statistics for a device, enter
ip -s link ls device_name.
To view addresses of your devices, enter ip addr.
In the output of the ip addr, also find information
about MAC addresses of your devices. To show all routes, use
ip route show.
For more information about using ip,
enter ip help or see the
ip(8) man page.
The help option is also available for all ip objects.
If, for example, you want to read help for
ip addr, enter
ip addr help.
Find the ip manual in
/usr/share/doc/packages/iproute2/ip-cref.pdf.
Testing a Connection with
ping
The ping command is the standard tool
for testing whether a TCP/IP connection works. It uses the ICMP protocol
to send a small data packet, ECHO_REQUEST datagram, to the destination
host,
requesting an immediate reply. If this works, ping
displays
a message to that effect, which indicates that the network link
is basically functioning.
ping does more than test only the function of the
connection
between two computers: it also provides some basic information about
the quality of the connection. In Example 31-10,
you can see an example of the ping output. The
second-to-last line contains information about number of transmitted
packets, packet loss,
and total time of ping running.
As the destination, you can use a hostname or IP address, for example,
ping example.com or
ping 130.57.5.75.
The program sends packets until you press
Ctrl + C.
If you only need to check the functionality of the connection, you can limit
the number of the packets with the -c option. For
example to
limit ping to three packets, enter
ping -c 3 192.168.0.
Example 31-10 Output of the Command ping
ping -c 3 example.com
PING example.com (130.57.5.75) 56(84) bytes of data.
64 bytes from example.com (130.57.5.75): icmp_seq=1 ttl=49 time=188 ms
64 bytes from example.com (130.57.5.75): icmp_seq=2 ttl=49 time=184 ms
64 bytes from example.com (130.57.5.75): icmp_seq=3 ttl=49 time=183 ms
--- example.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2007ms
rtt min/avg/max/mdev = 183.417/185.447/188.259/2.052 ms
The default interval between two packets is one second. To change the interval,
ping provides option -i. For example to
increase ping interval to ten seconds, enter
ping -i 10 192.168.0.
In a system with multiple network devices, it is sometimes useful to send
the ping
through a specific interface address. To do so, use the -I
option with the name of the
selected device, for example,
ping -I wlan1 192.168.0.
For more options and information about using ping,
enter ping -h or see the
ping (8) man page.
Configuring the Network with ifconfig
ifconfig is a traditional network configuration
tool. In contrast to ip,
you can use it only for interface configuration. If you want to configure
routing, use route.
NOTE: ifconfig and ip
The program ifconfig is obsolete. Use ip instead.
Without arguments, ifconfig displays the status of the currently active
interfaces.
As you can see in Example 31-11, ifconfig
has
very well-arranged and detailed output. The output also contains information
about the MAC address of your device, the value of HWaddr,
in the first line.
Example 31-11 Output of the ifconfig Command
eth0 Link encap:Ethernet HWaddr 00:08:74:98:ED:51
inet6 addr: fe80::208:74ff:fe98:ed51/64 Scope:Link
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:634735 errors:0 dropped:0 overruns:4 frame:0
TX packets:154779 errors:0 dropped:0 overruns:0 carrier:1
collisions:0 txqueuelen:1000
RX bytes:162531992 (155.0 Mb) TX bytes:49575995 (47.2 Mb)
Interrupt:11 Base address:0xec80
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:8559 errors:0 dropped:0 overruns:0 frame:0
TX packets:8559 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:533234 (520.7 Kb) TX bytes:533234 (520.7 Kb)
wlan1 Link encap:Ethernet HWaddr 00:0E:2E:52:3B:1D
inet addr:192.168.2.4 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: fe80::20e:2eff:fe52:3b1d/64 Scope:Link
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:50828 errors:0 dropped:0 overruns:0 frame:0
TX packets:43770 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:45978185 (43.8 Mb) TX bytes:7526693 (7.1 Mb)
For more options and information about using ifconfig,
enter ifconfig -h or see the
ifconfig (8) man page.
Configuring Routing with route
route is a program for manipulating the IP routing
table.
You can use it to view your routing configuration and add or
remove of routes.
NOTE: route and ip
The program route is obsolete. Use ip instead. route is especially useful if you need quick and comprehensible
information about your routing configuration to determine problems
with routing. To view your current routing configuration, enter
route
-n as root.
Example 31-12 Output of the route -n Command
route -n
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.20.0.0 * 255.255.248.0 U 0 0 0 eth0
link-local * 255.255.0.0 U 0 0 0 eth0
loopback * 255.0.0.0 U 0 0 0 lo
default styx.exam.com 0.0.0.0 UG 0 0 0 eth0
For more options and information about using route,
enter route -h or see the
route (8) man page.
31.6.3 Start-Up Scripts
Apart from the configuration files described above, there are also various
scripts that load the network programs while the machine is booting.
These are started as soon as the system is switched to one of the
multiuser runlevels. Some of these scripts
are described in Table 31-9.
Table 31-9 Some Start-Up Scripts for Network Programs
|
/etc/init.d/network
|
This script handles the configuration of the network interfaces.
The hardware must already have been initialized by
/etc/init.d/coldplug (via
hotplug).
If the network service was not started, no
network interfaces are implemented when they are inserted
via hotplug.
|
|
/etc/init.d/inetd
|
Starts xinetd.
xinetd can be used
to make server services available on the system.
For example, it can start
vsftpd whenever an FTP
connection is initiated.
|
|
/etc/init.d/portmap
|
Starts the portmapper needed for the RPC server,
such as an NFS
server. |
|
/etc/init.d/nfsserver
|
Starts the NFS server. |
|
/etc/init.d/sendmail
|
Controls the sendmail process.
|
|
/etc/init.d/ypserv
|
Starts the NIS server. |
|
/etc/init.d/ypbind
|
Starts the NIS client. |
|
|
|
