Re: [systemd-devel] systemd-nspawn network ping
Hello I think it will be routed, I tied ping 169.254.x.x container to container, and it's successed. And, I created the systemd-nspawn container after 5 minus ago, the container's host0 network auto turns ip on 169.254.x.x rather than 10.0.0.x . -- Yours Sincerely Han At 2016-02-29 15:40:10, "Kai Krakow" wrote: Hello! This is link local IP. You can see it like 127.0.0.0/8 but for the whole network segment: it won't be route thus it never leaves the bridge. I think you can safely ignore it tho I also think there is a way to deactivate assigning such addresses in networkd. AFAIK it's called APIPA. Regards, Kai kennedy schrieb am Mo., 29. Feb. 2016 um 07:43 Uhr: Thanks! it works! but I had a little question. In my container, I run `route -n` it show me 3 result ,they are: Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 0.0.0.0 0.0.0.0 U 2048 00 host0 10.0.0.00.0.0.0 255.0.0.0 U 0 00 host0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 00 host0 What's the "169.254.0.0" comes from ? I'v never configured that. and when I add the "--network-veth" option on systemd-nspawn, the "169.254.0.0" it's disappeared. -- Yours Sincerely Han At 2016-02-29 00:26:54, "Kai Krakow" wrote: >Am Sun, 28 Feb 2016 23:41:22 +0800 (CST) >schrieb kennedy : > >> how to ping container to container each other in systemd-nspawn ? >> I've tried --network-veth option but it doesn't work enough. > >You need to join all host-side veth interfaces into the same bridge. >Make two files for systemd-networkd: > ># 99-bridge-cn.netdev >[NetDev] >Name=br-containers >Kind=bridge >[Match] >Name=br-containers > ># 99-bridge-cn.network >[Network] >Address=10.0.0.1/24 >DHCPServer=yes >IPForward=yes >IPMasquerade=yes > >Then "systemctl --edit systemd-nspawn@.service" to contain the >following: > > >[Service] >ExecStart= >ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot \ >--link-journal=try-guest --private-network \ >--network-bridge=br-containers --machine=%I > > >This will add all your container veth devices to the same bridge which >you configured in systemd-networkd. You should now be able to ping each >other. > >You may need to adjust a few more settings for your needs. I'd >recommend to add nss-mymachines (see man page). > > >-- >Regards, >Kai > >Replies to list-only preferred. > >___ >systemd-devel mailing list >systemd-devel@lists.freedesktop.org >https://lists.freedesktop.org/mailman/listinfo/systemd-devel___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn network ping
Am Mon, 29 Feb 2016 16:38:59 +0800 (CST) schrieb kennedy : > I think it will be routed, I tied ping 169.254.x.x container to > container, and it's successed. And, I created the systemd-nspawn > container after 5 minus ago, the container's host0 network auto turns > ip on 169.254.x.x rather than 10.0.0.x . No, it's not routed. You can ping from container to container because they are connected to the same network segment (via the bridge, which is a virtual switch - well, that's layer2 routing of course). A ping won't leave the bridge: Try to ping from within the container to something else in your LAN (remove the masquerading first, disable DHCP, or use the source parameter on ping). It shouldn't work. If you run "sudo ip addr" it will show link scope on these addresses, not global. You expectation was "host scope" - packets won't leave the host. A host scope network is 127.0.0.0/8: Try running a web service on 127.0.0.2:80, now go to the other container and try curl on that address: won't work because 127/8 has host scope. Host scope: local loopback Link scope: local network segment Global scope: can pass segment boundaries IPv6 has an additional site scope: Packets won't pass outbound network segments (read: don't leave via the public external interface of a boundary/edge router). https://en.wikipedia.org/wiki/Link-local_address > At 2016-02-29 15:40:10, "Kai Krakow" wrote: > > Hello! > > > This is link local IP. You can see it like 127.0.0.0/8 but for the > whole network segment: it won't be route thus it never leaves the > bridge. I think you can safely ignore it tho I also think there is a > way to deactivate assigning such addresses in networkd. AFAIK it's > called APIPA. > > > Regards, > Kai > > > kennedy schrieb am Mo., 29. Feb. 2016 um 07:43 > Uhr: > > Thanks! it works! > but I had a little question. > In my container, I run `route -n` it show me 3 result ,they are: > > > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref > Use Iface 0.0.0.0 0.0.0.0 0.0.0.0 U > 2048 00 host0 10.0.0.00.0.0.0 > 255.0.0.0 U 0 00 host0 169.254.0.0 > 0.0.0.0 255.255.0.0 U 0 00 host0 > > > What's the "169.254.0.0" comes from ? I'v never configured that. > > > and when I add the "--network-veth" option on systemd-nspawn, the > "169.254.0.0" it's disappeared. > > > -- > Yours Sincerely > Han > > > > At 2016-02-29 00:26:54, "Kai Krakow" wrote: > >Am Sun, 28 Feb 2016 23:41:22 +0800 (CST) > >schrieb kennedy : > > > >> how to ping container to container each other in systemd-nspawn ? > >> I've tried --network-veth option but it doesn't work enough. > > > >You need to join all host-side veth interfaces into the same bridge. > >Make two files for systemd-networkd: > > > ># 99-bridge-cn.netdev > >[NetDev] > >Name=br-containers > >Kind=bridge > >[Match] > >Name=br-containers > > > ># 99-bridge-cn.network > >[Network] > >Address=10.0.0.1/24 > >DHCPServer=yes > >IPForward=yes > >IPMasquerade=yes > > > >Then "systemctl --edit systemd-nspawn@.service" to contain the > >following: > > > > > >[Service] > >ExecStart= > >ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot \ > >--link-journal=try-guest --private-network \ > >--network-bridge=br-containers --machine=%I > > > > > >This will add all your container veth devices to the same bridge > >which you configured in systemd-networkd. You should now be able to > >ping each other. > > > >You may need to adjust a few more settings for your needs. I'd > >recommend to add nss-mymachines (see man page). > > > > > >-- > >Regards, > >Kai > > > >Replies to list-only preferred. > > > >___ > >systemd-devel mailing list > >systemd-devel@lists.freedesktop.org > >https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Regards, Kai Replies to list-only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Can't make local user.conf work
On Sun, Feb 28, 2016 at 8:26 PM, G D'Arezzo wrote: > "You probably want to use [Service] instead." > > Thanks for the suggestion, Auke. Unfortunately, Service and > DefaultEnvironment don't go together: > > [/home/temp/.config/systemd/user/test.service.d/user.conf:2] Unknown > lvalue 'DefaultEnvironment' in section 'Service' I just reread the man page for that. DefaultEnvironment is valid only for user.conf, not any conf.d* file associated with a specific unit (obviously, since those are not variants of "user.conf", but instead are variants of unit files). The [Manager] section is only valid in: /etc/systemd/user.conf, /etc/systemd/user.conf.d/*.conf, /run/systemd/user.conf.d/*.conf, /usr/lib/systemd/user.conf.d/*.conf The manual page systemd-user.conf(5) does not mention at all being able to use ~/.config/systemd/. This seems like a shortcoming to me, though. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] tunnel configuration broken
systemd 229-3 I recently updated my Arch Linux. https://wiki.archlinux.org/index.php/IPv6_tunnel_broker_setup using a hurricane electric tunnel... and now the tunnel device wants to start and add all the static addresses that are specified on other physical net devices in fact the HE is attached to a bridge that has to wait itself for other things to start. I would have thought that naming 00-eth0.network; 01-eth1.network or something would start devices in that order? How do I specify a dependance order between network configurations? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] tunnel configuration broken
On Mon, Feb 29, 2016 at 7:12 PM, J Decker wrote: > systemd 229-3 > > I recently updated my Arch Linux. > > https://wiki.archlinux.org/index.php/IPv6_tunnel_broker_setup > > using a hurricane electric tunnel... > > and now the tunnel device wants to start and add all the static > addresses that are specified on other physical net devices in fact > the HE is attached to a bridge that has to wait itself for other > things to start. > > I would have thought that naming 00-eth0.network; 01-eth1.network or > something would start devices in that order? > > How do I specify a dependance order between network configurations? Sorry I sent to wrong place. I did recently add a ipv6 to a bridge to stop another issue. but after moving the ipv6 to the end of the bridge it still doesn't wait for eth0 to come up before it starts the tunnel [code] [root@tower2 network]# systemctl start systemd-networkd [root@tower2 network]# Feb 29 20:15:23 tower2 polkitd[913]: Registered Authentication Agent for unix-process:3325:15819222 (system bus name :1.44 [/usr/bin/pkttyagent --notify-fd 4 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.utf-8) Feb 29 20:15:23 tower2 systemd[1]: Starting Network Service... Feb 29 20:15:23 tower2 systemd-networkd[3331]: [/etc/systemd/network/he-tunnel.netdev:9] Tunnel addresses incompatible, ignoring assignment: Feb 29 20:15:23 tower2 systemd-networkd[3331]: [/etc/systemd/network/he-tunnel.netdev:10] Tunnel addresses incompatible, ignoring assignment: Feb 29 20:15:23 tower2 systemd-networkd[3331]: Tunnel with invalid address family configured in /etc/systemd/network/he-tunnel.netdev. Ignoring Feb 29 20:15:23 tower2 systemd-networkd[3331]: [/etc/systemd/network/he-tunnel.network:7] Route is invalid, ignoring assignment: Feb 29 20:15:23 tower2 systemd-networkd[3331]: [/etc/systemd/network/01-eth0.network:8] Tunnel is invalid, ignoring assignment: he-ipv6 [/code] there's then another started... oh starting started. eth0 needs to be up already and I can't confirm why it wouldn't be? it's DHCP so it needs to know when it gets its address before I can assign the he-tunnel. [/code] Feb 29 20:15:23 tower2 systemd-networkd[3331]: br0: netdev ready Feb 29 20:15:23 tower2 systemd-networkd[3331]: br0: Gained IPv6LL Feb 29 20:15:23 tower2 systemd-networkd[3331]: eno1: Gained IPv6LL Feb 29 20:15:23 tower2 systemd-networkd[3331]: eth0: Gained IPv6LL Feb 29 20:15:23 tower2 systemd-networkd[3331]: Enumeration completed Feb 29 20:15:23 tower2 systemd[1]: Started Network Service. Feb 29 20:15:23 tower2 systemd-networkd[3331]: br0: netdev exists, using ex [/code] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] tunnel configuration broken
Am Mon, 29 Feb 2016 19:12:11 -0800 schrieb J Decker : > I would have thought that naming 00-eth0.network; 01-eth1.network or > something would start devices in that order? No... It does say nothing about order in your sense. It's just ordering which configuration overwrites another when options are specified in multiple files. So it's not start order, it just order of precedence for configuration options. -- Regards, Kai Replies to list-only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] tunnel configuration broken
Yes; I thnk instead it's a DHCP issue; since the device has no address to start, adding the tunnel endpoing to that socket without an address seems to be failing. It has to wait until the DHCP signal, and then it really needs the DHCP address to update the tunnel endpoint configuration. On Mon, Feb 29, 2016 at 10:36 PM, Kai Krakow wrote: > Am Mon, 29 Feb 2016 19:12:11 -0800 > schrieb J Decker : > >> I would have thought that naming 00-eth0.network; 01-eth1.network or >> something would start devices in that order? > > No... It does say nothing about order in your sense. It's just ordering > which configuration overwrites another when options are specified in > multiple files. > > So it's not start order, it just order of precedence for configuration > options. > > -- > Regards, > Kai > > Replies to list-only preferred. > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] howto systemd restart one network device
well that was the search after everything is up how do I restart a single device so it will work in the meantime... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel