NFD nightly packages

NDN Forwarding Daemon (NFD) is the reference implementation of Named Data Networking (NDN) forwarding plane. The software is continuously developed, but binary releases happen rather infrequently. Recently, I made a workflow to build NFD and related software automatically.

Download page: nfd-nightly.ndn.today

Instructions

Which platform should I choose?

  • The platform identifier has two parts: Linux distribution and CPU architecture. Both parts must match your machine.
  • Linux distribution:
    • bionic is Ubuntu 18.04.
    • buster is Debian 10. This includes Raspberry Pi OS.
  • CPU architecture:

Ubuntu 16.04 NFD Development Machine

I shared how I setup my NFD development machine in 2017. Back then, NFD's minimum system requirement is Ubuntu 14.04 so my virtual machine is 14.04 as well. In May 2018, ndn-cxx started requiring Ubuntu 16.04, so it's time for a rebuild.

Vagrantfile for NFD Development in Ubuntu 16.04

Here's my new Vagrantfile:

$vmname = "devbox"
$sshhostport = 2222

$deps = <<SCRIPT
export DEBIAN_FRONTEND=noninteractive
apt-get update
apt-get dist-upgrade -yq
apt-get install -yq git build-essential gdb valgrind libssl-dev libsqlite3-dev libboost-all-dev pkg-config libpcap-dev doxygen graphviz python-sphinx python-pip
pip install sphinxcontrib-doxylink sphinxcontrib-googleanalytics
SCRIPT

Vagrant.configure(2) do |config|
  config.vm.box = "bento/ubuntu-16.04"
  config.vm.network :forwarded_port, guest: 22, host: $sshhostport, id: "ssh"
  config.vm.provider "virtualbox" do |vb|
    vb.name = $vmname
    vb.memory = 6144
    vb.cpus = 8
  end
  config.vm.provision "deps", type: "shell", inline: $deps
  config.vm.provision "hostname", type: "shell", inline: "echo " + $vmname + " > /etc/hostname; hostname " + $vmname
  config.vm.provision "sshpvtkey", type: "file", source: "~/.ssh/id_rsa", destination: ".ssh/id_rsa"
  config.vm.provision "sshpubkey", type: "file", source: "~/.ssh/id_rsa.pub", destination: ".ssh/id_rsa.pub"
  config.vm.provision "sshauth", type: "shell", inline: "cd .ssh; cat id_rsa.pub >> authorized_keys"
  config.vm.provision "gitconfig", type: "file", source: "~/.gitconfig", destination: ".gitconfig"
end

Differences from 2017

NFD on Windows 10 WSL

The NDN Forwarding Daemon (NFD) connects every Ubuntu and Mac OS machine to the Named Data Networking (NDN) testbed network. While it's awesome to get your NFD connected from a Linux server or a Macbook, 82.56% of the desktop users running Windows are out of luck. Compiling NFD for Windows is possible, but the amount of patches needed is astonishing.

Then the good news came: Microsoft announced Windows Subsystem for Linux (WSL), which lets developers run Linux environments directly on Windows, unmodified, without the overhead of a virtual machine. Ubuntu is the first Linux distribution supported by WSL. This means, we can now run NFD natively on Windows!

How to Install NFD on WSL

This section outlines how to install NDN Forwarding Daemon (NFD) on Windows Subsystem for Linux (WSL). As of this writing, I have Windows 10 version 1709 (Fall Creators Update), and the latest NFD release is version 0.6.1.

The steps to install NFD on Windows are:

How I Setup my NFD Development Machine

I'm the lead developer of NDN Forwarding Daemon (NFD). In this article, I want to share how my development machine is setup.

Everything in Virtual Machines

I do all NFD development work in virtual machines. There are many benefits in using VMs: I can have a clean operating system, I can test out different OS versions if necessary, and I can work on a different change on another VM when "my code's compiling".

My VM was setup using Vagrant, using the following Vagrantfile:

$vmname = "devbox"
$sshhostport = 2222

$deps = <<SCRIPT
apt-get update
apt-get dist-upgrade -y -qq
apt-get install -y -qq build-essential doxygen gdb git graphviz libboost-all-dev libcrypto++-dev libpcap-dev libsqlite3-dev libssl-dev pkg-config python-pip python-sphinx valgrind
pip install sphinxcontrib-doxylink sphinxcontrib-googleanalytics
SCRIPT

