7:39 a.m.
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
7 p.m.
On Mon, Oct 22, 2012 at 7:39 AM, <Paul.Goessinger(a)dab.com> 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?
9:28 p.m.
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.
2:46 p.m.
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.
10:14 p.m.
Zack Perry <zack.perry <at> sbcglobal.net> writes:
Hi there, thanks for the response.
0. 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.
1. 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.
2. 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.
3. 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?
11:18 p.m.
Hi there, thanks for the response.
> 0. 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.
> 1. 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.
> 2. 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...
> 3. 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_Ma...
HTH
-- Zack
11:52 a.m.
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:
0. 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 :)
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
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.
12:29 p.m.
[...]
> 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
1:59 p.m.
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!
1 p.m.
Hi,
On Thu, Nov 29, 2012 at 9:52 AM, Elliott Barrere <elliott(a)mywedding.com>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:
>
> 0. 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 :)
> 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
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-...
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
cobbler(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/cobbler
2:12 p.m.
Andrew Hamilton <ahamilton55 <at> gmail.com> writes:
http://www.centos.org/docs/5/html/Installation_Guide-en-US/s1-kickstart2-...
ginstall.html
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.
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!
4170
days inactive
4208
days old
cobbler@lists.fedorahosted.org
10 comments
5 participants
participants (5)
-
Andrew Hamilton -
Elliott Barrere -
James Cammarata -
Paul.Goessinger＠dab.com -
Zack Perry