dev notes

running unbound

Everyobody interested enough to read this blog knows what DNS is and why it is important for the internet as we know it. There are many problems with DNS, that are caused by it’s nature of being a distributed system that does not give consistent answers to the same questions everywhere, due to caching, manual intervention or filtering. Some people are even famous for saying, it is the source of all our problems.

The one thing with DNS that bothers me lately more and more is that governments are forcing internet providers to install DNS filters, so that content can be hidden from the (uninformed) general public. Since I am allergic against any form of censorship I started - like so many - switching to other DNS providers, most prominently to googles public DNS. I am just a geek so it had a very high geek appeal to me due to its IP address. It works fine and is right now unfiltered (from what I can tell), but it is yet another thing, that I could actually run myself but use from an entity that I don’t pay for providing me that service.

Therefore I decided to learn a bit more about DNS and set up DNS resolver that is under my control. First I looked into a caching-only configuration of BIND, but then I stumbled upon unbound, wich is described as:

Unbound is a validating, recursive, and caching DNS resolver.

The software is maintained by Nlnet labs, which is a subsidy of the NLnet foundation. If you have never heard of them, they have money and run around to give it to people that want to build something great with it (what’s not to like?).

My current configuration runs on a centos 5.x box (old school, I know) and it is pretty straight forward to install. First make sure you have the EPEL repository enabled (who doesn’t?) and then install it with
yum -y install unbound.
Once yum has done it’s magic, you can should unbound start by default:
chkconfig unbound on.

Not only is the installation straight forward, the configuration is very easy as well. The configuration file in /etc/unbound/unbound.cfg has an explanation of all the options and the man pages are excellent as well, however the minimal thing you have to do, is the following:

In case you have iptables enabled on your server, you have to open port 53 for tcp and udp (see /etc/sysconfig/iptables and /etc/sysconfig/ip6tables). Now you can simply start the server with service unbound start and then verify that it works with something like dig @localhost notes.kel.pe. It should resolve the name without any problem. Once all of this works, you can try from a remote host, to verify, that the firewall and access-control settings are correct and then it’s time to modify your home router, to announce your new server as the default nameserver in your network.

One of the nice side effects of this setup is that resolved names are cached and everythings goes a bit faster, the other nice thing about it is that your provider can no longer filter the domains you see.

flash artifacts

Ever since I switched to xmonad I have had some problems with flash video, namely that the video was leaving some strange artifacts all over my desktop, when I left the browser tab, where the video was playing.Whereever there was something black, I could see the video instead

After some googling search on duckduckgo I found out, that it’s not a problem related to xmonad, but a bug related to the flash player and the proprietary nvidia drivers (yeah, I know…). Turns out, by simply disabling the hardware accelleration in the settings of flash player, the problem goes away. There seems to be no negative side effect by doing so.

One step further to the perfect desktop!

(pic unrelated to the problem)

quicktip: xsession support on fedora

Back when I had a bit more hair, everything was easy: I had an .xinitrc with a glorious fluxbox setup, booted into runlevel 3, logged in and typed startx. The world was simple.

At some moment I grew somehow into one of those persons that boot into runlevel 5 and use a full blown desktop environment, instead of their hand-crafted desktop potpourri.

Be that as it may, as I said a few weeks ago, I am considering to learn a tiling window manager. The procrastination thinking has an end now: I decided to learn me some xmonad. Right now my setup is basically a copy of the howto on the haskell wiki, but I am starting to somewhat get it.

So where is the tip?

After all this introduction here is the actual thing I wanted to get to: For some reason or another, the good old startx way of doing things no longer works for me, at least on my fedora system. That is however not a problem, since displaymanager for X like kdm or gdm have support for xsessions, which start a file called $HOME/.xsession upon login (older people here, will understand, what I mean). It turns out, that they still do that, but not by default. So to make it easy for all of us here: This is the one true commandline that got it all working for me:

sudo yum install xorg-x11-xinit-session

Once you have that, you can select the User script entry in gdm or kdm and your .xsession file will be used for starting up your desktop environment.

