On Fri, 2016-03-04 at 15:49 +0000, Tim Coote wrote: > > > > On 4 Mar 2016, at 15:03, Thomas Haller <[email protected]> wrote: > > > > On Fri, 2016-03-04 at 15:57 +0100, Thomas Haller wrote: > > > > > > On Fri, 2016-03-04 at 11:15 +0000, Tim Coote wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 4 Mar 2016, at 10:40, Thomas Haller <[email protected]> > > > > > wrote: > > > > > > > > > > On Fri, 2016-03-04 at 10:19 +0000, Tim Coote wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hullo > > > > > > > > > > > > I’m starting to migrate my fedora stock to NetworkManager. > > > > > > In > > > > > > one > > > > > > particular test scenario, I tried to create a direct copy > > > > > > of > > > > > > the > > > > > > final machine configuration using NM and the old "systemctl > > > > > > start > > > > > > network” approach. The VMs are temporally separated (ie I > > > > > > spin > > > > > > up > > > > > > the > > > > > > old one save interrogation results about configuration; > > > > > > kill it > > > > > > and > > > > > > repeat with the new one). The only differences between the > > > > > > two > > > > > > machines should be the hostnames (so that the puppet > > > > > > configuration > > > > > > knows them as different machines) and the mac addresses. > > > > > > > > > > > > One inconsistency that I’ve found is that the > > > > > > NetworkManager > > > > > > cannot > > > > > > seem to spin up a tunnel unless the ipv4 addresses differ > > > > > > between > > > > > > the > > > > > > VMs. For the NM controlled VM, pulling apart the actual > > > > > > command > > > > > > run, > > > > > > I see: > > > > > > [code] > > > > > > nmcli con up uuid 4a341ad1-3e31-7ee8-82ee-2019bf995ad8 > > > > > > <response> > > > > > > Error: Connection activation failed: No suitable device > > > > > > found > > > > > > for > > > > > > this connection. > > > > > > [/code] > > > > > > > > > > > > where the uuid represents the sit1 device. However, on the > > > > > > same > > > > > > VM > > > > > > (either directly invoked or by turning off NM and running > > > > > > ifup > > > > > > sit1): > > > > > > [code] > > > > > > /etc/sysconfig/network-scripts/ifup-sit sit1 > > > > > > [/code] > > > > > > > > > > > > spins up the tunnel. > > > > > > > > > > > > If I put the ‘copy’ VM on different IP address(es). NM > > > > > > seems > > > > > > happy to > > > > > > spin up the tunnel. Note that in both cases there are no > > > > > > conflicting > > > > > > computers/ip addresses on the network at the same time. > > > > > > > > > > > > Am I (probabably) seeing the intended behaviour for NM - in > > > > > > which > > > > > > case I need to modify my testing approach - or do I need to > > > > > > dig > > > > > > further to confirm a bug? > > > > > > > > > > > > tia > > > > > Hi, > > > > > > > > > > > > > > > which version of NetworkManager? > > > > > > > > > > what gives > > > > > nmcli connection show 4a341ad1-3e31-7ee8-82ee-2019bf995ad8 > > > > > and how does the corresponding ifcfg-file look? > > > > > cat /etc/sysconfig/network-scripts/ifcfg-* > > > > > > > > > > > > > > > Thanks, > > > > > Thomas > > > Hi Tim, > > > > > > > > > Side note: usually it's better to answer with "reply-all", > > > because > > > then > > > the mailing list might help you. > > > > > > > > > > > > > > > > > > Sorry. I wasn’t intending to get into debugging my setup, more > > > > trying > > > > to understand what the design should do. > > > > > > > > in any case: > > > > > > > > NetworkManager-1.0.6-6.fc23.x86_64 (stock f23) > > > Note that this is not the most recent version on f23. Ithould be > > > 1.0.10. > > > > > > > > > > > > > > > > > > > > > > > > the nmcli connection … was gleaned from running sh -x > > > > usr/sbin/ifup > > > > sit1. /usr/sbin/ifup comes from initscripts-9.64- > > > > 1.fc23.x86_64 > > > > > > > > nb. these are the versions of the files that work. To break the > > > > configuration I change the IP addresses from 172.17.1.9 to > > > > 172.17.1.10 and from 192.168.31.61 to 192.168.31.60 throughout. > > > > > > > > /etc/sysconfig/network-scripts/ifcfg-eth0 > > > > # Broadcom Corporation NetXtreme BCM5751M Gigabit Ethernet PCI > > > > Express > > > > DEVICE=eth0 > > > > # temp static to avoid dhcp allcotion pluto as default router > > > > BOOTPROTO=none > > > > IPADDR=172.17.1.9 > > > > NETMASK=255.255.0.0 > > > > #HWADDR=00:15:58:09:b2:ec > > > > #needs to override dhcp, dhcp still used to ensure ip address > > > > not > > > > lost - fixme!! > > > > GATEWAY=192.168.31.100 > > > > ONBOOT=yes > > > > NM_CONTROLLED=no > > > > TYPE=Ethernet > > > > USERCTL=no > > > > # not using 6to4, but a dedicated tunnel. seems to work with > > > > this > > > > in, > > > > but generates warnings IPV6TO4INIT=yes > > > > IPV6INIT=yes > > > > IPV6ADDR_SECONDARIES="2001:470:zzzz::1/64" > > > > # unclear on value/necessity. I think it's for varying tunnels, > > > > so > > > > probably not essential > > > > IPV6_CONTROL_RADVD=yes > > > > PREFIX=16 > > > > > > > > /etc/sysconfig/network-scripts/ifcfg-eth0:1 > > > > # Please read /usr/share/doc/initscripts-*/sysconfig.txt > > > > # for the documentation of these parameters. > > > > GATEWAY=192.168.31.100 > > > > DNS1=172.17.31.77 > > > > DEVICE=eth0:1 > > > > BOOTPROTO=none > > > > NETMASK=255.255.255.0 > > > > TYPE=Ethernet > > > > IPADDR=192.168.31.61 > > > > IPV6INIT=yes > > > > USERCTL=no > > > > ONPARENT=yes > > > > NM_CONTROLLED=no > > > > PREFIX=24 > > > > > > > > > > > > /etc/sysconfig/network-scripts/ifcfg-lo > > > > DEVICE=lo > > > > IPADDR=127.0.0.1 > > > > NETMASK=255.0.0.0 > > > > NETWORK=127.0.0.0 > > > > # If you're having problems with gated making 127.0.0.0/8 a > > > > martian, > > > > # you can change this to something else (255.255.255.255, for > > > > example) > > > > BROADCAST=127.255.255.255 > > > > ONBOOT=yes > > > > NAME=loopback > > > > > > > > /etc/sysconfig/network-scripts/ifcfg-sit1 > > > > DEVICE=sit1 > > > > BOOTPROTO=none > > > > ONBOOT=yes > > > > IPV6INIT=yes > > > > IPV6TUNNELIPV4=aaa.bbb.ccc.dddd > > > > IPV6TUNNELIPV4LOCAL=172.17.1.9 > > > > IPV6ADDR=2001:470:xxxx:yyyy::2/64 > > > > > > So for me to understand: > > > > > > you used to call `ifup sit1` with initscripts alone, and it > > > worked. > > > Since enabling NetworkManager, `ifup sit1` ends up calling `nmcli > > > connection up uuid 4a341ad1-3e31-7ee8-82ee-2019bf995ad8`, which > > > now > > > fails? > > > > > > > > > > > > When using initscripts with NetworkManager enabled, > > > initscripts/ifup > > > ask NetworkManager whether NM wants to handle a certain ifcfg > > > file. > > > If > > > NM says yes, a ifup call results in `nmcli connection up`. > > > > > > > > > Can you show what NM thinks how 4a341ad1 looks like? > > > > > > $ nmcli connection show 4a341ad1-3e31-7ee8-82ee-2019bf995ad8 > > > > > > > > > > > > NetworkManager 1.0 and earlier don't support creation of sit > > > tunnels. > > > Only 1.2 does. NM should say that it doesn't know how to handle > > > "/etc/sysconfig/network-scripts/ifcfg-sit1" and leave it to > > > initscripts > > > to up the sit connection. > > > > NM thinks that your sit1 file is an "ethernet", not a sit-tunnel. > > You have to put NM_CONTROLLED=no there. > > > > > > Thomas > Thanks, Thomas. That solved it. And it looks to me like my initial > tests were wrong as I could not reproduce my initial success model. > Looks like I’m hardly using NM at all.
Cool. addendum: even better then "NM_CONTROLLED=no" is "TYPE=sit". Then NetworkManager knows the type at hand and ignores it properly. Thomas
signature.asc
Description: This is a digitally signed message part
_______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
