ERROR: Cannot open TUN/TAP dev /dev/net/tun

To allow this for a specific container in Proxmox, we need to make a few tweaks to allow this interface to work in a specific container (we don’t want to allow all containers to be able to setup a tunnel – hackers can hide their tracks using it).

How to do this:

ADD these lines to /etc/pve/lxc/<container-id>.conf


lxc.cgroup.devices.allow = c 10:200 rwm
lxc.hook.autodev = sh -c "modprobe tun; cd ${LXC_ROOTFS_MOUNT}/dev; mkdir net; mknod net/tun c 10 200; chmod 0666 net/tun"

The problem with creating a directory for something before is mounted is that when zfs-mount.service runs and attempts to mount the zfs mount points you will get these kind of errors:

root@pve:~# systemctl status zfs-mount.service
● zfs-mount.service - Mount ZFS filesystems
Loaded: loaded (/lib/systemd/system/zfs-mount.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Fri 2017-06-30 18:10:21 PDT; 21s ago
Process: 6590 ExecStart=/sbin/zfs mount -a (code=exited, status=1/FAILURE)
Main PID: 6590 (code=exited, status=1/FAILURE)

Jun 30 18:10:19 pve systemd[1]: Starting Mount ZFS filesystems...
Jun 30 18:10:20 pve zfs[6590]: cannot mount '/gdata/pve/subvol-102-disk-1': directory is not empty
Jun 30 18:10:20 pve zfs[6590]: cannot mount '/gdata/pve/subvol-106-disk-1': directory is not empty
Jun 30 18:10:20 pve zfs[6590]: cannot mount '/gdata/pve/subvol-109-disk-1': directory is not empty
Jun 30 18:10:21 pve systemd[1]: zfs-mount.service: Main process exited, code=exited, status=1/FAILURE
Jun 30 18:10:21 pve systemd[1]: Failed to start Mount ZFS filesystems.
Jun 30 18:10:21 pve systemd[1]: zfs-mount.service: Unit entered failed state.
Jun 30 18:10:21 pve systemd[1]: zfs-mount.service: Failed with result 'exit-code'.

Fixing the root of the problem: change how proxmox deals with mounts by editing /etc/pve/storage.cfg – you need to add “mkdir 0” and “is_mountpoint” to the directory mount. Example:

dir: gdata-dump
path /gdata/vz
content iso,vztmpl,backup
maxfiles 0
shared 0
mkdir 0
is_mountpoint 1

Now we need to do some system cleanup before we reboot and confirm the problem is fixed.

Let’s check which mount points have failed:
root@pve:~# zfs list -r -o name,mountpoint,mounted

Now let’s umount all zfs mount points (except rpool of course – assuming the rootfs is zfs)

# zfs umount -a

After making sure ZFS mount points are unmounted, now we can delete the empty folders. Recall the failed mount points that the zfs list command gave you and one by one delete them like so:

# rm -rf /gdata/pve/subvol-102-disk-1

Do this for each folder that showed issues mounting. You have a choice to remount everything with zfs mount -O -a — or better… reboot the system and check its fixed. I like the later better. So reboot.

After it boots back up check that service was able to mount zfs without issues:

# systemctl status zfs-mount.service
# zfs list -r -o name,mountpoint,mounted

That’s all folks… if you made the edit to storage.cfg and added the two variables this should not occur again. This was an annoying bug to deal with but good to have found a better solution than a startup script doing some dirty tricks!

This time, I have a couchpotato container that I want to change its default port from 5050 to port 80, so that it is as simple as http://mycouch/ to access from the local network.

Since CouchPotato is a python script, my other method of whitelisting the binary won’t work, an alternative is to use authbind to get around this by granting a user/group privileges to bind to one of those restricted ports (non-root can’t bind to ports 1024 or less).

Environment: LXC Container (Debian 9.0 Stretch) image, with couchpotato defaults running on port 5050 and systemd init script setup (couchpotato user is named gmedia)

#  groupadd -g 3200 gmedia
# useradd -u 3200 -g gmedia -M gmedia
# apt-get install authbind
# touch /etc/authbind/byport/80
# chown gmedia /etc/authbind/byport/80
# chmod 500 /etc/authbind/byport/80

Now edit the startup settings (Exec/user/group):
# nano /etc/systemd/system/couchpotato.service

Should look something like this:

[Unit]
Description=CouchPotato application instance
After=network.target

[Service]
ExecStart=/usr/bin/authbind --deep /opt/CouchPotatoServer/CouchPotato.py
Type=simple
User=gmedia
Group=gmedia

[Install]
WantedBy=multi-user.target

Now its time to test:

# systemctl daemon-reload
# systemctl start couchpotato.service
# systemctl status couchpotato.service

Confirm all is hunky dory.

root@couchpotato:~# systemctl status couchpotato.service
● couchpotato.service - CouchPotato application instance
Loaded: loaded (/etc/systemd/system/couchpotato.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2017-06-29 08:35:32 UTC; 2s ago
Main PID: 1203 (python)
Tasks: 9 (limit: 4915)
CGroup: /system.slice/couchpotato.service
└─1203 python /opt/CouchPotatoServer/CouchPotato.py

Jun 29 08:35:32 couchpotato systemd[1]: Started CouchPotato application instance.
root@couchpotato:~# lsof -i :80
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 1203 gmedia 49u IPv4 6008724 0t0 TCP *:http (LISTEN)
python 1203 gmedia 52u IPv4 6024843 0t0 TCP 192.168.200.140:http->192.168.200.5:56928 (ESTABLISHED)
root@couchpotato:~#

In *nix any usage of well-known ports (aka 1024 or less) requires special privileges or a kernel setting. In FreeBSD a simple sysctl net.inet.ip.portrange.reservedhigh =1 was enough to allow the BSD jail to use any port on the jail.

On LXC, I had to figure out how to do the same thing and its quite different. My environment is a debian stretch LXC container but should work on other linux versions.

# apt-get install libcap2-bin
# setcap 'cap_net_bind_service=+ep' /usr/bin/transmission-daemon

In the example above, the binary /usr/bin/transmission-daemon is now able to open any port, or port 80 http in my case all while running a service as a non-root user.

Hopefully these helps folks out there, the answer took some digging but I already had an idea on what was needed thanks to my FreeBSD experience in zones

On January 4, 2017 Rancher announced experimental support for Windows containers (link below).

Official Microsoft documentation on containers.
Rancher v.1.3 has implemented experimental windows container support.

This is a good reason to spin up a Windows Server 2016 node and experiment in a lab. I’ll be looking forward to trying this when I get some time.

Personally, I have been using virtualization circa 2004. It all took off after 2006 when chip manufacturer’s started bundling virtualization technologies in their processors (Intel VT-x or AMD-v). The reason why “cloud” computing is so popular can also be attributed to virtualization.

In a container world…

However, in the past couple of years a new technology has been making making the rounds everywhere, the words “containers”, “docker”, “orchestration” is picking up steam in the past year. They say that containers are changing the landscape for system administrators and application developers.

Claims that containers can be built and deployed in seconds, share a common storage layer and allow you to resize the container in real-time when you need more performance or capacity are really exciting concepts and I think the time is now for me to jump in and learn a thing of two about this new technology when its hot a new.

Time to ditch vmware ESXi for a hybrid hypervisor?

You may remember my blog entry building a low-power sandy bridge ESXi server with ZFS – now 5 years later it is time to find a new platform that will allow me to keep my legacy virtual machines (VMs) as well as allow me to host containers using Docker.

The process of finding a suitable replacement for ESXi may take awhile and more than just a single entry on my blog. This is the first entry on my journey.

Before replacing something that works with a new platform I think it is good to point out the strengths and weaknesses of vmware ESXi (which has been my platform of choice for 6 years)

Strengths of ESXi

• awesome windows GUI vSphere client that allows you to manage your hypervisor without the need for console or ssh
• a web-interface to manage it too if you install a plugin
• virtual switch with VLAN support
• support for PCI passthrough (Intel VT-d) allowing you to assign PCI devices to virtual guests

Weaknesses

• does not support docker containers (unless you wish to create a virtual machine and run docker from there – but I prefer a central platform if possible)
• vmware continues to remove features from the free version of ESX – vSphere client interface is no longer availabel in their latest release
• Nothing exciting has been released by vmware in the past 2 years (in terms of ESXi) and they push esxi users into paid licensees

The alternatives?

SmartOS is a fork off OpenIndiana/OpenSolaris, it seems to have a lot of great security features and features from Solaris that enjoy (you may have read of my love for the ZFS filesystem which is native to SmartOS). Joyent has recently open-sourced their SmartDataCenter “SDC” or they are now calling it Triton Enterprise.

What I like about it other than the fact it uses native Solaris and it uses the ZFS filesystem for storage is the fact that it is a hybrid hypervisor. It can host containers and VMs (using technology similar to virtualbox since virtualbox is also from solaris).

The downside of this platform seems to be the complexity needed to deploy containers with this tool. You need to have a “head node” to be the brains of the platform, the “head node” does a lot of critical things. It monitors the network, the other compute nodes (where you host your vms/containers), it also hosts the database for all the nodes. In dev mode you can force the head node to also be able to host VMs but this is not recommended or good practice.

The web interface (SmartDataCenter) to manage your containers and VMs is also very rudementary, there is no built-in console to your guests. You need to run a lot of commands in the head node’s shell to make JSON queries to grab the data you want like the VNC server and port address for your guests.

Honestly I have not dug much deeper into SmartOS but I probably should, it looks like an awesome project. I am sure for people that want to use their platform for scalable container/hypervisor deployments it makes sense, but to replace my single server at home doing virtualization it does not look very likely this may be a good choice given the complexity.

Proxmox is another platform I am looking at, you may recall that 7 years ago I discovered proxmox virtual environment and started using it on my lab. That was Proxmox VE 1.5 I think and I recently discovered they have made a lot of strides in the right direction.

Just a few weeks ago they released their latest PVE 4.4 and they are now supporting ZFS data pools (via FUSE/zfsonlinux), not to mention that they have replaced OpenVZ with LXC (linux containers). It may be worth it for me to download their latest release and check out their platform again.

Other than Proxmox or SmartOS, I have not come across any other ‘hybrid’ hypervisors. Please share in the comments if there is something else I should check out.