Re: [systemd-devel] Systemd-nspawn: Cannot create tun device in container
Everything works great now, thanks for all of your help! On Oct 10, 2014, at 2:13 AM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 09.10.14 23:53, James Lott (ja...@lottspot.com) wrote: I am using a setup which retains the CAP_NET_ADMIN capability inside the container and allows openvpn to setup the device. No persistent devices are involved. Below, I have included a snippet from a shell session which shows the command used to invoke nspawn and then the openvpn command executed within the container which fails. The devices cgroup controller is used by nspawn to ensure code running inside the container cannot freely create arbitrary device nodes and then open them. What was missing here is to actually update the policy for it to allow access to /dev/net/tun. I made that change now, please check with the git version for nspawn if everything works now. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-nspawn: Cannot create tun device in container
I am using a setup which retains the CAP_NET_ADMIN capability inside the container and allows openvpn to setup the device. No persistent devices are involved. Below, I have included a snippet from a shell session which shows the command used to invoke nspawn and then the openvpn command executed within the container which fails. [root@host01 ~]# systemctl status lanvpn | grep -A1 CGroup CGroup: /system.slice/lanvpn.service `-2169 /usr/bin/systemd-nspawn --network-bridge=switch1 -bD /home/lanvpn [root@host01 ~]# ssh lanvpn Last login: Thu Oct 9 15:01:42 2014 from host01.lottspot.vpn [root@lanvpn ~]# openvpn --config /etc/openvpn/vpngate.conf | tail -n2 Thu Oct 9 23:40:45 2014 ERROR: Cannot open TUN/TAP dev /dev/net/tun: Operation not permitted (errno=1) Thu Oct 9 23:40:45 2014 Exiting due to fatal error This same VPN configuration will successfully connect within the host environment. [root@lanvpn ~]# exit logout Connection to lanvpn closed. [root@host01 ~]# curl icanhazip.com 23.243.158.241 [root@host01 ~]# openvpn --daemon --config /home/lanvpn/etc/openvpn/vpngate.conf [root@host01 ~]# curl icanhazip.com 111.255.23.34 On Friday 10 October 2014 08:12:02 you wrote: On Fri, Oct 10, 2014 at 12:13 AM, James Lott ja...@lottspot.com wrote: Trying to start up an openvpn connection yields the following error: Thu Oct 9 15:01:52 2014 ERROR: Cannot open TUN/TAP dev /dev/net/tun: Operation not permitted (errno=1) As requested by Lennart, attached you will find an strace of the openvpn process as it attempts to setup the connection. Please let me know if there's anything else I can provide to be helpful, and thanks again for the help! Thanks. So to open /dev/net/tun you need either to have CAP_NET_ADMIN (which depends on how you start nspawn, e.g. passing --network-veth will give you this) or the tun device must be created persistently by someone else and openvpn must have the right uid/gid to take control of it. Which setup are you using? Could you send the commandline you used to invoke nspawn and the openvpn config file you are using? (And also the same for whatever method you are using to create the persistent tun netdev, if this is what you do). Cheers, Tom -- James Lott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-nspawn: cannot add interfaces with --network-interface flag
Hi Lennart! Thanks for your response! I observed this issue on Arch Linux ARM running systemd-216-3, which it appears uses sources from about a week before that patch was committed. Thanks for pointing out the commit! I'll compile from HEAD and test again On Wednesday 08 October 2014 14:08:07 Lennart Poettering wrote: On Fri, 03.10.14 10:58, James Lott (ja...@lottspot.com) wrote: Hello, A little bit back I wrote in about having some difficulties adding network devices to containers. With some help from the list, I figured out how to add my network devices to an already running container using 'iw phy' and 'ip link'. However, I have not yet successfully added an interface to a container by way of the --network-interface flag. Attempting to add any ethernet devices by this method meets with the error: [root@host01 lanvpn]# systemd-nspawn --network-interface=eth1 Spawning container lanvpn on /home/lanvpn. Press ^] three times within 1s to kill container. Failed to move interface eth1 to namespace: File exists According to the systemd-nspawn documentation, it seems like this invocation should work --network-interface= Assign the specified network interface to the container. This will remove the specified interface from the calling namespace and place it in the container. When the container terminates, it is moved back to the host namespace. Note that --network-interface= implies --private-network. This option may be used more than once to add multiple network interfaces to the container. If I'm doing something wrong, then it seems like the documentation may desire revisiting. If I'm not, then this could be unintended behavior. Which version of systemd-nspawn are you trying this with? Note that there was a recent fix in the code handling --network-interface=, that might make work what you are trying to do: http://cgit.freedesktop.org/systemd/systemd/commit/src/nspawn/nspawn.c?id=31 25b3ef5db70d45882c7d6f617705802c5f939e Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-nspawn: Cannot create tun device in container
Does anyone have any feedback on this thread? If it's not possible for a container to create its own /dev/net/tun device (or use the host system's), I'll just move on to finding a less preferable solution. On Oct 3, 2014, at 10:46 AM, James Lott ja...@lottspot.com wrote: Hello, list! In some work I've been doing with systemd-nspawn containers, I've been trying to connect one of my containers to an openvpn network. This conteiner is being run with the --network-bridge flag to setup its networking, so according to the documentation, should retain CAP_NET_ADMIN capabilities. However, the container appears to be unable to create a new tun device [root@lanvpn ~]# ip tuntap add dev tun0 mode tun open: No such file or directory I tried retaining the CAP_MKNOD capability for this container using the -- capability flag as well, and this met with the same result. I also tried binding the /dev/net device directory from the parent to the /dev/net device directory of the child container, and added the following line to the systemd-nspawn service file of the container [root@host01 ~]# grep Device /etc/systemd/system/lanvpn.service DeviceAllow=/dev/net/tun rwm This resulted in the error [root@lanvpn ~]# ip tuntap add tun0 mode tun open: Operation not permitted Is there any way to run my containers which will allow them to create tun/tap devices? System is arch linux arm, running systemd 216-r3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Systemd-nspawn: Cannot create tun device in container
Hello, list! In some work I've been doing with systemd-nspawn containers, I've been trying to connect one of my containers to an openvpn network. This conteiner is being run with the --network-bridge flag to setup its networking, so according to the documentation, should retain CAP_NET_ADMIN capabilities. However, the container appears to be unable to create a new tun device [root@lanvpn ~]# ip tuntap add dev tun0 mode tun open: No such file or directory I tried retaining the CAP_MKNOD capability for this container using the -- capability flag as well, and this met with the same result. I also tried binding the /dev/net device directory from the parent to the /dev/net device directory of the child container, and added the following line to the systemd-nspawn service file of the container [root@host01 ~]# grep Device /etc/systemd/system/lanvpn.service DeviceAllow=/dev/net/tun rwm This resulted in the error [root@lanvpn ~]# ip tuntap add tun0 mode tun open: Operation not permitted Is there any way to run my containers which will allow them to create tun/tap devices? System is arch linux arm, running systemd 216-r3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-nspawn -- Canot add interface to container
Figured out that 'ip link set device netns pid' works much the same as 'iw phy device set netns pid', but I still can't seem to figure out what types of interfaces --network-interface will accept. If anyone happens to have a good example of how to use it, I would love to take a look at it. On Sep 26, 2014, at 4:28 PM, James Lott ja...@lottspot.com wrote: Hello again! Once again, thanks for all the help with getting my wireless interface moved into the container! Now I just have one more interface I'm having trouble with. I can't seem to move my ethernet interfaces into the container. I'm getting the same error, so I presume it's for the same reason. I can find the path to my physical devices in kernel space (they're both on a USB bus), but I can't figure out what device name I should pass to systemd-nspawn (or what other userspace program I could use to move one of the interfaces into a container's namespace). Thanks in advance for any pointers! [root@host01 lanvpn]# systemd-nspawn --network-interface=eth1 Spawning container lanvpn on /home/lanvpn. Press ^] three times within 1s to kill container. Failed to move interface eth1 to namespace: File exists [root@host01 lanvpn]# ls -lah /sys/class/net/ | egrep 'eth[0-1] ' lrwxrwxrwx 1 root root 0 Dec 31 1969 eth0 - ../../devices/platform/bcm2708_usb/usb1/1-1/1-1.1/1-1.1:1.0/net/eth0 lrwxrwxrwx 1 root root 0 Dec 31 1969 eth1 - ../../devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.0/net/eth1 On Thursday 25 September 2014 17:05:34 James Lott wrote: Shame on me for not spending more time trying to figure this out before responding. Please ignore my previous sad plea for help, I understand fully now exactly what you're saying, and was able to successfully move the phy0 interface into my container. At this point, my challenge is going to be coordinating the movement of this interface within a service file, so I don't need to do it manually when starting the container... but I suppose I can write an ExecStartPost script which can manage this. Thanks again for all your help! On Thursday 25 September 2014 16:25:02 James Lott wrote: Hi Zbyszek, Thanks for all your help! This is a new concept to me though, as I have never tried to refer to a process inside of a container from outside of the container before (I did not realize this was possible). Since specifying PID 1 would obviously be referring to the host system's init process, would you be willing to give me an example that might help me understand how I can specify an in-container PID from the host system? Thanks again for taking the time to help me grasp all of this :) On Sep 25, 2014, at 2:10 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Thu, Sep 25, 2014 at 10:40:42AM -0700, James Lott wrote: Hi Mantas, Thanks for the clarification. The first thing I tried actually was using the PID of the systemd-nspawn instance, like so [root@host01 lanvpn]# ps aux | grep -v grep | grep systemd-nspawn root 143 0.0 0.3 2884 728 ?Ss 08:42 0:00 /usr/bin/systemd-nspawn --network-bridge=switch1 -bD /home/proxy -M 0 root 4564 0.7 0.6 2884 1124 pts/3S+ 10:38 0:00 systemd- nspawn --private-network [root@host01 lanvpn]# iw phy phy0 set netns 4564 systemd-nspawn is *outside* of the container. You should use the child of systemd-nspawn, i.e. the init process, instead. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-nspawn -- Canot add interface to container
Hello again! Once again, thanks for all the help with getting my wireless interface moved into the container! Now I just have one more interface I'm having trouble with. I can't seem to move my ethernet interfaces into the container. I'm getting the same error, so I presume it's for the same reason. I can find the path to my physical devices in kernel space (they're both on a USB bus), but I can't figure out what device name I should pass to systemd-nspawn (or what other userspace program I could use to move one of the interfaces into a container's namespace). Thanks in advance for any pointers! [root@host01 lanvpn]# systemd-nspawn --network-interface=eth1 Spawning container lanvpn on /home/lanvpn. Press ^] three times within 1s to kill container. Failed to move interface eth1 to namespace: File exists [root@host01 lanvpn]# ls -lah /sys/class/net/ | egrep 'eth[0-1] ' lrwxrwxrwx 1 root root 0 Dec 31 1969 eth0 - ../../devices/platform/bcm2708_usb/usb1/1-1/1-1.1/1-1.1:1.0/net/eth0 lrwxrwxrwx 1 root root 0 Dec 31 1969 eth1 - ../../devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.0/net/eth1 On Thursday 25 September 2014 17:05:34 James Lott wrote: Shame on me for not spending more time trying to figure this out before responding. Please ignore my previous sad plea for help, I understand fully now exactly what you're saying, and was able to successfully move the phy0 interface into my container. At this point, my challenge is going to be coordinating the movement of this interface within a service file, so I don't need to do it manually when starting the container... but I suppose I can write an ExecStartPost script which can manage this. Thanks again for all your help! On Thursday 25 September 2014 16:25:02 James Lott wrote: Hi Zbyszek, Thanks for all your help! This is a new concept to me though, as I have never tried to refer to a process inside of a container from outside of the container before (I did not realize this was possible). Since specifying PID 1 would obviously be referring to the host system's init process, would you be willing to give me an example that might help me understand how I can specify an in-container PID from the host system? Thanks again for taking the time to help me grasp all of this :) On Sep 25, 2014, at 2:10 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Thu, Sep 25, 2014 at 10:40:42AM -0700, James Lott wrote: Hi Mantas, Thanks for the clarification. The first thing I tried actually was using the PID of the systemd-nspawn instance, like so [root@host01 lanvpn]# ps aux | grep -v grep | grep systemd-nspawn root 143 0.0 0.3 2884 728 ?Ss 08:42 0:00 /usr/bin/systemd-nspawn --network-bridge=switch1 -bD /home/proxy -M 0 root 4564 0.7 0.6 2884 1124 pts/3S+ 10:38 0:00 systemd- nspawn --private-network [root@host01 lanvpn]# iw phy phy0 set netns 4564 systemd-nspawn is *outside* of the container. You should use the child of systemd-nspawn, i.e. the init process, instead. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-nspawn -- Canot add interface to container
Hi Mantas, Thanks for the clarification. The first thing I tried actually was using the PID of the systemd-nspawn instance, like so [root@host01 lanvpn]# ps aux | grep -v grep | grep systemd-nspawn root 143 0.0 0.3 2884 728 ?Ss 08:42 0:00 /usr/bin/systemd-nspawn --network-bridge=switch1 -bD /home/proxy -M 0 root 4564 0.7 0.6 2884 1124 pts/3S+ 10:38 0:00 systemd- nspawn --private-network [root@host01 lanvpn]# iw phy phy0 set netns 4564 Upon re-attaching to the container, I didn't see the interface [root@lanvpn ~]# ip l 1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 [root@lanvpn ~]# iw list [root@lanvpn ~]# I suppose at this point I'm probably using the iw interface incorrectly and should seek help from a more appropriate channel to address that? On Thursday 25 September 2014 20:11:56 Mantas Mikulėnas wrote: On Thu, Sep 25, 2014 at 7:49 PM, James Lott ja...@lottspot.com wrote: Hi Marcel, Thanks for the help pointing that one out! With your guidance I was able to figure out that I'll need to run something like: iw phy phy0 set netns pid Unfortunately I'm having some trouble trying to figure out the network namespace PID to assign the phy0 interface to. Although I definitely have containers with private networking running, I can't view any information about their network namespaces Generally, using the PID of /any/ process in the container (e.g. the init) should work the same. `ip netns` only shows persistent namespaces which were given a name using the same tool. Containers generally don't bother with that. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-nspawn -- Canot add interface to container
Hi Zbyszek, Thanks for all your help! This is a new concept to me though, as I have never tried to refer to a process inside of a container from outside of the container before (I did not realize this was possible). Since specifying PID 1 would obviously be referring to the host system's init process, would you be willing to give me an example that might help me understand how I can specify an in-container PID from the host system? Thanks again for taking the time to help me grasp all of this :) On Sep 25, 2014, at 2:10 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Thu, Sep 25, 2014 at 10:40:42AM -0700, James Lott wrote: Hi Mantas, Thanks for the clarification. The first thing I tried actually was using the PID of the systemd-nspawn instance, like so [root@host01 lanvpn]# ps aux | grep -v grep | grep systemd-nspawn root 143 0.0 0.3 2884 728 ?Ss 08:42 0:00 /usr/bin/systemd-nspawn --network-bridge=switch1 -bD /home/proxy -M 0 root 4564 0.7 0.6 2884 1124 pts/3S+ 10:38 0:00 systemd- nspawn --private-network [root@host01 lanvpn]# iw phy phy0 set netns 4564 systemd-nspawn is *outside* of the container. You should use the child of systemd-nspawn, i.e. the init process, instead. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-networkd -- Cannot acquire DHCP lease on bridge interface
Hi Leonid! I asked because you could try and see if networkd can acquire a lease by itself, without dhcpcd (I don't expect it to). Actually, the reason I am using dhcpcd fro mthe command line is as a debugging measure, because I originally setup a .network file for this interface to attempt to allow systemd-networkd to handle acquiring the DHCP lease. In line with your expectations, this failed, so I tried using dhcpcd to see if I could glean what was happening. I will happily provide the disabled .network file I tried using if you would like to review it, but I'm fairly confident it isn't the issue. Also, could you run dhcpcd with -d -t 0 (debug output, no timeout) to see what it's doing? Always happy to gather more information! See the output below [root@host01 ~]# ip l show switch0 7: switch0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state UP mode DEFAULT group default link/ether 4e:c1:ff:d9:d1:49 brd ff:ff:ff:ff:ff:ff [root@host01 ~]# dhcpcd -dd -t0 switch0 dhcpcd[361]: version 6.4.3 starting dhcpcd[361]: all: IPv6 kernel autoconf disabled dhcpcd[361]: switch0: IPv6 kernel autoconf disabled dhcpcd[361]: switch0: adding address fe80::4cc1::fed9:d149 dhcpcd[361]: if_addaddress6: Operation not supported dhcpcd[361]: switch0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' PREINIT dhcpcd[361]: switch0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' CARRIER dhcpcd[361]: DUID 00:01:00:01:c7:92:cd:f9:e2:b2:c0:dd:be:4e dhcpcd[361]: switch0: IAID ff:d9:d1:49 dhcpcd[361]: switch0: delaying DHCP for 0.7 seconds dhcpcd[361]: switch0: using ClientID 01:4e:c1:ff:d9:d1:49 dhcpcd[361]: switch0: soliciting a DHCP lease dhcpcd[361]: switch0: sending DISCOVER (xid 0x79fe0186), next in 4.5 seconds dhcpcd[361]: switch0: sending DISCOVER (xid 0x79fe0186), next in 7.7 seconds dhcpcd[361]: switch0: sending DISCOVER (xid 0x79fe0186), next in 15.2 seconds dhcpcd[361]: switch0: sending DISCOVER (xid 0x79fe0186), next in 31.5 seconds I have seen a similar issue with networkd and bonding of interfaces. It turned out that the way networkd works with links is racy, so in ~70% of boots dhcp lease attempts failed both via networkd and dhcpcd. The only solution which I found was to use netctl (should be availabel on ALARM) where you can explicitly specify a precise order in which links should be managed. Yuck. I'm really not a fan of netctl, and would probably sooner hack together some oneshot service files that manually setup the interfaces and acquire leases. So it sounds like systemd-networkd is not quite ready for prime time when it comes to being a complete interface management solution. I guess that's what I get for living life on the edge ;) On Thursday 25 September 2014 18:23:47 Leonid Isaev wrote: Hi, On Wed, Sep 24, 2014 at 08:14:55PM -0700, James Lott wrote: Hello, There is no .network file for the bridge. Systemd-networkd is currently only in charge of setting up the interface. As you can see from the provided output in my original email, I am running the dhcpcd service directly from the command line (the output from each run of the dhcpcd service is included in that email as well). I asked because you could try and see if networkd can acquire a lease by itself, without dhcpcd (I don't expect it to). Also, could you run dhcpcd with -d -t 0 (debug output, no timeout) to see what it's doing? I have seen a similar issue with networkd and bonding of interfaces. It turned out that the way networkd works with links is racy, so in ~70% of boots dhcp lease attempts failed both via networkd and dhcpcd. The only solution which I found was to use netctl (should be availabel on ALARM) where you can explicitly specify a precise order in which links should be managed. Cheers, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-nspawn -- Canot add interface to container
Shame on me for not spending more time trying to figure this out before responding. Please ignore my previous sad plea for help, I understand fully now exactly what you're saying, and was able to successfully move the phy0 interface into my container. At this point, my challenge is going to be coordinating the movement of this interface within a service file, so I don't need to do it manually when starting the container... but I suppose I can write an ExecStartPost script which can manage this. Thanks again for all your help! On Thursday 25 September 2014 16:25:02 James Lott wrote: Hi Zbyszek, Thanks for all your help! This is a new concept to me though, as I have never tried to refer to a process inside of a container from outside of the container before (I did not realize this was possible). Since specifying PID 1 would obviously be referring to the host system's init process, would you be willing to give me an example that might help me understand how I can specify an in-container PID from the host system? Thanks again for taking the time to help me grasp all of this :) On Sep 25, 2014, at 2:10 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Thu, Sep 25, 2014 at 10:40:42AM -0700, James Lott wrote: Hi Mantas, Thanks for the clarification. The first thing I tried actually was using the PID of the systemd-nspawn instance, like so [root@host01 lanvpn]# ps aux | grep -v grep | grep systemd-nspawn root 143 0.0 0.3 2884 728 ?Ss 08:42 0:00 /usr/bin/systemd-nspawn --network-bridge=switch1 -bD /home/proxy -M 0 root 4564 0.7 0.6 2884 1124 pts/3S+ 10:38 0:00 systemd- nspawn --private-network [root@host01 lanvpn]# iw phy phy0 set netns 4564 systemd-nspawn is *outside* of the container. You should use the child of systemd-nspawn, i.e. the init process, instead. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Systemd-networkd -- Cannot acquire DHCP lease on bridge interface
Hello! With some help from the kind people on this list, I was able to get my basic network interfaces up and runnign with systemd-networkd. Now I've moved on to playing with some slightly more complex setups, and have run into some issues that as far as I can tell may be bugs (but I'm not quite ready to rule out user error, so I thought I'd start here before submitting to the bug tracker ;) ). I have configured a vlan interface to be a member of a bridge via the appropriate .netdev and .network files, and these interfaces get setup without any issues. However, when I try to acquire a dhcp lease through the bridge interface, I am unable to do so. Removing the bridge interface and re-adding it using brctl (as well as its vlan member) then allows me to gain a lease. Details are included below. This is on arch linux ARM, systemd 216-r3. As always, I'm happy to provide any additional information required! [root@host01 ~]# networkctl list [42/59] IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 ifb0 ether off unmanaged 3 ifb1 ether off unmanaged 4 eth0 ether carrier configured 5 wlan0wlan off unmanaged 6 switch1 ether carrier configured 7 switch0 ether off unmanaged 8 vlan0ether carrier configured 9 vlan1ether carrier configured 10 vb-0 ether carrier unmanaged 10 links listed [root@host01 ~]# brctl show bridge name bridge id STP enabled interfaces switch0 8000.4ec1ffd9d149 no vlan0 switch1 8000.42f3b831050d no vb-0 vlan1 [root@host01 ~]# ip l show switch0 7: switch0: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN mode DEFAULT group default link/ether 4e:c1:ff:d9:d1:49 brd ff:ff:ff:ff:ff:ff [root@host01 ~]# cat /etc/systemd/network/switch0.netdev [NetDev] Description=Virtual switch for container instances Name=switch0 Kind=bridge [root@host01 ~]# dhcpcd switch0 [15/59] dhcpcd[324]: version 6.4.3 starting dhcpcd[324]: all: IPv6 kernel autoconf disabled dhcpcd[324]: switch0: IPv6 kernel autoconf disabled dhcpcd[324]: switch0: adding address fe80::4cc1::fed9:d149 dhcpcd[324]: if_addaddress6: Operation not supported dhcpcd[324]: switch0: waiting for carrier dhcpcd[324]: switch0: carrier acquired dhcpcd[324]: all: IPv6 kernel autoconf disabled dhcpcd[324]: switch0: IPv6 kernel autoconf disabled dhcpcd[324]: DUID 00:01:00:01:c7:92:cd:f9:e2:b2:c0:dd:be:4e dhcpcd[324]: switch0: IAID ff:d9:d1:49 dhcpcd[324]: switch0: soliciting a DHCP lease dhcpcd[324]: timed out dhcpcd[324]: exited [root@host01 ~]# ip l set switch0 down [root@host01 ~]# brctl delbr switch0 [root@host01 ~]# brctl addbr switch0 [root@host01 ~]# brctl addif switch0 vlan0 [root@host01 ~]# dhcpcd switch0 dhcpcd[370]: version 6.4.3 starting dhcpcd[370]: all: IPv6 kernel autoconf disabled dhcpcd[370]: switch0: IPv6 kernel autoconf disabled dhcpcd[370]: switch0: adding address fe80::1c28:afff:fec4:2bd6 dhcpcd[370]: if_addaddress6: Operation not supported dhcpcd[370]: switch0: waiting for carrier dhcpcd[370]: switch0: carrier acquired dhcpcd[370]: all: IPv6 kernel autoconf disabled dhcpcd[370]: switch0: IPv6 kernel autoconf disabled dhcpcd[370]: DUID 00:01:00:01:c7:92:cd:f9:e2:b2:c0:dd:be:4e dhcpcd[370]: switch0: IAID af:c4:2b:d6 dhcpcd[370]: switch0: soliciting a DHCP lease dhcpcd[370]: switch0: offered 192.168.0.115 from 192.168.0.1 dhcpcd[370]: switch0: leased 192.168.0.115 for 86400 seconds dhcpcd[370]: switch0: adding route to 192.168.0.0/24 dhcpcd[370]: switch0: adding default route via 192.168.0.1 dhcpcd[370]: forked to background, child pid 420 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-networkd -- Cannot acquire DHCP lease on bridge interface
Hello, There is no .network file for the bridge. Systemd-networkd is currently only in charge of setting up the interface. As you can see from the provided output in my original email, I am running the dhcpcd service directly from the command line (the output from each run of the dhcpcd service is included in that email as well). On Wednesday 24 September 2014 22:44:17 Leonid Isaev wrote: Hi, On Wed, Sep 24, 2014 at 07:16:03PM -0700, James Lott wrote: However, when I try to acquire a dhcp lease through the bridge interface, I am unable to do so. Removing the bridge interface and re-adding it using brctl (as well as its vlan member) then allows me to gain a lease. Details are included below. This is on arch linux ARM, systemd 216-r3. As always, I'm happy to provide any additional information required! What does the .network file for the bridge do, i.e. what are its IP settings? Also, how do you start dhcpcd? Via the stock ArchLinux dhcpcd@.service? Cheers, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Systemd-nspawn -- Canot add interface to container
Hello again! I'm having another issue with private networking in systemd-nspawn. This one I'm not so certain is a bug, but probably some kind of mistake on my part. Base on my reading of the systemd-nspawn man page though, I can't figure out what the problem is. Basically, all I'm tring to do is remove an interface from the host namespace and provide it to the container. Details are included below (This is systemd 216-r3 in Arch Linux ARM). [root@host01 ~]# systemd-nspawn --network-interface=wlan0 -M1 -bD /home/lanvpn/ Spawning container 1 on /home/lanvpn. Press ^] three times within 1s to kill container. Failed to move interface wlan0 to namespace: File exists Thanks in advance for any help! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Systemd-nspawn -- Unable to initialize virtual ethernet connection
Hello! I am trying to setup and play around with some of the private networking features of systemd, and one of the big thinks I'm trying to get working is the virtual ethernet links. For some reason though, I am unable to start a containder using a virtual ethernet link. My attempt is included below. --- [root@utility01 ~]# systemd-nspawn --network-veth -bD /home/proxy.ddwrt01 Spawning container proxy.ddwrt01 on /home/proxy.ddwrt01. Press ^] three times within 1s to kill container. Failed to add netlink interface name: Invalid argument --- Dropping the --network-veth option: --- [root@utility01 ~]# systemd-nspawn -bD /home/proxy.ddwrt01 Spawning container proxy.ddwrt01 on /home/proxy.ddwrt01. Press ^] three times within 1s to kill container. systemd 216 running in system mode. (+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN ) Detected virtualization 'systemd-nspawn'. Detected architecture 'arm'. Welcome to Arch Linux ARM! --- Some additional environment information: [root@utility01 ~]# uname -a Linux utility01 3.12.26-2-ARCH #1 PREEMPT Sun Aug 31 22:36:40 MDT 2014 armv6l GNU/Linux [root@utility01 ~]# pacman -Q systemd systemd 216-3 I'm happy to run any additional tests or provide any additional information needed to help try to reproduce. Thanks in advance for any help! -- James Lott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-networkd -- Unable to create VLAN device
Hello again! I've been eager to play with networking features, in case you couldn't tell ;) This patricular issue seems separate from my first one though, so I thought it would be best to discuss separately. I am trying to use systemd-networkd to essentially replace vconfig. I am using eth0 as a trunked link and am trying to setup a pair of VLAN devices to receive the taged frames. It seems that the VLAN netdevs are silently failing to be created. Sep 19 09:47:34 utility01 systemd[1]: Starting Network Service... Sep 19 09:47:34 utility01 systemd-networkd[776]: [/etc/systemd/network/vlan1.network:6] VLAN could not be found, ignoring assignment: 1 Sep 19 09:47:34 utility01 systemd-networkd[776]: [/etc/systemd/network/vlan0.network:6] VLAN could not be found, ignoring assignment: 0 Sep 19 09:47:34 utility01 systemd-networkd[776]: [/etc/systemd/network/eth0.network:6] VLAN could not be found, ignoring assignment: 1 Sep 19 09:47:34 utility01 systemd-networkd[776]: [/etc/systemd/network/eth0.network:7] VLAN could not be found, ignoring assignment: 0 Sep 19 09:47:34 utility01 systemd-networkd[776]: eth0.0 : gained carrier Sep 19 09:47:34 utility01 systemd-networkd[776]: eth0: gained carrier Sep 19 09:47:34 utility01 systemd-networkd[776]: lo : gained carrier Sep 19 09:47:34 utility01 systemd[1]: Started Network Service. Although I strongly believe this to be an error I am making somewhere, I have read and re-read all of the systemd-networkd man pages, and cannot for the life of me figure out where I went wrong. Any help is much appreciated! Additional environment information is included below. [root@utility01 network]# uname -a Linux utility01 3.12.26-2-ARCH #1 PREEMPT Sun Aug 31 22:36:40 MDT 2014 armv6l GNU/Linux [root@utility01 network]# pacman -Q systemd systemd 216-3 [root@utility01 network]# lsmod | grep 8021q 8021q 20658 0 garp6303 1 8021q mrp 8249 1 8021q [root@utility01 network]# pwd /etc/systemd/network [root@utility01 network]# for f in *; do echo; echo -- $f; echo; cat $f; done -- eth0.network [Match] Name=eth0 [Network] DHCP=v4 VLAN=1 VLAN=0 -- vlan0.netdev [NetDev] Name=vlan0 Kind=vlan [VLAN] Id=0 -- vlan0.network [Match] Name=vlan0 [Network] DHCP=v4 VLAN=0 -- vlan1.netdev [NetDev] Name=vlan1 Kind=vlan [VLAN] Id=1 -- vlan1.network [Match] Name=vlan1 [Network] DHCP=v4 VLAN=1 [root@utility01 network]# ip link 1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: ifb0: BROADCAST,NOARP mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 32 link/ether 3e:ff:bc:28:42:cb brd ff:ff:ff:ff:ff:ff 3: ifb1: BROADCAST,NOARP mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 32 link/ether 3a:65:88:fc:ab:27 brd ff:ff:ff:ff:ff:ff 4: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether b8:27:eb:9d:3a:06 brd ff:ff:ff:ff:ff:ff 5: wlan0: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 64:66:b3:20:04:f5 brd ff:ff:ff:ff:ff:ff 6: eth0.0@eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state UP mode DEFAULT group default link/ether b8:27:eb:9d:3a:06 brd ff:ff:ff:ff:ff:ff NOTE: The existing eth0.0 was created using vconfig, which I created simply to get this machine back on the network while I troubleshooted my issue. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd -- Unable to create VLAN device
Holy smokes, that did it! Many thanks for taking time out of your day to help me find my silly mistake :) On Friday 19 September 2014 22:51:41 Tom Gundersen wrote: On Fri, Sep 19, 2014 at 6:59 PM, James Lott ja...@lottspot.com wrote: Hello again! I've been eager to play with networking features, in case you couldn't tell ;) This patricular issue seems separate from my first one though, so I thought it would be best to discuss separately. I am trying to use systemd-networkd to essentially replace vconfig. I am using eth0 as a trunked link and am trying to setup a pair of VLAN devices to receive the taged frames. It seems that the VLAN netdevs are silently failing to be created. Sep 19 09:47:34 utility01 systemd[1]: Starting Network Service... Sep 19 09:47:34 utility01 systemd-networkd[776]: [/etc/systemd/network/vlan1.network:6] VLAN could not be found, ignoring assignment: 1 Sep 19 09:47:34 utility01 systemd-networkd[776]: [/etc/systemd/network/vlan0.network:6] VLAN could not be found, ignoring assignment: 0 Sep 19 09:47:34 utility01 systemd-networkd[776]: [/etc/systemd/network/eth0.network:6] VLAN could not be found, ignoring assignment: 1 Sep 19 09:47:34 utility01 systemd-networkd[776]: [/etc/systemd/network/eth0.network:7] VLAN could not be found, ignoring assignment: 0 Sep 19 09:47:34 utility01 systemd-networkd[776]: eth0.0 : gained carrier Sep 19 09:47:34 utility01 systemd-networkd[776]: eth0: gained carrier Sep 19 09:47:34 utility01 systemd-networkd[776]: lo : gained carrier Sep 19 09:47:34 utility01 systemd[1]: Started Network Service. Although I strongly believe this to be an error I am making somewhere, I have read and re-read all of the systemd-networkd man pages, and cannot for the life of me figure out where I went wrong. Any help is much appreciated! Additional environment information is included below. [root@utility01 network]# uname -a Linux utility01 3.12.26-2-ARCH #1 PREEMPT Sun Aug 31 22:36:40 MDT 2014 armv6l GNU/Linux [root@utility01 network]# pacman -Q systemd systemd 216-3 [root@utility01 network]# lsmod | grep 8021q 8021q 20658 0 garp6303 1 8021q mrp 8249 1 8021q [root@utility01 network]# pwd /etc/systemd/network [root@utility01 network]# for f in *; do echo; echo -- $f; echo; cat $f; done -- eth0.network [Match] Name=eth0 [Network] DHCP=v4 VLAN=1 VLAN=0 This needs to be the names of your vlan interfaces, not their vlanid. I.e., VLAN=vlan0 VLAN=vlan1 -- vlan0.netdev [NetDev] Name=vlan0 Kind=vlan [VLAN] Id=0 -- vlan0.network [Match] Name=vlan0 [Network] DHCP=v4 VLAN=0 -- vlan1.netdev [NetDev] Name=vlan1 Kind=vlan [VLAN] Id=1 -- vlan1.network [Match] Name=vlan1 [Network] DHCP=v4 VLAN=1 [root@utility01 network]# ip link 1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: ifb0: BROADCAST,NOARP mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 32 link/ether 3e:ff:bc:28:42:cb brd ff:ff:ff:ff:ff:ff 3: ifb1: BROADCAST,NOARP mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 32 link/ether 3a:65:88:fc:ab:27 brd ff:ff:ff:ff:ff:ff 4: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether b8:27:eb:9d:3a:06 brd ff:ff:ff:ff:ff:ff 5: wlan0: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 64:66:b3:20:04:f5 brd ff:ff:ff:ff:ff:ff 6: eth0.0@eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state UP mode DEFAULT group default link/ether b8:27:eb:9d:3a:06 brd ff:ff:ff:ff:ff:ff NOTE: The existing eth0.0 was created using vconfig, which I created simply to get this machine back on the network while I troubleshooted my issue. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-nspawn -- Unable to initialize virtual ethernet connection
Thanks so much for debugging that! Your recommended work around, of course, works perfectly for me until the release hits the Arch repos (although my gentoo machines will happily and impatiently pull in the git snapshot ). Do you know what the version number for the next systemd release will be? I want to make sure I keep my eyes peeled for it! On Friday 19 September 2014 23:04:40 Tom Gundersen wrote: On Fri, Sep 19, 2014 at 6:37 PM, James Lott ja...@lottspot.com wrote: I am trying to setup and play around with some of the private networking features of systemd, and one of the big thinks I'm trying to get working is the virtual ethernet links. For some reason though, I am unable to start a containder using a virtual ethernet link. My attempt is included below. This is a bug. Thanks for the report! I now pushed a fix: http://cgit.freedesktop.org/systemd/systemd/commit/?id=c00524c9cc7fb498c724 4350e25823b8352f078c. The problem was that we were not correctly truncating the machine name (by default taken from the folder name) when using it to create a veth link. Until the fix lands in your distro, you can simply rename your container instance to a shorter name using the --machine switch to systemd-nspawn. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
