1 | <?xml version="1.0" encoding="ISO-8859-1"?> |
---|
2 | <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" |
---|
3 | "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [ |
---|
4 | <!ENTITY % general-entities SYSTEM "../../general.ent"> |
---|
5 | %general-entities; |
---|
6 | ]> |
---|
7 | |
---|
8 | <sect1 id="ch-scripts-network"> |
---|
9 | <?dbhtml filename="network.html"?> |
---|
10 | |
---|
11 | <title>Configuring the network Script</title> |
---|
12 | |
---|
13 | <indexterm zone="ch-scripts-network"> |
---|
14 | <primary sortas="d-network">network</primary> |
---|
15 | <secondary>configuring</secondary></indexterm> |
---|
16 | |
---|
17 | <para>This section only applies if a network card is to be |
---|
18 | configured.</para> |
---|
19 | |
---|
20 | <para>If a network card will not be used, there is likely no need to |
---|
21 | create any configuration files relating to network cards. If that is |
---|
22 | the case, remove the <filename class="symlink">network</filename> |
---|
23 | symlinks from all run-level directories (<filename |
---|
24 | class="directory">/etc/rc.d/rc*.d</filename>).</para> |
---|
25 | |
---|
26 | <sect2> |
---|
27 | <title>Creating stable names for network interfaces</title> |
---|
28 | |
---|
29 | <para>Instructions in this section are optional if you have only one |
---|
30 | network card.</para> |
---|
31 | |
---|
32 | <para>With Udev and modular network drivers, the network interface numbering |
---|
33 | is not persistent across reboots by default, because the drivers are loaded |
---|
34 | in parallel and, thus, in random order. For example, on a computer having |
---|
35 | two network cards made by Intel and Realtek, the network card manufactured |
---|
36 | by Intel may become <filename class="devicefile">eth0</filename> and the |
---|
37 | Realtek card becomes <filename class="devicefile">eth1</filename>. In some |
---|
38 | cases, after a reboot the cards get renumbered the other way around. To |
---|
39 | avoid this, create Udev rules that assign stable names to network cards |
---|
40 | based on their MAC addresses or bus positions.</para> |
---|
41 | |
---|
42 | <para>If you are going to use MAC addresses to identify your network |
---|
43 | cards, find the addresses with the following command:</para> |
---|
44 | |
---|
45 | <screen role="nodump"><userinput>grep -H . /sys/class/net/*/address</userinput></screen> |
---|
46 | |
---|
47 | <para>For each network card (but not for the loopback interface), |
---|
48 | invent a descriptive name, such as <quote>realtek</quote>, and create |
---|
49 | Udev rules similar to the following:</para> |
---|
50 | |
---|
51 | <screen role="nodump"><userinput>cat > /etc/udev/rules.d/26-network.rules << EOF |
---|
52 | <literal>ACTION=="add", SUBSYSTEM=="net", SYSFS{address}=="<replaceable>00:e0:4c:12:34:56</replaceable>", \ |
---|
53 | NAME="<replaceable>realtek</replaceable>" |
---|
54 | ACTION=="add", SUBSYSTEM=="net", SYSFS{address}=="<replaceable>00:a0:c9:78:9a:bc</replaceable>", \ |
---|
55 | NAME="<replaceable>intel</replaceable>"</literal> |
---|
56 | EOF</userinput></screen> |
---|
57 | |
---|
58 | <!-- Yes, I know that VLANs are beyond BLFS. This is not the reason to get them |
---|
59 | incorrect by default when every distro does this right. --> |
---|
60 | |
---|
61 | <note> |
---|
62 | <para>Although the examples in this book work properly, be aware |
---|
63 | that Udev does not recognize the backslash for line continuation. |
---|
64 | If modifying Udev rules with an editor, be sure to leave each rule |
---|
65 | on one physical line.</para> |
---|
66 | </note> |
---|
67 | |
---|
68 | <para>If you are going to use the bus position as a key, create |
---|
69 | Udev rules similar to the following:</para> |
---|
70 | |
---|
71 | <screen role="nodump"><userinput>cat > /etc/udev/rules.d/26-network.rules << EOF |
---|
72 | <literal>ACTION=="add", SUBSYSTEM=="net", BUS=="<replaceable>pci</replaceable>", ID=="<replaceable>0000:00:0c.0</replaceable>", \ |
---|
73 | NAME="<replaceable>realtek</replaceable>" |
---|
74 | ACTION=="add", SUBSYSTEM=="net", BUS=="<replaceable>pci</replaceable>", ID=="<replaceable>0000:00:0d.0</replaceable>", \ |
---|
75 | NAME="<replaceable>intel</replaceable>"</literal> |
---|
76 | EOF</userinput></screen> |
---|
77 | |
---|
78 | <para>These rules will always rename the network cards to |
---|
79 | <quote>realtek</quote> and <quote>intel</quote>, independently |
---|
80 | of the original numbering provided by the kernel (i.e.: the original |
---|
81 | <quote>eth0</quote> and <quote>eth1</quote> interfaces will no longer |
---|
82 | exist, unless you put such <quote>descriptive</quote> names in the NAME |
---|
83 | key). Use the descriptive names from the Udev rules instead |
---|
84 | of <quote>eth0</quote> in the network interface configuration files |
---|
85 | below.</para> |
---|
86 | |
---|
87 | <para>Note that the rules above don't work for every setup. For example, |
---|
88 | MAC-based rules break when bridges or VLANs are used, because bridges and |
---|
89 | VLANs have the same MAC address as the network card. One wants to rename |
---|
90 | only the network card interface, not the bridge or VLAN interface, but the |
---|
91 | example rule matches both. If you use such virtual interfaces, you have two |
---|
92 | potential solutions. One is to add the DRIVER=="?*" key after |
---|
93 | SUBSYSTEM=="net" in MAC-based rules which will stop matching the virtual |
---|
94 | interfaces. This is known to fail with some older Ethernet cards because |
---|
95 | they don't have the DRIVER variable in the uevent and thus the rule does |
---|
96 | not match with such cards. Another solution is to switch to rules that use |
---|
97 | the bus position as a key.</para> |
---|
98 | |
---|
99 | <para>The second known non-working case is with wireless cards using the |
---|
100 | MadWifi or HostAP drivers, because they create at least two interfaces with |
---|
101 | the same MAC address and bus position. For example, the Madwifi driver |
---|
102 | creates both an athX and a wifiX interface where X is a digit. To |
---|
103 | differentiate these interfaces, add an appropriate KERNEL parameter such as |
---|
104 | KERNEL=="ath*" after SUBSYSTEM=="net".</para> |
---|
105 | |
---|
106 | <para>There may be other cases where the rules above don't work. Currently, |
---|
107 | bugs on this topic are still being reported to Linux distributions, and no |
---|
108 | solution that covers every case is available.</para> |
---|
109 | |
---|
110 | </sect2> |
---|
111 | |
---|
112 | <sect2> |
---|
113 | <title>Creating Network Interface Configuration Files</title> |
---|
114 | |
---|
115 | <para>Which interfaces are brought up and down by the network script |
---|
116 | depends on the files and directories in the <filename |
---|
117 | class="directory">/etc/sysconfig/network-devices</filename> hierarchy. |
---|
118 | This directory should contain a sub-directory for each interface to be |
---|
119 | configured, such as <filename>ifconfig.xyz</filename>, where |
---|
120 | <quote>xyz</quote> is a network interface name. Inside this directory |
---|
121 | would be files defining the attributes to this interface, such as its IP |
---|
122 | address(es), subnet masks, and so forth.</para> |
---|
123 | |
---|
124 | <para>The following command creates a sample <filename>ipv4</filename> |
---|
125 | file for the <emphasis>eth0</emphasis> device:</para> |
---|
126 | |
---|
127 | <screen><userinput>cd /etc/sysconfig/network-devices && |
---|
128 | mkdir -v ifconfig.eth0 && |
---|
129 | cat > ifconfig.eth0/ipv4 << "EOF" |
---|
130 | <literal>ONBOOT=yes |
---|
131 | SERVICE=ipv4-static |
---|
132 | IP=192.168.1.1 |
---|
133 | GATEWAY=192.168.1.2 |
---|
134 | PREFIX=24 |
---|
135 | BROADCAST=192.168.1.255</literal> |
---|
136 | EOF</userinput></screen> |
---|
137 | |
---|
138 | <para>The values of these variables must be changed in every file to match |
---|
139 | the proper setup. If the <envar>ONBOOT</envar> variable is set to |
---|
140 | <quote>yes</quote> the network script will bring up the Network Interface |
---|
141 | Card (NIC) during booting of the system. If set to anything but |
---|
142 | <quote>yes</quote> the NIC will be ignored by the network script and not |
---|
143 | be brought up.</para> |
---|
144 | |
---|
145 | <para>The <envar>SERVICE</envar> variable defines the method used for |
---|
146 | obtaining the IP address. The CLFS-Bootscripts package has a modular IP |
---|
147 | assignment format, and creating additional files in the <filename |
---|
148 | class="directory">/etc/sysconfig/network-devices/services</filename> |
---|
149 | directory allows other IP assignment methods. This is commonly used for |
---|
150 | Dynamic Host Configuration Protocol (DHCP), which is addressed in the |
---|
151 | BLFS book.</para> |
---|
152 | |
---|
153 | <para>The <envar>GATEWAY</envar> variable should contain the default |
---|
154 | gateway IP address, if one is present. If not, then comment out the |
---|
155 | variable entirely.</para> |
---|
156 | |
---|
157 | <para>The <envar>PREFIX</envar> variable needs to contain the number of |
---|
158 | bits used in the subnet. Each octet in an IP address is 8 bits. If the |
---|
159 | subnet's netmask is 255.255.255.0, then it is using the first three octets |
---|
160 | (24 bits) to specify the network number. If the netmask is 255.255.255.240, |
---|
161 | it would be using the first 28 bits. Prefixes longer than 24 bits are |
---|
162 | commonly used by DSL and cable-based Internet Service Providers (ISPs). |
---|
163 | In this example (PREFIX=24), the netmask is 255.255.255.0. Adjust the |
---|
164 | <envar>PREFIX</envar> variable according to your specific subnet.</para> |
---|
165 | |
---|
166 | </sect2> |
---|
167 | |
---|
168 | <sect2 id="resolv.conf"> |
---|
169 | <title>Creating the /etc/resolv.conf File</title> |
---|
170 | |
---|
171 | <indexterm zone="resolv.conf"> |
---|
172 | <primary sortas="e-/etc/resolv.conf">/etc/resolv.conf</primary> |
---|
173 | </indexterm> |
---|
174 | |
---|
175 | <para>If the system is going to be connected to the Internet, it will |
---|
176 | need some means of Domain Name Service (DNS) name resolution to |
---|
177 | resolve Internet domain names to IP addresses, and vice versa. This is |
---|
178 | best achieved by placing the IP address of the DNS server, available |
---|
179 | from the ISP or network administrator, into |
---|
180 | <filename>/etc/resolv.conf</filename>. Create the file by running the |
---|
181 | following:</para> |
---|
182 | |
---|
183 | <screen><userinput>cat > /etc/resolv.conf << "EOF" |
---|
184 | <literal># Begin /etc/resolv.conf |
---|
185 | |
---|
186 | domain <replaceable>[Your Domain Name]</replaceable> |
---|
187 | nameserver <replaceable>[IP address of your primary nameserver]</replaceable> |
---|
188 | nameserver <replaceable>[IP address of your secondary nameserver]</replaceable> |
---|
189 | |
---|
190 | # End /etc/resolv.conf</literal> |
---|
191 | EOF</userinput></screen> |
---|
192 | |
---|
193 | <para>Replace <replaceable>[IP address of the nameserver]</replaceable> |
---|
194 | with the IP address of the DNS most appropriate for the setup. There will |
---|
195 | often be more than one entry (requirements demand secondary servers for |
---|
196 | fallback capability). If you only need or want one DNS server, remove the |
---|
197 | second <emphasis>nameserver</emphasis> line from the file. The IP address |
---|
198 | may also be a router on the local network.</para> |
---|
199 | |
---|
200 | </sect2> |
---|
201 | |
---|
202 | </sect1> |
---|