DNS configuration with VPNs and Ubuntu 17.04: working again

I must have hit this bug on the upgrade from 16.10 to 17.04.

Result: DNS queries not working if not using FQDNs for my VPNs.

Time to find a workaround and so here’s my new configuration (note: see the update part at the end of the post).

Before you go on: if you try this, you will lose DNS resolution before you finish this setup. This will break your connections. So, ensure that you are able to roll-back all the changes or don’t do this.

First, I got rid of the systemd-resolved service:

sudo systemctl disable systemd-resolved.service

And resolvconf along with it:

sudo systemctl disable resolvconf.service

Then I installed openresolv:

sudo apt install openresolv

At this point /etc/resolv.conf should not anymore be a link, but a real file. Remove the link so that NetworkManager will recreate a file at /etc/resolv.conf:

sudo unlink /etc/resolv.conf

I then ensured that NetworkManager was using dnsmasq for dns, that is, this line must be uncommented and present in /etc/NetworkManager/NetworkManager.conf:


Using NetworkManager itself for DNS resolution will also work (dns=default), but then you will hit the limit of resolv.conf (i.e. max. 3 nameservers will work).

Then, restart NetworkManager:

sudo systemctl restart NetworkManager

With this configuration search domains and nameservers work as expected and they can be configured in the NetworkManager GUI.

For more details about NetworkManager: https://developer.gnome.org/NetworkManager/stable/NetworkManager.conf.html.

UPDATE: 09 Aug 2017

Since one of the VPNs was misconfigured and it was sending wrong nameserver information, I took this even more drastically and decided to manually manage the DNS setup via dnsmaq.

In addition to the above, I then uninstalled openresolve, and set


in /etc/NetworkManager/NetworkManager.conf to get full control over /etc/resolv.conf.

I installed dnsmasq and configured the nameservers for the domains there, e.g.:


with a plain and simple resolv.conf:

search example.domain

This setup requires some maintenance if I have to add new VPNs or change the nameservers for the existing ones, but at least it should be stable!

Giving away my MacBook Pro and going back to Linux

I’ve used GNU/Linux as my main and only desktop OS since more than 10 years (as a University student first and now at work).

I’ve always been fine with Linux and I never felt like I was missing something (except Skype, maybe – or a better multiscreen support on KDE). I would from time to time change my desktop environment to refresh the user experience when the UI started to become boring on the eyes (cycling between Unity, KDE, elementary, GNOME) and that purely aesthetic freedom felt great.

But I kept seeing a growing number of colleagues around me using Apple laptops. Were/Are they all blindly following the flavor of the week? No, I don’t think so, they’re smart people. I concluded that there had to be something really better about these MacBooks.

So I ordered one as my new work machine…

…and my experience with it has been positive (yes, past tense, it’s already over). Everything is there and works, the Desktop UI is very consistent (you notice this after so many years of Linux desktop :D), it’s pleasant to use and touch.

I’ve used it for 8 months and then I gave it back and ordered a System76 Lemur to re-embrace Linux.

From a professional point of view, to get the work done, there was really no substantial difference in using Mac OS or Linux. I use some terminals and an editor most of the times, then a browser, simplenote, HipChat. Basically all the software that I need is available and works well on both. My workflow is the same on the two OSs.

So why did I bother going back? I mean, if productivity is the same, I could have saved myself the inconvenience to make another switch.

Here are my reasons in order of importance:

  1. Open Source. I depend on open source, most of the engineers in tech do (Software engineers, DevOps, SysAdmins, etc). And this is not only for what runs on the servers. We all run plenty of open source tools on our laptops and our productivity is heavily determined by them. How would you work without git? Then filesystems, programming languages (Python, C/C++ compilers, scala, …), command-line utilities, Jenkins, Docker, VirtualBox, owncloud, VLC, transmission, … Open Source is so fundamental for me that the least that I can do is giving back. And this means fully embracing it and trying to contribute to some of the projects that I use. So, yes, my first reason for going back to Linux is ethical.
  2. Freedom. Simply put, if you don’t like something on your Desktop, make it better for you and everyone else. This is only possible with open source projects.
  3. Clear terms. Your main desktop OS comes with clear terms. You know what applications will do and if you have doubts, have a look at the source code.

