Cobbler uses DHCP instead of a static IP

Hi,

We are using cobber to manage our machines for our satellite. Re are using satellite 5.5 with cobbler 2.0.7. Since our last upgrade, our VMWare Machines do not use the static IP anymore during kickstart.

NOTICE NetworkManager:    ifcfg-rh: Ignoring connection 'System eth0' and its device due to NM_CONTROLLED/BRIDGE/VLAN.

Before the upgrade, this worked.
We use this cobbler command to add the machine:

cobbler system add --name=thename --profile=theprofilename --hostname=thename --kopts="ksdevice=eth0 umgebung=LAN" --interface=eth0 --static=true --mac=00:50:56:9b:2e:c6 --ip=6.7.8.9 --subnet=255.255.255.0 --gateway=3.4.5.6 --name-servers=1.2.3.4

What are we doing wrong? I searched for different combinations of cobbler, NetworkManager, DHCP etc. but I did not find any usable answer. I hope this is a cobbler problem.

Cheers,
Paul

[James Cammarata]

On Mon, Oct 22, 2012 at 7:39 AM,   wrote:
> Hi,
>
> We are using cobber to manage our machines for our satellite. Re are using
> satellite 5.5 with cobbler 2.0.7. Since our last upgrade, our VMWare
> Machines do not use the static IP anymore during kickstart.
>
> NOTICE NetworkManager:    ifcfg-rh: Ignoring connection 'System eth0' and
> its device due to NM_CONTROLLED/BRIDGE/VLAN.
>
> Before the upgrade, this worked.
> We use this cobbler command to add the machine:
>
> cobbler system add --name=thename --profile=theprofilename
> --hostname=thename --kopts="ksdevice=eth0 umgebung=LAN" --interface=eth0
> --static=true --mac=00:50:56:9b:2e:c6 --ip=6.7.8.9 --subnet=255.255.255.0
> --gateway=3.4.5.6 --name-servers=1.2.3.4
>
> What are we doing wrong? I searched for different combinations of cobbler,
> NetworkManager, DHCP etc. but I did not find any usable answer. I hope this
> is a cobbler problem.

It would seem NetworkManager is interfering, eth0 doesn't exist
(em0/1?) or the MAC for that interface is incorrect. You can try
adding NM_CONTROLLED=no to the pre_install_network_config snippet (and
to the post version as well), though it may depend on during what
state of the kickstart it's trying to request a DHCP address.

Are you kickstarting RH guests on VMware hosts, or using
cobbler/satellite to kickstart the VMware host itself?

[Elliott Barrere]

I am having the same problem.  Cobbler 2.2.3.

I have checked that the MAC address and interface name matches the interface
that has a static IP assigned in cobbler, but Anaconda still prompts for an IP.
I have set management=true on the _other_ interface as well, so I would
expect cobbler to be using that interface to install.

[Zack Perry]

May I suggest you to check the following?

0. Do you use ISC DHCP server, or the dnsmasq? Does cobbler manage it?
1. Have you used cobbler system getks --name=... to check your rendered
   kickstart file? Do you see the desired IP in the rendered version?
2. Have you used cobbler cobbler system dumpvars --name=... to examine 
   all variables?
3. Have you checked your installation log and see what the actions 
   have been taken for your installation?

Typically, after the above four steps, and assuming for 0, you have 
*really* acquainted yourself with the respective man page of the 
two DHCP servers, you should be able to make a static IP assignment
for Red Hat alike systems without a hitch.

Per my first hand experience, with Red Hat alike systems, static IP
address assignment is quite doable. For Debian/Ubuntu, the presence 
of a DHCP server *NOT* under your control does take some doing, but 
still doable.

Worst comes to the worst, you have the cobbler built-in configuration
management features come to your rescue. I have found that the 
'Template Files' attribute for both profile and system objects, 
together with the bundled download snippet, as the last, but very
reliable, resort.

