Eigentlich ist es keine Kunst, aber wenn man das erste Mal damit zu tun hat, wird man doch ziemlich erschlagen. Deshalb gibt es hier kleine Übersicht der Möglichkeiten und eine nähere Erläuterung meiner Lösung, die von hier abgeleitet wurde.
Alles gilt für Debian Lenny.

Grundsätzlich gibt es folgende Möglichkeiten:

1. SSH-Server in einer chroot-Umgebung auf einem eigenen Port lauschen lassen.
2. Einen evtl. existierenden SSH-Server zu verwenden und nur bestimmte User per Konfigurationsdatei in eine chroot-Umgebung einzusperren.

Für 1. muss man eine relativ große chroot-Umgebung schaffen. D.h. man muss viele Konfigurationsdateien wie /etc/hostname, /etc/passwd, /etc/group etc. und natürlich auch sshd inklusive aller nötigen Bibliotheken in diese Umgebung kopieren. Außerdem muss man ein init-Skript anlegen, das den SSH-Server automatisch startet und /proc und einige /dev-Devices in die Umgebung mounten (u.a. devpts und ptmx).

Bei 2. ist es einfacher. Seit Version 4.9 kann SSH unter Linux auch von sich aus (ausgewählte) Benutzer in eine chroot-Umgebung einsperren. Man kann sie sogar so zu “nur SFTP”-Benutzern degradieren. Dafür sind folgende Änderungen an der /etc/ssh/sshd_config nötig:

Subsystem sftp internal-sftp

Wenn man das normale SFTP-Subsystem benutzt kommt es zu Fehlern.

Nun konfiguriert man für spezielle Benutzer ein paar SSH-Optionen um:

Match group sshchroot
         ChrootDirectory /home/%u
         X11Forwarding no
         AllowTcpForwarding no
         ForceCommand internal-sftp

Die Option ForceCommand muss man auskommentieren, wenn die Benutzer auch Shell-Zugriff per SSH haben sollen.
Das %u steht für den Usernamen. Das heißt, wenn ein Benutzer sich einloggt, ist er direkt in das Verzeichnis /home/<username> eingesperrt.

Anschließend fügt man die Benutzer zu der Gruppe sshchroot hinzu:

# adduser user sshchroot
# usermod -d / user
# chown root:root /home/user

Es ist wichtig, dass das Wurzelverzeichnis der chroot-Umgebung dem Benutzer root gehört! Untergeordnete Verzeichnisse dürfen dann dem jeweiligen Benutzer gehören, in die er dann auch schreiben kann.

Wenn der Benutzer nun auch SSH-Zugang haben soll, muss eine passende chroot-Umgebung mit /bin/bash, /bin/ls etc. erstellt werden. Dies ist relativ einfach, aber je nach Umfang der chroot-Umgebung langwierig zu erstellen. Ganz am Anfang sollte man ein Homeverzeichnis unter /home/user/home/user für den Benutzer erstellen und es ihm als sein Heimatverzeichnis zuweisen:

# usermod -d /home/user user

Am Beispiel von /bin/bash, welches dabei sein muss, erläutere ich das Vorgehen für das Hinzufügen von Programmen in die chroot-Umgebung. Natürlich sind Pfadangaben an den entsprechenden Stellen zu ersetzen.

• /bin/bash nach /home/user/bin/ kopieren
• ldd /bin/bash ausführen und die entsprechenden Bibliotheken nach /home/user/lib/ kopieren. Wichtig ist, dass /lib64/-Bibliotheken dann nach /home/user/lib64/ kopiert werden.
• Konfigurationsdateien anlegen bzw. kopieren. Im Falle von /bin/bash ist das z.B. die Datei .bashrc im /home-Verzeichnis des Benutzers.

Anschließend kann die Umgebung getestet werden:

# chroot /home/user

Wenn nun ein Fehler erscheint sollte man seine Schritte nochmals überprüfen. Per exit verlässt man die chroot-Umgebung wieder.

Als letztes folgt der Test per SSH, wenn dieser erfolgreich verläuft hat man es geschafft und einen Benutzer erfolgreich eingesperrt.

Nach 2 Jahren habe ich nun meine Webseite komplett neu aufgesetzt. Der Blog ist nun als Hauptseite eingerichtet und beinhaltet die alten Blogeinträge und Downloads. Die alten Links werde ich nicht weiterleiten, das lohnt sich nicht.

Neu ist das WebDAV, wo man dies und das von mir findet. Meistens liegen dort kleine Skripte oder auch ab und zu mal irgendwelche Bilder oder temporäre Dateien.

Eigentlich bin ich ja nicht so der Web 2.0-Typ. Twitter interessiert eigentlich mich auch nicht. Dennoch interessiere ich mich seit einiger Zeit für Twitter. Aber nicht für den Inhalt, sondern für dessen API.

Es fing mit Langeweile an. Seit vielen, vielen Wochen sitze ich herum und habe nichts zu tun. Abitur geschafft, aber eeewig Zeit bis es irgendwie weitergeht (morgen gibt’s das Zeugnis). Deshalb lag es nahe sich weiterzubilden und so habe ich angefangen mich mit Python zu beschäftigen. Angeblich soll Python sehr einfach und gut durchdacht sein und vor einigen Monaten wagte ich ja schon erste Gehversuche, gab es aber relativ schnell auf, da die Schule rief.

