Hello,
I’m a big fan of Foreman, I use it everywhere to spawn my virtual machines (mostly with VMWare vCenter or AWS) and then apply directly Puppet classes on it to get a fully configured new host in a few clicks. Maybe I’ll write about it one day, let’s see.
Anyway, this week theme was mostly “Let’s upgrade from Jessie to Stretch, I’m craving Python 3.5 and the new async/await syntax)”.
Sadly, it went wrong. I was unable to use my Foreman anymore against ESX 6.0 because when injecting the customization XML file (used to define IP settings within the VM through open-vm-tools) the resulting VM had no network set.
After looking at what happened, I figured out /etc/network/interfaces had been created wrong: instead of using eth0 (yes, I disabled predicitve interface name in my template) it was all set like the interface was named ether. Uh ?
Quick Google search with “debian stretch vmware ether” lead me to the following GitHub bug opened against open-vm-tools. Sadly the issue wouldn’t come from open-vm-tools: this issue comes from a VMWare script not parsing correctly current ifconfig output (yeah, I added net-tools in my template too).
Here is an extract of the net-tools package NEWS.Debian file:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
net-tools (1.60+git20161116.90da8a0-1) unstable; urgency=medium After 15 years without upstream development, net-tools is being worked on again, fixing many long-standing issues. The bad news is that the output of many commands has changed, and it is sure to break scripts that relied on parsing it. If you have customs scripts that use any of these commands, please make sure they still work after this upgrade: netstat, ifconfig, ipmaddr, iptunnel, mii-tool, nameif, plipconfig, rarp, route, slattach, arp. Apologies in advance for the trouble that this may cause, but maintaining a separate version of net-tools just to keep the old format is something I am not able to do. |
Wow, that’s a pretty dangerous move you did here….
The script creating the network configuration is actually a piece of Perl crap copied directly from the vCenter server into the VM filesystem. Yeah, that sounds like black magic but the good news is that’s it’s Perl, so it’s fixable.
So I searched for this “Customization.pm” file on my vCenter Windows server and I found it here:
C:\Program Files\VMware\vCenter Server\vpxd\imgcust\linux\imgcust-scripts\Customization.pm
I managed quite easily to understand what was wrong, and I must say that original output parsing was pretty cheap.
Anyway, here’s a better one that just works:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
+++ Customization.pm.new 2017-07-27 20:21:35.559476473 +0200 @@ -756,17 +756,17 @@ if (! defined $ifcfgResult) { $ifcfgResult = Utils::ExecuteCommand('/sbin/ifconfig -a'); } + + my @interfaces = split/\n\n/, $ifcfgResult; - my $result = undef; - - my $macAddressValid = ($macAddress =~ /^([0-9a-f]{2}:){5}[0-9a-f]{2}$/i); - - if ($macAddressValid && - ($ifcfgResult =~ /^\s*(\w+?)(:\w*)?\s+.*?$macAddress/mi)) { - $result = $1; + foreach my $interface (@interfaces) { + if ($interface =~ /$macAddress/) { + print($interface); + if ($interface =~ m/^(\w+)(:|\s)/) { + return $1; + } + } } - - return $result; } sub GetInterfaceByMacAddressIPAddrShow |
Nothing to restart, this file in copied everytime you apply customization to a template. You’ll find attached a text version of the patch: vcenter_Customization_pm.diff
Good luck!