In fact, I use this mechanism for assigning static IP 
address to Debian/Ubuntu nodes (both physical and virtual) even when
I don't have control (or prefer not to control) the existing DHCP
server . Works like a charm.

Regards,

-- Zack
> I am having the same problem. 
> Cobbler 2.2.3.
>
> I have checked that the MAC address and interface name
> matches the interface that has a static IP assigned in cobbler, 
> but Anaconda still prompts for an IP. I have set management=true 
> on the _other_ interface as well, so I would
> expect cobbler to be using that interface to install.

[Elliott Barrere]

Zack Perry <zack.perry <at> sbcglobal.net> writes:

Hi there, thanks for the response.
> Do you use ISC DHCP server, or the dnsmasq? Does cobbler manage it?

There is no DHCP server on the subnet in question (the network eth0 is plugged
in to).  There _is_ a DHCP server on the eth1 subnet (the net the system is
supposed to boot from and use for install).  This server is managed by Cobbler.
> Have you used cobbler system getks --name=... to check your rendered
> kickstart file? Do you see the desired IP in the rendered version?

Everything looks fine in here.  I see static network configurations being >'d
in to sysconfig/network-scripts files.
> Have you used cobbler cobbler system dumpvars --name=... to examine 
> all variables?

The only thing that looks weird in here is "owner_eth*" and "hostname_eth*"
are set to the hostname of the copied system, rather than the system I'm
installing.  I don't know what these variables do or how to set them so I'm
not sure if it's a problem.
> Have you checked your installation log and see what the actions 
> have been taken for your installation?

I haven't gotten through the install process.  It stops and prompts for an
address at the very first step.  I've tried looking at the other consoles but
there isn't much there.  It is just setting up network cards and trying DHCP.
> Typically, after the above four steps, and assuming for 0, you have 
> *really* acquainted yourself with the respective man page of the 
> two DHCP servers, you should be able to make a static IP assignment
> for Red Hat alike systems without a hitch.

I'm not sure what you mean.  I shouldn't _need_ a DHCP server, right?
> Worst comes to the worst, you have the cobbler built-in configuration
> management features come to your rescue. I have found that the 
> 'Template Files' attribute for both profile and system objects, 
> together with the bundled download snippet, as the last, but very
> reliable, resort.

I'm happy to look in to this as an option, but I'm not sure where to start.
Any advice?

[Zack Perry]

> Hi there, thanks for the response.
> > Do you use ISC DHCP server, or the dnsmasq? Does
>
> cobbler manage it?
>
> There is no DHCP server on the subnet in question (the
> network eth0 is plugged in to).  There _is_ a DHCP server on the 
> eth1 subnet (the net the system is supposed to boot from and use 
> for install).  This server is managed by Cobbler.

That's OK. When you do PXE network install, a DHCP server is a 
mandatory component. Once installed, the system can use a different
network interface for production.  This is fine.
> > Have you used cobbler system getks --name=... to
>
> check your rendered kickstart file? Do you see the desired IP
> in the rendered version?
>
> Everything looks fine in here.  I see static network
> configurations being >'d in to sysconfig/network-scripts files.

OK.
> > Have you used cobbler cobbler system dumpvars
>
> --name=... to examine all variables?
>
> The only thing that looks weird in here is "owner_eth*" and
> "hostname_eth*" are set to the hostname of the copied system, 
> rather than the system I'm installing.  I don't know what these 
> variables do or how to set them so I'm not sure if it's a problem.

Not having the same environment, I am afraid that I can't be of much
help here. But...
> > Have you checked your installation log and see what
> >
> > the actions have been taken for your installation?
>
> I haven't gotten through the install process.  It stops
> and prompts for an address at the very first step.  I've tried 
> looking at the other consoles but there isn't much there.  It is 
> just setting up network cards and trying DHCP.

If your kickstart template has provided all necessary information,
then anaconda shouldn't prompt you for anything.  There are two ways
that you can do:

0. Use the kickstart logging option to log everything to a remote
   logging server
