<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>Hi Glenn,<br>
</tt><tt> <br>
</tt><tt> On 9/12/2010 9:03 AM, Glenn Satchell wrote:<br>
</tt><tt> <span style="white-space: pre;">> In ISC dhcpd you can
define options within different scopes, for example at a host,
group, pool, subnet, class or global scope. All requests that
are included in that scope inherit the options and settings.
Generally this gives a very flexible approach. Is this the sort
of thing you were expecting?<br>
</span></tt><tt><span style="white-space: pre;">></span><br>
</tt><tt><span style="white-space: pre;">
<br>
</span>I've seen this. I think what ypu're describing is that I
can make a group for booting and installing RHEL5u3, define the
options for RHEL5u3 in that group, then list all the hosts I want
to actually install RHEL5u3 in that group? Then repeat for SLES11,
Solaris 10, etc?<br>
</tt><tt> <br>
</tt><tt> That's close I suppose but not quite it. It might be OK
for the linux installs since there a few less permutations, But
for the Solaris ones ugh!<br>
</tt><tt> <br>
</tt><tt> I really prefer to only keep each setting in one place, so
I can't miss any of them when I need to change it. So currently I
use a hierarchy of macros like this:<br>
</tt><tt> (Psuedo code here - Sun's syntax is not that easy to
read.)<br>
</tt><tt> <br>
</tt><tt> INST_Solaris_s10u8_X64_a<br>
</tt><tt> </tt><tt> {<br>
</tt><tt> GrubMenu /tftp/Solaris_S10u8_X64_a # This menu uses
port A for the console<br>
</tt><tt> include INST_Solaris_s10u8_X64 # note no _a<br>
</tt><tt> }<br>
</tt><tt> <br>
</tt> <tt>INST_Solaris_s10u8_X64_b<br>
</tt><tt> </tt><tt> {<br>
</tt><tt> GrubMenu /tftp/Solaris_S10u8_X64_b # This menu uses
port B kernel console<br>
</tt><tt> include INST_Solaris_s10u8_X64 # note no _b<br>
</tt><tt> }<br>
</tt><tt> <br>
</tt><tt> </tt><tt>INST_Solaris_s10u8_X64_v<br>
</tt><tt> </tt><tt> {<br>
</tt><tt> GrubMenu /tftp/Solaris_S10u8_X64_v # This menu uses
VGA for the kernel console<br>
</tt><tt> include INST_Solaris_s10u8_X64 # note no _v<br>
</tt><tt> }<br>
</tt><tt> <br>
</tt><tt> INST_Solaris_s10u8_X64<br>
</tt><tt> {<br>
</tt><tt> ...Sun Options specific to s10u8 for X64<br>
</tt><tt> include INST_Solaris_s10u8 # note no _X64<br>
</tt><tt> }<br>
</tt><tt> <br>
</tt><tt> INST_Solaris_s10u8_SPARC<br>
</tt><tt> {<br>
</tt><tt> ...Sun Options specific to s10u8 for SPARC<br>
</tt><tt> include INST_Solaris_s10u8 # note no _SPARC<br>
</tt><tt> }<br>
</tt><tt> <br>
</tt><tt> INST_Solaris_s10u8<br>
</tt><tt> { <br>
</tt><tt> ...Sun Options specific to s10u8 for all Archs.<br>
</tt><tt> include INST_Solaris_s10 # note no u8<br>
</tt><tt> }<br>
</tt><tt> <br>
</tt><tt> INST_Solaris_s10<br>
</tt><tt> {<br>
</tt><tt> ...Sun Options specific to s10 for all updates... None
of these at the moment.<br>
</tt><tt> include INST_Solaris_Common<br>
</tt><tt> }<br>
</tt><tt> <br>
</tt><tt> INST_Solaris_Common<br>
</tt><tt> {<br>
</tt><tt> ...Sun Options common to all Solaris installs<br>
</tt><tt> include INST_Common<br>
</tt><tt> }<br>
</tt><tt> <br>
</tt><tt> INST_Common<br>
</tt><tt> { <br>
</tt><tt> ... PXE and other options common to all installs<br>
</tt><tt> }<br>
</tt><tt> <br>
</tt><tt> I have parts of the pattern above repeated for many OS's
like:<br>
</tt><tt> <br>
</tt><tt> Solaris 10 all updates, Solaris NV and OpenSolaris many
builds both X64 and SPARC.<br>
</tt><tt> RHEL4, 5 and 6 all updates, both X32 and X64<br>
</tt><tt> SLES9, 10 and 11, all updates, both X32 and X64<br>
</tt><tt> Ditto for CentOS, Oracle Linux, Fedora, Ubuntu, etc.<br>
</tt><tt> <br>
</tt><tt> This pattern may seem like a lot of work, but the best
part is that when defining a host I only have to select the right
top level macro (like INST_Linux_SLES11_X64-b) for it. We update
which OS is going to be installed on which hosts all the time. <br>
</tt><tt> <br>
</tt><tt> If I group the hosts by OS to install, then I'll need to
move the whole Host record between <br>
</tt><tt> groups. That's not impossible to do, but it's less
straight forward than just switching a hosts' macro from
INST_RHEL5u4_X64-a to INST_SLES11ga_X32-a.<br>
</tt><tt> <br>
</tt><tt> <br>
</tt><tt> In ISC DHCP, can whole config files be included at any
level? I mean can I do this:<br>
</tt><tt><br>
</tt><tt>host foo {<br>
hardware ethernet xx:xx:xx:xx:xx:xx;<br>
fixed-address 192.168.x.y;<br>
include /some/dir/Linux/RHEL5/u3/X64-a<br>
} <br>
</tt><tt><br>
host bar {<br>
hardware ethernet xx:xx:xx:xx:xx:xx;<br>
fixed-address 192.168.x.y;<br>
include /some/dir/Linux/SLES11/ga/X32-a<br>
} <br>
</tt><br>
<tt>I think I could make do with something like this if it'll work.<br>
<br>
-Kyle<br>
<br>
<br>
</tt> <tt><span style="white-space: pre;"></span></tt><br>
</body>
</html>