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
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
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
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
On Fri, Oct 3, 2014 at 7:46 PM, 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
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!
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
