I am seeing the following.....
in my dhcp template i have
subnet 10.70.201.0 netmask 255.255.255.0 { next-server 10.70.201.217; filename "pxelinux.0"; default-lease-time 21600; max-lease-time 43200; }
so hosts in 10.70.201.x should have those network details however boxes in that network have a dhcp configuration generated that look like the below.
host generic3 { hardware ethernet 00:1f:29:e3:be:00; fixed-address 10.70.201.202; filename "/pxelinux.0"; next-server 10.70.205.7; }
the 'next-server' is wrong - any clue?
thanks
On Fri, Jun 12, 2009 at 5:29 AM, Tom Browntom@ng23.net wrote:
I am seeing the following.....
in my dhcp template i have
subnet 10.70.201.0 netmask 255.255.255.0 { next-server 10.70.201.217; filename "pxelinux.0"; default-lease-time 21600; max-lease-time 43200; }
so hosts in 10.70.201.x should have those network details however boxes in that network have a dhcp configuration generated that look like the below.
host generic3 { hardware ethernet 00:1f:29:e3:be:00; fixed-address 10.70.201.202; filename "/pxelinux.0"; next-server 10.70.205.7; }
the 'next-server' is wrong - any clue?
Is it being overwritten by the next_server directive in /etc/cobbler/settings? Here is how we get around that. Assuming you have a dns zone for every subnet you also do dhcp for, add a dns A or CNAME record from the name cobbler to whatever place it should be. Stuff like that allows us to cheat and use the same settings file everywhere. You could also just edit the template to not include the next-server line for each system record. It should be /etc/cobbler/dhcp.template. Does that work for you?
## Cobbler defaults to $next_server, but some users ## like to use $iface.system.server for proxied setups ## next-server $iface.next_server;
Is it being overwritten by the next_server directive in /etc/cobbler/settings? Here is how we get around that. Assuming you have a dns zone for every subnet you also do dhcp for, add a dns A or CNAME record from the name cobbler to whatever place it should be. Stuff like that allows us to cheat and use the same settings file everywhere. You could also just edit the template to not include the next-server line for each system record. It should be /etc/cobbler/dhcp.template. Does that work for you?
## Cobbler defaults to $next_server, but some users ## like to use $iface.system.server for proxied setups ## next-server $iface.next_server;
so setting next-server in the template does not mean that this is added into the dhcp config for hosts in that network ?
let me see what can be done in the template but it would be good if that type of thing were inherited
thanks
Is it being overwritten by the next_server directive in /etc/cobbler/settings? Here is how we get around that. Assuming you have a dns zone for every subnet you also do dhcp for, add a dns A or CNAME record from the name cobbler to whatever place it should be. Stuff like that allows us to cheat and use the same settings file everywhere. You could also just edit the template to not include the next-server line for each system record. It should be /etc/cobbler/dhcp.template. Does that work for you?
## Cobbler defaults to $next_server, but some users ## like to use $iface.system.server for proxied setups ## next-server $iface.next_server;
hmm - actually no as i kinda need the next_server to be in the dhcp config just like the option routers etc ??
On Fri, Jun 12, 2009 at 6:05 AM, Tom Browntom@ng23.net wrote:
Is it being overwritten by the next_server directive in /etc/cobbler/settings? Here is how we get around that. Assuming you have a dns zone for every subnet you also do dhcp for, add a dns A or CNAME record from the name cobbler to whatever place it should be. Stuff like that allows us to cheat and use the same settings file everywhere. You could also just edit the template to not include the next-server line for each system record. It should be /etc/cobbler/dhcp.template. Does that work for you?
## Cobbler defaults to $next_server, but some users ## like to use $iface.system.server for proxied setups ## next-server $iface.next_server;
hmm - actually no as i kinda need the next_server to be in the dhcp config just like the option routers etc ??
Not quite, those can all be inherited on a per-subnet basis. You don't have to do it on a per host basis but that happens to be how the shipping cobbler dhcp templates do it.
Not quite, those can all be inherited on a per-subnet basis. You don't have to do it on a per host basis but that happens to be how the shipping cobbler dhcp templates do it.
do you have an example of how they can be inherited on a subnet basis as seemingly the subnet settings in the template are being ignored ?
On Fri, Jun 12, 2009 at 6:10 AM, Tom Browntom@ng23.net wrote:
Not quite, those can all be inherited on a per-subnet basis. You don't have to do it on a per host basis but that happens to be how the shipping cobbler dhcp templates do it.
do you have an example of how they can be inherited on a subnet basis as seemingly the subnet settings in the template are being ignored ?
I meant that ISC dhcpd allows settings to be inherited on a per-subnet basis. Try commenting out the next-server line in the loop that happens for each host. Then declaring it for the subnet, doing a cobbler sync, and re dhcping. If you tcpdump on ports 67-69 on the dhcp server you should see the traffic exchange from both sides plus the tftp requested files. This is very likely an issue that can be solved by fudging the template a bit.
I meant that ISC dhcpd allows settings to be inherited on a per-subnet basis. Try commenting out the next-server line in the loop that happens for each host. Then declaring it for the subnet, doing a cobbler sync, and re dhcping. If you tcpdump on ports 67-69 on the dhcp server you should see the traffic exchange from both sides plus the tftp requested files. This is very likely an issue that can be solved by fudging the template a bit.
so if its 'blank' in that not in the host definition but in the subnet definition that will be inherited?
it would be very neat if that could be inherited into the config via the template on a host by host basis, although not sure how at the moment.
On Fri, Jun 12, 2009 at 7:08 AM, Tom Browntom@ng23.net wrote:
I meant that ISC dhcpd allows settings to be inherited on a per-subnet basis. Try commenting out the next-server line in the loop that happens for each host. Then declaring it for the subnet, doing a cobbler sync, and re dhcping. If you tcpdump on ports 67-69 on the dhcp server you should see the traffic exchange from both sides plus the tftp requested files. This is very likely an issue that can be solved by fudging the template a bit.
so if its 'blank' in that not in the host definition but in the subnet definition that will be inherited?
Well we have that exact same setup with RHEL and CentOS servers running ISC dhcpd 3.x before we started moving to newer hosts and cobbler. So my professional answer would be yup.
it would be very neat if that could be inherited into the config via the template on a host by host basis, although not sure how at the moment.
Michael seems great about accepting patches that improve the project, you might take a stab at it once you figure it out.
it would be very neat if that could be inherited into the config via the template on a host by host basis, although not sure how at the moment.
Michael seems great about accepting patches that improve the project, you might take a stab at it once you figure it out.
This was the original intent behind --dhcp-tag, which you can use to write your own templates that do things on a particular subnet by subnet basis. It's a bit of a hack though as it doesn't really model anything, it's just a field to key off of.
Having the next-server specifiable on a per-network-object-basis is probably what we'll want to do for 2.0.
Indeed, help in the development of that is very welcome.
--Michael
cobbler@lists.fedorahosted.org