This seems to come with unlimited data for ~20USD for 24hrs. I manage to stream Google Music just fine.

I totally went Matrix mode during the flight. While the flight is half empty I am wondering if they think I am haxoring it now.

EVA uses T-Mobile Germany as carrier.

Public IP routes to a German IP (and Google redirects to Google.de).

nazgul ~ $ curl canhazip.com
88.128.80.215

Whois info:

[...]

inetnum: 88.128.80.0 - 88.128.95.255
netname: ca-de
descr: Telekom Deutschland GmbH
country: DE
admin-c: TH12429-RIPE
tech-c: AS8728-RIPE
tech-c: MS47198-RIPE
remarks: ***************************************************************************
remarks: Please send any abuse complaints to: abuse@telekom.de
remarks: Behoerdenauskuenfte koennen nur ueber folgende Ruf- bzw. Faxnummern beantwortet werden:
remarks: Fax: 0180-18812-66 (0,039 Euro/Minute aus dem Festnetz der Deutschen Telekom AG.)
remarks: Tel.: 0180-18812-77 (0,039 Euro/Minute aus dem Festnetz der Deutschen Telekom AG.)
remarks: ***************************************************************************
status: ASSIGNED PA
mnt-by: MNT-TMD
created: 2008-05-06T07:54:12Z
last-modified: 2012-07-30T08:54:39Z
source: RIPE

Trace routes are quite odd:

nazgul ~ $ traceroute yeri.be
traceroute to yeri.be (83.149.69.152), 64 hops max, 52 byte packets
1 ns.evawifi.com (172.19.248.1) 3.429 ms 2.746 ms 2.921 ms
2 10.207.1.1 (10.207.1.1) 2.998 ms 2.535 ms 2.455 ms
3 172.18.15.41 (172.18.15.41) 553.837 ms 536.711 ms 541.207 ms
4 172.18.14.34 (172.18.14.34) 615.658 ms 534.722 ms 536.465 ms
5 * * *
6 yeri.be (83.149.69.152) 728.306 ms 749.172 ms 738.020 ms
7 yeri.be (83.149.69.152) 743.171 ms 735.898 ms 858.885 ms
8 yeri.be (83.149.69.152) 731.611 ms 764.056 ms 734.694 ms
9 yeri.be (83.149.69.152) 745.765 ms 745.182 ms 729.407 ms
10 yeri.be (83.149.69.152) 745.248 ms 1002.078 ms 750.183 ms
11 yeri.be (83.149.69.152) 901.702 ms 758.616 ms 898.359 ms
12 yeri.be (83.149.69.152) 750.162 ms 779.888 ms 863.083 ms
13 yeri.be (83.149.69.152) 777.654 ms 777.442 ms 750.133 ms
14 yeri.be (83.149.69.152) 745.435 ms 783.786 ms 942.607 ms
15 yeri.be (83.149.69.152) 926.653 ms 939.882 ms 830.519 ms
16 yeri.be (83.149.69.152) 1239.295 ms 754.112 ms 753.986 ms

