It seems that Ubuntu/Debian (or perhaps other distros as well) prefer IPv6 DNS records instead of IPv4 when applicable and some times this results in loss of connectivity or similar problems.

I ran into this issue today while trying to update an old VPS with apt-get/aptitude. Specifically, security.ubuntu.com was being resolved in an unreachable IPv6 address and I had to wait some minutes for timeout every time.

Fortunately, there is an easy fix for this; you just have to edit the file located at: /etc/gai.conf which is the configuration for getaddrinfo(). There you have to uncomment line ~54 which reads: “precedence ::ffff:0:0/96 100”, and you are all set! (assuming that every other option is commented out by default as in my case).

I recently completed a project with the goal of automating our functional testing infrastructure. I should actually call it semi-automation since a team of human engineers are still needed in order to build and fire test runs (which is not a downside, it was designed with that in mind). Below I will describe a rough plan for everybody who wants to do something similar. I won’t go into much details but I will surely give an overall workflow that is easy to follow.

The challenge here was mostly the integration of TestRail with the local QA environment, and this is what I am going to describe. If you don’t use TestRail, I am not sure if this will be of any benefit to you.

The tools

I suppose that to search for this article you have an idea of how to implement testing automation and have already installed some of the needed tools. In any case here are some of the tools I used:

TestRail: TestRail is described as a “Test Case Management & Test Management Software Tool”, which is actually a pretty good description. You can think of it like a CMS to organize your tests. You can create different projects, categories, test suites and test cases. And then you can take some of these test suites as a whole or specific test cases and group them in what is called a “test run”. A test run is let’s say a runnable instance of the selected tests. The goal of the overall project was to automate the actual execution of each test run and report back the results to TestRail.

Amazon Web Services (AWS): One or more servers where our tests would run on were needed, so some commodity EC2 instances served that need. You don’t have to buy something powerful to begin, a small EC2 instance can be enough.

Selenium: In particular, Selenium Server and WebDriver, in order to run each test properly since they actually automate browser functionality and actions. Using a combination of those on the same machine you can either run the tests locally or remotely (perhaps on a cloud service like Sauce Labs or BrowserStack).

Python with unittest to write the actual functional tests using the WebDriver API and py.test to execute the tests (perhaps in parallel) and get back their results.

Bear in mind that this is not what was eventually implemented (as it gets more complex down the road with multiple servers, parallel testing, etc) but it was my first working prototype and it should serve as a good basis to start with.

I am happy to announce another small side-project. This time, I decided to make a Dionaea malware honeypot VM available with one command (no kidding!)

Lately, I have been playing around with Vagrant which is a fantastic tool to include in your development workflow. Apart from others, Vagrant allows you to create virtual machines and provision them using simple shell scripts or configuration management software like Chef, Puppet, etc. You can then package and distribute a VM among your team so everyone starts with the same base (no more worries about missing dependencies, different versions or platforms) or create baselines for various systems in your environment. Read here for more benefits.

In any case, I have created some simple shell scripts to automate the installation, configuration and execution of Dionaea. These three are included in a so-called Vagrantfile (Vagrant’s configuration file) which is applied to a VM upon launch. To use it, first install VirtualBox and Vagrant itself for your OS version.

This will download (only the first time) a virtual disk, create a new Ubuntu 12.04 LTS VM on the fly and start it, install Dionaea and all of its dependencies and execute it as daemon along with p0f. And that’s it!

You can then login into the machine by typing “vagrant ssh” or using an SSH client (e.g. PuTTY) and connect to localhost:2222 — username: vagrant, password: vagrant. Once inside the VM, type “ifconfig” to find out the IP address assigned to the bridged adapter (eth1), which you can use to forward ports from your home router back to the VM. For a list of ports used by Dionaea type “sudo netstat -antp | grep dionaea”.

If you want to stop the machine type “vagrant halt” (on the outer terminal, not inside the machine). Every time you want to start the honeypot VM a simple “vagrant up” issued inside the dionaea-vagrant directory is enough! (hint: see the list of CLI commands for more)