Ein Projekt war schnell gefunden: Ein IRC-Bot, der Twitterstati von Personen in IRC schreibt und auch für Leute schreiben kann. Passenderweise gibt es auch direkt 2 Bibliotheken: python-irclib und python-twitter. Dadurch entfiel ein Großteil der Arbeit, die auch fundiertere Kenntnisse Pythons verlangt hätte. Netzwerk ist meiner Meinung nach nichts für jemanden, der gerade mit einer Sprache anfängt.

Aber auch so stellte es eine Herausforderung dar. Mehrere Klassen, Multithreading und als besonderes Schmankerl: die Syntax. Man darf sie nicht unterschätzen, habe ich festgestellt. Ein Leerzeichen zu viel und schon startet das Programm nicht. Auch das Schreiben vom Methoden (nicht zu verwechseln mit Funktionen) mit dem obligatorischen Parameter self ist gewöhnungsbedürftig. Genauso wie der Zugriff auf Variablen in Klassen. Am fiesesten finde ich aber die runden Klammern. An falscher Stelle platziert hat man plötzlich ein Tuple.

Schwer war auch die Umgewöhnung von der Programmierweise in Java zu der in Python. Viele Sachen sind einfach anders gelöst. Teils eleganter, teils weniger elegant.

Die Python-Befehlsreferenz ist sehr gut. Auf der Python-Webseite finden sich alle eingebauten Funktionen sehr gut dokumentiert. Ich glaube aber, dass dies erst seit Python 3.0 so ist. Erinnert mich ein wenig an Java, obwohl die Javadocs noch ein Wenig besser sind.

Nach einiger Eingewöhnungszeit programmiert es sich ganz flüssig in Python. Hier und da vergesse ich noch ein self, aber insgesamt gefällt mir Python immer besser. Besonders wegen der kleinen funktionalen Anteile à la foo = [bar.lower() for bar in foo].

Den Bot werde ich hier bald veröffentlichen, dann kann ihn jeder testen.

Hast du keinen Spiegel zur Hand, aber dafür eine Webcam?

I got no mirror!

Seit Anfang an störte mich etwas am Firefox: seine Geschwindigkeit war im Vergleich zu Windows einfach schlecht. Was unter Windows flüssig lief, lief unter Linux ruckelnd und teilweise auch unbenutzbar langsam. Ich lebte 2 Jahre lang damit, hoffte auf eine Verbesserung in 2.0 und später dann in 3.0, aber sie blieb aus. Vor ein paar Tagen las ich durch Zufall dies: Native Firefox on Ubuntu is even slower than on Wine.

Die erste Lösung klang vielversprechend: “Compile Firefox with PGO by default”. Gesagt getan. Nach einigen Sekunden Suchen, fand ich die Anleitungen im Mozilla Developer Wiki.

Fix den Quellcode-Tarball für Firefox heruntergeladen und entpackt. Laut des Wikis musste ich nun eine Datei mit dem Namen .mozconfig anlegen, um dort dann die Konfiguration für den Buildprozess festzulegen. Die Datei gehört in das root-Verzeichnis des Quellcodes. Mit einigen herausgesuchten Funktionen aus schon erstellten Firefoxen (about:buildconfig) erstellte ich nun folgende .mozconfig:

. $topsrcdir/browser/config/mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/ff-opt
mk_add_options PROFILE_GEN_SCRIPT='$(PYTHON) $(MOZ_OBJDIR)/_profile/pgo/profileserver.py'
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --enable-optimize
ac_add_options --enable-update-packaging

Jetzt noch fix die Abhängigkeiten installiert und nun musste make ran:

make -f client.mk profiledbuild

profiledbuild am Ende ist wichtig, sonst wird Firefox ganz normal kompiliert!

Nachdem ich ein paar Abhängigkeiten korrigiert hatte, die ich wohl übersehen hatte, hatte ich viel Zeit für andere Sachen, bis der Prozess beendet war. PGO baut Firefox zweimal, daher dauert es entsprechend länger bis man fertig ist.

Als schließlich make die Fertigstellung meldete war ich ganz begierig den Firefox zu testen. Schnell einen Tarball erstellt

make -C ff-opt/browser/installer

und ihn von ./ff-opt/dist entpackt in ein eigenes Verzeichnis geschoben. Dann gestartet, und: Begeisterung pur! Er ist so schnell, das hätte ich mir nicht mal in meinen kühnsten Träumen vorstellen können. Die Geschwindigkeit ist bestimmt um den Faktor 3 höher als bei dem von Mozilla vorkompilierten Firefox.

Fazit:
Jeder Linux-Firefox-Benutzer sollte es mal mit einem selbst kompilierten Firefox versuchen, wenn nicht schon seine Distribution einen mit PGO kompilierten anbietet.

Anmerkung:
Sicherlich gibt es noch mehr Funktionen um auch das letzte Quant Geschwindigkeit herauszuholen, aber ich bin mit dem jetzigen Ergebnis so zufrieden, dass ich momentan nicht die Lust verspüre, nochmal 2 Stunden für 0,1% verbesserte Geschwindigkeit zu investieren.