9:20 p.m.
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
1:50 a.m.
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 ?
1:53 a.m.
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!
2:35 p.m.
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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
12:39 p.m.
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(a)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> 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(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/cobbler
>
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
12:43 p.m.
Christopher Johnston wrote:
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.
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(a)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(a)lists.fedorahosted.org
<mailto:cobbler@lists.fedorahosted.org>
> https://fedorahosted.org/mailman/listinfo/cobbler
>
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>
https://fedorahosted.org/mailman/listinfo/cobbler
------------------------------------------------------------------------
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
2:06 p.m.
Michael DeHaan wrote:
Christopher Johnston wrote:
> 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.
>
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(a)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(a)lists.fedorahosted.org
> <mailto:cobbler@lists.fedorahosted.org>
> > https://fedorahosted.org/mailman/listinfo/cobbler
> >
>
> _______________________________________________
> cobbler mailing list
> cobbler(a)lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>
> https://fedorahosted.org/mailman/listinfo/cobbler
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> cobbler mailing list
> cobbler(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/cobbler
>
>
_______________________________________________
cobbler mailing list
cobbler(a)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.
1:38 p.m.
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"
1:42 p.m.
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
4:56 p.m.
New subject: Notes From Fedora 10 Attempt
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
5:03 p.m.
New subject: Notes From Fedora 10 Attempt
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(a)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
11:38 p.m.
New subject: DHCP Stopped Working
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
1 a.m.
New subject: DHCP Stopped Working
On Thu, Dec 4, 2008 at 9:38 PM, Ole Ersoy <ole.ersoy(a)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
Don't drink and derive, alcohol and analysis don't mix.
http://www.digitalprognosis.com
7:02 a.m.
New subject: DHCP Stopped Working
Jeff Schroeder wrote:
On Thu, Dec 4, 2008 at 9:38 PM, Ole Ersoy <ole.ersoy(a)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.
10:28 a.m.
New subject: DHCP Stopped Working
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
7 a.m.
New subject: DHCP Stopped Working
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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
5629
days inactive
5637
days old
cobbler@lists.fedorahosted.org
16 comments
5 participants
participants (5)
-
Christopher Johnston -
Jeff Schroeder -
Michael DeHaan -
Ole Ersoy -
Tom Brown