Build and run vpnc on CoreOS?

209 views
Skip to first unread message

Derek Mahar

unread,
Jul 7, 2016, 6:26:52 PM7/7/16
to CoreOS Dev
How could I build and run vpnc on CoreOS?  Could I build it on Ubuntu and then install the binary on CoreOS?

Derek

Nick Owens

unread,
Jul 7, 2016, 6:51:53 PM7/7/16
to coreo...@googlegroups.com
On 07/07/2016 03:26 PM, Derek Mahar wrote:
> How could I build and run vpnc <https://www.unix-ag.uni-kl.de/~massar/vpnc/> on
> CoreOS? Could I build it on Ubuntu and then install the binary on CoreOS?

is there any reason you can't run it in a rkt or docker container?

if you really cannot, then the binary should be statically linked.
dynamically linked binaries from other systems either will not work
because of missing libraries, or will potentially crash at runtime due
to ABI problems, so it's not a very good idea.

>
> Derek
>

Seán C. McCord

unread,
Jul 7, 2016, 9:25:39 PM7/7/16
to coreo...@googlegroups.com
If this is for an ad-hoc VPN connection, you should be able to build and run it inside `toolbox`.  Otherwise, as Nick said:  run it in a container.  Because it requires the ability to create tun/tap devices, it will need to be a privileged container with access to at least `/dev`, and you may need to add `ExecStartPre=/usr/sbin/modprobe tun` in your systemd/fleet unit for it.

It looks like it only links to libraries which are present in CoreOS, though, so if you do have to run it bare, for some reason, you can probably copy the binary over from Ubuntu:

~/d/v/vpnc-0.5.3 $ ldd vpnc
linux-vdso.so.1 (0x00007ffe1647d000)
libgcrypt.so.20 => /usr/lib64/libgcrypt.so.20 (0x00007f410eabd000)
libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x00007f410e8aa000)
libc.so.6 => /lib64/libc.so.6 (0x00007f410e50d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f410eda0000)


--
Seán C McCord
CyCore Systems, Inc

Derek Mahar

unread,
Jul 8, 2016, 9:29:33 AM7/8/16
to CoreOS Dev
On Thursday, 7 July 2016 18:51:53 UTC-4, Nick Owens wrote:
On 07/07/2016 03:26 PM, Derek Mahar wrote:
> How could I build and run vpnc <https://www.unix-ag.uni-kl.de/~massar/vpnc/> on
> CoreOS?  Could I build it on Ubuntu and then install the binary on CoreOS?

is there any reason you can't run it in a rkt or docker container?

I've tried running it in a container, but couldn't get it to start, probably because I didn't run it as a privileged container, as Sean McCord suggested.  Assuming that I can run it inside its own container, I'd then have to figure out how to configure the container network so that the application containers use the VPN container as a VPN gateway.  I have only basic experience with Linux networking, so I'd have to do some research in order to solve this problem.

 

if you really cannot, then the binary should be statically linked.
dynamically linked binaries from other systems either will not work
because of missing libraries, or will potentially crash at runtime due
to ABI problems, so it's not a very good idea.

Yes, this is what I thought, too.  However, according to Sean, it seems that the vpnc binary uses only libraries which are present in CoreOS, so it should run even without static linking.
 
Derek

Derek Mahar

unread,
Jul 8, 2016, 10:08:07 AM7/8/16
to CoreOS Dev
On Thursday, 7 July 2016 21:25:39 UTC-4, Seán McCord wrote:
If this is for an ad-hoc VPN connection, you should be able to build and run it inside `toolbox`.  Otherwise, as Nick said:  run it in a container.  Because it requires the ability to create tun/tap devices, it will need to be a privileged container with access to at least `/dev`, and you may need to add `ExecStartPre=/usr/sbin/modprobe tun` in your systemd/fleet unit for it.

What is "toolbox"?  As I mentioned to Nick, I couldn't run vpnc in a container, probably because I didn't run it inside one that was privileged.  What is the purpose of "/usr/sbin/modprobe tun"?


 
It looks like it only links to libraries which are present in CoreOS, though, so if you do have to run it bare, for some reason, you can probably copy the binary over from Ubuntu:

~/d/v/vpnc-0.5.3 $ ldd vpnc
linux-vdso.so.1 (0x00007ffe1647d000)
libgcrypt.so.20 => /usr/lib64/libgcrypt.so.20 (0x00007f410eabd000)
libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x00007f410e8aa000)
libc.so.6 => /lib64/libc.so.6 (0x00007f410e50d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f410eda0000)

This is encouraging.

Is there any particular location where I should or should not copy the binary so that it isn't overwritten by the CoreOS update process?

Derek

Derek Mahar

unread,
Jul 8, 2016, 11:41:01 AM7/8/16
to CoreOS Dev
I managed to run vpnc in a privileged Docker container.  Now I need to figure out how to configure the container network so that one of the application containers uses the VPN container as a gateway to the VPN.

