Are you still stuck with Windows 8.1 or earlier? Then, if you want to use Docker, you have to use the Docker Toolbox.

Docker Toolbox comes with its own “shell” called Docker Quickstart Terminal. It uses Windows’ own command window – which is pretty limited.

As I explored in Command Line Replacement For Windows, there are alternatives.

To be able to interact with Docker Toolbox in these alternative command line tools, you can create a simple batch file that drops you into the same Docker shell as the “Docker Quickstart Terminal”:

@echo off
setlocal
cd /D %DOCKER_TOOLBOX_INSTALL_PATH%
"%GIT_INSTALL_ROOT%\bin\bash.exe" --login -i "%DOCKER_TOOLBOX_INSTALL_PATH%\start.sh"

Even though Windows has a command line, this command line is very limited when compared to the ones available on Mac or Linux.

Fortunately, there are (free) alternatives out there. In this article we’ll be looking at three of them: ConsoleZ, ConEmu, and Cmder

At the end of the day, we’re looking for the best tool. So I’ve assembled a comparison chart for these three tools to find out which one is the best for me and you.

Read more →

As developers, we sometimes want to quickly test some software. Instead of installing it directly on our developer machine, it’s better to install it in a virtual machine (VM). But if you don’t have a VM ready, setting one up usally takes a lot of time – and there goes your productivity.

Fortunately, there is a solution: Vagrant

Vagrant is a free tool that lets you quickly spin-up fresh VMs out of thin air. It can even spin-up multiple VMs at the same time.

This article is step by step tutorial for getting from nothing to a multi-VM setup where the VMs can talk to each other.

Read more →

There are a lot of articles out there that explain how to run a PXE server. However, I couldn’t find a single one that contained all the information to setup a PXE server:

• on Ubuntu

• without replacing the network’s existing DHCP server (e.g. provided by a hardware router)

So, with article I’m trying to fill this gap.

The Goal ∞

At the end of this article you’ll have a working PXE server that lets you boot memtest86+ over a network.

The goal is to have a simple but working solution. This is why I’m using memtest. It consists of just one file and thus is easy to use in a PXE setup. More complex scenarios (i.e. loading real operating systems) can be built on top of this simple setup.

Everything described in the article can be done inside a virtual machine. The only requirement is that the VM is connected directly (i.e. no NAT) to the network where it’s supposed to serve PXE (usually the host’s network).

The Basics: PXE, DHCP, ProxyDHCP, TFTP, and dnsmasq ∞

PXE is an abbreviation for “Preboot Execution Environment”. To put it simple: It’s a standardized way to boot an operating system over network (rather than from hard disk).

DHCP is usually used to assign IP addresses to computers/devices in a network. PXE is an extension to DHCP. To use PXE one needs a PXE-capable DHCP server.

When PXE was designed, the creators wanted to make it compatible with networks that already have an existing DHCP server. As a result, PXE and DHCP can be provided by separate servers without interfering with each other. In this scenario, the PXE server is called proxyDHCP server and only provides the PXE functionality (but doesn’t do IP assigning).

TFTP (Trivial File Transfer Protocol) is used by PXE clients to download the operating system (file) from the PXE server.

dnsmasq is a “simple” Linux tool that combines a DNS server, a DHCP server, a TFTP server, and a PXE server. This is the tool you’ll use in this article.

Prerequisites ∞

The steps in this article are based on Ubuntu 16.04.

You need the following packages:

$ apt-get install dnsmasq pxelinux syslinux-common

You also need the precompiled memtest binary:

$ wget http://www.memtest.org/download/5.01/memtest86+-5.01.bin.gz
$ gzip -dk memtest86+-5.01.bin.gz

Furthermore, you need a working DHCP server (e.g. one provided by a hard router).

The last thing you need is to know the network you’re on. My network is 192.168.178.XXX – so I’ll use this in this article. This information is only needed once in a configuration file (see below).

Warning: During the course of this article your Ubuntu machine may temporarily lose the ability to do DNS lookups. This is caused by dnsmasq. If this happens to you and you need to download anything or access the web, just (temporarily) stop dnsmasq.

Step by Step: From Start to Finish ∞

Lets do it then. This section describes all steps need to get a working PXE server.

First, lets stop dnsmasq for now.

$ service dnsmasq stop

Create the directory where all transferable operating system files will reside:

$ mkdir -p /var/lib/tftpboot

Inside of this directory, create a directory for the unzipped memtest binary file and copy it there:

$ mkdir -p /var/lib/tftpboot/memtest
$ cp ~/memtest86+-5.01.bin /var/lib/tftpboot/memtest/memtest86+-5.01

Important: Note that the copy command removed the .bin file extension. This is required.

Now create the directory for the PXE configuration file:

$ mkdir -p /var/lib/tftpboot/pxelinux.cfg

Important: This directory must always be called pxelinux.cfg.

Inside of this directory, create a file called default and put in the following content:

default memtest86
prompt 1
timeout 15

