Fedora 27 container has a problem

Discussion in 'Proxmox VE: Networking and Firewall' started by falves1, Jul 2, 2018.

Tags:
  1. falves1

    falves1 Member

    Joined:
    Jan 11, 2009
    Messages:
    65
    Likes Received:
    0
    I created a Fedora 27 container with a public IP address, but the resulting IP inside the container is DHCP. I am at a loss as how to fix this, since the configuration is correct. Is there an override to the automatic overwriting of network files?
     

    Attached Files:

  2. Richard

    Richard Proxmox Staff Member
    Staff Member

    Joined:
    Mar 6, 2015
    Messages:
    408
    Likes Received:
    10
    Seems to be a bug in the template - as workaround the following helps in some cases:

    Code:
    echo systemctl restart network > /etc/rc.local
    chmod 555 /etc/rc.local
    
    See also https://bugzilla.proxmox.com/show_bug.cgi?id=1519
     
    #2 Richard, Jul 9, 2018
    Last edited: Jul 9, 2018
  3. falves1

    falves1 Member

    Joined:
    Jan 11, 2009
    Messages:
    65
    Likes Received:
    0
    I found that all containers have the same issue. Proxmox rewrites the network and always sets erroneously the BOOTPROTO=none when it should not rewrite anything. Also it messes up the file /etc/resolv.conf, deleting what we put in the line DNS1=XX.X.XX.XX, and adding nameserver=192.168.0.1
    Proxmox must fix this. It was designes for NATted containers, but companies need to use public IPs, and we need to be able to set it and NOT be altered by Proxmox.
     
  4. Stoiko Ivanov

    Stoiko Ivanov Proxmox Staff Member
    Staff Member

    Joined:
    May 2, 2018
    Messages:
    196
    Likes Received:
    11
  5. falves1

    falves1 Member

    Joined:
    Jan 11, 2009
    Messages:
    65
    Likes Received:
    0
    No, it does not. The issue is this: if you set a static IP address in the configuration, at booting, the container still has BOOTPROTO=none, when it should be BOOTPROTO=static. Since it has BOOTPROTO=none, it defaults to DHCP.
    If I set "static" in the configuration, it has to migrate to the container as such.
     
  6. Stoiko Ivanov

    Stoiko Ivanov Proxmox Staff Member
    Staff Member

    Joined:
    May 2, 2018
    Messages:
    196
    Likes Received:
    11
    I think I successfully reproduced your problem.
    In my case the problem was related to systemd-networkd being enabled, whereas PVE's pre-boot scripts still work with the config in /etc/sysconfig/network-scripts.

    the container template has a file for eth0 in /etc/systemd/network/ - which is also where the dhcp configuration came from in my case.
    disabling systemd-networkd and enabling network.service and rebooting made the container use the static ip address.
    (I guess configuring systemd-networkd should also fix the problem).

    The .pve-ignore file was not necessary (but did work, in preventing PVE from touching the ifcfg-eth0 file).

    You can always manually set the container to unmanaged, then PVE does not touch the config at all.

    Just out of curiosity - where did you get the BOOTPROTO=static information (my RedHat/Fedora/CentOS knowledge is a bit rusty, and I didn't find anything with a quick search) - in my case BOOTPROTO=none worked.
     
  7. falves1

    falves1 Member

    Joined:
    Jan 11, 2009
    Messages:
    65
    Likes Received:
    0
    BOOTPROTO=none is wrong if you are to have any IP address, the right options are static or dhcp. "none" means the interface is UP but is not communicating with the network, nor it is advertising its presence. In the Debian world there is no "none", but the equivalent is "manual". I use it all the time when my containers share the same network interface and the box has two, one for accessing the box and the second one for container access to the world. This network model is called macvlan.
    As I said, if there is a BOOTPROTO=none, this is a bug in almost all scenarios. Proxmox should fix it.
     
  8. Stoiko Ivanov

    Stoiko Ivanov Proxmox Staff Member
    Staff Member

    Joined:
    May 2, 2018
    Messages:
    196
    Likes Received:
    11
    We addressed the issue by configuring the network via systemd-networkd for new fedora containers (since upstream, and fedora seem to have taken this road).

    pve-container > 2.0-25 contains the fix and containers created/started with it should work and configure the network as set in the container config.

    The package is currently on our testing repository and tests would be much appreciated (https://pve.proxmox.com/wiki/Package_Repositories)

    As for the BOOTPROTO=static - I can't find any reference to that being still supported in RHEL/CentOS >=5 (see e.g. [0], [1], [2]).

    [0] https://access.redhat.com/documenta...deployment_guide/s1-networkscripts-interfaces
    [1] https://github.com/cobbler/cobbler/issues/361
    [2] https://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-networkscripts-interfaces.html
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice