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.

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.

Seit gestern habe ich VirtualBox für mich entdeckt. Virtualisierung ist kein neues Thema, aber erst seit kurzem ist es mit möglich diese auch zu betreiben. Diverse Linux-Distributionen und Windows XP laufen wunderbar und dank Guest-AddOns sogar schon beinahe wie nativ.

Manchmal vermisse ich bewährte Windowsprogramme unter Linux. WINE bringt leider in einigen Fällen nicht den gewünschten Erfolg. Nun habe ich mich weiter umgesehen und bin in der c’t bei VirtualBox hängengeblieben. Mit gefällt das Programm auch. Einfache Installation und sehr einfache Bedienung. Als Testsystem musste Ubuntu 6.06 herhalten. Dies lief ohne Probleme sehr schnell. Trotz eingestellter 256MB RAM lief es flüssig und es gab nur bei großen Programmen wie OpenOffice Ruckler. So habe ich schon viele Systeme getestet und einige Linux-Distributionen ausprobiert (es ist trotzdem keine besser als Sidux ;D).

VirtualBox lohnt sich auf jeden Fall für Leute, die gerne an Betriebssystem herumspielen oder erst mal Programme ausprobieren wollen bevor sie sie aktiv auf dem Arbeitssystem installieren. Besonders durch das einfache Speichern des Zustandes sind VMs (virtuelle Maschinen) schnell gestartet und einsatzbereit. Und wenn etwas schief läuft kann man das OS zum letzten Sicherungspunkt zurückführen.

VirtualBox-Webseite
Innotek-Website (Hersteller)

Vor kurzem bin ich von Kubuntu auf Sidux umgestiegen. Sidux hat eine wesentlich bessere Einbindung von GTK-Programmen in die KDE- bzw. Qt-Oberfläche. Zudem ist Sidux wesentlich schneller als Kubuntu. Dies mag an der kleineren Installation liegen.
Einige Programme, die man von Kubuntu gewöhnt war muss man hier erstmal nachinstallieren. Dabei kann man sich der Debian-Repositories bedienen, die zusätzlich zu den Sidux-Quellen aktiviert sind, denn Sidux ist nichts anderes als die aktuelle Debian-Beta (Sid, deshalb Sidux). Dafür funktioniert aber alles super

Manche Linuxkenner sollten sich Sidux mal anschauen, für Anfänger ist es aber nichts, da man schon einiges auf der Konsole erledigen muss, besonders, wenn der XServer mal nicht möchte. Zudem fehlen einige Programme, wie z.B. ein einfacher Rechner (den ich nicht benötige, da ich einen wesentlich besseren Taschenrechner habe ). Im Vergleich zu Kubuntu kann man Sidux auch viel feiner konfigurieren (Gentoouser, jaja ihr könnt das noch besser ), außerdem sieht es insgesamt runder aus.