label memtest86
  menu label Memtest86+ 5.01
  kernel /memtest/memtest86+-5.01

Next, you need to put the files pxelinux.0 (Ubuntu package pxelinux) and ldlinux.c32 (Ubuntu package syslinux-common) in /var/lib/tftpboot. I’ll use symlinks for that:

$ ln -s /usr/lib/PXELINUX/pxelinux.0 /var/lib/tftpboot/
$ ln -s /usr/lib/syslinux/modules/bios/ldlinux.c32 /var/lib/tftpboot/

Now, clear all contents of /etc/dnsmasq.conf and replace them with this:

1
2
3
4
5
6
7
8
910
11
12
13
14
15
16
17

# Disable DNS Server
port=0
 
# Enable DHCP logging
log-dhcp
 
# Respond to PXE requests for the specified network;
# run as DHCP proxy
dhcp-range=192.168.178.0,proxy 
dhcp-boot=pxelinux.0
 
# Provide network boot option called "Network Boot".
pxe-service=x86PC,"Network Boot",pxelinux
 
enable-tftp
tftp-root=/var/lib/tftpboot

Important: In line 9 you need to put in your network, if you’re not on 192.168.178.XXX.

Edit /etc/default/dnsmasq and add the following line to the end:

DNSMASQ_EXCEPT=lo

This line is necessary because you disabled dnsmasq’s DNS functionality above (with port=0). Without it Ubuntu will still redirect all DNS queries to dnsmasq – which doesn’t answer them anymore and thus all DNS lookups would be broken. You can check /etc/resolv.conf and verify that it contains the correct IP address for your network’s DNS server.

Last step – start dnsmasq again:

$ service dnsmasq start

Now, when starting a PXE-enabled machine, it should boot memtest.

Troubleshooting ∞

While I was trying to get a PXE server working, I stumbled across some pitfalls that I like to add here.

Starting dnsmasq fails because resource limit ∞

When starting dnsmasq with:

$ service dnsmasq start

and you get the error:

Job for dnsmasq.service failed because a configured resource limit was exceeded.

… then you (accidentally) deleted /etc/dnsmasq.d/README.

The dnsmasq init script checks the existence of this file and this leads to this obscure error message (filed as #819856).

PXE Boot with VMWare Fusion ∞

VMWare Fusion’s GUI is more designed for regular users than developers. If you want to use PXE boot in a VMWare Fusion VM, make sure you select “Bridged Networking” rather than “Share with my Mac” (which is NAT).

PXE Boot with Hyper-V ∞

To be able to PXE boot a Hyper-V VM, you need to add a Legacy Network Adapter to the VM. By default, only a non-legacy network adapter is added to VMs and it doesn’t support PXE boot (for whatever reason).

This is especially confusing since the “BIOS” section always lists “Legacy Network adapter” – even if none has been added to the VM.

In a local network (or any other network), it’s desirable to be able to find computers by name rather than by ip address.

So, instead of using:

$ ping 192.168.178.25

one wants to use:

$ ping mycomputer

This mapping task is typically done by a DNS server.

Sometime back I wrote an article about how to ping/identify computers by name on Windows.

Unfortunately this solution highly depends on a good router that

• lets you specify names for individual ip addresses (or determines them automatically)

• provides a domain name for your local network (e.g. “fritz.box”)

Unfortunately, I recently was forced to switch to a less “superior” router that doesn’t support these features. So an alternative had to be found.

Multicast DNS ∞

Fortunately, a solution exists and this solution is called Multicast DNS (short: mDNS).

Multicast DNS lets you find computers on your local network by name. You just have to add .local to the computer’s name.

So, to ping a computer called marvin you’d use:

$ ping marvin.local

What Do I Need? ∞

There are two major mDNS implementations: Apple’s Bonjour and Microsoft’s Link-local Multicast Name Resolution (LLMNR).

Bonjour seems to have a wider adoption so I’m concentrating on this.

Here’s what you need:

• Windows: If you have iTunes installed, you’re ready to go. If you don’t want to install iTunes, you’ll need to install the Bonjour Print Services for Windows. (Don’t be bothered by the “printing” part in the name. The package is a fully functional mDNS solution and it’s the only standalone Bonjour package available for Windows anyway.)
• Linux: You need Avahi which is compatible with Bonjour. On Ubuntu/Debian, you need two packages: avahi-daemon (to be visible on the network) and libnss-mdns (to be able to find other computers)

• OS X: Everything is pre-installed. You don’t need anything else.

Notes:

• The domain .local has officially been reserved for resolving names in a local network. This means that:

  • there will never be a “real” domain ending called “.local”. So you don’t run the risk of name conflicts with the internet.
  • good routers won’t ask your ISP’s DNS server for “.local” names. So connecting to a “.local” name, will always result in an ip address from the local network.
• mDNS, of course, only works if no two computers on the local network share the same name.

• With mDNS, you don’t need to specify .local as “primary DNS suffix” on Windows – unlike the solution in the aforementioned article.