Vagrant.configure(2) do |config|
  config.vm.box = "ubuntu/trusty64"
  config.vm.network :forwarded_port, guest: 22, host: $sshhostport, id: "ssh"
  config.vm.provider "virtualbox" do |vb|
    vb.name = $vmname
    vb.memory = 4096
    vb.cpus = 4
  end
  config.vm.provision "deps", type: "shell", inline: $deps
  config.vm.provision "hostname", type: "shell", inline: "echo " + $vmname + " > /etc/hostname; hostname " + $vmname
  config.vm.provision "sshpvtkey", type: "file", source: "~/.ssh/id_rsa", destination: ".ssh/id_rsa"
  config.vm.provision "sshpubkey", type: "file", source: "~/.ssh/id_rsa.pub", destination: ".ssh/id_rsa.pub"
  config.vm.provision "sshauth", type: "shell", inline: "cd .ssh; cat id_rsa.pub >> authorized_keys"
  config.vm.provision "gitconfig", type: "file", source: "~/.gitconfig", destination: ".gitconfig"
end

Install OpenConnect VPN Server with Trusted Certificate from Let's Encrypt

OpenConnect VPN server, or ocserv, is an SSL VPN server compatible with Cisco AnyConnect. It can easily be installed in a cheap OpenVZ Virtual Private Server (VPS) with TUN capability. However, most online tutorials for installing OpenConnect VPN server rely on certtool to generate a self-signed certificate via OpenSSL. Afterwards, since the self-signed certificate is not trusted by operating systems, either the VPN client must be configured to skip certificate checking, or the self-signed certificate must be imported as a trusted certificate on the VPN client machine. Both practices are insecure. Bypassing certificate checking would allow an attacker to impose as the VPN server. Importing a trusted certificate does not seem wrong at first, but in case the private key is compromised, an attacker would be able to impose as any server to the client, including online shopping and bank websites, using a certificate signed by that private key. Remember that the self-signed certificate's private key is stored on the VPS filesystem, it is much less secure than Hardware Security Modules used at real CAs to store private keys, and therefore it is a bad idea to trust such certificates in client machines.

Let's Encrypt is a free, automated, and open Certificate Authority (CA). It allows anyone to obtain a domain-verified certificate within minutes, and without paying anything. Certificates from Let's Encrypt are trusted by most modern operating systems. They are ideal for securing an OpenConnect VPN server.

This article explains how to request a proper trusted certificate from Let's Encrypt for use with ocserv, how to install OpenConnect VPN Server and use the Let's Encrypt certificate, and how to configure Cisco AnyConnect client to connect to ocserv. These steps are verified with an OpenVZ Ubuntu 16.04 64bit VPS provided by SecureDragon. It is required to enable TUN devices for the VPS, typically through a button in SolusVM or other control panel provided by the hosting company.

Request Let's Encrypt Certificate for OpenConnect VPN Server

Before requesting a certificate from Let's Encrypt, you must have a Virtual Private Server with an IPv4 address, and have a domain name (could be subdomain) resolved to the server so that you are able to ping the server via the domain name.

parallelize.sh: run commands in parallel with bash

Recently I'm doing some heavy research work. One part of my work involves invoking a simulation script with different inputs and parameters and then an analysis script to analyze the simulation output.

At first, this is an easy bash loop:

(
  echo 3 11
  echo 3 11
  echo 5 19
  echo 5 19
) | while read -r -a L; do
  X=${L[0]}
  Y=${L[1]}
  python2 simulation.py --x=$X --y=$Y < input.tsv > $X-$Y.simulation.log
  gawk -f analysis.awk $X-$Y.simulation.log > $X-$Y.analysis.tsv
done

The loop works fine, but it takes too long time when the input gets larger, because scripts are running sequentially. Since we have a big server with 32 CPU cores, can I run the scripts in parallel?

So I wrote this nifty little script, parallelize.sh:

Share Dropbox between VirtualBox Host and Guest

My laptop comes with Windows, like most other laptops in the market. But as a computer science student, I need to use Linux from time to time. The laptop manufacturer advised me not to install Linux directly on this laptop. Although this would not void my warranty, they would not provide technical support or supply device drivers if I install Linux. Therefore, I turned into VirtualBox, a hypervisor that allows me to run Linux in a virtual machine, alongside the Windows installation.

I'm also a heavy user of Dropbox, a file hosting service that can synchronize my documents among all my device. I have Dropbox clients installed everywhere, including the Windows of this laptop, and the Linux virtual machine. When I edit a file, the Dropbox client uploads this file to the cloud, and then the Dropbox clients on all other devices download the file from the cloud.

One day, there's a congestion on my apartment's WiFi hotspot, and I notice that the Dropbox synchronization between Windows and the Linux virtual machine is having significant delay: every update travels a long way to the cloud, and then comes back. I also realize that, in my setup, the entire Dropbox contents are duplicated twice: it has one copy in Windows, and another copy in Linux virtual machine. Although having multiple copies is usually a good thing because you have more redundancy, having multiple copies on the same hard drive is not useful. Can I eliminate the synchronization delay and the redundant copy?

VirtualBox Shared Folder

VirtualBox has a nifty feature, shared folders, which allows files of the host system to be accessed within a guest system. In my setup, I could use this feature to access the Dropbox on Windows within the Linux virtual machine.