Daniels Blog

Link: http://browsershots.org/

Ich hatte vor geraumer Zeit schon einmal auf BrowserShots verwiesen und bin vor kurzem wieder darauf gestoßen.

Dabei fiel mir dann auf, dass die Screenshots der Webseiten dort von Freiwilligen erstellt werden: der Hauptserver nimmt die Anfragen entgegen und verteilt sie an die einzelnen Factories/Fabriken. Auch der Code der Server und Factories scheint komplett offen zu liegen.

Also musste ich natürlich auch ein paar Fabriken auf meinem Server einrichten.

Full story »

To get a list of files in your current backup, sorted by (current) file size, you can use the following snippet, which will create a file backup-size.list with the result.

Code:

I've used this to find the biggest files in the current backup which are not required to get backed up and excluded them via the exclude list feature of ftplicity/duply/duplicity (ftplicity or duply are frontends for duplicity).

Quite a while ago I've installed etckeeper and changed the configuration to use Bazaar as its backend for myself (and sponsored/helped with a patch to change the default in Ubuntu).

However, already the first comment asked me why I would be using you Bazaar, if Git was that much faster (and required less space).

At that time I've thought, that Bazaar would catch up, and they (luckily) have done so in some areas, but Git is still a lot faster.

Therefore I've decided to change the repository from bzr to git. I've done so on my home machine and will do so on my dedicated server boxes in the next days, so it's a not only a recommendation but also documentation.

Howto convert a bzr repository to git (etckeeper)

Open a root shell, then you should export $GIT_DIR first:

export GIT_DIR=/etc/.git

The following will then convert /etc from a bzr to a git repository:

bzr fast-export --export-marks=$GIT_DIR/bzr.mark /etc | git fast-import --export-marks=$GIT_DIR/git.mark

After this (which will take a while depending on your history) you want to adjust the VCS setting in etckeeper.conf  (uncomment VCS=git and comment VCS=bzr):

sed -i -r -e s/'#\s*(VCS="git)"'/'\1'/ -e s/'VCS="bzr"'/'# \0'/ /etc/etckeeper/etckeeper.conf

I don't remember correctly, but the Git repository was not really setup correctly in the end - but the following fixed it:

etckeeper init

Benchmarks

I've done some benchmarking, comparing "$DVCS status" against each other. This will look if there are any files modified in the current tree, and it's what etckeeper does before and after upgrading (IIRC).
The following shows the commands with cold and warm caches (I've cleared the disk caches when changing to a new set).

What you can see is not only that "git status" is twice as fast with a cold cache (and even more with a warm one), but also that bzr takes even more time to print a single line of "It sure does!".

$ sudo time git st
0.01user 0.04system 0:05.61elapsed 1%CPU (0avgtext+0avgdata 0maxresident)k
29232inputs+688outputs (113major+1605minor)pagefaults 0swaps                                        
$ sudo time git st                                                                                   
0.02user 0.02system 0:00.06elapsed 59%CPU (0avgtext+0avgdata 0maxresident)k
16inputs+688outputs (0major+1716minor)pagefaults 0swaps

$ sudo time bzr st
0.14user 0.06system 0:11.74elapsed 1%CPU (0avgtext+0avgdata 0maxresident)k
17840inputs+8outputs (36major+3750minor)pagefaults 0swaps
$ sudo time bzr st
0.16user 0.03system 0:00.32elapsed 62%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+3787minor)pagefaults 0swaps

$ sudo time bzr rocks
It sure does!
0.20user 0.05system 0:08.19elapsed 3%CPU (0avgtext+0avgdata 0maxresident)k
17392inputs+8outputs (34major+3422minor)pagefaults 0swaps
$ sudo time bzr rocks
It sure does!
0.16user 0.01system 0:00.20elapsed 92%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+3458minor)pagefaults 0swaps

I'll update this post when scripting for the update of my various OpenVZ containers, but the basic information should stand.

From now on, I will save 5+ seconds on any "aptitude safe-upgrade". Hopefully this multiplies somehow, so the time investment into this post pays back..

Nach etwas mehr als einem Jahr gab es nun wieder ein Server-Upgrade, auf den Root Server EQ 4 von Hetzner (Intel® Core™ i7-920 Quad-Core, 8GB RAM).

Da der alte Server in den letzten Tagen vermehrt ausfielschwächelte, und das Angebot sehr günstig ist, habe ich direkt zugeschlagen.

Der Umzug auf komplett neue Hardware und IPs verlief recht einfach mittels:

• Beide Server in den Rescue-Modus booten
• Festplatte mittels dd bzw. deltacp.pl übertragen
• DNS aktualisieren
• Auf dem neuen Server dann:
  
  • Datenpartition erweitern; alte löschen und neu erstellen (fdisk)
  • LVM erweitern; lvextend -l100%FREE
  • RAID fixen (Partitionen haben (wahrscheinlich durch das neue Anlegen) eine neue UUID bekomment
  • Neues Root-Filesystem mounten
  • IP-Konfiguration anpassen (iptables, /etc/networking/interfaces, OpenVZ conf, .htaccess Dateien, ...)
  • Reboot (und evtl. wieder ab in's Rescue-System )

Das ganze lief dann nicht ganz so glatt, da der Rescue-Modus zwischendurch versagte (als ich das Netzwerk wohl noch nicht richtig konfiguriert hatte), aber insgesamt weitaus einfacher, als alles neu aufzusetzen..

When hacking on b2evolution using vim, I often forget to ":set noet" (to not expand tabs) and it's really annoying to change this global setting everytime I open a b2evo related file.

According to the mantra, to search for a shortcut when a task becomes repetitive, I've finally searched for it and found a plugin, which looks for _vimrc_local.vim files (in the parent directories (and $HOME)).

Now, I can have a single _vimrc_local.vim file in the directory where all my b2evo related directories/branches reside - and override my global settings therein; It gets sourced/executed whenever I'm opening a file "below".

For more information see the Question on Stack Overflow and the actual plugin by Luc Hermitte. Thanks!

Update: as noted on Reddit, you could also use the following code in a vimrc file (e.g. ~/.vimrc):

:au! BufRead,BufNewFile /path/to/project/* setlocal noet


I still like the approach of having local override files in the directory structure though, which might come in handy for projects: if somebody has installed the plugin already there's no need to edit any .vimrc file (if the project ships the _vimrc_local.vim file in the project's root directory).

To get clean URLs (e.g. for permalinks) in Lighttpd, you have to use the magnet module (lighttpd-mod-magnet in Ubuntu/Debian), and a Lua script.

I've created a file /etc/lighttpd/rewrite-to-docroot.lua:

if (not lighty.stat(lighty.env["physical.path"])) then
    lighty.env["physical.path"] = lighty.env["physical.doc-root"] .. "index.php"
end

And enabled it using:

magnet.attract-physical-path-to = ("/etc/lighttpd/rewrite-to-docroot.lua")

This simulates the following mod_rewrite snippet known from Apache:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

Previously I was using a tricky method, which would use the 404 handler ("server.error-handler-404 = /index.php"), but this caused missing GET params (as documented in the Lighttpd FAQ).
As a result, paged browsing of categories and tags wasn't possible.

Seit nun schon fast einer Woche ist der neue Server, auf dem auch hahler.de läuft, online. Nicht ganz ohne Probleme (z.B. Proxy-Probleme über HTTPS), aber nun läuft es sehr rund, mit nur noch kleinen Änderungen hier und da.
Der alte Server wurde zum 01.05. gekündigt, während der neue - aufgrund von offenbar großer Nachfrage, bis Mitte April auf sich warten liess.

Es handelt sich dabei um den "DS 5000" von Hetzner (AMD Athlon 64 X2 5600+ Dual Core, 4GB RAM, 2 x 400 GB SATA II).

Ich setze dort OpenVZ zur Virtualisierung ein. Dies erlaubt es sehr schön und einfach virtuelle Maschinen/Umgebungen zu erstellen, so dass z.B. der Mailserver in einem eigenen Container/"Rechner" läuft. Das erhöht die Sicherheit (Angriffe, Ausfall) erheblich und erlaubt es, Dienste voneinander abzugrenzen.

Da die Zeit zum Ende des Monats (und besonders am letzten Tag) sehr knapp wurde, habe ich aber einen Großteil des alten Servers einfach als ganzes in einen solchen Container gesteckt. Diesen werde ich im Laufe der nächsten Wochen dann "zerstückeln" - soweit es sich anbietet und erforderlich ist.

Wer Interesse an System- und Statusinformationen hat, kann sich die von Munin erstellten Graphiken anschauen (mittlerweile durch Passwort geschützt). Hier kann man ganz gut die einzelnen Container anschauen/erkennen.

Das nur soweit zur Information und nun viel Spass mit einem viel leistungsfähigerem Server..