1. In /etc/cobbler/settings, turn on anamon, and use the anamon 
   snippets in the /var/lib/cobbler/snippets to help you get the
   installation log

Granted, the above logs won't appear until anaconda is started. So,
in case like this, I would use tcpdump to figure out what's going on.
> > Typically, after the above four steps, and assuming for
> > 0, you have *really* acquainted yourself with the respective man
> > page of the two DHCP servers, you should be able to make a static
> > IP assignment for Red Hat alike systems without a hitch.
>
> I'm not sure what you mean.  I shouldn't _need_ a DHCP
> server, right?

During PXE installation, you do. After installation, if your nodes
use static IP addresses, then the DHCP server is out of the
picture.
> > Worst comes to the worst, you have the cobbler built-in
> > configuration management features come to your rescue. I have 
> > found that the 'Template Files' attribute for both profile and 
> > system objects, together with the bundled download snippet, as 
> > the last, but very reliable, resort.
>
> I'm happy to look in to this as an option, but I'm not sure
> where to start.
> Any advice?

I would suggest you to get the PXE network install going without being
prompted for manual input first.  After that, if somehow your nodes
are still dependent on DHCP, then use the above suggestion.

Reference: http://cobbler.github.com/manuals/2.2.3/5/3/1_-_Built-In_Configuration_Manag...

HTH

-- Zack

[Elliott Barrere]

Zack Perry <zack.perry <at> sbcglobal.net> writes:
> That's OK. When you do PXE network install, a DHCP server is a 
> mandatory component. Once installed, the system can use a different
> network interface for production.  This is fine.

Figured.  That't the current setup.
> If your kickstart template has provided all necessary information,
> then anaconda shouldn't prompt you for anything.  There are two ways
> that you can do:
> Use the kickstart logging option to log everything to a remote
> logging server

Sounds like a nice option, however this is before the system has any IP 
addresses so I don't suppose it will be able to syslog remotely :)
> In /etc/cobbler/settings, turn on anamon, and use the anamon 
> snippets in the /var/lib/cobbler/snippets to help you get the
> installation log

I will look in to this.
> Granted, the above logs won't appear until anaconda is started. So,
> in case like this, I would use tcpdump to figure out what's going on.

It only gets to Anaconda init before trying DHCP, so I doubt either of the 
above log methods will work.  What would you look for in a packet capture?  I 
guess the kickstart file could be sniffed from the wire?
> During PXE installation, you do. After installation, if your nodes
> use static IP addresses, then the DHCP server is out of the
> picture.

Got it.  Thanks again for your help with this.

[Zack Perry]

[...]
> > Granted, the above logs won't appear until anaconda is
> > started. So, in case like this, I would use tcpdump to figure out
> > what's going on.
>
> It only gets to Anaconda init before trying DHCP, so I doubt
> either of the above log methods will work.  What would you look for
> in a packet capture?

[...]

If I really want to see what's going on, I would run tcpdump on the
node that runs cobbler, and records the traffic from the inception
of the PXE booting process, save it to a file, and review it using
wireshark UI (on the same node or your desktop).  That way, I can 
use wireshark's filter to do drill-down whenever I need.  Just a
suggestion.  You may prefer to use tcpdump directly. Some do.

[...]
> I guess the kickstart file could be sniffed from the wire?

[...]

All packets, if you wish ;-)

HTH

-- Zack

[Elliott Barrere]

Zack Perry <zack.perry <at> sbcglobal.net> writes:
> If I really want to see what's going on, I would run tcpdump on the
> node that runs cobbler, and records the traffic from the inception
> of the PXE booting process, save it to a file, and review it using
> wireshark UI (on the same node or your desktop).  That way, I can 
> use wireshark's filter to do drill-down whenever I need.  Just a
> suggestion.  You may prefer to use tcpdump directly. Some do.

I did exactly that right after posting my last message :)  I found some 
interesting stuff.

