kevin's blog

Mit dem folgenden Howto zeige ich euch, wie man auf einem Hosteurope VPS (Virtual Private Server), der unter der Virtualisierungssoftware Parallels läuft, ein aktuelles Debian Lenny installiert. Leider ist nur Debian 4.0 als neustes Debian-Image verfügbar, daher installieren wir Lenny mittels debootstrap über den Recovery-Modus.

Installation

Als aller erstes Installieren wir debootstrap unter dem bereits laufendem Etch-System:

apt-get update
apt-get install debootstrap

Wir werden das neue Lenny-System in einem Unterordner innerhalb des alten Systems installieren.

mkdir /.new

Das neue Lenny-System wird nun mittels debootstrap in den Ordner /.new installiert:

debootstrap --arch i386 lenny /.new http://ftp.de.debian.org/debian/

Konfiguration

Wir kopieren wir ein paar notwendige Konfigurationsdateien aus dem laufenden System in das neue:

cp /etc/fstab /.new/etc
cp /etc/network/interfaces* /.new/etc/network
cp /etc/hosts /.new/etc
cp /etc/hostname /.new/etc

Nun starten wir im Rescue-Modus, wo wir den Inhalt des alten Systems in /repair finden.
/.new ist also nun in /repair/.new.

Wir löschen als aller erstes das alte System:

// entfernt alle ordner außer ".new" von /repair
rm -rv /repair/*

Danach verschieben wir das neue System von /repair/.new nach /repair:

mv /repair/.new/* /repair
rm -r /repair/.new

Damit apt/dpkg (rm) korrekt für die SSH-Installation funktioniert, müßen wir noch das proc- und devpts-Dateisystem in das neue System mounten:

mount -t proc proc /repair/proc
mount -t devpts none /repair/dev/pts

chroot in das neue Lenny-System…

LANG=C chroot /repair /bin/bash

… und SSH installieren:

apt-get update
apt-get install ssh

Passwort setzen nicht vergessen:

passwd

… und wieder raus aus dem chroot:

exit

Das wars!
Nun in das Virtuozzo PowerPanel rein, den Repair-Modus beenden und danach sollte das neue Lenny-System erreichbar sein.

In /etc/network/interfaces bei dem entsprechenden device:

hwaddress ether 02:01:02:03:04:08

Danach ein:

/etc/init.d/networking restart

Rapidshare ist wohl einer, wenn nicht gar der größte One Click Hoster der Welt. Als normaler Benutzer kann man Dateien nur mit lästiger Warzezeit und eingeschränkten Downloadraten beziehen. Als Premium Benutzer gibt es diese Beschränkung nicht.

Ich möchte hier die Schwachstelle der Rapidshare Authentifizierung durch das user-Cookie aufzeigen. Das hier ist *keine* Anleitung zum sniffen von Rapidshare Zugangsdaten.

(weiterlesen…)

Da es mich immer wieder geärgert hat das die meisten Howtos zu dem Thema schäbige Tabellenlayouts nutzen und alles in eine Konfig stopften – hauptsache es geht – habe ich beschlossen ein eigenes Howto zu schreiben. In dem Howto nutzen wir als Datenbank zwar nach wie vor MySQL, jedoch mit InnoDB und Foreign-Keys. Die Konfigurationsdateien für SQL und Quota sind in extra Dateien ausgelagert und der Proftpd Benutzer hat nun einen gescheiten Namen.

Ich hoffe es gefällt euch und kommt mit diesem Howto schneller und einfacher zum Ziel :-).

Proftpd + MySQL + Quota unter Debian Lenny

Ich schreibe gerade an einem lighttpd perl script, das über STDIN access-log lines parst und in eine Remote MySQL Datenbank schreibt (DBI).

Mit lighttpd lassen sich die accesslogs per STDIN in einen von lighttpd gestarteten Prozess schreiben:

accesslog.filename = "|/var/www/test.pl"

Das Script test.pl erhält die Daten per und läuft anhand eines while loops:

while (<stdin>) { ... mysql insert ... }

lighttpd kurz neustarten – funktioniert.

Erklärung

lighttpd startet den Prozess test.pl, welcher die Log-Lines über die pipe auf STDOUT schreibt. Der test.pl-Prozess wartet anhand des while-loops auf hereinkommende Log-Lines (STDIN). Kommen Log-Lines auf STDIN an, fängt der while-loop an diese auf einen entfernen MySQL Log Server zu schreiben.

Die pipe in lighttpd nichts anderes als:

cat access.log | ./test.pl

Nur das cat access.log der lighttpd Prozess ist, der auf STDOUT schreibt.

Nun kommen wir zum eigentlichen Problem:

Problem

Die pipe hat einen begrenzen Buffer: 64K. Werden also die Log-Lines von test.pl nicht schnell genug abgearbeitet, darf der Prozess der auf STDOUT schreibt, warten.

Das beudetet bei lighttpd: Werden zu schnell zu viele Log-Lines generiert, kann test.pl diese nicht abarbeiten und die Website steht still.

Lösung

Buffering der Log-Lines. Mir wurden in #perl einige Lösungen angeboten:
- IO::All
- IO::Async
- Buffern über Dateien
- Buffern in Ram-Disk

Auslagern auf Dateien kommt nicht in Frage, da ich temporäre Logs bei 80% übrigen Ram (was 6GB ausmacht) nicht in eine Datei schreibe.
Buffern in Ram-Disk wäre zwar nice und einfach, jedoch wieder Änderungen am System, was ich wegen diesem kleinem Script nicht wollte.
Ebenso fallen die externen Module weg, da das Script später auf vielen Servern eingesetzt wird, möchte ich nicht jedesmal in CPAN rumfummeln.

Nun habe ich ein Programm gefunden, das genau diese Aufgabe erledigt: bfr

Wir installieren kurz bfr:

apt-get install bfr

Und konfigurieren lighttpd um:

accesslog.filename = "| bfr -b 2M -m 0 -p |/var/www/test.pl"

Die Buffergröße wird durch -b 50M festgelegt (default: 1M).
Durch “-p” erhalten wir eine Progress-Anzeige, die die aktuelle Nutzung des Buffers anzeigt (kann nach Erfassung der notwendigen Buffergröße entfernt werden).
Mit “-m 0″ sagen wir bfr, das sobald Daten vorhanden sind, diese weitergeleitet werden. 1M würde beispielsweise bedeutet: Sammele 1M und schiebe diese dann durch die pipe.

Nun wird alles in den von bfr erzeugten Buffer geschrieben und bfr schreibt sobald die pipe nicht blockiert ist per STDOUT an den Prozess.

Damit der Buffer Sinn macht, muss es natürlich eine Zeit geben, an dem das Script die Daten abarbeiten kann. Gibt es permanent zuviele Log-Lines und das Script kommt nicht nach, sollte man nach anderen Lösungen suchen.

Ich hoffe ich konnte helfen :-).

Endlich! Nach über 2 Jahren closed-Source Treibern für die Creative X-Fi Reihe gibt nun Creative die Sourcen für die Treiber heraus und lizensiert diese unter GPL v2, wie gulli berichtet.

Die offizielle Nachricht findet sich im Creative-Board.

Windows

Unter Windows gibt es das Freeware Server-Client Programm netcps (Download) das eine normale TCP/IP-Verbindung nutzt um ohne Festplattenzugriff Daten zu versenden und empfangen.

Server

Auf dem Server starten wir das Programm mit folgendem Parameter:

netcps.exe -server

Client

Auf dem Client starten wir das Programm ebenfalls, übergeben aber mit “-m500″ die Anzahl der zu übertragenen Daten in Megabyte an. Der zweite Parameter ist die IP des Servers, der auf dem Standardport 4455 lauscht:

netcps.exe -m500 192.168.0.40

In meinem 1Gbit-Netzwerk erziele ich dabei im Durchschnitt 90MB/s:

Linux

Für Linux gibt es das freie Programm iperf, das von der Anwendung her fast gleich ist.

Server

iperf -s

Client

iperf -c 192.168.0.4

Ergebnis zwischen meinem Router und meinem Fileserver:

Sollte folgende Fehlermeldung beim Versuch eine domU zu starten auftreten, sicherstellen ob brctl installiert ist und gegebenenfalls nach installieren!

Device 0 (vif) could not be connected. Backend device not found.

Falls brctl fehlt:

apt-get install bridge-utils