One major drawback of doing web development on Windows is the difficulty of running software primarily developed for Linux, things like redis, node.js and git. With great virtualization software nowadays, it is very feasible to run Linux software inside of Windows without any performance penalty. In particular, running Linux headless, and accessing the VM only over the network, is a great resource-saver.
Here’s how to get a headless Linux virtual machine running under Windows in 10 minutes. My tiny Linux distribution of choice is SliTaz 4.0, whose installation ISO is a respectable 8 MB. It’s tiny and fast: installation to disk takes about 30 seconds, boot time is about 10 seconds (running on my five year old laptop). When I have the headless virtual machine running, I access the shell via SSH (with Putty) and edit files via SFTP (with WinSCP). [Why not use Vagrant?] [Why not use shared directories?]
In VirtualBox (I am using 4.2.10), create a new virtual machine. Give it as much RAM as you want. I give 512 MB which is probably more than enough, depending on what you want to do. For the hard drive, make a dynamically allocated VDI with a maximum size of 8 GB or so. Set the virtual machine to boot from the SliTaz 4.0 base ISO (8.08 MB) and start it.
After booting from the ISO, you should arrive at a splash screen. Choose “SliTaz Live” to run the operating system from the read-only media. Choose the language and keyboard settings, and then you will get thrown to a login prompt. Login as
root; the password is
root. Now we want to install the operating system onto our VirtualBox disk. We have to partition and format the disk image, which we accomplish like this:
# fdisk -l Disk /dev/sda: 8589 MB, 8589934592 bytes ... Disk /dev/sda doesn't contain a valid partition table # fdisk /dev/sda [note: same disk as reported above] ... Command (m for help): n [note: create new partition] Command action e extended p primary partition (1-4) p [note: primary partition] Partition number (1-4): 1 First cylinder (1-1044, default 1): [ENTER] Last cylinder or +size or +sizeM or +sizeK (1-1044, default 1044): [ENTER] Command (m for help): w [note: write and exit]
fdisk -l should show
/dev/sda having a partition table. Take note of the partition name, which will probably be
tazinst new setup.conf which will create the installation configuration file
setup.conf. Edit it with
vi setup.conf. You will want to change the following:
TGT_PARTITION="/dev/sda1"or whatever partition
fdisk -ltold you.
TGT_GRUB="yes"otherwise you will not be able to boot from the hard drive.
If you’ve never used
i to start editing the text of the file. When you’ve finished editing the file, press
ESC and type
:x, then press
Now proceed with the installation:
tazinst install setup.conf. This should take less than a minute and then it will bring you back to a prompt.
reboot. You can log in as
tux; the password is blank.
At this point, the operating system is installed and bootable on the virtual hard drive, but some things have to be changed before it’s truly usable. The 8 second GRUB countdown is one of those things (especially for running the VM headless). Run
su (remember the root password is
vi /boot/grub/menu.lst and set the timeout to
While you are still root,
tazpkg get-install sudo (
tazpkg is the SliTaz package manager). Once that finishes,
visudo and insert the following line at the end of the file:
tux ALL=(ALL) NOPASSWD: ALL. This will let you execute
sudo from the
tux user without being prompted for a password, if you’re into that sort of thing. Now we can
exit and proceed as
We want the SSH daemon (SliTaz uses
dropbear) to run at system boot. Run
sudo vi /etc/rcS.conf and modify the value of
RUN_DAEMONS to contain
dropbear. Mine reads
firewall dropbear; there are probably other daemons listed which you should feel free to delete. In addition to running the SSH daemon, you should also
sudo tazpkg get-install sftp-server, which will enable SFTP over SSH.
Here are some additional changes that I make which are up to personal preference:
sudo tazpkg get-install bashand then edit the
sudo tazpkg get-install openssh(to replace the dropbear SSH client, which is a headache if you are using git).
sudo tazpkg get-install vim-tiny(to replace
ENDkeys, add the following to
bind '"\e[1~": beginning-of-line'and
bind '"\e[4~": end-of-line'.
~/.profile, remove the
After you’ve made all of the changes you want to make,
To run the virtual machine in headless mode, go into the VirtualBox GUI and
SHIFT+DOUBLECLICK the virtual machine you just made. Edit the settings for the virtual machine (it’s okay if it’s already running at this point), go to “Network”, “Advanced”, click on “Port Forwarding”. Add a rule where the “Guest Port” is
22 and the “Host Port” is whatever you want (say,
2222). Note that the default network type (NAT) is perfectly sufficient for what we’re doing.
Open Putty and connect to
localhost on port
2222 (or whatever port you chose). Open WinSCP and do the same. Enjoy.
Once you have this base VM set up, you can duplicate it and spin off tiny virtual machines dedicated to different projects. I recommend doing full clones, avoiding VirtualBox’s “linked clone” feature which, in my experience, is prone to disk corruption.
Vagrant can be a useful tool, but I have two reasons for avoiding it in this case.
First, this is a very quick bootstrap process which can be instructive for somebody new or a refresher for somebody with more experience. Once the setup has been done once, duplicates can be made within VirtualBox, so it’s not a problem to spin up several copies for different purposes.
Second, the Windows port of Vagrant is not great. In order to SSH to the Vagrant VM, you have to use either cygwin or jump through hoops to use Putty. Also, the installation takes up over 200 megabytes, which can’t be justified for this use case.
Shared directories are extremely slow (especially if you try to use something like git from inside the guest system). They also require the VirtualBox guest additions to be installed, which is a waste of effort and disk space in this particular case. WinSCP monitors file modifications so that any changes made in your text editor (on the host system) are more or less instantly relayed to the virtual machine.