tcpdump saw no packets at all on eth1 until I backed out of the eth0 
configuration and selected eth1 as the install device.  I see the following in 
the cobbler-generated PXE configurations for BOTH interface MAC addresses:

label linux
        kernel /images/CentOS_5.8-x86_64/vmlinuz
        ipappend 2
        append initrd=/images/CentOS_5.8-x86_64/initrd.img ksdevice=bootif 
lang=  kssendmac nostorage text  ks=http://<CBLR_IP>/cblr/svc/op/ks/system/kvm2

Then I realized I actually used koan to install a grub boot record on this host 
(!), so it wouldn't use PXE at all.  I guess the question then is why koan 
wouldn't pick up the boot device from the Cobbler "Management Interface" 
property, rather than using ksdevice=link.  I _think_ that getting that set 
correctly might just solve my problem!

[Andrew Hamilton]

Hi,

On Thu, Nov 29, 2012 at 9:52 AM, Elliott Barrere wrote:
> Zack Perry <zack.perry <at> sbcglobal.net> writes:
> > That's OK. When you do PXE network install, a DHCP server is a
> > mandatory component. Once installed, the system can use a different
> > network interface for production.  This is fine.
>
> Figured.  That't the current setup.
> > If your kickstart template has provided all necessary information,
> > then anaconda shouldn't prompt you for anything.  There are two ways
> > that you can do:
> > Use the kickstart logging option to log everything to a remote
> > logging server
>
> Sounds like a nice option, however this is before the system has any IP
> addresses so I don't suppose it will be able to syslog remotely :)
> > In /etc/cobbler/settings, turn on anamon, and use the anamon
> > snippets in the /var/lib/cobbler/snippets to help you get the
> > installation log
>
> I will look in to this.
> > Granted, the above logs won't appear until anaconda is started. So,
> > in case like this, I would use tcpdump to figure out what's going on.
>
> It only gets to Anaconda init before trying DHCP, so I doubt either of the
> above log methods will work.  What would you look for in a packet capture?
>  I
> guess the kickstart file could be sniffed from the wire?

This isn't really and issue with the kickstart file as at this stage the
Anaconda installer hasn't downloaded it. The kickstart is downloaded after
the network has been setup. If you want to have eth1 used for DHCP you'll
need to change the "ksdevice" entry that is passed to the kernel by adding
"ksdevice=eth1" to the "Kernel Options" of the system (or profile). You can
also setup a static IP on an interface with kernel arguments as well.

http://www.centos.org/docs/5/html/Installation_Guide-en-US/s1-kickstart2-sta...

I'm not sure if this is totally what you're looking for but I hope it helps.

Regards,

Andrew
> > During PXE installation, you do. After installation, if your nodes
> > use static IP addresses, then the DHCP server is out of the
> > picture.
>
> Got it.  Thanks again for your help with this.
>
> cobbler mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/cobbler

[Elliott Barrere]

Andrew Hamilton <ahamilton55 <at> gmail.com> writes:
> This isn't really and issue with the kickstart file as at this stage the

Anaconda installer hasn't downloaded it. The kickstart is downloaded after the 
network has been setup. If you want to have eth1 used for DHCP you'll need to 
change the "ksdevice" entry that is passed to the kernel by adding 
"ksdevice=eth1" to the "Kernel Options" of the system (or profile). You can 
also setup a static IP on an interface with kernel arguments as well.
>

http://www.centos.org/docs/5/html/Installation_Guide-en-US/s1-kickstart2-sta...
ginstall.html
> I'm not sure if this is totally what you're looking for but I hope it helps.

That is great, thank you!  I didn't see this until I posted my last comment.

I have added the kopts as needed and it does seem to fix the issue.  It was my 
understanding that cobbler would automatically use the interface specified as 
"Management Interface".

http://answerpot.com/showthread.php?3183712-Management+interface%3F

Not that it's a deal-breaker, but it would be nice if that worked as expected.  
Ideas?

Thanks for everyone's help!