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 <[email protected]> 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
> [email protected]
> https://lists.fedorahosted.org/admin/lists/[email protected]
>



-- 
\*..+.-
--Greg Chavez
+//..;};
_______________________________________________
cobbler mailing list
[email protected]
https://lists.fedorahosted.org/admin/lists/[email protected]

Reply via email to