nazgul ~ $ traceroute google.com
traceroute to google.com (172.217.17.46), 64 hops max, 52 byte packets
1 ns.evawifi.com (172.19.248.1) 1.716 ms 1.200 ms 2.627 ms
2 10.207.1.1 (10.207.1.1) 2.155 ms 1.932 ms 2.165 ms
3 172.18.15.41 (172.18.15.41) 583.366 ms 588.440 ms 730.303 ms
4 172.18.14.34 (172.18.14.34) 552.347 ms 963.682 ms 550.350 ms
5 172.30.1.34 (172.30.1.34) 841.324 ms * 637.136 ms
6 ams16s29-in-f46.1e100.net (172.217.17.46) 752.359 ms 744.614 ms 819.851 ms
7 ams16s29-in-f46.1e100.net (172.217.17.46) 735.554 ms 737.249 ms 785.678 ms
8 ams16s29-in-f46.1e100.net (172.217.17.46) 766.046 ms 738.774 ms 750.276 ms
9 ams16s29-in-f46.1e100.net (172.217.17.46) 817.491 ms 736.133 ms 765.344 ms
10 ams16s29-in-f46.1e100.net (172.217.17.46) 1047.754 ms 754.939 ms *
11 * ams16s29-in-f46.1e100.net (172.217.17.46) 761.013 ms 762.848 ms
12 * ams16s29-in-f46.1e100.net (172.217.17.46) 840.602 ms 750.186 ms
13 ams16s29-in-f46.1e100.net (172.217.17.46) 935.149 ms 808.133 ms 745.638 ms
14 ams16s29-in-f46.1e100.net (172.217.17.46) 736.075 ms 881.481 ms 788.661 ms
15 * * *
16 ams16s29-in-f46.1e100.net (172.217.17.46) 876.269 ms 1195.194 ms 754.661 ms
17 ams16s29-in-f46.1e100.net (172.217.17.46) 749.985 ms 850.065 ms 742.763 ms
18 ams16s29-in-f46.1e100.net (172.217.17.46) 737.418 ms 1079.194 ms 751.415 ms
19 ams16s29-in-f46.1e100.net (172.217.17.46) 765.339 ms 763.116 ms 754.928 ms
20 ams16s29-in-f46.1e100.net (172.217.17.46) 765.059 ms 767.733 ms 762.777 ms
21 ams16s29-in-f46.1e100.net (172.217.17.46) 860.458 ms 780.965 ms 757.507 ms
22 ams16s29-in-f46.1e100.net (172.217.17.46) 768.432 ms 747.930 ms 764.553 ms
23 ams16s29-in-f46.1e100.net (172.217.17.46) 758.869 ms 747.489 ms 751.329 ms
24 ams16s29-in-f46.1e100.net (172.217.17.46) 797.699 ms 818.899 ms *

nazgul ~ $ traceroute t-mobile.de
traceroute to t-mobile.de (46.29.100.15), 64 hops max, 52 byte packets
1 ns.evawifi.com (172.19.248.1) 1.978 ms 1.080 ms 1.071 ms
2 10.207.1.1 (10.207.1.1) 4.575 ms 1.885 ms 1.847 ms
3 172.18.15.41 (172.18.15.41) 540.670 ms 739.430 ms 787.836 ms
4 172.18.14.34 (172.18.14.34) 646.621 ms 775.771 ms 562.301 ms
5 * 172.30.1.34 (172.30.1.34) 630.660 ms *
6 46.29.100.15 (46.29.100.15) 1014.377 ms 813.739 ms 755.431 ms
7 46.29.100.15 (46.29.100.15) 766.290 ms 805.572 ms 735.697 ms
8 46.29.100.15 (46.29.100.15) 806.918 ms 792.377 ms 945.535 ms
9 46.29.100.15 (46.29.100.15) 783.751 ms 736.085 ms 781.832 ms
10 46.29.100.15 (46.29.100.15) 817.682 ms 738.980 ms 1031.463 ms
11 46.29.100.15 (46.29.100.15) 872.993 ms 767.682 ms 807.777 ms
12 46.29.100.15 (46.29.100.15) 986.659 ms 804.279 ms 806.750 ms
13 46.29.100.15 (46.29.100.15) 846.340 ms 767.556 ms 939.215 ms
14 46.29.100.15 (46.29.100.15) 737.330 ms 759.259 ms 786.724 ms
15 * * *
16 * * *

Not very sure what witchery is going on here.

arp shows AP isolation and two different servers running for the WiFi:

nazgul ~ $ arp -a
ns.evawifi.com (172.19.248.1) at 0:d:2e:0:40:1 on en0 ifscope [ethernet]
www.evawifi.com (172.19.248.2) at 0:d:2e:0:0:a8 on en0 ifscope [ethernet]
? (172.19.249.255) at (incomplete) on en0 ifscope [ethernet]
? (224.0.0.251) at 1:0:5e:0:0:fb on en0 ifscope permanent [ethernet]
? (239.192.0.0) at 1:0:5e:40:0:0 on en0 ifscope permanent [ethernet]
? (239.255.255.250) at 1:0:5e:7f:ff:fa on en0 ifscope permanent [ethernet]

