Linux Networking Software www

Raspberry Pi + ad blocking + nginx

There’s this howto that explains how to set up the RPi as ad blocker.

I’ve two RPi’s acting a router and was already running dnsmasq. I decided to give it a try. Note that this howto can actually be used on any DNS serving Linux server.

First of all, don’t go with the pixelserv as it crashes after a few minutes.

Apache is an option that worked fine. A general hint: if you’re already running Apache or whatever on port 80, just add a 2nd static IP and make Apache listen to that.

For example (/etc/network/interfaces) — be sure it’s in the same subnet:

auto eth0:0
iface eth0:0 inet static
 broadcast is the Apache IP that just serves a HTTP 200 (or 204).

Here’s the relevant config part (note the HTTP 204 code, more info on that later):

<VirtualHost adblock:80>
 ServerAdmin [email protected]
 DocumentRoot /var/www
 <Directory />
 Options FollowSymLinks
 AllowOverride All
 <Directory /var/www/>
 Options Indexes FollowSymLinks MultiViews
 AllowOverride None
 Order allow,deny
 allow from all
 RewriteEngine on
 RedirectMatch 204 (.*)$
 ErrorDocument 204 " "

ErrorLog ${APACHE_LOG_DIR}/error.log
 LogLevel warn
 CustomLog ${APACHE_LOG_DIR}/access.log combined

And edit /etc/hosts to add “adblock”: adblock.local adblock

If I had used the IP instead of adblock I would have had this error:

# apache2ctl configtest
[Mon Sep 16 20:27:21 2013] [error] (EAI 2)Name or service not known: 
Failed to resolve server name for (check DNS) 
-- or specify an explicit ServerName
Syntax OK

With the HTTP 200 code, some browsers expect some content/file in return. So it’s generally safer to use HTTP 204 “No Content“; which basically means “all good but I have nothing to serve you.”

Now, I call myself an nginx fan. Running Apache on a RPi is a no go (at least for me). I could’ve ran nginx on the RPi, but decided to run it on a remote server with an additional IP. At least for now. To preserve resources on the RPi.

Here’s the relevant config to run it on nginx (and be sure this config is the first file nginx parses; or it might redirect all the domains to some other site):

server {
 listen 80;
 server_name _;
 access_log /var/log/nginx/pixel.access.log;
 error_log /var/log/nginx/pixel.error.log;
 expires max;
 autoindex off; 
 rewrite ^(.*)$ /;
 location / {
  return 204 'pixel';

And if we test it, this is what we get:

HTTP/1.1 204 No Content
Server: nginx/1.4.0
Date: Mon, 16 Sep 2013 18:36:52 GMT
Connection: close
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000

And that’s it.

<3 nginx

The only downside is that this won’t work with HTTPS. You can run your webbrowser with a self signed certificate, but this will throw errors…

The result:


Hardware Linux Software

Munin + Raspberry Pi + temperature

Quick hack to get Munin to graph the cpu temperature.


First of all, install Munin and make sure it’s working.

Then follow these steps:

1) We’ll use cron to write the current temp to a log file. We do this because I wasn’t able to get Munin to directly execute the command (error: temp.value VCHI initialization failed)

Execute crontab -e and add this line (this has to be on one line):

*/5 * * * * /opt/vc/bin/vcgencmd measure_temp | cut -d "=" -f2 | cut -d "'" -f1 > /tmp/.temp

2) Go to /etc/munin/plugins/, and create a file temp, and add this content:

case $1 in
cat <<'EOM'
graph_category system
graph_title Temperature
graph_vlabel temp
temp.label Celsius
exit 0;;
echo -n "temp.value "
cat /tmp/.temp

Save and exit the editor.

I’m not sure this is needed, but better do it: chmod +x temp

3) restart munin-node (/etc/init.d/munin-node restart)

4) test if it’s working:

# telnet localhost 4949
Connected to localhost.
Escape character is '^]'.
# munin node at
fetch temp
temp.value 57.3

That’s it. Your munin daemon/host should now correctly graph the temperature.

Edit (8/2/2014): updated script can be found here.

Apple Hardware Linux Networking Software

Home made TimeMachine


Used my Raspberry Pi, with an USB disk as TimeMachine. Another disk as NAS/storage. It’s just quite slow… Not sure whether it’s my WiFi or RPi that can’t keep up.

But for now, it’s working.

Hardware Linux Networking Software

Connect different LANs over openVPN

I now own three Raspberry Pi’s.

Using two of them (and my Guruplug as WiFi AP) I connected my new apartment with my old house (= parents) over VPN.

