Enterprise Linux 7 Dynamic network cards fix (ref #4171)

[vStone]

Uses fedora's network configuration for RedHat and CentOS 7.

Possibly fixes #4171 but I doubt this is the 'cleanest' way. Pointers
welcome.

[hnakamur]

@vStone Hi, thanks for your fix! No comment for a cleaner way for 20 days. How about merging this pull request now? I myself downloaded https://github.com/vStone/vagrant-centos7_fix and am happy with it (Thanks for the fix too!).
However it would be easy for my colleagues if this is merged to the Vagrant core.

[khiro]

LGTM, I think this pr will fix #4078 and #4107.

[mitchellh]

Hm. I like that this fixes it but wonder if there is a cleaner way. I'm going to hold this open for now as the issue-fixer but I'm going to play around and see if I can get a cleaner fix in. Thanks!

[bemeyert]

@mitchellh We cannot use CentOS7 boxes because of this. So we would really appreciate this fix or any other in production. Thanks!

[vStone]

@bemeyert use

vagrant plugin install vagrant-centos7_fix

while mitchellh figures this out :)

[bemeyert]

Thx, that did the trick. I'm happy that the plugin exists. But this code should be in Vagrant.

[bemeyert]

OK, it worked on my Linux box. But on my colleagues Mac came this:

"An error occurred while installing nokogiri (1.6.3.1), and Bundler cannot continue.
 Make sure that `gem install nokogiri -v '1.6.3.1'` succeeds before bundling."

 sudo gem install nokogiri -v 1.6.3.1 funktioniert auch nicht:

 "libiconv is missing"

And he is using the official DMG 1.6.3 from the download site. A lot of people will use our CentOS 7 box. It would have been ok to upgrade Vagrant or even to install above plugin. But fixing things like the above is too much. @mitchellh Can you please figure this out a bit faster? ;)

[vStone]

@bemeyert: its unclear if you are having problems with my temporary centos7 fix. If so, please file a bug here: https://github.com/vStone/vagrant-centos7_fix/issues although I'm not clear on why this dependency is pulled in since I dont list any.

[bemeyert]

@vStone Thanks a lot, I will forward this to my colleague.

[filex]

the installation problems, which @bemeyert has mentioned, seem to be the same issue like sparklemotion/nokogiri#1140. it works on one mac but doesn't on another with the same OS version. most likely the reason is not within the centos7-fix-plugin.

[fsalum]

Hi.

Is this fix going to be merged ?

[ghost]

@vStone

vagrant plugin install vagrant-centos7_fix

Vagrant 1.6.3
Centos7

has fix the bug

The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

ARPCHECK=no /sbin/ifup eth1 2> /dev/null

Stdout from the command:

Stderr from the command:

it work good!

ths!

[andytson]

The only way I see this can be cleaner is if capabilities are separated from their guests and included

[andytson]

e.g. the reason this capability needs to be implemented is because either:

• redhat - redhat-based OS introducted it - no it's a specific set of versions of it and other future OS's
• systemd - Systemd provides the functionality - yes
• consistent-network-device-naming - it was introduced to provide Consistent Network Device Naming - yes but may be a bit too specific

so we have a folder plugins/guest-capabilities/systemd/cap/configure_networks, systemd/plugin checks for systemd in use on guest, and adds it's configure_networks capability to the guest

[mitchellh]

Fixed.

@andytson I agree the whole RedHat/Fedora guests could be handled a lot better. They're all so similar they should really fall under the same guest. Notice the "flavor" switch I do now. I think this is a better approach for now. For things such as consistent network device naming, extracting helpers out would be helpful for multiple guests.

[purpleidea]

Yikes! Cute patch... Anyways, can someone confirm that the "rhel_7" machine.guest.capability("flavor") is also returned for centos 7... ?

[mitchellh]

@purpleidea It should be, I copied the same regex used in this PR.

[purpleidea]

@mitchellh cool, thanks.
btw, a quick look through: https://github.com/mitchellh/vagrant/blob/master/plugins/guests/fedora/cap/configure_networks.rb

but without any testing makes me think this might need patching too... Keep in mind that newer fedora ~19/20 work quite differently network wise from early fedora...

[mitchellh]

Let me know. I just copied this patch to make it work, which others are saying work.

[misheska]

I don't think this works - at least not for CentOS 7. I'm using the image 'box-cutter/centos7' on vagrantcloud. No issues with VirtualBox and public networks, only with VMware Fusion. Though my image is using the new-style network addresses. Here' s the output of ls /sys/class/net:

ls /sys/class/net | grep -v lo
ens32
ens33

No eth0 or eth1, but again, this works fine on VirtualBox.

[purpleidea]

This works for me on CentOS-7 and vagrant-libvirt.
Here is a box you can test with:
https://download.gluster.org/pub/gluster/purpleidea/vagrant/centos-7.0/

On Wed, Sep 10, 2014 at 4:28 PM, Mischa Taylor notifications@github.com
wrote:

I don't think this works - at least not for CentOS 7. I'm using the image
'box-cutter/centos7' on vagrantcloud. No issues with VirtualBox and public
networks, only with VMware Fusion. Though my image is using the new-style
network addresses. Here' s the output of ls /sys/class/net:

ls /sys/class/net | grep -v lo
ens32
ens33

No eth0 or eth1, but again, this works fine on VirtualBox.

—
Reply to this email directly or view it on GitHub
#4195 (comment).

[Xylakant]

Libvirt seems to assign eth0, 1... as interface names, so the issue would not occur there.

[owenallenaz]

I ran into this issue this issue today and did some testing around it. I believe it may provide some insight in tracking it down.

I'm using Vagrant 1.6.5 on Windows with VirtualBox.

If I vagrant up a box with NO private networking using a CentOS-6.3-x86_64-minimal.box from vagrant boxes. If I then vagrant package that box. I can vagrant up into the packaged box just fine, whether I do private networking or not.

Now, if I vagrant up a box WITH private networking using the same CentOS-6.3-x86_64-minimal.box. If I then vagrant package that box. I cannot vagrant up into the subsequent box whether I have private networking or not enabled.

So basically if I have private networking enabled when I package the box I permanently get the ARPCHECK=no /sbin/ifup eth1 2> /dev/null that @hawaii162162 mentioned. If I don't have it enabled, then I don't have the problem at all.

[jnardiello]

I'm having exactly the same issue as @owenallenaz . Not sure why.

[Gabelbombe]

Seems like this has duplicate effects on Oracle boxes as well, what was the root cause of this so I can implement a fix on Oracles side?

[andytson]

@ehime Its because RHEL 7 derivatives are the first to change from SysVInit to systemd out of all RHEL derivatives Vagrant has supported. Each has their own /etc/redhat-release text that needs to be checked by the flavours.rb regex. Oracle linux can be fixed by updating the regex to include a match Oracle linux's release 7 text

[khaije1]

I'm seeing exact same error on my CentOS v5 Virtualbox VM boxes.
Is there something I can do to test if this is the same error and if some variation of the same fix would work?