That’s it.

As I said, “there was really no substantial difference” to get the work done, so the determining factor for going back to Linux had to be on some other – non technical level.

If you think that Linux on the desktop sucks, than start using it and help your DE of choice become great.

Install owncloud with docker, ZFS and ansible

I’ve been happily running FreeNAS on my server for quite some time now, I am a fan of ZFS and I’ve used it to great advantage both at home and at work.

After its good service and with ZFS on Linux becoming stable, I have decided to move away from FreeNAS and install a plain Ubuntu 16.04 server image to play with docker and ansible and enjoy destroying and re-spawning my ephemeral service instances in seconds!

Continue reading “Install owncloud with docker, ZFS and ansible”

Quickly setup powerline for bash in ubuntu

Powerline can do many things and it is very configurable.

I wrote a small script in case you just want to power-up your bash prompt and do it without a lot of manual steps.

This is what you will get:

Get it done!

Read the README file first, then:

(you may need to install git first, or just copy and paste the script somewhere from the repo… it will anyway install git)

git clone git@github.com:vincepii/ubuntu-powerline-bash.git
cd ubuntu-powerline-bash

Feel free to improve the script.

Repository on GitHub: https://github.com/vincepii/ubuntu-powerline-bash

Remember The Lens – Revamped

I want to start this post by thanking Pavel Shabardin as he created some new tickets on the GitHub page of Remember The Lens that caused new nice features to be brought to the project.

What’s new

  • Icons. I was willing to replace those ugly icons I made a while ago since a long time. I found some really nice ones on openclipart.org that gave the lens a new fresh look.
  • Preview. It is now possible to right-click on a task to get extra information.
  • Complete/Uncomplete tasks. On the preview screen, a button will appear to complete/uncomplete a task (depending on its current status). Very handy.
  • Show completed tasks. Because of that button above, it’s also good to show already completed tasks, so a “Complete” can be easily undone. A new “Show/Hide” section on the lens filters has a button for this.
  • Internationalization. The lens is now open to translations. I lost the Russian translation because I introduced new messages and changed existing ones. The Italian translation is of course there :).

Under the lens

Screenshots are more immediate than a video showing the lens at work (also, last time I wasn’t able to speak loud enough). Here are some.

Setting up a personal git repository: end-to-end tutorial

Recently I was in France with a colleague at an event organized by ETSI. In that occasion we needed to work on some code, but for some reasons we couldn’t use the company remote repositories.

Manually merging changes to a local copy we had was a time consuming and inefficient task, so I quickly set up a git repository on my machine that my colleague could access through the local network. Having a reference to do that operation in a short time may be very useful in situations similar to that one, but version tracking may be essential as well when working on personal projects or sketching code for new ideas. Setting up a git server is also a good idea to recycle some old hardware (I used to have an old notebook which worked as a printing server and git repository on my home network).

The following tutorial summarizes the steps required to setup a SSH server, use RSA keys, authorize users, and create a new git repository. This reference is first of all useful for me, but I hope that someone else will take advantage of this yet-another-git-setup-tutorial :).


There are many different ways of setting up a git repository. This tutorial shows a possible way for doing this quickly. Do not use this tutorial to set up a git repository in a production environment, where every configuration parameter (e.g.: for the SSH server) must be finely tuned and well understood.

Intended audience and assumptions

If you need to setup a git repository for personal use or for some reasons you don’t want to use a cloud service such as github, then this guide may help you. The steps here described will allow for the quick setup and use of a git repository on top of a fresh installation of an Ubuntu GNU/Linux distribution (I am using Ubuntu 12.10).