There seems to be a transparant Squid/3.4.6 caching proxy running:

More random things can be found here.

However, it’s now time for something new.

As always, as minimalistic as possible.

On a side note, this blog has been moved from vm1 (and one before that) a virtual machine running on a dual Xeon 3070 (2.66Ghz) at Databarn to Akama, a VM on an 8 core Xeon E3-1230 (3.2Ghz) at Leaseweb.

I’ve also correctly repaired IPv6 on this blog. Apparently nginx never and/or stopped correctly listening to IPv6 (suddenly my Android devices displayed errors on this page, Chrome & Firefox on OS X seemed to fall back to IPv4 instantly… Not sure how long it was broken, but it’s back).

Note to self:

listen          yeri.be:443;
server_name     yeri.be;

Does not work with IPv6, it has to be

listen          [::]:443;
server_name     yeri.be;

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
 address 10.100.200.254
 netmask 255.255.255.0
 broadcast 10.100.200.255

10.100.200.254 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 webmaster@domain.net
 DocumentRoot /var/www
 <Directory />
 Options FollowSymLinks
 AllowOverride All
 </Directory>
 <Directory /var/www/>
 Options Indexes FollowSymLinks MultiViews
 AllowOverride None
 Order allow,deny
 allow from all
 RewriteEngine on
 RedirectMatch 204 (.*)$
 ErrorDocument 204 " "
 </Directory>

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

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

