Hide Forgot
Description of problem: Network configuration for cloud-init isn't working. I have tried this syntax and variations on this theme: network-interfaces: | iface eth0 inet static address 192.168.1.10 netmask 255.255.255.0 broadcast 192.168.1.255 gateway 192.168.1.254 Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. Set up a network-interfaces section 2. boot 3. frown Actual results: Fedora Atomic defaults to DHCP and that is what is both configured and in /etc/sysconfig/network-scripts/ifcfg-eth0 Expected results: A static network configuration and proper information in /etc/sysconfig/network-scripts/ifcfg-eth0 Additional info:
Source for syntax (not perfect but the only reference online): http://cloudinit.readthedocs.org/en/latest/topics/datasources.html?highlight=netmask#no-cloud
Hi Brian, What atomic image are you using? I was able to manually do a build of http://koji.fedoraproject.org/koji/taskinfo?taskID=7290385 using virt-intstall and was able to get cloud-init to work with this sytax. Here is my meta-data: [root@vmhost ud]# cat meta-data instance-id: test0 hostname: mytest0 network-interfaces: | iface eth0 inet static address 192.168.122.240 network 192.168.122.0 netmask 255.255.255.0 broadcast 192.168.122.255 gateway 192.168.122.1 Here is what I see within the guest after attaching an iso with the meta/user data and booting: [root@localhost ~]# rpm -q cloud-init cloud-init-0.7.5-6.fc21.x86_64 [root@localhost ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 BOOTPROTO=static ONBOOT=no TYPE=Ethernet PERSISTENT_DHCLIENT=yes BROADCAST=192.168.122.255 NETMASK=255.255.255.0 IPADDR=192.168.122.240 GATEWAY=192.168.122.1 So it appears that it is working using the same syntax (different values) as what you used. Do you have any more details? Can you reproduce? If you are interested my virt-install command line is: virt-install --name atomtest --ram 2048 --vcpus 2 --disk path=/guests/test.img,size=10 --accelerate --network bridge=virbr0 --extra-args='ks=https://kojipkgs.fedoraproject.org//work/tasks/385/7290385/fedora-cloud-atomic-fc3e80c.ks' --location http://kojipkgs.fedoraproject.org/mash/branched-20140813/21/x86_64/os/ - Dusty
Hi Dusty, That is working for me now. The key was that the information goes in the meta-data file and not the user-data file. How would I have known this? I missed it somewhere and I'd like to know where so I can reference that. Thank you. regards, bex PS: I'll close this after your response.
I spoke too soon ... it appears that while the file is setup correctly, the machine still is booted with the device set to DHCP.
(In reply to Brian (bex) Exelbierd from comment #3) > Hi Dusty, > > That is working for me now. The key was that the information goes in the > meta-data file and not the user-data file. How would I have known this? I > missed it somewhere and I'd like to know where so I can reference that. > The documentation that you referenced earlier says that it is in 'metadata': "Also, you can inject an /etc/network/interfaces file by providing the content for that file in the network-interfaces field of metadata." I admit it's not extremely obvious but that is what the documentation said so I followed it.
(In reply to Brian (bex) Exelbierd from comment #4) > I spoke too soon ... it appears that while the file is setup correctly, the > machine still is booted with the device set to DHCP. Odd. Seem s to be working fine for me. My interface comes up with the address I requested and I don't see the dhclient process running as I observe on machines that are using dhcp. Can you provide any more details?
(In reply to Dusty Mabe from comment #5) > (In reply to Brian (bex) Exelbierd from comment #3) > The documentation that you referenced earlier says that it is in 'metadata': Yes it does. I must have been tired to have missed that in my reading :( (In reply to Dusty Mabe from comment #6) > (In reply to Brian (bex) Exelbierd from comment #4) > > I spoke too soon ... it appears that while the file is setup correctly, the > > machine still is booted with the device set to DHCP. > > Odd. Seem s to be working fine for me. My interface comes up with the > address I requested and I don't see the dhclient process running as I > observe on machines that are using dhcp. > > Can you provide any more details? I have some details below, however I would rather test with a newer qcow. What would it take to build one in koji (I am not familiar with the process)? Config: [bexelbie@dhcp-2-218 fedora-test]$ cat meta-data instance-id: FedoraAtomic0 local-hostname: FedoraAtomic0 network-interfaces: | iface eth0 inet static address 192.168.122.240 network 192.168.122.0 netmask 255.255.255.0 broadcast 192.168.122.255 gateway 192.168.122.1 First boot network config: [root@FedoraAtomic0 foobar]# ip a s 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group ... 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:f3:22:ec brd ff:ff:ff:ff:ff:ff inet 192.168.122.158/24 brd 192.168.122.255 scope global dynamic eth0 valid_lft 3255sec preferred_lft 3255sec inet6 fe80::5054:ff:fef3:22ec/64 scope link valid_lft forever preferred_lft forever [root@FedoraAtomic0 foobar]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 BOOTPROTO=static ONBOOT=no TYPE=Ethernet PERSISTENT_DHCLIENT=yes BROADCAST=192.168.122.255 NETMASK=255.255.255.0 IPADDR=192.168.122.240 GATEWAY=192.168.122.1 [root@FedoraAtomic0 foobar]# ps -ef | grep dhclient root 594 1 0 09:25 ? 00:00:00 /sbin/dhclient -H localhost -q -lf /var/lib/dhclient/dhclient--eth0.lease -pf /var/run/dhclient-eth0.pid eth0 cloud-init version: [root@FedoraAtomic0 foobar]# rpm -qi cloud-init Name : cloud-init Version : 0.7.5 Release : 6.fc21 Architecture: x86_64 Install Date: Fri 25 Jul 2014 10:53:11 AM UTC
(In reply to Brian (bex) Exelbierd from comment #7) You are right. I think I wasn't seeing dhclient before because I did the install manually and there is an automatic reboot in the kickstart (which means the system booted, then I shut it down and attached an iso with the ud/md). If I download the latest cloud image (https://kojipkgs.fedoraproject.org//work/tasks/3247/7413247/fedora-cloud-base-20140817-21.x86_64.qcow2) and do an import: virt-install --import --name test2 --ram 2048 --vcpus 2 --disk /guests/test2.qcow2 --disk /tmp/ud/test0-cidata.iso,device=cdrom --network bridge=virbr0 Then I do see dhclient still running. I wonder if this is also an issue upstream. Basically the problem boils down to the fact that cloud-init brings up the network(dhcp) to look for data sources. Later we then tell it what config we want and it populates the file and then does an ifup on eth0 but it never takes down eth0 first (which means dhclient gets left running). For me my interface does have the right IP address.. for now. dhclient (since it is still running) may later assign it the one from dhcp again. I'll make an attachment with some of the log details.
Created attachment 928339 [details] cloud-init log output
As suspected this is a bug in upstream as well: https://bugs.launchpad.net/cloud-init/+bug/1225922 On the plus side, at least for me, the interface did come up with the right configuration. Brian, you may want to try some of the workarounds in the linked bug report.
Thank you Dusty. The work arounds worked. I hope we will see some fixes upstream soon.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.