I assume that a git repository is created on the local machine inside the home folder of a new “git” user. In a more general configuration, where the git client and server are remote machines, you will just need to replace the loopback address with the one of the server.

Some basic knowledge of the Unix command line interface is required.

SSH Server configuration

The machine that will host the git repository needs to be accessed by clients. A possible way to access a machine remotely is through SSH.
SSH supports both password and public/private keys authentication. In this tutorial I will use RSA keys.

Install and configure an SSH server on the machine that will host the git repository:

sudo apt-get install openssh-server

Edit the /etc/ssh/sshd_config file to tweak the SSH server settings at your preference. I generally disable Password Authentication (you may need to uncomment the line) and Challenge Response Authentication:

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Start or restart the ssh daemon to accept the new configuration:

sudo /etc/init.d/ssh restart

Authorized Keys configuration

The public keys of the authorized entities who can login through ssh must be collected in the authorized_keys file under the ~/.ssh folder.

Create a git user on the machine that will host the repository (handle this as you prefer, it is not required to create a new user, but much cleaner):

sudo adduser git

Login as the git user, if you are on the same machine, just use

su git

to change to git user, then cd to the home directory


Create a .ssh folder and set its permissions (see the ssh man (1) page for explanations on permissions of the .ssh folder and its content):

mkdir .ssh
chmod 700 .ssh

Create an authorized_keys file under the ~/.ssh folder and append to it the public keys of the authorized git users:

touch .ssh/authorized_keys

A possible way to populate the authorized_keys file, from a user on the same machine as the “git” user would be (appends the public key of the current user at the end of the authorized_keys file of the “git” user, command issued from the home directory):

sudo bash -c "cat .ssh/id_rsa.pub >> ../git/.ssh/authorized_keys"

Set the proper permissions for the authorized_keys file:

chmod 600 .ssh/authorized_keys

Create a new git repository

Install git (if needed):

sudo apt-get install git

Initialize an empty git repository (I assume repositories are created in the home folder of the git user):

mkdir test_repo.git
cd test_repo.git
git init --bare

The server configuration is done.

Setup RSA keys on the client

The remaining part of the tutorial refers to operations to be done on the client who wants to access the git repository that we have prepared. In order to use the Secure SHell connection, the client needs a pair of public/private keys.

If you already have RSA keys, put them in ~/.ssh, otherwise you can create a new pair with:

ssh-keygen -t rsa -C "Comment Here (usually your email)"

Move the pair of generated keys (id_rsa and id_rsa.pub) into ~/.ssh
See the FILES section of the SSH man (1) page to set the proper permission to the ~/.ssh folder and its content. In a typical configuration, you may want to use:

chmod 700 .ssh/
chmod 400 .ssh/id_rsa
chmod 400 .ssh/id_rsa.pub

Clone the git repository

Set the git user global configuration:

git config --global user.name "Your Name"
git config --global user.email you@example.com

Create a new folder where you want to clone the repository, cd into that folder and initialize git:

mkdir foo
cd foo
git init

Configure the git client to access the test_repo.git repository (add the pointer to a remote called origin):

git remote add origin ssh://git@

Clone the repository (if someone has already committed some changes):

git clone ssh://git@

Create a new file and upload to the repository:

echo "Hello" > readme.txt
git add readme.txt
git commit -m "First commit"

Push the committed changes to the master branch:

git push origin master


Ubuntu 12.10 and Hybrid Graphics on Sony VAIO S

Today I made a fresh install of Ubuntu 12.10.

After having read this thread on phoronix forums about the latest release of the proprietary AMD drivers, I decided (once more) to use the vgaswitcheroo solution.

The vgaswitcheroo module can be used to power off the discrete graphic card and use only the integrated one from Intel. Personally, I don’t have any advantage in using the discrete graphic as the integrated one is enough to play HD video, the most GPU consuming task I ever need.

So I confirm that the solution described in this post still works on 12.10.

I edited the two files, rebooted the notebook… and then there was silence!