Derek Mahar

unread,
Jul 8, 2016, 11:46:57 AM7/8/16
to CoreOS Dev
On second thought, it should be easier simply to bundle the application that must communicate with the VPN and vpnc in the same container.  It will nice to isolate the VPN client inside the container of the only application that must communicate over the VPN instead of running the VPN client in the host.

Seán C. McCord

unread,
Jul 8, 2016, 12:55:27 PM7/8/16
to CoreOS Dev
That sounds very reasonable.  I would lead you, in that case, toward using a rkt pod, so that the vpn client and the user of the VPN can run as separate containers within the same network namespace, which should make management of those containers simpler.


--

Derek Mahar

unread,
Jul 8, 2016, 2:04:14 PM7/8/16
to CoreOS Dev
Wouldn't I still have to configure a network proxy on the vpn client container or some routing tables on the application container?  By 'rkt pod' do you mean run the containers using 'rkt run'?

Seán C. McCord

unread,
Jul 8, 2016, 2:17:15 PM7/8/16
to CoreOS Dev
I don't see any reason for a proxy.  This is a VPN _client_, not a VPN server.

The pod is a construct of multiple containers which share namespaces (apropos here, the same network namespace).  This means that you can have one (potentially reusable and independently maintained) container for vpnc and another for whatever application is consuming the VPN connection.  They would be independent of each other except that they would share the same network namespace.  Since the function of the VPN is to configure a VPN interface and route over that VPN, all of which reside in the network namespace, as long as the network namespaces are the same, they can operate independently.

Still, it sounds as if you are just beginning, so all of that may be too steep challenge, when getting started.   Take a look at the rkt pod blog post, though, and gauge its comparative complexity with that of maintaining a compounded single container.



Derek Mahar

unread,
Jul 8, 2016, 2:50:42 PM7/8/16
to CoreOS Dev
Thank you for your suggestions.  I'm very new to CoreOS and rkt, but less new to Docker which I've been using in development for about three or four months.  The reason I'm turning to CoreOS and rkt is because Docker Engine still doesn't work well with systemd, and CoreOS is much leaner than Ubuntu Server.  The only obstacle holding me back from adopting CoreOS has been the need for the VPN client (vpnc).

Seán C. McCord

unread,
Jul 8, 2016, 3:10:59 PM7/8/16
to CoreOS Dev
Those are excellent and valid reasons to look at CoreOS (my opinion, obviously).  rkt is really turning out to be a beautiful container engine, and it slots perfectly into the role you mention here.

It definitely suffers from documentation deficiencies, particularly with respect to its 'pods' concept.  When you use things like Kubernetes, you don't have to worry about the details, but for those who just want to be able to leverage simple rkt pods without all the extra infrastructure, the documentation is rather limited, and it is difficult to know what you are looking for. 

The `rkt run` documentation does show how to run multiple containers in one rkt pod, though:



Derek Mahar

unread,
Jul 20, 2016, 7:11:57 PM7/20/16
to CoreOS Dev
How can I run a privileged container using rkt?

Alban Crequy

unread,
Jul 21, 2016, 9:09:58 AM7/21/16
to coreo...@googlegroups.com
Hi,

On Thu, Jul 21, 2016 at 1:11 AM, Derek Mahar <derek...@gmail.com> wrote:
> How can I run a privileged container using rkt?

There is no global "--privileged" flag in rkt, although there was some
discussion about it:
https://github.com/coreos/rkt/issues/2158#issuecomment-233603912

It depends what kind of privileges you want for your container. What
are you trying to achieve?

You can relax the isolation in several ways:

