Unclear on why cobbler is not updating dhcpd.conf, I have omapi management disabled and the stock dhcp.template modified slightly to support a private subnet in one of my labs. Cobbler check looks ok, cobbler sync obviously fails to restart dhcpd because the file never gets written out. Does my template look correct (its the stock template) dhcpd_bin: /usr/sbin/dhcpd dhcpd_conf: /etc/dhcpd.conf manage_dhcp: 1 omapi_enabled: 0 omapi_port: 647 restart_dhcp: 1
# ****************************************************************** # 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. # # ******************************************************************
ddns-update-style interim;
allow booting; allow bootp; #if $omapi_enabled omapi-port $omapi_port; #end if
ignore client-updates; set vendorclass = option vendor-class-identifier;
subnet 192.168.125.0 netmask 255.255.255.0 { option domain-name-servers 192.168.125.32; option subnet-mask 255.255.255.0; filename "/pxelinux.0"; default-lease-time 21600; max-lease-time 43200; next-server $next_server; }
#for dhcp_tag in $dhcp_tags.keys(): ## group could be subnet if your dhcp tags line up with your subnets ## or really any valid dhcpd.conf construct ... if you only use the ## default dhcp tag in cobbler, the group block can be deleted for a ## flat configuration # 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.subnet: option subnet-mask $iface.subnet; #end if #if $iface.gateway: option routers $iface.gateway; #end if #if $iface.system.netboot_enabled: filename "$iface.filename"; ## Cobbler defaults to $next_server, but some users ## like to use $iface.system.server for proxied setups next-server $next_server; ## next-server $iface.system.server; #end if } #end for } #end for
Christopher Johnston wrote:
Unclear on why cobbler is not updating dhcpd.conf, I have omapi management disabled and the stock dhcp.template modified slightly to support a private subnet in one of my labs. Cobbler check looks ok, cobbler sync obviously fails to restart dhcpd because the file never gets written out. Does my template look correct (its the stock template)
dhcpd_bin: /usr/sbin/dhcpd dhcpd_conf: /etc/dhcpd.conf manage_dhcp: 1 omapi_enabled: 0 omapi_port: 647 restart_dhcp: 1
and manage_dhcp: 1 in your cobbler settings ?
Tom Brown wrote:
Christopher Johnston wrote:
Unclear on why cobbler is not updating dhcpd.conf, I have omapi management disabled and the stock dhcp.template modified slightly to support a private subnet in one of my labs. Cobbler check looks ok, cobbler sync obviously fails to restart dhcpd because the file never gets written out. Does my template look correct (its the stock template)
dhcpd_bin: /usr/sbin/dhcpd dhcpd_conf: /etc/dhcpd.conf manage_dhcp: 1 omapi_enabled: 0 omapi_port: 647 restart_dhcp: 1
and manage_dhcp: 1 in your cobbler settings ?
although i think thats what you meant by above and its too early for me!
Christopher Johnston wrote:
Unclear on why cobbler is not updating dhcpd.conf, I have omapi management disabled and the stock dhcp.template modified slightly to support a private subnet in one of my labs. Cobbler check looks ok, cobbler sync obviously fails to restart dhcpd because the file never gets written out. Does my template look correct (its the stock template)
dhcpd_bin: /usr/sbin/dhcpd dhcpd_conf: /etc/dhcpd.conf manage_dhcp: 1 omapi_enabled: 0 omapi_port: 647 restart_dhcp: 1
Some ideas and things to check:
0) You've possibly never run "cobbler sync", as that's needed to create and update the file. 1) You might possibly have the dnsmasq module enabled instead in /etc/cobbler/modules.conf, in which case it won't be generating /etc/dhcp.conf but instead the configuration file for dnsmasq. The ISC version is the default. 2) You might also have not restarted cobblerd yet after making the above changes? 3) What version of cobbler is installed? (rpm -q cobbler)
--Michael
# ****************************************************************** # 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. # # ******************************************************************
ddns-update-style interim;
allow booting; allow bootp; #if $omapi_enabled omapi-port $omapi_port; #end if
ignore client-updates; set vendorclass = option vendor-class-identifier;
subnet 192.168.125.0 http://192.168.125.0 netmask 255.255.255.0 http://255.255.255.0 { option domain-name-servers 192.168.125.32 http://192.168.125.32; option subnet-mask 255.255.255.0 http://255.255.255.0; filename "/pxelinux.0"; default-lease-time 21600; max-lease-time 43200; next-server $next_server; }
#for dhcp_tag in $dhcp_tags.keys(): ## group could be subnet if your dhcp tags line up with your subnets ## or really any valid dhcpd.conf construct ... if you only use the ## default dhcp tag in cobbler, the group block can be deleted for a ## flat configuration # 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 http://iface.name { hardware ethernet $mac; #if $iface.ip_address: fixed-address $iface.ip_address; #end if #if $iface.subnet: option subnet-mask $iface.subnet; #end if #if $iface.gateway: option routers $iface.gateway; #end if #if $iface.system.netboot_enabled: filename "$iface.filename"; ## Cobbler defaults to $next_server, but some users ## like to use $iface.system.server for proxied setups next-server $next_server; ## next-server $iface.system.server; #end if } #end for } #end for
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
0) ran many times -- dhcp trigger kicks off but no file is generated 1) manage_isc is setup in modules.conf 2) yes restarted a few times 3) I have tried 1.2.8-1, 1.3.1-1, 1.3.2-1
Is there any way to enable debuguging with cobbler as to print more information out in the logs, ie debug statements of what functions are being called without modifying the code? I resorted to running an strace and I noticed a function called write_dhcp_file does indeed get called.
*stat("/usr/lib/python2.4/site-packages/cobbler/modules/manage_dnsmasq", 0x7fff631cc5c0) = -1 ENOENT (No such file or directory)*
*open("/usr/lib/python2.4/site-packages/cobbler/modules/manage_dnsmasq.so", O_RDONLY) = -1 ENOENT (No such file or directory)*
*open("/usr/lib/python2.4/site-packages/cobbler/modules/manage_dnsmasqmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory)*
*open("/usr/lib/python2.4/site-packages/cobbler/modules/manage_dnsmasq.py", O_RDONLY) = 5*
*fstat(5, {st_mode=S_IFREG|0644, st_size=7271, ...}) = 0*
*open("/usr/lib/python2.4/site-packages/cobbler/modules/manage_dnsmasq.pyc", O_RDONLY) = 6*
*fstat(6, {st_mode=S_IFREG|0644, st_size=6051, ...}) = 0*
*mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b844de7c000*
*read(6, "m\362\r\np\270\332Hc\0\0\0\0\0\0\0\0\3\0\0\0@\0\0\0s\340\0\0\0d\0"..., 4096) = 4096*
*fstat(6, {st_mode=S_IFREG|0644, st_size=6051, ...}) = 0*
*read(6, "\0\0write_dhcp_fileM\0\0\0sZ\0\0\0\0\4\0\2\f\1"..., 4096) = 1955*
*read(6, "", 4096) = 0*
*close(6) = 0*
On Sun, Nov 30, 2008 at 12:35 PM, Michael DeHaan mdehaan@redhat.com wrote:
Christopher Johnston wrote:
Unclear on why cobbler is not updating dhcpd.conf, I have omapi management disabled and the stock dhcp.template modified slightly to support a private subnet in one of my labs. Cobbler check looks ok, cobbler sync obviously fails to restart dhcpd because the file never gets written out. Does my template look correct (its the stock template)
dhcpd_bin: /usr/sbin/dhcpd dhcpd_conf: /etc/dhcpd.conf manage_dhcp: 1 omapi_enabled: 0 omapi_port: 647 restart_dhcp: 1
Some ideas and things to check:
- You've possibly never run "cobbler sync", as that's needed to create
and update the file.
- You might possibly have the dnsmasq module enabled instead in
/etc/cobbler/modules.conf, in which case it won't be generating /etc/dhcp.conf but instead the configuration file for dnsmasq. The ISC version is the default. 2) You might also have not restarted cobblerd yet after making the above changes? 3) What version of cobbler is installed? (rpm -q cobbler)
--Michael
# ****************************************************************** # 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. # # ******************************************************************
ddns-update-style interim;
allow booting; allow bootp; #if $omapi_enabled omapi-port $omapi_port; #end if
ignore client-updates; set vendorclass = option vendor-class-identifier;
subnet 192.168.125.0 http://192.168.125.0 netmask 255.255.255.0 http://255.255.255.0 { option domain-name-servers 192.168.125.32 http://192.168.125.32; option subnet-mask 255.255.255.0 http://255.255.255.0; filename "/pxelinux.0"; default-lease-time 21600; max-lease-time 43200; next-server $next_server; }
#for dhcp_tag in $dhcp_tags.keys(): ## group could be subnet if your dhcp tags line up with your subnets ## or really any valid dhcpd.conf construct ... if you only use the ## default dhcp tag in cobbler, the group block can be deleted for a ## flat configuration # 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 http://iface.name { hardware ethernet $mac; #if $iface.ip_address: fixed-address $iface.ip_address; #end if #if $iface.subnet: option subnet-mask $iface.subnet; #end if #if $iface.gateway: option routers $iface.gateway; #end if #if $iface.system.netboot_enabled: filename "$iface.filename"; ## Cobbler defaults to $next_server, but some users ## like to use $iface.system.server for proxied setups next-server $next_server; ## next-server $iface.system.server; #end if } #end for } #end for
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Christopher Johnston wrote:
- ran many times -- dhcp trigger kicks off but no file is generated
- manage_isc is setup in modules.conf
- yes restarted a few times
- I have tried 1.2.8-1, 1.3.1-1, 1.3.2-1
Is there any way to enable debuguging with cobbler as to print more information out in the logs, ie debug statements of what functions are being called without modifying the code? I resorted to running an strace and I noticed a function called write_dhcp_file does indeed get called.
There's no "extra heavy" debug mode other than what is already written to the log file.
If you'd like to email me your settings, modules.conf, dhcp.template (all from /etc/cobbler) and /var/lib/cobbler/config/* in a tarball I can perhaps try to see if I can replicate this on my end.
I'd say we would have definitely heard of this on 1.2.8 so it's going to be something specific to your configuration most likely... though I can't guarantee I can repro it that is the first thing to try.
--Michael
*stat("/usr/lib/python2.4/site-packages/cobbler/modules/manage_dnsmasq", 0x7fff631cc5c0) = -1 ENOENT (No such file or directory)*
*open("/usr/lib/python2.4/site-packages/cobbler/modules/manage_dnsmasq.so", O_RDONLY) = -1 ENOENT (No such file or directory)*
*open("/usr/lib/python2.4/site-packages/cobbler/modules/manage_dnsmasqmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory)*
*open("/usr/lib/python2.4/site-packages/cobbler/modules/manage_dnsmasq.py", O_RDONLY) = 5*
*fstat(5, {st_mode=S_IFREG|0644, st_size=7271, ...}) = 0*
*open("/usr/lib/python2.4/site-packages/cobbler/modules/manage_dnsmasq.pyc", O_RDONLY) = 6*
*fstat(6, {st_mode=S_IFREG|0644, st_size=6051, ...}) = 0*
*mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b844de7c000*
*read(6, "m\362\r\np\270\332Hc\0\0\0\0\0\0\0\0\3\0\0\0@\0\0\0s\340\0\0\0d\0"..., 4096) = 4096*
*fstat(6, {st_mode=S_IFREG|0644, st_size=6051, ...}) = 0*
*read(6, "\0\0write_dhcp_fileM\0\0\0sZ\0\0\0\0\4\0\2\f\1"..., 4096) = 1955*
*read(6, "", 4096) = 0*
*close(6) = 0*
On Sun, Nov 30, 2008 at 12:35 PM, Michael DeHaan <mdehaan@redhat.com mailto:mdehaan@redhat.com> wrote:
Christopher Johnston wrote: > Unclear on why cobbler is not updating dhcpd.conf, I have omapi > management disabled and the stock dhcp.template modified slightly to > support a private subnet in one of my labs. Cobbler check looks ok, > cobbler sync obviously fails to restart dhcpd because the file never > gets written out. Does my template look correct (its the stock template) > > dhcpd_bin: /usr/sbin/dhcpd > dhcpd_conf: /etc/dhcpd.conf > manage_dhcp: 1 > omapi_enabled: 0 > omapi_port: 647 > restart_dhcp: 1 > > Some ideas and things to check: 0) You've possibly never run "cobbler sync", as that's needed to create and update the file. 1) You might possibly have the dnsmasq module enabled instead in /etc/cobbler/modules.conf, in which case it won't be generating /etc/dhcp.conf but instead the configuration file for dnsmasq. The ISC version is the default. 2) You might also have not restarted cobblerd yet after making the above changes? 3) What version of cobbler is installed? (rpm -q cobbler) --Michael > > # ****************************************************************** > # 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. > # > # ****************************************************************** > > ddns-update-style interim; > > allow booting; > allow bootp; > #if $omapi_enabled > omapi-port $omapi_port; > #end if > > ignore client-updates; > set vendorclass = option vendor-class-identifier; > > subnet 192.168.125.0 <http://192.168.125.0> <http://192.168.125.0> netmask 255.255.255.0 <http://255.255.255.0> > <http://255.255.255.0> { > option domain-name-servers 192.168.125.32 <http://192.168.125.32> <http://192.168.125.32>; > option subnet-mask 255.255.255.0 <http://255.255.255.0> <http://255.255.255.0>; > filename "/pxelinux.0"; > default-lease-time 21600; > max-lease-time 43200; > next-server $next_server; > } > > #for dhcp_tag in $dhcp_tags.keys(): > ## group could be subnet if your dhcp tags line up with your subnets > ## or really any valid dhcpd.conf construct ... if you only use the > ## default dhcp tag in cobbler, the group block can be deleted for a > ## flat configuration > # 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 <http://iface.name> <http://iface.name> { > hardware ethernet $mac; > #if $iface.ip_address: > fixed-address $iface.ip_address; > #end if > #if $iface.subnet: > option subnet-mask $iface.subnet; > #end if > #if $iface.gateway: > option routers $iface.gateway; > #end if > #if $iface.system.netboot_enabled: > filename "$iface.filename"; > ## Cobbler defaults to $next_server, but some users > ## like to use $iface.system.server for proxied setups > next-server $next_server; > ## next-server $iface.system.server; > #end if > } > #end for > } > #end for > > ------------------------------------------------------------------------ > > _______________________________________________ > cobbler mailing list > cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > https://fedorahosted.org/mailman/listinfo/cobbler > _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Michael DeHaan wrote:
Christopher Johnston wrote:
- ran many times -- dhcp trigger kicks off but no file is generated
- manage_isc is setup in modules.conf
- yes restarted a few times
- I have tried 1.2.8-1, 1.3.1-1, 1.3.2-1
Is there any way to enable debuguging with cobbler as to print more information out in the logs, ie debug statements of what functions are being called without modifying the code? I resorted to running an strace and I noticed a function called write_dhcp_file does indeed get called.
There's no "extra heavy" debug mode other than what is already written to the log file.
If you'd like to email me your settings, modules.conf, dhcp.template (all from /etc/cobbler) and /var/lib/cobbler/config/* in a tarball I can perhaps try to see if I can replicate this on my end.
I'd say we would have definitely heard of this on 1.2.8 so it's going to be something specific to your configuration most likely... though I can't guarantee I can repro it that is the first thing to try.
--Michael
*stat("/usr/lib/python2.4/site-packages/cobbler/modules/manage_dnsmasq", 0x7fff631cc5c0) = -1 ENOENT (No such file or directory)*
*open("/usr/lib/python2.4/site-packages/cobbler/modules/manage_dnsmasq.so", O_RDONLY) = -1 ENOENT (No such file or directory)*
*open("/usr/lib/python2.4/site-packages/cobbler/modules/manage_dnsmasqmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory)*
*open("/usr/lib/python2.4/site-packages/cobbler/modules/manage_dnsmasq.py", O_RDONLY) = 5*
*fstat(5, {st_mode=S_IFREG|0644, st_size=7271, ...}) = 0*
*open("/usr/lib/python2.4/site-packages/cobbler/modules/manage_dnsmasq.pyc", O_RDONLY) = 6*
*fstat(6, {st_mode=S_IFREG|0644, st_size=6051, ...}) = 0*
*mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b844de7c000*
*read(6, "m\362\r\np\270\332Hc\0\0\0\0\0\0\0\0\3\0\0\0@\0\0\0s\340\0\0\0d\0"..., 4096) = 4096*
*fstat(6, {st_mode=S_IFREG|0644, st_size=6051, ...}) = 0*
*read(6, "\0\0write_dhcp_fileM\0\0\0sZ\0\0\0\0\4\0\2\f\1"..., 4096) = 1955*
*read(6, "", 4096) = 0*
*close(6) = 0*
On Sun, Nov 30, 2008 at 12:35 PM, Michael DeHaan <mdehaan@redhat.com mailto:mdehaan@redhat.com> wrote:
Christopher Johnston wrote: > Unclear on why cobbler is not updating dhcpd.conf, I have omapi > management disabled and the stock dhcp.template modified slightly to > support a private subnet in one of my labs. Cobbler check looks ok, > cobbler sync obviously fails to restart dhcpd because the file never > gets written out. Does my template look correct (its the stock template) > > dhcpd_bin: /usr/sbin/dhcpd > dhcpd_conf: /etc/dhcpd.conf > manage_dhcp: 1 > omapi_enabled: 0 > omapi_port: 647 > restart_dhcp: 1 > > Some ideas and things to check: 0) You've possibly never run "cobbler sync", as that's needed to create and update the file. 1) You might possibly have the dnsmasq module enabled instead in /etc/cobbler/modules.conf, in which case it won't be generating /etc/dhcp.conf but instead the configuration file for dnsmasq. The ISC version is the default. 2) You might also have not restarted cobblerd yet after making the above changes? 3) What version of cobbler is installed? (rpm -q cobbler) --Michael > > # ****************************************************************** > # 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. > # > # ****************************************************************** > > ddns-update-style interim; > > allow booting; > allow bootp; > #if $omapi_enabled > omapi-port $omapi_port; > #end if > > ignore client-updates; > set vendorclass = option vendor-class-identifier; > > subnet 192.168.125.0 <http://192.168.125.0> <http://192.168.125.0> netmask 255.255.255.0 <http://255.255.255.0> > <http://255.255.255.0> { > option domain-name-servers 192.168.125.32 <http://192.168.125.32> <http://192.168.125.32>; > option subnet-mask 255.255.255.0 <http://255.255.255.0> <http://255.255.255.0>; > filename "/pxelinux.0"; > default-lease-time 21600; > max-lease-time 43200; > next-server $next_server; > } > > #for dhcp_tag in $dhcp_tags.keys(): > ## group could be subnet if your dhcp tags line up with your subnets > ## or really any valid dhcpd.conf construct ... if you only use the > ## default dhcp tag in cobbler, the group block can be deleted for a > ## flat configuration > # 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 <http://iface.name> <http://iface.name> { > hardware ethernet $mac; > #if $iface.ip_address: > fixed-address $iface.ip_address; > #end if > #if $iface.subnet: > option subnet-mask $iface.subnet; > #end if > #if $iface.gateway: > option routers $iface.gateway; > #end if > #if $iface.system.netboot_enabled: > filename "$iface.filename"; > ## Cobbler defaults to $next_server, but some users > ## like to use $iface.system.server for proxied setups > next-server $next_server; > ## next-server $iface.system.server; > #end if > } > #end for > } > #end for > > ------------------------------------------------------------------------ > > _______________________________________________ > cobbler mailing list > cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > https://fedorahosted.org/mailman/listinfo/cobbler > _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
We narrowed this down on IRC.
In 1.3.X, the template should contain $gateway not iface.gateway, hence the error.
This will be correct for 1.3.X (look out for .rpmnew's when upgrading) and I'll look into making the error reporting better.
Hi,
I think I'm running into a similar problem with DHCP. I just installed Fedora 10, and am trying to setup cobbler.
I did all the cobbler check tasks, but dhcpd is not starting when starting cobblerd or running cobbler sync. I tried tail /var/log/messages to see if anything got logged, but there's nothing.
I also tried changing changing all cases of iface.gateway to gateway, and still no love.
Thoughts (I pasted settings and dhcp.template below)?
TIA, - Ole
P.S. This is my dhcp.template: # ****************************************************************** # Cobbler managed dhcpd.conf file # # generated from cobbler dhcp.conf template ($date) # # ******************************************************************
ddns-update-style interim;
allow booting; allow bootp; #if $omapi_enabled omapi-port $omapi_port; #end if
ignore client-updates; set vendorclass = option vendor-class-identifier;
subnet 192.168.1.0 netmask 255.255.255.0 { option routers 192.168.1.1; option subnet-mask 255.255.255.0; range dynamic-bootp 192.168.1.2 192.168.1.254; filename "/pxelinux.0"; default-lease-time 21600; max-lease-time 43200; next-server $next_server; }
#for dhcp_tag in $dhcp_tags.keys(): ## group could be subnet if your dhcp tags line up with your subnets ## or really any valid dhcpd.conf construct ... if you only use the ## default dhcp tag in cobbler, the group block can be deleted for a ## flat configuration # 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.subnet: option subnet-mask $iface.subnet; #end if #if $gateway: option routers $gateway; #end if #if $iface.system.netboot_enabled: filename "$iface.filename"; ## Cobbler defaults to $next_server, but some users ## like to use $iface.system.server for proxied setups next-server $next_server; ## next-server $iface.system.server; #end if } #end for } #end for
=======================================
--- # cobbler settings file # restart cobblerd and consider running "cobbler sync" after making changes # (it's a good idea to make backups too) # # This config file is in YAML 1.0 format # see http://yaml.org # # if 1, cobbler will allow insertions of system records that duplicate # the mac address information of other system records. In general, # this is undesirable. allow_duplicate_macs: 0
# if 1, cobbler will allow insertions of system records that duplicate # the ip address information of other system records. In general, # this is undesirable. allow_duplicate_ips: 0
# the path to BIND's executable for this distribution. bind_bin: /usr/sbin/named
# if no kickstart is specified, use this template (FIXME) default_kickstart: /etc/cobbler/default.ks
# for libvirt based installs in koan, if no virt bridge # is specified, which bridge do we try? default_virt_bridge: xenbr0
# if koan is invoked without --virt-type and no virt-type # is set on the profile/system, what virtualization type # should be assumed? Values: xenpv, xenfv, qemu, vmware # (NOTE: this does not change what virt_type is chosen by import) default_virt_type: xenpv
# use this as the default disk size for virt guests (GB) default_virt_file_size: 5
# use this as the default memory size for virt guests (MB) default_virt_ram: 512
# if using the authz_ownership module (see the Wiki), objects # created without specifying an owner are assigned to this # owner and/or group. Can be a comma seperated list. default_ownership: "admin"
# location for some important binaries and config files # that can vary based on the distribution. dhcpd_bin: /usr/sbin/dhcpd dhcpd_conf: /etc/dhcpd.conf dnsmasq_bin: /usr/sbin/dnsmasq dnsmasq_conf: /etc/dnsmasq.conf httpd_bin: /usr/sbin/httpd
# change this port if Apache is not running plaintext on port # 80. Most people can leave this alone. http_port: 80
# kernel options that should be present in every cobbler installation. # kernel options can also be applied at the distro/profile/system # level. kernel_options: ksdevice: eth0 lang: ' ' text: ~
# configuration options if using the authn_ldap module. See the # the Wiki for details. This can be ignored if you are not using # LDAP for WebUI/XMLRPC authentication. ldap_server: "ldap.example.com" ldap_base_dn: "DC=example,DC=com" ldap_port: 389 ldap_tls: 1 ldap_anonymous_bind: 1 ldap_search_bind_dn: '' ldap_search_passwd: '' ldap_search_prefix: 'uid='
# set to 1 to enable Cobbler's DHCP management features. # the choice of DHCP management engine is in /etc/cobbler/modules.conf manage_dhcp: 1
# set to 1 to enable Cobbler's DNS management features. # the choice of DNS mangement engine is in /etc/cobbler/modules.conf manage_dns: 0
# if using BIND (named) for DNS management in /etc/cobbler/modules.conf # and manage_dns is enabled (above), this lists which zones are managed # See the Wiki (https://fedorahosted.org/cobbler/wiki/ManageDns) for more info manage_forward_zones: [] manage_reverse_zones: []
# location where cobbler will write its named.conf when BIND dns management is # enabled named_conf: /etc/named.conf
# if using cobbler with manage_dhcp, put the IP address # of the cobbler server here so that PXE booting guests can find it # if you do not set this correctly, this will be manifested in TFTP open timeouts. next_server: '192.168.1.6'
# if using cobbler with manage_dhcp and ISC, omapi allows realtime DHCP # updates without restarting ISC dhcpd. omapi_enabled: 1 omapi_port: 647 omshell_bin: /usr/bin/omshell
# if this setting is set to 1, cobbler systems that pxe boot # will request at the end of their installation to toggle the # --netboot-enabled record in the cobbler system record. This eliminates # the potential for a PXE boot loop if the system is set to PXE # first in it's BIOS order. Enable this if PXE is first in your BIOS # boot order, otherwise leave this disabled. See the manpage # for --netboot-enabled. pxe_just_once: 0
# when DHCP and DNS management are enabled, cobbler sync can automatically # restart those services to apply changes. The exception for this is # if using ISC for DHCP, then omapi eliminates the need for a restart. # If DHCP and DNS are going to be managed, but hosted on a box that # is not on this server, disable restarts here and write some other # script to ensure that the config files get copied/rsynced to the destination # box. This can be done by modifying the restart services trigger. # Note that if manage_dhcp and manage_dns are disabled, the respective # parameter will have no effect. Most users should not need to change # this. restart_dns: 1 restart_dhcp: 1
# if set to 1, new systems doing profile based installations will # contact cobbler to have system records created for them containing # the mac address information that they have requested for install. # this effectively allows for registration of new hardware via PXE # without having to manually enter in all of the mac addresses for # every machine on your network register_new_installs: 0
# install triggers are scripts in /var/lib/cobbler/triggers/install # that are triggered in kickstart pre and post sections. Any # executable script in those directories is run. They can be used # to send email or perform other actions. They are currently # run as root so if you do not need this functionality you can # disable it, though this will also disable "cobbler status" which # uses a logging trigger to audit install progress. run_install_triggers: 1
# this is the address of the cobbler server -- as it is used # by systems during the install process, it must be the address # or hostname of the system as those systems can see the server. # if you have a server that appears differently to different subnets # (dual homed, etc), you need to read the --server-override section # of the manpage for how that works. server: '192.168.1.6'
# this is a directory of files that cobbler uses to make # templating easier. See the Wiki for more information. Changing # this directory should not be required. snippetsdir: /var/lib/cobbler/snippets
# if modules.conf specifies authn_spacewalk, this is the XMLRPC # endpoint to authenticate against. If Satellite/Spacewalk is # not in use, ignore this setting entirely. # See fedorahosted.org/spacewalk for details on that project. spacewalk_url: "http://satellite.example.com/rpc/api"
# by default, installs are set to send syslog traffic on this port # and cobblerd will listen on this port. syslog data (for installs # that support it... RHEL 5 and later, etc) is logged in /var/log/cobbler # and can be used to help debug problematic installations. Syslog # is UDP and may not be available depending on network/firewall configuration. syslog_port: 25150
# locations of the TFTP binary and config file tftpd_bin: /usr/sbin/in.tftpd tftpd_conf: /etc/xinetd.d/tftp
# cobbler's web directory. Don't change this setting -- see the # Wiki on "relocating your cobbler install" if your /var partition # is not large enough. webdir: /var/www/cobbler
# cobbler's public XMLRPC listens on this port. Change this only # if absolutely needed, as you'll have to start supplying a new # port option to koan if it is not the default. xmlrpc_port: 25151
# cobbler's read write XMLRPC is the version of XMLRPC # used by the WebUI and some features like system registration. # XMLRPC connections here require login information to access. # this feature can be disabled to gain increased security but # will disable the WebUI, registration, and potentially other # cobbler features. Most users should leave XMLRPC RW # enabled. The port can be relocated if needed. xmlrpc_rw_enabled: 1 xmlrpc_rw_port: 25152
# "cobbler repo add" commands set cobbler up with repository # information that can be used during kickstart and is automatically # set up in the cobbler kickstart templates. By default, these # are only available at install time. To make these repositories # usable on installed systems (since cobbler makes a very convient) # mirror, set this to 1. Most users can safely set this to 1. Users # who have a dual homed cobbler server, or are installing laptops that # will not always have access to the cobbler server may wish to leave # this as 0. In that case, the cobbler mirrored yum repos are still # accessable at http://cobbler.example.org/cblr/repo_mirror and yum # configuration can still be done manually. This is just a shortcut. yum_post_install_mirror: 0
# additional flags to yum commands yumreposync_flags: "-l" yumdownloader_flags: "--resolve"
Ole Ersoy wrote:
Hi,
I think I'm running into a similar problem with DHCP. I just installed Fedora 10, and am trying to setup cobbler.
I did all the cobbler check tasks, but dhcpd is not starting when starting cobblerd or running cobbler sync. I tried tail /var/log/messages to see if anything got logged, but there's nothing.
I also tried changing changing all cases of iface.gateway to gateway, and still no love.
Thoughts (I pasted settings and dhcp.template below)?
Disable omapi (set omapi_enabled to 0), restart cobblerd, and then cobbler sync.
That should do it.
($iface.gateway works fine in the latest development branch or 1.2.9, no template change is required anymore.)
--Michael
Hi,
I'm trying out cobbler on Fedora 10. I noticed that SELinux denies cobbler access to:
./menu.c32
Also I see the following in the log:
Dec 4 16:15:03 ole setroubleshoot: SELinux is preventing in.tftpd (tftpd_t) "read" to ./vmlinuz-PAE (httpd_sys_content_t). For complete SELinux messages. run sealert -l ed35d123-47b4-4dee-89ee-ccb9e95497b4
This caused the pxe booting to spin constantly printing the message: Could not find kernel image: /images/fedora10-i386/vmlinuz-PAE
After disabling SELinux everything worked fine.
I pasted the selinux summary below. Please let me know if I should add a ticket for this. I did run the command: setsebool -P httpd_can_network_connect true
prior to attempting the run.
Below is the summary of the ./menu.c32 denial.
Cheers, Ole
Summary:
SELinux is preventing in.tftpd (tftpd_t) "read" to ./menu.c32 (var_lib_t).
Detailed Description:
SELinux denied access requested by in.tftpd. It is not expected that this access is required by in.tftpd and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access.
Allowing Access:
Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for ./menu.c32,
restorecon -v './menu.c32'
If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package.
Additional Information:
Source Context system_u:system_r:tftpd_t:s0-s0:c0.c1023 Target Context system_u:object_r:var_lib_t:s0 Target Objects ./menu.c32 [ file ] Source in.tftpd Source Path /usr/sbin/in.tftpd Port <Unknown> Source RPM Packages tftp-server-0.48-6.fc10 Target RPM Packages Policy RPM selinux-policy-3.5.13-26.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Alert Count 4 First Seen Thu 04 Dec 2008 03:23:19 PM CST Last Seen Thu 04 Dec 2008 03:54:57 PM CST Local ID be33bc6a-3d9c-47bb-8451-8deb16997450 Line Numbers
Ole Ersoy wrote:
Hi,
I'm trying out cobbler on Fedora 10. I noticed that SELinux denies cobbler access to:
./menu.c32
Also I see the following in the log:
Dec 4 16:15:03 ole setroubleshoot: SELinux is preventing in.tftpd (tftpd_t) "read" to ./vmlinuz-PAE (httpd_sys_content_t). For complete SELinux messages. run sealert -l ed35d123-47b4-4dee-89ee-ccb9e95497b4
This caused the pxe booting to spin constantly printing the message: Could not find kernel image: /images/fedora10-i386/vmlinuz-PAE
After disabling SELinux everything worked fine.
I pasted the selinux summary below. Please let me know if I should add a ticket for this. I did run the command: setsebool -P httpd_can_network_connect true
prior to attempting the run.
Below is the summary of the ./menu.c32 denial.
Cheers, Ole
Summary:
SELinux is preventing in.tftpd (tftpd_t) "read" to ./menu.c32 (var_lib_t).
Detailed Description:
SELinux denied access requested by in.tftpd. It is not expected that this access is required by in.tftpd and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access.
Allowing Access:
Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for ./menu.c32,
restorecon -v './menu.c32'
If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package.
Additional Information:
Source Context system_u:system_r:tftpd_t:s0-s0:c0.c1023 Target Context system_u:object_r:var_lib_t:s0 Target Objects ./menu.c32 [ file ] Source in.tftpd Source Path /usr/sbin/in.tftpd Port <Unknown> Source RPM Packages tftp-server-0.48-6.fc10 Target RPM Packages Policy RPM selinux-policy-3.5.13-26.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Alert Count 4 First Seen Thu 04 Dec 2008 03:23:19 PM CST Last Seen Thu 04 Dec 2008 03:54:57 PM CST Local ID be33bc6a-3d9c-47bb-8451-8deb16997450 Line Numbers _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Appreciate the report, changing SELinux policies are always fun.
can you please file a bug at http://fedorahosted.org/cobbler ?
(Accounts: https://admin.fedoraproject.org/accounts)
We can probably get this in for 1.4.0, if not, a fix release shortly after.
Thanks!
--Michael
Hi,
I had dhcp working fine. Then after rebooting the cobbler client in order to try another install attempt, I noticed that my voice over IP device had stolen the IP that the cobbler client wants. So I reconfigured dhcpd.conf to use a different IP for the cobbler client. Now the cobbler client times out when attempting to get a lease.
I tried uninstalling and reinstalling dhcp and then starting with a clean configuration, but there's still no love. I also tried looking at the log and there's no logged requests for a dhcp lease.
Any ideas on how to reset this?
TIA, - Ole
On Thu, Dec 4, 2008 at 9:38 PM, Ole Ersoy ole.ersoy@gmail.com wrote:
Hi,
I had dhcp working fine. Then after rebooting the cobbler client in order to try another install attempt, I noticed that my voice over IP device had stolen the IP that the cobbler client wants. So I reconfigured dhcpd.conf to use a different IP for the cobbler client. Now the cobbler client times out when attempting to get a lease.
I tried uninstalling and reinstalling dhcp and then starting with a clean configuration, but there's still no love. I also tried looking at the log and there's no logged requests for a dhcp lease.
cobbler system report --name $system_name
Take a look at the netboot line and it is probably set to false. After you kickstart a server, it turns the netboot flag to false to keep from accidentally rekickstarting it again.
Try: cobbler system edit --name $system_name --netboot 1 && cobbler sync. Then reboot the box again.
Any ideas on how to reset this?
Also take a look at the file: /tftpboot/pxelinux.cfg/$mac-address before and after the sync as it contains the boot configuration.
Jeff Schroeder wrote:
On Thu, Dec 4, 2008 at 9:38 PM, Ole Ersoy ole.ersoy@gmail.com wrote:
Hi,
I had dhcp working fine. Then after rebooting the cobbler client in order to try another install attempt, I noticed that my voice over IP device had stolen the IP that the cobbler client wants. So I reconfigured dhcpd.conf to use a different IP for the cobbler client. Now the cobbler client times out when attempting to get a lease.
I tried uninstalling and reinstalling dhcp and then starting with a clean configuration, but there's still no love. I also tried looking at the log and there's no logged requests for a dhcp lease.
cobbler system report --name $system_name
Take a look at the netboot line and it is probably set to false. After you kickstart a server, it turns the netboot flag to false to keep from accidentally rekickstarting it again.
Try: cobbler system edit --name $system_name --netboot 1 && cobbler sync. Then reboot the box again.
FYI -- Toggling the netboot enabled flag should have no affect on the DHCP config. You can use cobbler system records to manage DHCP for systems that never get installed by cobbler.
Any ideas on how to reset this?
Also take a look at the file: /tftpboot/pxelinux.cfg/$mac-address before and after the sync as it contains the boot configuration.
I think he's reporting a DHCP problem which is before the stage where the bootloader talks to the TFTP server.
Hi Guys,
Thanks for all the feedback. Let me provide a little more context in case that's helpful. I'm starting the DHCP server manually (Not during boot with chkconfig dhcpd on). That was working fine before, so I assume that's OK?
Currently I do the following: disable selinux service iptables stop service httpd start service cobblerd start service dhcpd start cobbler sync
This was working fine in the very beginning, however there was a hickup with cobbler sync not restarting the dhcp server (It was generating /etc/dhcpd.conf though), so we turned omapi_enabled to 0. Now it restarts the dhcp server. However, it also stopped regenerating /etc/dhpcd.conf. So I'm editing /etc/dhcpd.conf manually and then running cobbler sync, which AFAIK just restarts dhcpd for me. If I try setting omapi_enabled to 1 again, and running cobbler sync, I get this:
[root@ole ole]# cobbler sync dhcpctl_connect: connection refused dhcpctl_connect: connection refused
I'm going to give it another try listing my exact steps:
cobbler profile add --name=bb.example.com.fedora10 --distro=fedora10-i386 --kickstart=/etc/cobbler/fedora10_i386_bb_template.ks
cobbler system add --name=bb.example.com --hostname=bb.example.com --profile=bb.example.com.fedora10 --mac=00:16:ec:cc:d1:f6 --ip=192.168.1.7
Cobbler Check ----------------------------------------------- [root@ole ole]# cobbler check The following potential problems were detected: #0: since iptables may be running, ensure 69, 80, 25150, and 25151 are unblocked #1: One or more kickstart templates references default password 'cobbler' and should be changed for security reasons: /etc/cobbler/sample.ks, /etc/cobbler/legacy.ks, /etc/cobbler/sample_end.ks
IPTables Off ----------------------------------------------- [root@ole ole]# service iptables stop iptables: Flushing firewall rules: [ OK ] iptables: Setting chains to policy ACCEPT: filter [ OK ] iptables: Unloading modules: [ OK ]
Cobbler Sync ----------------------------------------------- [root@ole ole]# cobbler sync Shutting down dhcpd: [ OK ] Starting dhcpd: [ OK ]
/etc/dhcpd.conf looks like this prior to the cobbler sync:
# ****************************************************************** # Cobbler managed dhcpd.conf file # generated from cobbler dhcp.conf template (Thu Dec 4 20:25:14 2008) # ******************************************************************
ddns-update-style interim;
allow booting; allow bootp;
ignore client-updates; set vendorclass = option vendor-class-identifier;
subnet 192.168.1.0 netmask 255.255.255.0 { option routers 192.168.1.1; option subnet-mask 255.255.255.0; range dynamic-bootp 192.168.1.2 192.168.1.254; filename "/pxelinux.0"; default-lease-time 21600; max-lease-time 43200; next-server 192.168.1.6; }
host bb.mydemandchain.com { hardware ethernet 00:16:ec:cc:d1:f6; fixed-address 192.168.1.7; option host-name "bb.example.com"; }
Now everything should be ready to go, so I'm going to reboot the target machine that wants to pxe install. I also made sure that I turned off dhcp on the router prior to doing this.
The result is: PXE-E51: No DHCP or dhcpPROXY lease offered.
I tried examining the log which looks like this:
[root@ole ole]# tail /var/log/messages Dec 5 10:12:38 ole dhcpd: Copyright 2004-2007 Internet Systems Consortium. Dec 5 10:12:38 ole dhcpd: All rights reserved. Dec 5 10:12:38 ole dhcpd: For info, please visit http://www.isc.org/sw/dhcp/ Dec 5 10:12:38 ole dhcpd: Not searching LDAP since ldap-server, ldap-port and ldap-base-dn were not specified in the config file Dec 5 10:12:38 ole dhcpd: Wrote 0 deleted host decls to leases file. Dec 5 10:12:38 ole dhcpd: Wrote 0 new dynamic host decls to leases file. Dec 5 10:12:38 ole dhcpd: Wrote 1 leases to leases file. Dec 5 10:12:38 ole dhcpd: Listening on LPF/eth0/00:0e:a6:65:57:99/192.168.1.0/24 Dec 5 10:12:38 ole dhcpd: Sending on LPF/eth0/00:0e:a6:65:57:99/192.168.1.0/24 Dec 5 10:12:38 ole dhcpd: Sending on Socket/fallback/fallback-net
Does anything look off?
Thanks again, - Ole
Ole Ersoy wrote:
Hi,
I had dhcp working fine. Then after rebooting the cobbler client in order to try another install attempt, I noticed that my voice over IP device had stolen the IP that the cobbler client wants. So I reconfigured dhcpd.conf to use a different IP for the cobbler client. Now the cobbler client times out when attempting to get a lease.
I tried uninstalling and reinstalling dhcp and then starting with a clean configuration, but there's still no love. I also tried looking at the log and there's no logged requests for a dhcp lease.
Any ideas on how to reset this?
TIA,
- Ole
Do not configure dhcp.conf, cobbler overwrites it by design.
Edit /etc/cobbler/dhcpd.template to add static things or create cobbler system records to add MAC/IP mappings for your systems.
Also confirm that omapi is still disabled and you have dhcpd set to start up automatically when the system boots.
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
cobbler@lists.fedorahosted.org