Everything works great now, thanks for all of your help!
> On Oct 10, 2014, at 2:13 AM, Lennart Poettering
> 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 openvp
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
>
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
On Fri, Oct 10, 2014 at 12:13 AM, James Lott 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
Hey there Tom,
No problem! Many thanks for taking the time to check this out and write up a
patch!
I compiled the latest systemd with the patch you pushed, and my container is
now able to create a /dev/net/tun device with no problems. However, there
appears to be a problem with the container b
On Fri, Oct 3, 2014 at 7:46 PM, James Lott 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 accor
On Fri, 03.10.14 10:46, 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 n
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 wrote:
>
> Hello, list!
>
> In some work I
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 ca