- give more capabilities:
https://github.com/coreos/rkt/blob/master/Documentation/capabilities-guide.md
(and more soon with https://github.com/coreos/rkt/pull/2917)

- run in the namespaces of the host using "rkt fly":
https://github.com/coreos/rkt/blob/master/Documentation/running-fly-stage1.md

Cheers,
Alban

Derek Mahar

unread,
Jul 21, 2016, 10:28:38 AM7/21/16
to CoreOS Dev
On Thursday, 21 July 2016 09:09:58 UTC-4, Alban Crequy wrote:
On Thu, Jul 21, 2016 at 1:11 AM, Derek Mahar <derek...@gmail.com> wrote:
> How can I run a privileged container using rkt?

There is no global "--privileged" flag in rkt, although there was some
discussion about it:
https://github.com/coreos/rkt/issues/2158#issuecomment-233603912

It depends what kind of privileges you want for your container. What
are you trying to achieve?

I'm trying to run vpnc, a Cisco VPN client in a container along with the Java application that uses the VPN.  Sean explained in an earlier message that the container must run in privileged mode in order to create tun/tap devices.  I managed to run the client in a Docker container, but would prefer to do the same in an rkt container so that I can run both vpnc and the Java application in the same pod.  The Java application will also have to connect to an ActiveMQ broker running on another node, but this node is outside the VPN.
 

You can relax the isolation in several ways:

- give more capabilities:
https://github.com/coreos/rkt/blob/master/Documentation/capabilities-guide.md
(and more soon with https://github.com/coreos/rkt/pull/2917)


How do these capabilities apply to rkt containers running Docker images?  I've installed vpnc in an Ubuntu Docker image, but with some effort I think I could repackage it as an ACI.  Would this mean that I'd have to repackage all of my images as ACIs or can rkt mix and match Docker and ACIs in a pod?
 

- run in the namespaces of the host using "rkt fly":
https://github.com/coreos/rkt/blob/master/Documentation/running-fly-stage1.md


I think "rkt fly" would make sense for running vpnc.  If I were to run vpnc in "rkt fly", how might the Java application connect to the VPN?  Would it still have to run in the same pod as vpnc?  Could the Java app be packaged as a Docker image or must it be an ACI?

Derek

Alban Crequy

unread,
Jul 21, 2016, 10:54:41 AM7/21/16
to coreo...@googlegroups.com
On Thu, Jul 21, 2016 at 4:28 PM, Derek Mahar <derek...@gmail.com> wrote:
> On Thursday, 21 July 2016 09:09:58 UTC-4, Alban Crequy wrote:
>>
>> On Thu, Jul 21, 2016 at 1:11 AM, Derek Mahar <derek...@gmail.com> wrote:
>> > How can I run a privileged container using rkt?
>>
>> There is no global "--privileged" flag in rkt, although there was some
>> discussion about it:
>> https://github.com/coreos/rkt/issues/2158#issuecomment-233603912
>>
>> It depends what kind of privileges you want for your container. What
>> are you trying to achieve?
>
>
> I'm trying to run vpnc, a Cisco VPN client in a container along with the
> Java application that uses the VPN. Sean explained in an earlier message
> that the container must run in privileged mode in order to create tun/tap
> devices. I managed to run the client in a Docker container, but would
> prefer to do the same in an rkt container so that I can run both vpnc and
> the Java application in the same pod. The Java application will also have
> to connect to an ActiveMQ broker running on another node, but this node is
> outside the VPN.

/dev/net/tun is available for applications in rkt pods. But you will
need CAP_NET_ADMIN to use it.

You can try something like the following (note the CAP_NET_ADMIN at the end):

rkt run my_image
--cap-retain="CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FSETID,CAP_FOWNER,CAP_MKNOD,CAP_NET_RAW,CAP_SETGID,CAP_SETUID,CAP_SETFCAP,CAP_SETPCAP,CAP_NET_BIND_SERVICE,CAP_SYS_CHROOT,CAP_KILL,CAP_AUDIT_WRITE,CAP_NET_ADMIN"


>> You can relax the isolation in several ways:
>>
>> - give more capabilities:
>>
>> https://github.com/coreos/rkt/blob/master/Documentation/capabilities-guide.md
>> (and more soon with https://github.com/coreos/rkt/pull/2917)
>>
>
> How do these capabilities apply to rkt containers running Docker images?
> I've installed vpnc in an Ubuntu Docker image, but with some effort I think
> I could repackage it as an ACI.

The capabilities passed on the command line (--cap-retain) apply in
the same way to ACIs and Docker images. So there is no need to
repackage.

If you want to repackage to avoid having to pass the --cap-retain each
time, you can use docker2aci to convert the image from the Docker
format to an ACI, and then use "actool patch-manifest" to specify the
capabilities.

> Would this mean that I'd have to repackage
> all of my images as ACIs or can rkt mix and match Docker and ACIs in a pod?

They can be mixed:

$ sudo rkt run docker://busybox --exec echo -- BUSYBOX-DOCKER ---
quay.io/coreos/alpine-sh --exec echo -- ALPINE-ACI
[278815.172141] busybox[6]: BUSYBOX-DOCKER
[278815.176207] alpine-sh[7]: ALPINE-ACI

>> - run in the namespaces of the host using "rkt fly":
>>
>> https://github.com/coreos/rkt/blob/master/Documentation/running-fly-stage1.md
>>
>
> I think "rkt fly" would make sense for running vpnc. If I were to run vpnc
> in "rkt fly", how might the Java application connect to the VPN? Would it
> still have to run in the same pod as vpnc? Could the Java app be packaged
> as a Docker image or must it be an ACI?

"rkt fly" does not support pods, it can only run one app at a time.
"rkt fly" does not isolate anything, so the vpnc would create the
network interface on the host and the Java application could be
executed in another "rkt fly" instance and connect to it, an any other
application on the host.

Cheers,
Alban
Reply all
Reply to author
Forward
0 new messages