Hi Tory,

This is a little bit late, but I've been handling the issue of multiple next-servers by using Cheetah templating code in dhcp.template. I started with 3 data centers  -- A, B, and C -- which all had a cobbler instance repliacted from a master cobbler server (the only one with cobbler-web).

On each cobbler server, I defined a unique $tag_pattern to be matched against each system object's dhcp_tag.

If CobblerA recognized that a system object's dhcp_tag matched its $tag_pattern, it created a dhcpd host definition with the appropriate next-server (pulled from CobblerA 's /etc/cobbler/settings).

Systems that were not set with netboot-enable=True or did not match the $tag_pattern were skipped. This resulted in a clean dhcpd.conf, containing only the host definitions relevant for that network.

It would be a simple matter to update my template for multi-homed Cobbler servers with a Cheetah if statement that examined the system object's gateway and assigned a different next-server value. 

Here's my dhcp.template. If you're still struggling with too much complexity and/or uncertainty, I hope this helps.

# Cobbler managed dhcpd.conf file
#
# generated from cobbler dhcp.conf template ($date)
# Do NOT make changes to /etc/dhcpd.conf. Instead, make your changes
# in /etc/cobbler/dhcp.template, as /etc/dhcpd.conf will be
# overwritten.
#
# ******************************************************************
authoritative;
allow booting;
allow bootp;

option domain-name "example.com";
option domain-name-servers 10.10.148.12;
option ntp-servers 10.10.148.12;
option routers 10.10.148.1;

ddns-update-style interim;
default-lease-time 10800;
max-lease-time 10800;

log-facility local4;

key ddns_key {
  algorithm hmac-md5;
  secret "XXXXXXXXXXXXXXXXXXXXXX";
}

subnet 10.10.148.0 netmask 255.255.252.0 {
     option routers             10.10.148.1;
     option domain-name-servers 10.10.148.12;
     option domain-name "example.com";
     option subnet-mask         255.255.252.0;
     filename                   "/pxelinux.0";
     next-server                $next_server;
}

# For kicking OpenStack Compute nodes
subnet 192.168.241.0 netmask 255.255.255.0 {
     option routers             192.168.241.1;
     option domain-name-servers 192.168.241.10;
     option domain-name         "example.com";
     option subnet-mask         255.255.255.0;
     filename                   "/pxelinux.0";
     next-server                192.168.241.10;
}

#import re
#set $tag_pattern = $re.compile("^cobbler_A")
#for dhcp_tag in $dhcp_tags.keys():
#unless $tag_pattern.match($dhcp_tag) # <-- add the if statement
#continue                                         #       after this line to 
#end unless                                             #       determine next_server
# group for Cobbler DHCP tag: $dhcp_tag
group {
        #for mac in $dhcp_tags[$dhcp_tag].keys():
            #set iface = $dhcp_tags[$dhcp_tag][$mac]
    host $iface.name {
        hardware ethernet $mac;
        #if $iface.ip_address:
        fixed-address $iface.ip_address;
        #end if
        #if $iface.hostname:
        option host-name "$iface.hostname";
        #end if
        #if $iface.subnet:
        option subnet-mask $iface.netmask;
        #end if
        #if $iface.gateway:
        option routers $iface.gateway;
        #end if
        filename "$iface.filename";
        ## Cobbler defaults to $next_server, but some users
        ## may like to use $iface.system.server for proxied setups
        next-server $iface.next_server;
    }
        #end for
}
#end for

On Thu, May 5, 2016 at 9:50 PM, Tory M Blue <tmblue@gmail.com> wrote:
Okay just circling back.

So some of this was my misunderstanding and my days of trying to
modify the "template" (it's not the actual kickstart file), as well as
mis understanding what Cobbler's role in this whole thing was. So what
I was after was not really even possible, thanks to NACC on the
#cobbler irc channel, he was able to straighten out my terminology.

So ya Cobbler has no idea and never will (unless you go static!) what
my clients IP is. This is really an anaconda/pxe issue and not
Cobbler, Cobbler is creating the kickstart files and stuff out of my
template, so really I need to attack this from a different angle.. So
this was much more of me not understanding Cobbler's role in my
pxebooting process.

NACC found me some cool stuff via the pxelinux and some stuff I can do
there to get the right information (prevent PXE from traversing the
network)..

May not get me 100%, but I'm a much better person now that my
misconceptions have been cleared up.

Sorry Cobbler this was on me, not you!!

Thanks for everyones assistance!

Tory
_______________________________________________
cobbler mailing list
cobbler@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/cobbler@lists.fedorahosted.org



--
\*..+.-
--Greg Chavez
+//..;};