<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffcc" text="#000000">
    At some point reading this post I got the feeling you would move the
    host statements around in your file.<br>
    <br>
    Be warned: that will not accomplish anything but trouble, host
    statements ARE global, wherever they are placed in the file.<br>
    <br>
    One thing that might come closer to solving your issue might be
    classes and sub-classes.<br>
    <br>
    I think - define all options for the class and use a sub-class
    statement to place each host in the correct class at this moment.
    Examples are in the archives.<br>
    <br>
    I have never tried this but many seem to have it working.<br>
    <br>
    <br>
    On 12/09/10 16:56, Kyle McDonald wrote:
    <blockquote cite="mid:4C8CEA18.50300@Egenera.COM" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <title></title>
      <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<br>
          define options within different scopes, for example at a host,<br>
          group, pool, subnet, class or global scope. All requests that<br>
          are included in that scope inherit the options and settings.<br>
          Generally this gives a very flexible approach. Is this the
          sort<br>
          of thing you were expecting?<br>
          <br>
        </span></tt><tt><span style="white-space: pre;">></span><br>
      </tt><tt><span style="white-space: pre;"><br>
          <br>
          <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>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
dhcp-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/dhcp-users">https://lists.isc.org/mailman/listinfo/dhcp-users</a></pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 
</pre>
  </body>
</html>