Those were a lot of words for such an easy task, but it helps if google duckduckgo indexes this information for other generations to come.

P.S.: I spent some (lunch break) minutes at work trying to find the right package on an ubuntu system, but I could not find it. Has anyone a clue, which one it is?

setting up a (free) vpn in no time

Last week I attended the 28th Chaos Communication Congress (#28c3) in Berlin, which is in my book the best volunteer based conference in our solar system. The conference had — as always — excellent internet connectivity. If you go to such conferences, you have to assume, that people watch your traffic, so it is a good idea to use a VPN. (The same is also true for the wireless network in your favorite coffee shop).

Getting a cheap VPN, for a month with multiple exit points on the planet, is possible, by paying a few Euro over at blackVPN and their service is excellent, but setting one up ourselves is also fun and only takes a few minutes. All we need are a server on the public internet with ssh access and a little piece of software called sshuttle.

To the cloud!

In order to get a server on the public internet, we can go over to amazon’s cloud and start a t1.micro instance, which is the smallest instance type they offer and costs you the incredible amount of 0.025$ per hour (in the EU region). If that is to much for your wallet I have good news for you: If you sign up for aws now, you are eligible for the so called free usage tier, which means you can run that thing at zero costs. (for more details on the free usage tier, see the introduction). Launch the instance via the webconsole or your preferred way and wait until it is up. We now have an exit point for our VPN on the public internet, but we still have to send our traffic over there, which is what we do next.

Building a tunnel.

As I said above, we are going to use sshuttle to set up the tunnel. It uses - as you might have guessed - ssh for tunneling all you traffic. This assumes that you have local sudo rights on your computer and that you have set up your ssh-config for aws.

git clone https://github.com/apenwarr/sshuttle.git
cd sshuttle
./sshuttle  -r ec2-user@[hostname-of-your-amazon-instance] --dns 0.0.0.0/0
(it now asks for local sudo rights )

That is all! All you traffic is now piped through the ssh connection. You can easily verify it, by running for instance curl ifconfig.me, which will print your current external IP. It should be the one of your aws instance. Since the tunnel is on kernel level, it is transparent to all running applications, so you don’t have to configure anything further.

If you want to stop the vpn/tunnel, just "Ctrl-C" sshutle and everything is back to normal.

For more information on sshuttle, check the README and if you have other tips like this, please leave a comment.

NOTE: All traffic is send encrypted to amazon, but if you use plain text protocols, those could still be sniffed on the other side. It is a good idea to always use encrypted protocols and if you use firefox, you should install the HTTPS Everywhere extension made by the EFF.

get a CLUE!

“Linux, the OS with a CLUE - Command Line User Environment”

I saw this quote in a signature on usenet a long time ago and as with so many funny quotes, it stuck in my head. It takes some time to discover the wisdom of this quote, because it is not just a silly word play. The commandline user environment is an overlooked power horse and with all things on unix, highly customizable.

The problem with the customizations is, that maintaining everything in .bashrc can be clunky and the distributions tend do do all sorts of stuff in there, as soon as you create a new user. After spending to much time on many boxes with all different settings, I built myself a solution, that fixes this for me once and for all:

I keep my entire bash setup on github, so that I can easily install it on any box I get an account on. Getting things, the way I like them is as easy as:

cd ~
git clone git://github.com/fs111/bash.d.git .bash.d
cd .bash.d
./install
bash

The .bash.d directory contains a set of shell scripts, that are sourced upon startup of bash. One contains aliases I use, one contains my colored prompt, one contains PATH modifications - you get the idea. The niceness about this is, that it only takes a minute for me on a new box, to be in a commandline environment, that works the way I like it.

Since all settings are maintained in git it is super easy to create experimental branches, to try new things out. If I start using a new setting, I just add it on one of the boxes, push it to the githubs and on all other boxes I work regularly, I just do a git pull. This is all very low tech, but the simplicity makes it so powerful in the end. Invest 30 minutes and do the same, you will be more productive ever after!

If you have some more tips and tricks leave a comment or if you keep your environment portable in a different way, please leave a comment as well.

Happy hacking!