The private network with static ip is not activated when Guest OS starts #8250

xuanswe · 2017-02-02T21:53:37Z

Vagrant 1.9.1

Host operating system

Windows 10 Pro x64 - Version 1607 (OS Build 14393.693)

Guest operating system

CentOS 7.3-1611 x86_64

Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

  # overwrite default hardware configuration
  config.vm.provider "virtualbox" do |vb|
    vb.memory = 1024
    vb.cpus = 1
  end

  config.ssh.insert_key = false

  config.vm.define :server_dev do |server_dev|
    server_dev.vm.box = "bento/centos-7.3"
    server_dev.vm.network :private_network, ip: '10.0.0.100' # network interface "ifcfg-enp0s8" below
    server_dev.vm.network :forwarded_port, guest: 22, host: 2222, id: "ssh", auto_correct: true
  end
end

Expected behavior

The private network ifcfg-enp0s8 with static ip should be activated by default on startup!

Actual behavior: I must restart network service manually (or add inline shell to my Vagrantfile). The generated file ifcfg-enp0s8 is correct.

[vagrant@localhost ~]$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:8f:ef:23 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic enp0s3
       valid_lft 86379sec preferred_lft 86379sec
    inet6 fe80::65fb:b4a9:c70d:9156/64 scope link 
       valid_lft forever preferred_lft forever
3: enp0s8: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether 08:00:27:de:61:2a brd ff:ff:ff:ff:ff:ff

[vagrant@localhost ~]$ sudo less /etc/sysconfig/network-scripts/ifcfg-enp0s8
#VAGRANT-BEGIN
# The contents below are automatically generated by Vagrant. Do not modify.
NM_CONTROLLED=no
BOOTPROTO=none
ONBOOT=yes
IPADDR=10.0.0.100
NETMASK=255.255.255.0
DEVICE=enp0s8
PEERDNS=no
#VAGRANT-END

[vagrant@localhost ~]$ **sudo systemctl restart network**
[vagrant@localhost ~]$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:8f:ef:23 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic enp0s3
       valid_lft 86389sec preferred_lft 86389sec
    inet6 fe80::65fb:b4a9:c70d:9156/64 scope link 
       valid_lft forever preferred_lft forever
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:de:61:2a brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.100/24 brd 10.0.0.255 scope global enp0s8
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fede:612a/64 scope link 
       valid_lft forever preferred_lft forever

The text was updated successfully, but these errors were encountered:

mtbvang · 2017-02-03T07:47:52Z

+1

bystac · 2017-02-05T15:15:53Z

+1

dragomirr · 2017-02-06T13:54:25Z

+1 Host Ubuntu 16.04, guest CentOS7

albrin · 2017-02-06T14:40:40Z

+1

wmikefish · 2017-02-07T08:59:37Z

+1

Aga303 · 2017-02-08T11:43:28Z

+1