10.100.200.254 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 10.100.200.254 (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 pixel.0x04.com 10.100.200.254 _;
 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:

[...]
/usr/lib/ruby/1.8/puppet/agent/locker.rb:21:in `lock'
/usr/lib/ruby/1.8/puppet/agent.rb:44:in `run'
/usr/lib/ruby/1.8/sync.rb:230:in `synchronize'
/usr/lib/ruby/1.8/puppet/agent.rb:44:in `run'
/usr/lib/ruby/1.8/puppet/agent.rb:108:in `with_client'
/usr/lib/ruby/1.8/puppet/agent.rb:42:in `run'
/usr/lib/ruby/1.8/puppet/application.rb:172:in `call'
/usr/lib/ruby/1.8/puppet/application.rb:172:in `controlled_run'
/usr/lib/ruby/1.8/puppet/agent.rb:40:in `run'
/usr/lib/ruby/1.8/puppet/application/agent.rb:337:in `onetime'
/usr/lib/ruby/1.8/puppet/application/agent.rb:311:in `run_command'
/usr/lib/ruby/1.8/puppet/application.rb:309:in `run'
/usr/lib/ruby/1.8/puppet/application.rb:416:in `hook'
/usr/lib/ruby/1.8/puppet/application.rb:309:in `run'
/usr/lib/ruby/1.8/puppet/application.rb:407:in `exit_on_fail'
/usr/lib/ruby/1.8/puppet/application.rb:309:in `run'
/usr/lib/ruby/1.8/puppet/util/command_line.rb:69:in `execute'
/usr/bin/puppet:4
err: Could not send report: Error 413 on SERVER: <html>
<head><title>413 Request Entity Too Large</title></head>
<body bgcolor="white">
<center><h1>413 Request Entity Too Large</h1></center>
<hr><center>nginx/1.1.19</center>
</body>
</html>

The error seems quite easy to solve by modifying nginx’ config to allow bigger body sizes.

Edit nginx.conf and add this line:

client_max_body_size 50M;

(I’ve set it to 50M, although that’s probably way to big, but so far I’ve not been able to reproduce this error).

So from 0.9.4 to 0.6.32 (Lenny), which will be upgraded to 0.7.x in Squeeze.

I’ve come across this error on certain servers:

# /etc/init.d/nginx restart
Restarting nginx: 2011/02/11 11:34:58 [emerg] 3624#0: could not build the server_names_hash, 
you should increase server_names_hash_bucket_size: 32
nginx.

This can be solved by adding this to the nginx.conf:

server_names_hash_bucket_size 64;

Be sure to place it between the http-section.

[...]
http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    server_names_hash_bucket_size 64;

    access_log	/var/log/nginx/access.log;
	
    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;
    tcp_nodelay        on;
    tcp_nopush	       on;

    gzip  on;
    gzip_comp_level   5;
    gzip_http_version 1.0;
    gzip_min_length   0;
    gzip_proxied      any;
    gzip_buffers      16 8k;
    # Some version of IE 6 don't handle compression well on some mime-types, 
    # so just disable for them
    gzip_disable "MSIE [1-6].(?!.*SV1)";
    gzip_types        text/plain text/css image/x-icon application/x-javascript text/xml  application/xml application/xml+rss text/javascript image/gif image/jpeg image/png application/json application/x-tar application/zip application/x-rar-compressed application/msword application/octet-stream application/vnd.ms-excel application/pdf application/vnd.ms-powerpoint;
    gzip_vary         on;

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

Being unresponsive I reset the machine to reboot it.

After booting up and testing websites running on it I came along an odd PHP error;

Call to undefined function http_post_data()

Probably due to PHP updates from Lenny/testing to Squeeze.

This error is caused by not having installed PECL-HTTP (and php-pear php5-dev libcurl3-openssl-dev)

However, PECL-HTTP had been installed for ages and running the pecl install command resulted in this:

# pecl install pecl_http
pecl/pecl_http is already installed and is the same as the released version 1.7.0
install failed

Some quick Googling didn’t come up with a simple fix.

I then tried to reinstall PECL-HTTP (by uninstalling and reinstalling it)

# pecl uninstall pecl_http
Unable to remove "extension=http.so" from php.ini
uninstall ok: channel://pecl.php.net/pecl_http-1.7.0
# pecl install pecl_http
downloading pecl_http-1.7.0.tgz ...
Starting to download pecl_http-1.7.0.tgz (173,979 bytes)
[...]

Which luckily did solve my issue…

So reinstalling does actually solve stuff on Linux :x

Be sure to have extension=http.so in your php.ini and to restart php if it’s running with fastcgi or restarting Apache after making the changes.

And well, performance just wasn’t good enough. So I said bye to one.rootspirit.com, and hi to vm1.rootspirit.com a couple of days ago. Vm1 is no longer the nginx proxy, but is hosting my whole blog now. No more Apache for me.

Now to see if performance increases and if it was any point in changing.

Oh, and all static/upload/image requests are now rewritten to a new domain (static.0x04.com). Gives me to option to move static pages to a different webserver/host in the future. And why 0x04.com and not static.yeri.be or static.tuinslak.org ? Well, don’t know. Just like my “0x04” domain name! :D

Oh well… Just playing around…

• /etc/nginx/nginx.conf // general nginx config
• /etc/nginx/sites-available/blog // my current (as of posting this) rproxy settings for this blog
• /etc/nginx/conf.d/proxy.conf // reverse proxy related config

none on /var/cache/nginx/blog type tmpfs (rw,size=512m)

none  512M   47M  466M   4% /var/cache/nginx/blog

Let’s see what performance boosts this will give. :P

Here are some stats: image+html and php. Note that the php on apache (recompiled each request, about 1.5-2sec between every request) versus the cached output has a huge difference. Difference between images and static text files aren’t that huge. Also note that nginx has gzip enabled. The downside is that nginx caches all pages (HTTP code 200) for one hour and isn’t notified when pages are modified (yet).

My “live” blog is also accessible using blog.yeri.be as blog.tuinslak.org will now point to the nginx reverse proxy.

I’ve come across a few issues though, pages such as this (shows your current IP address) and this (compare to this and refresh a few times) are cached as well, and actually show the previous visitor (if any) their output and the pages aren’t updated when a new visitor visits them. Edit: fixed, correctly refreshes; .php under wp- isn’t cached.

Same goes for layout (I use WPtouch for mobile devices). A page that got visited on the iPhone and then on a desktop as well as a page that got first cached using a desktop browser and then an iPhone. I’ve disabled WPtouch for now.

And a 3rd issue is that the Wordpress stats image () is cached as well. So if a regular visitor visits the site before a a registered user (admin), the stats image will still be present (and generate incorrect stats). This doesn’t happen the other way around, as no pages are cached for a registered user (unless they are already in its cache)… Weird. Edit: fixed by watching the http cookie and this plugin. Admin pages are never cached now but at least stats are correct again.

Speed gain is insane though.

vs

cache.blog.tuinslak.org 85.12.6.171 - - [22/May/2010:16:27:40 +0200] “GET /2010/05/nginx-reverse-proxy/ HTTP/1.0” 200 22639 “-” “Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.53 Safari/533.4” 1771 23031

First one being my current home IP address, the second one being the nginx server IP address. The idea is to have the first line to show up in the logs.

On Gentoo (and I guess it’s fairly similar on other distributions);

*  www-apache/mod_rpaf
      Latest version available: 0.6
      Latest version installed: 0.6
      Size of files: 7 kB
      Homepage:      http://stderr.net/apache/rpaf/
      Description:   Reverse proxy add forward module
      License:       Apache-2.0

Emerge it, add “-D RPAF” to /etc/conf.d/apache2 and add the following the the correct vhost (e.g. /etc/apache2/vhosts.d/your_vhost.conf):

<IfModule mod_rpaf.c>
      RPAFenable On
      RPAFsethostname On
      RPAFproxy_ips 85.12.6.171
</IfModule>

Change the bold IP address to your nginx rproxy IP address

Might be safe to run “apache2ctl configtest” to make sure you don’t have any errors in your config file(s).

And restart Apache. This makes it show the correct IP address in its log files.

Next on my to do list, getting it to actually cache something.

I’m deliberately making a difference between cache.* and live.* as blog.tuinslak.* might move to the cached version lateron.

The question, is it useful to reverse proxy this blog? No, probably not. But meh… It’s fun. :)

IP differences between both versions: live vs cache°. I’m guessing as most of the stats (Google Analytics and WP Stats) are JavaScript based, all stats should still be correctly generated. Only the Apache logs show the nginx proxy IP address. Which is normal, I guess.

First small test doesn’t seem too good. Apparently not a lot of caching is going on. Though most of this site’s content is HTML (using WPSuperCache).

• Live, on One, using Apache: here & here
• Proxy, on VM1, using nginx: here & here

More tests & fine tuning later!

(°): Due to a minor edit, the live and cached version both show the correct IP address (yours) instead of the nginx proxy IP address.

As there’s a PHP page as well, I had to set up fastcgi with PHP. I mainly followed this tutorial to try to get PHP working.

However, every PHP page I visited returned following error:

No input file specified.

As I was fairly sure it was path (or variable) related, I played around with:

fastcgi_param   SCRIPT_FILENAME  $document_root$fastcgi_script_name;

Changing $document_root to the full path, etc, without success.

However, as I used the init script in the tutorial, and read a few posts about possible permission errors, I tried adding the group to the fastcgi daemon starter as well.

Change this:

start-stop-daemon --quiet --start --background --chuid "$USER" --exec /usr/bin/env -- $PHP_CGI_ARGS

to:

start-stop-daemon --quiet --start --background --chuid "$USER" -g www-data --exec /usr/bin/env -- $PHP_CGI_ARGS

Notice the “-g www-data” part.

You can always make a variable in case you ever want to edit it.

Restart php_fastcgi and try again. Should work fine now.

Some fast stats: vm1 + nginx, vm1 + lighttpd, vm0 + IIS7, one + Apache, vm1 + nginx + PHP and one + Apache + PHP.

These stats should only give a quick overview. To get correct results it should be ran on the same hardware, at the same moment with the same load, and 100% the same pages.

“One” is a Gentoo dual Pentium III with 1.2Gb ram, “vm0” is a Windows 2008 Xen Virtual machine with 1 Gb ram, and has access to two vCPUs (Xeon), “vm1” is a Debian with 128Mb ram, and also access to two vCPUs (Xeon). Nginx wins on static content (followed by Lighttpd). Apache wins by a little over nginx on PHP content in these tests.

Here’s another site with some stats.