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 /sbin/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 /sbin/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
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
The configuration names—everything
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
(PCI slot) or
and product ID). The name of the associated interface could be
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 /sbin/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:
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
Persistent interface names can be assigned to all interfaces whose
configurations do not include interface names. This
can be done by means of
entries in an interface configuration (
However, the persistent name
not be the same as the name that would automatically be assigned by
the kernel. Therefore,
iucv*, and so on are not permitted.
net* or descriptive names like
dmz. 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
must be executed. The command
is not sufficient for this purpose.
|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. If you experience a problem of this kind, inform us using http://www.suse.de/feedback.
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
and the network service was started. Formerly,
the command ifup
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 22.5, “Manual Network Configuration Scripts” summarizes the most important scripts involved in the network configuration. Where possible, the scripts are distinguished by hardware and interface.
Table 22.5. Manual Network Configuration Scripts
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.
This section provides an overview of the network configuration files and explains their purpose and the format used.
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
configurations are applied when coldplug is started.
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
config can be used in
if a general setting should be used for only
config contains general settings for the
behavior of ifup, ifdown, and
dhcp contains settings
for DHCP and
wireless for wireless LAN cards. The
variables in all three configuration files are commented and can also be
ifcfg-* files, where they are treated with
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:
* with the name of the interface. The entries in the
routing configuration files look like this:
DESTINATION GATEWAY NETMASK INTERFACE [ TYPE ] [ OPTIONS ] DESTINATION GATEWAY PREFIXLEN INTERFACE [ TYPE ] [ OPTIONS ] DESTINATION/PREFIXLEN GATEWAY - INTERFACE [ TYPE ] [ OPTIONS ]
To omit GATEWAY, NETMASK, PREFIXLEN, or INTERFACE, write
instead. The entries TYPE and OPTIONS may just be omitted.
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 last 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.
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
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
search entries. Use multiple
by entering several lines, each beginning with
nameserver. Precede comments with
# signs. YaST enters the specified
name server in this file. Example 22.5, “
/etc/resolv.conf could look like.
# 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
/etc/resolv.conf by means of the
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.
/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,
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
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
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.
In this file, shown in Example 22.6, “
/etc/hosts”, 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
blanks and tabs. Comments are always preceded by the
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 22.7, “
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 22.6, “Parameters for /etc/host.conf” shows
the parameters available. A sample
/etc/host.conf is shown in
Example 22.8, “
Table 22.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
bind: Accesses a name server
nis: Uses NIS
Defines if a host entered in
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.
The specified domain name is separated from the hostname after host
name resolution (as long as the hostname includes the domain name).
This option is useful if only names from the local domain are in the
The order for queries is defined in the file
/etc/nsswitch.conf. A sample
nsswitch.conf is shown
in Example 22.9, “
Comments are introduced by
In this example, the entry under the
database means that a request is
via DNS (see Chapter 24, The Domain Name System).
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 22.7, “Databases Available via /etc/nsswitch.conf”. In addition,
expected in the near future.
The configuration options for NSS databases are listed in
Table 22.8, “Configuration Options for NSS “Databases””.
Table 22.7. Databases Available via /etc/nsswitch.conf
Mail aliases implemented by
For user groups, used by
For hostnames and IP addresses, used by
Valid host and user lists in the network for the purpose of
controlling access permissions; see
Network names and addresses, used by
User passwords, used by
Network protocols, used by
Remote procedure call names and
addresses, used by
Network services, used by
Shadow passwords of users, used by
Table 22.8. Configuration Options for NSS “Databases”
directly access files, for example,
access via a database
NIS, see also Chapter 25, Using NIS
can only be used as an extension for
can only be used as an extension for
This file is used to configure nscd
(name service cache daemon). See
8 nscd and
By default, the system entries of
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
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
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 22.9, “Some Start-Up Scripts for Network Programs”.
Table 22.9. Some Start-Up Scripts for Network Programs
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.
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.
Starts the portmapper needed for the RPC server, such as an NFS server.
Starts the NFS server.
Controls the sendmail process.
Starts the NIS server.
Starts the NIS client.