22.3. Manual Network Configuration

Manual configuration of the network software should always be the last alternative. Using YaST is recommended. The background information about the network configuration can assist in your work with YaST.

All built-in network cards as well as hotplug network cards (PCMCIA, USB, some PCI cards) are detected and configured via hotplug. The following information will help you to understand this procedure:

Various Views of Network Cards

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 over 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.

Assignment of Interface Names by the Kernel

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 requires 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 /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.

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.

The following table 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

Configuration StageCommandFunction
Hardwarehw{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.
Interfacegetcfggetcfg 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.
Interfaceif{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 18. The Hotplug System and 19. Dynamic Device Nodes with udev.

22.3.1. Configuration Files

This section provides an overview of the network configuration files and explains their purpose and the format used.

22.3.1.1. /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.

22.3.1.2. /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.

22.3.1.3. /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.

22.3.1.4. /etc/sysconfig/network/routes,ifroute-*

The static routing of TCP/IP packets is determined here. In these files, the destination of the route is entered in the first column, the gateway in the second, the network mask of the destination in the third, and an optional network interface in the fourth. Special options can be entered in the fifth column and additional columns. Empty columns are marked with a -. Details are provided in the manual page of routes and in 22.5. “Routing in SUSE LINUX”.

If the network interface is omitted, the system tries to implement the route for every interface. However, this only works for the suitable interface. For example, this can be used for the default route. Of course, configuration names can be used instead of interface names.

To use a route only with a specific interface configuration, it can be entered in ifroute-<configuration name> instead of routes. In this way, different default routes can be configured. The default route of the last implemented network interface is used.

22.3.1.5. /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 (keyword nameserver) to access. 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 22.5. “/etc/resolv.conf” shows what /etc/resolv.conf could look like.

Example 22.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 above-mentioned services are only temporary.

22.3.1.6.  /etc/hosts

In this file (see Example 22.6. “/etc/hosts”), IP addresses are assigned to host names. 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 host name, and the host name (such as earth) into the file. The IP address must be at the beginning of the line, the entries separated by blanks and tabs. Comments are always preceded by the # sign.

Example 22.6. /etc/hosts

127.0.0.1 localhost
192.168.0.20 sun.example.com sun
192.168.0.0 earth.example.com earth

22.3.1.7. /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 22.7. “/etc/networks”).

Example 22.7. /etc/networks

loopback     127.0.0.0
localnet     192.168.0.0

22.3.1.8. /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 22.6. “Parameters for /etc/host.conf” shows the parameters available. An example for /etc/host.conf is shown in Example 22.8. “ /etc/host.conf ”.

Table 22.6. Parameters for /etc/host.conf

order hosts, bindSpecifies 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: Via NIS
multi on/offDefines if a host entered in /etc/hosts can have multiple IP addresses.
nospoof on spoofalert on/offThese 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 host name after host name resolution (as long as the host name 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 22.8.  /etc/host.conf

# We have named running
order hosts bind
# Allow multiple addrs
multi on

22.3.1.9. /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 man 5 nsswitch.conf and The GNU C Library Reference Manual for details.

The order for queries is defined in the file /etc/nsswitch.conf. An example of nsswitch.conf is shown in Example 22.9. “/etc/nsswitch.conf”. 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 22.7. “DNS — Domain Name System”).

Example 22.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 22.7. “Databases Available via /etc/nsswitch.conf”. In addition, automount, bootparams, netmasks, and publickey are 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

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 host names 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 man 5 netgroup.
networks Network names and addresses, used by getnetent.
passwd User passwords, used by getpwent; see man 5 passwd.
protocols Network protocols, used by getprotoent; see man 5 protocols.
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 man 5 shadow.

Table 22.8. Configuration Options for NSS “Databases

files directly access files, for example, /etc/aliases
dbaccess via a database
nisNIS, see also 22.8. “NIS — Network Information Service”
nisplus 
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

22.3.1.10. /etc/nscd.conf

This file is used to configure nscd (name service cache daemon). See man 8 nscd and man 5 nscd.conf. 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 causes the local system to be 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.

22.3.1.11. /etc/HOSTNAME

Here is the host name 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 host name is set.

22.3.2. 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 (see also Table 22.9. “Some Start-up Scripts for Network Programs”).

Table 22.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 will be implemented when they are inserted via hotplug.
/etc/init.d/inetdStarts 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/portmapStarts the portmapper needed for the RPC server, such as an NFS server.
/etc/init.d/nfsserverStarts the NFS server.
/etc/init.d/sendmailControls the sendmail process.
/etc/init.d/ypservStarts the NIS server.
/etc/init.d/ypbindStarts the NIS client.

SUSE LINUX 9.2