Manual configuration of the network software should always be the last alternative. Using YaST is recommended. All network interfaces are activated with the script /sbin/ifup. To halt the interface, use ifdown. To check its status, use ifstatus.
If you only use internal network cards, simply configure the interfaces by means of their names. With the commands ifup eth0, ifstatus eth0, and ifdown eth0, start, check, or stop the interface eth0. The respective configuration files are stored in /etc/sysconfig/network/ifcfg-eth0. eth0 is the name of the interface and the name of the configuration.
Alternatively, configure the network in relation to the hardware address (MAC address) of a network card. In this case, use a hardware-based configuration file named in the format ifcfg-<hardware address without colons>. Use lowercase characters in the hardware address, as displayed by the command ip link (ifconfig shows uppercase letters). If ifup finds a configuration file matching the hardware address, a possibly existing ifcfg-eth0 file is ignored.
Things are a little more complicated with hotplug network cards, however. If you do not use one of those cards, proceed directly to Section 21.3.1. “Configuration Files”.
Hotplug network cards are not assigned a static interface name, so the configuration for one of those cards cannot be stored under the name of the interface. Instead, a name is used that contains the kind of hardware and the connection point. In the following, this name is referred to as the hardware description. ifup must be started with two arguments — the hardware description and the current interface name. ifup then determines the configuration that best fits the hardware description.
|Hotpluggable Network Cards on IBM S/390 and zSeries|
As a general rule, network cards on IBM S/390 and zSeries are hotpluggable. Unlike PCMCIA cards on PCs, the automatic configuration via DHCP is not possible on these platforms. The cards are detected but must be configured manually. The following example deals exclusively with hardware with PCMCIA support.
For example, consider a laptop with two PCMCIA slots, a PCMCIA ethernet network card, and an internal network card configured as eth0. If the internal card is in slot 0, its hardware description is eth-pcmcia-0. The cardmgr or the hotplug network script runs the command ifup eth-pcmcia-0 eth1. ifup searches /etc/sysconfig/network/ for the file ifcfg-eth-pcmcia-0. If this file does not exist, it consecutively searches for ifcfg-eth-pcmcia, ifcfg-pcmcia-0, ifcfg-pcmcia, ifcfg-eth1, and ifcfg-eth. The first of these files found by ifup is used for the configuration. To generate a network configuration valid for all PCMCIA network cards in all slots, the configuration file must be named ifcfg-pcmcia. This file would be used for the ethernet card in slot 0 (eth-pcmcia-0) as well as for a token ring card in slot 1 (tr-pcmcia-1).
YaST numbers the configurations for hotplug cards and writes the corresponding settings to ifcfg-eth-pcmcia-<number>. To use such a configuration file for all slots, ifcfg-eth-pcmcia is linked to this file. Keep this in mind if you configure the network sometimes with and sometimes without YaST.
This section provides an overview of the network configuration files and explains their purpose and the format used.
This directory contains a separate file for every device (network card). These files contain the configuration parameters (kernel module, start mode, script assocations, etc.).
These files contain data specific to a network interface. They may be named after the network interface (ifcfg-eth2), the hardware address of a network card (ifcfg-000086386be3), or the hardware description (ifcfg-usb). If network aliases are used, the respective files are named ifcfg-eth2:1 or ifcfg-usb:1. The script ifup gets the interface name and, if necessary, the hardware description as arguments then searches for the best matching configuration file.
IBM S/390 and zSeries do not support USB. The names of the interface files and network aliases contain S/390-specific elements, like qeth. ▪
The configuration files contain the IP address (BOOTPROTO=“static”, IPADDR=“10.10.11.214”) or the direction to use DHCP (BOOTPROTO=“dhcp”). The IP address should already contain the netmask (IPADDR=“10.10.11.214/16”). Refer to man ifup for the complete list of variables. In addition, all the variables in the files dhcp, wireless, and config can be used in the ifcfg-* files, if a general setting should only be used for one interface. By using the variables POST_UP_SCRIPT and PRE_DOWN_SCRIPT, individual scripts can be run after starting or before stopping the interface.
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.
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.
Example 21.5. /etc/resolv.conf
# Our domain search example.com # # We use sun (192.168.0.20) as nameserver nameserver 192.168.0.20
An example of /etc/resolv.conf is shown in Example 21.5. “/etc/resolv.conf”. YaST enters the specified name server here. 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 it happens that 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 (e.g., 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 will subsequently warn the user that changes will be lost after restoring the file. Apart from this, YaST will 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.
In this file (see Example 21.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 (e.g., earth) into the file. The IP address must be at the beginning of the line, the entries divided by blanks and tabs. Comments are always preceded by the # sign.
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 21.7. “/etc/networks”).
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 21.5. “Parameters for /etc/host.conf” shows the parameters available. An example for /etc/host.conf is shown in Example 21.8. “ /etc/host.conf ”.
Table 21.5. 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: Via 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 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.|
The order for queries is defined in the file /etc/nsswitch.conf. An example of nsswitch.conf is shown in Example 21.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 Section 21.7. “DNS — Domain Name System”).
Example 21.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 21.6. “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 21.7. “Configuration Options for NSS Databases”.
Table 21.6. Databases Available via /etc/nsswitch.conf
|aliases||Mail aliases implemented by sendmail; see man 5 aliases.|
|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 21.7. Configuration Options for NSS “Databases”
|files||directly access files, for example, /etc/aliases|
|db||access via a database|
|nis||NIS, see also Section 21.9. “NIS — Network Information Service”|
|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|
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. 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.
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 21.8. “Some Start-up Scripts for Network Programs”).
Table 21.8. Some Start-up Scripts for Network Programs
|/etc/init.d/network||This script handles the configuration of the network hardware and software when the system is booted.|
|/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.|