| SUSE LINUX – Administration Guide Chapter 14. Linux in the Network / 14.3. Manual Network Configuration | ||||
|---|---|---|---|---|
 | 14.2. IPv6 — The Next Generation Internet | 14.4. Network Integration |  | |
| SUSE LINUX – Administration Guide Chapter 14. Linux in the Network / 14.3. Manual Network Configuration | ||||
|---|---|---|---|---|
| 14.2. IPv6 — The Next Generation Internet | 14.4. Network Integration | | |
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 colon>. 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 file ifcfg-eth0 will be ignored.
Things are a little more complicated with hotplug network cards. If you do not use one of those cards, proceed directly to Section 14.3.1. “Configuration Files”.
Hotplug network cards are assigned the interface name arbitrarily, 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.
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).
A configuration based on the hardware address is treated with higher priority. This option was only omitted in the example for the sake of clarity.
YaST lists the configurations for hotplug cards and accordingly writes the 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 sometimes configure the network with and sometimes without YaST.
This section provides an overview of the network configuration files and explains their purpose and the format used.
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.
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. Comments are preceded by # signs.
Example 14.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 File 14.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 by which it has been modified, 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 where 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 File 14.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, a line consisting of the IP address, the fully qualified host name, and the host name (e.g., earth) is entered 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 File 14.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 the libc4 or the 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 14.5. “Parameters for /etc/host.conf” shows the parameters available. An example for /etc/host.conf is shown in File 14.8. “ /etc/host.conf ”.
Table 14.5. Parameters for /etc/host.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 more details.
The order for queries is defined in the file /etc/nsswitch.conf. An example of nsswitch.conf is shown in File 14.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 14.6. “DNS — Domain Name System”).
Example 14.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 14.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 14.7. “Configuration Options for NSS Databases”.
Table 14.6. 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 14.7. Configuration Options for NSS “Databases”
| files | directly access files, for example, to /etc/aliases |
| db | access via a database |
| nis | NIS, see also Section 14.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 |
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. This waiting time can be reduced 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 14.8. “Some Start-Up Scripts for Network Programs”).
Table 14.8. Some Start-Up Scripts for Network Programs
