1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
|
<a name="toc">
<h2>Cobbler's DHCP Features</h2>
</a>
<a name="about">
<h2>About</h2>
</a>
<p>
Cobbler can optionally help configure a DHCP setup, to make sure that specific systems (specified by MAC address) get assigned to specific IP addresses.
</p>
<a name="whatssupported">
<h2>What's Supported</h2>
</a>
<p>
Currently cobbler can help generate a ISC DHCP configuration (package name: dhcpd). Cobbler 0.5.0 (release pending) can also use dnsmasq. DNSmasq can help you assign hostnames to specific systems as well as just the IP's.
</p>
<a name="#when">
<h2>When To Enable DHCP Management</h2>
</a>
<p>
If you are running on a larger network, most likely DHCP already exists. Cobbler managing DHCP, though, may be very appropriate for labs or other situations where admins can already control their DHCP. For all of this to work, cobbler must be running on the DHCP server.
</p>
<a name="#do_not_want">
<h2>What If I Don't Want This?</h2>
</a>
<p>
It's fine to not have Cobbler manage your DHCP infrastructure. In fact, it's the default behavior. If you want PXE to work in this case, just make sure that the next-server entry in your dhcp.conf, as well as the filename information is correct to serve up pxelinux.0 to the machines that want it.
<p>
<p>
The idea in having cobbler manage DHCP is that it's closely related to PXE installation, and if we're maintaing a database about what systems we have and what they run, it makes sense to keep track of (and control) hostnames and IP's as well. Controlling DHCP from Cobbler makes this possible -- and it's one less thing the administrator has to configure.
</p>
<a name="enabling">
<h2>Enabling DHCP Management</h2>
</a>
<p>
Change /var/lib/cobbler/settings so that manage_dhcp has the value of 1.
</p>
<p>
Edit /var/lib/cobbler/dhcp.template to taste -- mainly just making sure that the DHCP information is correct. You can add whatever else you want to that file, including anything you may have had from an existing setup.
</p>
<p>
For Cobbler 0.5.0 and later, you can also optionally select dnsmasq instead of ISC dhcpd by changing the 'manage_dhcp_mode' to 'dnsmasq'. This is covered in more detail in the cobbler manpage. This allows, among other things, controlling the hostnames of provisioned machines as well as just the IP's.
</p>
<a name="howitworks">
<h2>How It Works</h2>
</a>
<p>
Suppose the following command is given:
</p>
<blockquote>
<code>
cobbler system add --name=AA:BB:CC:DD:EE:FF --pxe-address=192.168.1.1
(newer versions:) cobbler system add --name=AA:BB:CC:DD:EE:FF --ip=192.168.1.1
</code>
</blockquote>
<p>
That will take the template file in /etc/cobbler/dhcp.template, fill in the appropriate fields, and generate a configuration that ensures that when AA:BB:CC:DD:EE:FF asks for an IP, it gets 192.168.1.1. The part to specify the address is not required, DHCP knows how to assign something within the configured range as well.
</p>
<a name="itaniums">
<h2>Itaniums</h2>
</a>
<p>
These are complicated. In order to PXE an Itanium correctly, one has to provide a "filename" value that references elilo, not pxelinux. Thankfully cobbler knows how to do this. When creating the distro object, make sure that --arch=ia64 is specified, and the right thing will be done here. Also note that to PXE Itaniums, the --pxe-address parameter is mandatory. This is due to a deficiency in LILO where it will ask for an encoded IP address, but will not ask for a PXE configuration file based on the MAC address. This is covered some in the cobbler manpage but bears repeating here.
</p>
<p>
Also, sometimes Itaniums tend to hang during net installs... we're not sure why this is :)
</p>
<a name="dynamic">
<h2>Dynamic DNS</h2>
</a>
<p>
If you are using Cobbler >= 0.5.0, change 'manage_dhcp_mode' to dnsmasq, you can
specify the parameter --hostname for any "cobbler system add" command where you also
provide a MAC address. Restart dnsmasq before provisioning to apply changes.
</p>
<p>
You may also use the Cobbler trigger mechanism documented on the <A HREF="http://et.redhat.com/page/Cobbler_Triggers">Cobbler Wiki</A> to write your own scripts that interface with your own DNS install, if not using dnsmasq.
</p>
<a name="static">
<h2>Static IPs</h2>
</a>
<p>
Don't like DHCP at all?
</p>
<p>
Other than for configuring PXE, you can still use static IPs in your kickstarts and on
your network with Cobbler. To do this, take
advantage of the --ksmeta option mentioned in the manpage to customize your kickstart
templates -- then create a cobbler system record for each object, defining --ksmeta
variables for the intended IP addresses and so forth. You can then substitute in variables to create system specific kickstarts, while only maintaining one kickstart template
in common between multiple systems.
</p>
<p>
This will work with koan and "--system" out of the box. However, to PXE, you'll
need at least a bare minimum DHCP config.
</p>
|
