%general-entities; ]> network configuring This section only applies if a network card is to be configured. If a network card will not be used, there is likely no need to create any configuration files relating to network cards. If that is the case, remove the network symlinks from all run-level directories (/etc/rc.d/rc*.d). Instructions in this section are optional if you have only one network card. With Udev and modular network drivers, the network interface numbering is not persistent across reboots by default, because the drivers are loaded in parallel and, thus, in random order. For example, on a computer having two network cards made by Intel and Realtek, the network card manufactured by Intel may become eth0 and the Realtek card becomes eth1. In some cases, after a reboot the cards get renumbered the other way around. To avoid this, create Udev rules that assign stable names to network cards based on their MAC addresses or bus positions. If you are going to use MAC addresses to identify your network cards, find the addresses with the following command: grep -H . /sys/class/net/*/address For each network card (but not for the loopback interface), invent a descriptive name, such as realtek, and create Udev rules similar to the following: cat > /etc/udev/rules.d/70-persistent-net.rules << EOF ACTION=="add", SUBSYSTEM=="net", SYSFS{address}=="00:e0:4c:12:34:56", \ NAME="realtek" ACTION=="add", SUBSYSTEM=="net", SYSFS{address}=="00:a0:c9:78:9a:bc", \ NAME="intel" EOF Be aware that Udev does not recognize the backslash for line continuation. The examples in this book work properly because both the backslash and newline are ignored by the shell. This makes the shell send each rule to cat on only one line. (The shell ignores this sequence because the EOF string used in the here-document redirection is not enclosed in either double or single quotes. For more details, see the bash(1) manpage, and search it for "Here Documents".) If modifying Udev rules with an editor, be sure to leave each rule on one physical line. If you are going to use the bus position as the key, find the position of each card with the following commands: for dir in /sys/class/net/* ; do [ -e $dir/device ] && { basename $dir ; readlink -f $dir/device } done This will yield output similar to: eth0 /sys/devices/pci0000:00/0000:00:0c.0 eth1 /sys/devices/pci0000:00/0000:00:0d.0 In this example, eth0 has PCI bus position 0000:00:0c.0 (domain 0000, bus 00, device 0c, function 0), and eth1 has PCI bus position 0000:00:0d.0 (domain 0000, bus 00, device 0d, function 0). Now create Udev rules similar to the following: cat > /etc/udev/rules.d/70-persistent-net.rules << EOF ACTION=="add", SUBSYSTEM=="net", BUS=="pci", KERNELS=="0000:00:0c.0", \ NAME="realtek" ACTION=="add", SUBSYSTEM=="net", BUS=="pci", KERNELS=="0000:00:0d.0", \ NAME="intel" EOF Udev has installed a rule_generator rules file that uses MAC addresses, not bus positions. Rules generated by this file will conflict with the rules you just created, so delete the file: rm /etc/udev/rules.d/75-persistent-net-generator.rules You will also have to remember to create a new bus-position-based rule each time you plug in an additional network card. In a MAC address based persistence scheme, the rule_generator rules file would do this automatically. Regardless of which method you use, these rules will always rename the network cards to realtek and intel, independently of the original numbering provided by the kernel (i.e.: the original eth0 and eth1 interfaces will no longer exist, unless you put such descriptive names in the NAME key). Use the descriptive names from the Udev rules instead of eth0 in the network interface configuration files below. Note that the rules above don't work for every setup. For example, MAC-based rules break when bridges or VLANs are used, because bridges and VLANs have the same MAC address as the network card. One wants to rename only the network card interface, not the bridge or VLAN interface, but the example rule matches both. If you use such virtual interfaces, you have two potential solutions. One is to add the DRIVER=="?*" key after SUBSYSTEM=="net" in MAC-based rules which will stop matching the virtual interfaces. This is known to fail with some older Ethernet cards because they don't have the DRIVER variable in the uevent and thus the rule does not match with such cards. Another solution is to switch to rules that use the bus position as a key. The second known non-working case is with wireless cards using the MadWifi or HostAP drivers, because they create at least two interfaces with the same MAC address and bus position. For example, the Madwifi driver creates both an athX and a wifiX interface where X is a digit. To differentiate these interfaces, add an appropriate KERNEL parameter such as KERNEL=="ath*" after SUBSYSTEM=="net". There may be other cases where the rules above don't work. Currently, bugs on this topic are still being reported to Linux distributions, and no solution that covers every case is available. Which interfaces are brought up and down by the network script depends on the files and directories in the /etc/sysconfig/network-devices hierarchy. This directory should contain a sub-directory for each interface to be configured, such as ifconfig.xyz, where xyz is a network interface name. Inside this directory would be files defining the attributes to this interface, such as its IP address(es), subnet masks, and so forth. The following command creates a sample ipv4 file for the eth0 device: cd /etc/sysconfig/network-devices && mkdir -v ifconfig.eth0 && cat > ifconfig.eth0/ipv4 << "EOF" ONBOOT=yes SERVICE=ipv4-static IP=192.168.1.1 GATEWAY=192.168.1.2 PREFIX=24 BROADCAST=192.168.1.255 EOF The values of these variables must be changed in every file to match the proper setup. If the ONBOOT variable is set to yes the network script will bring up the Network Interface Card (NIC) during booting of the system. If set to anything but yes the NIC will be ignored by the network script and not be brought up. The SERVICE variable defines the method used for obtaining the IP address. The LFS-Bootscripts package has a modular IP assignment format, and creating additional files in the /etc/sysconfig/network-devices/services directory allows other IP assignment methods. This is commonly used for Dynamic Host Configuration Protocol (DHCP), which is addressed in the BLFS book. The GATEWAY variable should contain the default gateway IP address, if one is present. If not, then comment out the variable entirely. The PREFIX variable needs to contain the number of bits used in the subnet. Each octet in an IP address is 8 bits. If the subnet's netmask is 255.255.255.0, then it is using the first three octets (24 bits) to specify the network number. If the netmask is 255.255.255.240, it would be using the first 28 bits. Prefixes longer than 24 bits are commonly used by DSL and cable-based Internet Service Providers (ISPs). In this example (PREFIX=24), the netmask is 255.255.255.0. Adjust the PREFIX variable according to your specific subnet. /etc/resolv.conf If the system is going to be connected to the Internet, it will need some means of Domain Name Service (DNS) name resolution to resolve Internet domain names to IP addresses, and vice versa. This is best achieved by placing the IP address of the DNS server, available from the ISP or network administrator, into /etc/resolv.conf. Create the file by running the following: cat > /etc/resolv.conf << "EOF" # Begin /etc/resolv.conf domain <Your Domain Name> nameserver <IP address of your primary nameserver> nameserver <IP address of your secondary nameserver> # End /etc/resolv.conf EOF Replace <IP address of the nameserver> with the IP address of the DNS most appropriate for the setup. There will often be more than one entry (requirements demand secondary servers for fallback capability). If you only need or want one DNS server, remove the second nameserver line from the file. The IP address may also be a router on the local network.