Hosts: Ubuntu 16.04.1 and OS X Sierra 10.12.3
Guest: CentOS7 (https://atlas.hashicorp.com/geerlingguy/boxes/centos7)

Restarting the network.service inside the box fixes the problem also here.

LukeCarrier · 2017-02-13T14:14:55Z

Same with an Ubuntu 16.10 host, CentOS 7.3.1611 guest.

Looks as though something screwy is going on in one of the network capabilities, as the wrong SELinux context is applied to an interface configuration file:

[vagrant@salt ~]$ sudo sealert -a /var/log/audit/audit.log
100% done
found 1 alerts in /var/log/audit/audit.log
--------------------------------------------------------------------------------

SELinux is preventing /usr/bin/python2.7 from open access on the file /etc/sysconfig/network-scripts/ifcfg-eth1.

*****  Plugin restorecon (99.5 confidence) suggests   ************************

If you want to fix the label. 
/etc/sysconfig/network-scripts/ifcfg-eth1 default label should be net_conf_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /etc/sysconfig/network-scripts/ifcfg-eth1

*****  Plugin catchall (1.49 confidence) suggests   **************************

If you believe that python2.7 should be allowed open access on the ifcfg-eth1 file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'firewalld' --raw | audit2allow -M my-firewalld
# semodule -i my-firewalld.pp


Additional Information:
Source Context                system_u:system_r:firewalld_t:s0
Target Context                unconfined_u:object_r:user_tmp_t:s0
Target Objects                /etc/sysconfig/network-scripts/ifcfg-eth1 [ file ]
Source                        firewalld
Source Path                   /usr/bin/python2.7
Port                          <Unknown>
Host                          <Unknown>
Source RPM Packages           python-2.7.5-48.el7.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-102.el7_3.7.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     salt.moodle
Platform                      Linux salt.moodle 3.10.0-514.2.2.el7.x86_64 #1 SMP
                              Tue Dec 6 23:06:41 UTC 2016 x86_64 x86_64
Alert Count                   12
First Seen                    2017-02-13 12:22:19 UTC
Last Seen                     2017-02-13 13:00:31 UTC
Local ID                      834462c8-0a0e-40b7-8467-de4414ba574a

Raw Audit Messages
type=AVC msg=audit(1486990831.248:416): avc:  denied  { open } for  pid=662 comm="firewalld" path="/etc/sysconfig/network-scripts/ifcfg-eth1" dev="dm-0" ino=100663382 scontext=system_u:system_r:firewalld_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file


type=SYSCALL msg=audit(1486990831.248:416): arch=x86_64 syscall=open success=no exit=EACCES a0=1c9c5c0 a1=0 a2=1b6 a3=24 items=0 ppid=1 pid=662 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=firewalld exe=/usr/bin/python2.7 subj=system_u:system_r:firewalld_t:s0 key=(null)

Hash: firewalld,firewalld_t,user_tmp_t,file,open

Fixes hashicorp#8250

LukeCarrier · 2017-02-13T17:21:33Z

My patch above doesn't completely fix this. It seems that Vagrant-configured interfaces don't come back after a restart; the SELinux policy violation above is simply because of firewalld reading the network configuration (and is a bug in its own right).

In this configuration, eth0 comes up, but not eth1:

[vagrant@salt ~]$ cat /etc/sysconfig/network-scripts/ifcfg-eth0 
DEVICE="eth0"
BOOTPROTO="dhcp"
ONBOOT="yes"
TYPE="Ethernet"
PERSISTENT_DHCLIENT="yes"
[vagrant@salt ~]$ cat /etc/sysconfig/network-scripts/ifcfg-eth1
#VAGRANT-BEGIN
# The contents below are automatically generated by Vagrant. Do not modify.
NM_CONTROLLED=no
BOOTPROTO=none
ONBOOT=yes
IPADDR=192.168.120.5
NETMASK=255.255.255.0
DEVICE=eth1
PEERDNS=no
#VAGRANT-END

Adding the following block to the redhat/configure_networks capability below the network service restart works:

          networks.each do |network|
            commands << "/sbin/ifup #{network[:device]}"
          end

mtbvang · 2017-02-17T09:30:24Z

Has anyone rolled back to a version of vagrant that doesn't have this issue? I'm on ubuntu 16.04 host and using the openshift-vagrant cdk image which is rhel 7.3 maipo.

killglance · 2017-02-22T21:51:58Z

@mtbvang I just hit the same issue with centos7.2 & 7.3.

I just downgraded to vagrant-1.9.0 and cannot reproduce the issue anymore. May be a possible workaround until this issue is resolved, but YMMV

vcultharris · 2017-02-24T20:29:51Z

Downgrading to vagrant 1.9.0 still had the problem for me.

harobed · 2017-03-01T09:25:35Z

Fixed in Vagrant 1.9.2 for me with this Guest:

# cat /etc/centos-release
CentOS Linux release 7.3.1611 (Core)

harobed · 2017-03-01T09:35:36Z

I think this issue is fixed by: #8096

chrisroberts · 2017-03-01T14:17:16Z

This is fixed in the 1.9.2 release via PR #8148. Thanks!

cheeseplus mentioned this issue Feb 9, 2017

Host only network with Centos 7 doesn't work chef/bento#752

Closed

LukeCarrier added a commit to LukeCarrier/vagrant that referenced this issue Feb 13, 2017

Correctly apply mode and labels to RHEL network-scripts

b676129

Fixes hashicorp#8250

LukeCarrier mentioned this issue Feb 13, 2017

Correctly apply mode and labels to RHEL network-scripts #8280

Closed

coolbrg mentioned this issue Feb 22, 2017

`vagrant service-manager install-cli openshift´ fails projectatomic/vagrant-service-manager#448

Open

harobed mentioned this issue Feb 22, 2017

Write etcd config file fails: no ipv4 address for eth1 kubernetes-retired/contrib#1573

Closed

cheeseplus mentioned this issue Feb 23, 2017

Vagrant 1.9.1 does not enable additional network interfaces for centos 7 test-kitchen/kitchen-vagrant#287

Closed

chrisroberts closed this as completed Mar 1, 2017

ghost locked and limited conversation to collaborators Apr 4, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

The private network with static ip is not activated when Guest OS starts #8250

The private network with static ip is not activated when Guest OS starts #8250

xuanswe commented Feb 2, 2017 •

edited

Loading

mtbvang commented Feb 3, 2017

bystac commented Feb 5, 2017

dragomirr commented Feb 6, 2017

albrin commented Feb 6, 2017

wmikefish commented Feb 7, 2017

Aga303 commented Feb 8, 2017 •

edited

Loading

LukeCarrier commented Feb 13, 2017 •

edited

Loading

LukeCarrier commented Feb 13, 2017

mtbvang commented Feb 17, 2017

killglance commented Feb 22, 2017

vcultharris commented Feb 24, 2017

harobed commented Mar 1, 2017

harobed commented Mar 1, 2017

chrisroberts commented Mar 1, 2017

The private network with static ip is not activated when Guest OS starts #8250

The private network with static ip is not activated when Guest OS starts #8250

Comments

xuanswe commented Feb 2, 2017 • edited Loading

Host operating system

Guest operating system

Vagrantfile

Expected behavior

Actual behavior: I must restart network service manually (or add inline shell to my Vagrantfile). The generated file ifcfg-enp0s8 is correct.

mtbvang commented Feb 3, 2017

bystac commented Feb 5, 2017

dragomirr commented Feb 6, 2017

albrin commented Feb 6, 2017

wmikefish commented Feb 7, 2017

Aga303 commented Feb 8, 2017 • edited Loading

LukeCarrier commented Feb 13, 2017 • edited Loading

LukeCarrier commented Feb 13, 2017

mtbvang commented Feb 17, 2017

killglance commented Feb 22, 2017

vcultharris commented Feb 24, 2017

harobed commented Mar 1, 2017

harobed commented Mar 1, 2017

chrisroberts commented Mar 1, 2017

xuanswe commented Feb 2, 2017 •

edited

Loading

Aga303 commented Feb 8, 2017 •

edited

Loading

LukeCarrier commented Feb 13, 2017 •

edited

Loading