This way I can access the printers/scanners and NAS at home.

The 2 rPI’s are used as router (using a Macbook Air USB-to-Ethernet adapter as 2nd ethernet (eth1) port). Basic howto’s are easily found using Google to do this (a good starting point).

I made my own installation of Raspbian (as the downloadable image contains too much crap), details here (actually not that easy to find when Googling for bootstrap raspbian etc).


I’ve connected three different LANs over an OpenVPN connection:

  • LAN1 (home): (Gateway:, VPN ip:
  • LAN2 (apartment, ethernet): (Gateway:, VPN ip:
  • LAN3 (apartment, wifi): (Gateway:, VPN ip:

OpenVPN range: The subnet is in all cases.

LAN3 is connected via LAN2 to the internet. So the default gateway of router is

The gateway/routers are all Debian-based Linux systems. I’m using EDPnet as ISP, and thus need to use those Sagem/Belgacom approved routers (BBox-2 hardware). These Sagems are set in bridged mode, and don’t do the PPP stuff. PPPoeconfig on Debian takes care of most of the stuff. As EDPnet provides ipv6, I can ping6 from those routers.

The idea is to connect/ping each and every LAN from any of the clients connected the LANs (without running OpenVPN on the clients; only run it on the gateways).

For example: my PC with ip wants to connect to the NAS with ip

This can easily be achieved by setting a client-config-dir in the openvpn.conf file (or whatever the name of your config):

client-config-dir /etc/openvpn/tiete

And don’t forget to add route pushes:

push "route"
push "route"
push "route"

But here comes the annoying part. As I’m pushing routes via VPN, which is supposed to be my Guruplug’s default gateway as well (ISP > eth0:RaspberryPi:eth1 > eth0:Guruplug, remember?) this was causing quite some routing fuck ups.

The easiest way to solve this was to turn off VPN on the Guruplug all together, and route over the Raspberry Pi, by adding this line to /etc/network/interfaces:

up route add -net netmask gw dev eth1

Then I’ll change the client specific configs on the VPN. Create a file in whatever you picked as client-config-dir, and name it the actual VPN name (the name used when creating the key).

As I have three routers, I created three files (sheeva for my guruplug, Pi for my first rPI and Industry for my 2nd. Yep… Fancy names).

I also want to give a static IP address to the gateways, so I use the option:

ifconfig-push 10.9.8.<valid-ip> 10.9.8.<valid-ip - 1>

And I’ll also add the iroute option to push routes.

This is what it looks like for the router on the network (“Pi”):


For “Sheeva”, the WiFi AP on


And for plus routed over (“Industry”):


And don’t forget to set up masquerading over tun0 (or tun+) with iptables.

Now… Oddly enough, this didn’t require that much configuration, cursing and stress… And, well, it kind of just works.

From my Mac to my NAS:

nazgul ~ $ traceroute
traceroute to (, 64 hops max, 52 byte packets
 1 sheeva ( 1.936 ms 1.159 ms 0.800 ms
 2 ( 1.456 ms 1.776 ms 1.539 ms
 3 ( 55.745 ms 55.046 ms 54.734 ms
 4 ( 62.302 ms 55.327 ms 54.795 ms

From Pi (gateway to nazgul, my Mac:

pi ~ # traceroute
traceroute to (, 30 hops max, 60 byte packets
 1 ( 65.892 ms 74.177 ms 73.957 ms
 2 ( 73.441 ms 72.902 ms 72.342 ms
 3 ( 71.780 ms 71.187 ms 70.760 ms

From Heartbeat (, my Munin stats server to the printer:

heartbeat ~/bin # traceroute
traceroute to (, 30 hops max, 60 byte packets
 1 pi ( 39.835 ms 40.794 ms 41.567 ms
 2 ( 41.541 ms 42.452 ms 43.307 ms

From Heartbeat to Sheeva’s eth0 IP:

heartbeat ~/bin # traceroute
traceroute to (, 30 hops max, 60 byte packets
 1 industry ( 32.716 ms 32.615 ms 34.359 ms
 2 sheeva ( 34.405 ms 34.349 ms 35.014 ms

From Heartbeat to an Android device (not sure why the latency spike):

heartbeat ~/bin # traceroute
traceroute to (, 30 hops max, 60 byte packets
 1 industry ( 31.337 ms 32.269 ms 32.218 ms
 2 sheeva ( 33.006 ms 33.052 ms 32.996 ms
 3 ( 471.564 ms 472.169 ms 473.082 ms

Next up (once I have spare time): try to sync local DNS and fix local ipv6.

I’ll put most of the configs on Github at some point.