Anwenden kann man diese Konfiguration z.B. bei Shared-Webhosting, wo unabhängige User ihren eigenen Webspace verwalten. Anstelle des unsicheren FTP kann hier dann eine sichere SFTP-Kommunikation stattfinden. Auch CVS-Repositories können auf diese Weise abgesichert werden.

Ich gebe in diesem Artikel nachfolgend eine Kurzanleitung, die die grundsätzliche chroot-Konfiguration beschreibt. Ich verwende derzeit openSUSE 11.3, grundsätzlich ist die Distribution aber natürlich nicht entscheidend.

Als Beispiel-Basisordner für die chroot-Umgebung verwenden wir “/srv/sftp“. Jeder User soll darin seinen eigenen Unterordner erhalten.

1. Erstellen einer neuen Benutzergruppe “sftponly”:

   groupadd sftponly

    

2. Erstellen zweier Benutzerkonten “user1″ und “user2″:

   useradd -s /bin/false user1
   useradd -s /bin/false user2

    

3. Setzen der Passwörter für die neuen User:

   passwd user1
   passwd user2

    

4. Hinzufügen der User zur neuen Gruppe:

   usermod user1 -A sftponly
   usermod user2 -A sftponly

    

5. Erstellen des Ordners “/srv/sftp” und der exemplarischen Unterordner “/srv/sftp/user1″ und “/srv/sftp/user2″:

   mkdir /srv/sftp
   chown root:sftponly/srv/sftp
   chmod 750 /srv/sftp
   
   mkdir /srv/sftp/user1
   chown user1: /srv/sftp/user1
   chmod 700 /srv/sftp/user1
   
   mkdir /srv/sftp/user2
   chown user2: /srv/sftp/user2
   chmod 700 /srv/sftp/user2

    

6. Anpassen der Datei “/etc/ssh/sshd_config”:

   #Subsystem      sftp    /usr/lib64/ssh/sftp-server
   Subsystem       sftp    internal-sftp
   
   Match Group sftponly
       ForceCommand internal-sftp
       ChrootDirectory /srv/sftp
       X11Forwarding no
       AllowTcpForwarding no

    

7. Neustart des SSH-Servers:

   /etc/init.d/ssh restart

    

Verbinden sich die eingerichteten User nun via SFTP (z.B. “sftp”-Kommando bei Linux oder WinSCP bei Windows) mit dem Server, sollten sie automatisch im Ordner “/srv/sftp” landen. Im eigenen Unterordner des User ist dann die Schreibberechtigung für abzulegende Inhalte vorhanden.

Wichtig ist bei dieser Einrichtung vor allem die korrekte Vergabe der Verzeichnis-Berechtigungen:

• Der Eigentümer des chroot-Ordners MUSS “root” (UID 0) sein.
• Die Gruppe des chroot-Ordners MUSS die in der “sshd_config” angegebene Gruppe (hier “sftponly”) sein.
• Die Berechtigung des chroot-Ordners MUSS 750 (User: Vollzugriff, Gruppe, lesen+ausführen, Andere: kein Zugriff) sein.

Wird eine dieser Bedingungen nicht erfüllt, verweigert der SSH-Server den Zugriff mit einer entsprechenden Fehlermeldung im Syslog:

Feb 11 11:33:02 server sshd[10053]: fatal: bad ownership or
modes for chroot directory "/srv/sftp"

In einem meiner Systeme stecken 2 SATA2-Festplatten mit je 750 GB Speicherplatz. Das Betriebssystem ist SLES11 und hauptsächlich befinden sich dort Xen4-DomU’s. Die Gäste stellen Webserver, Mailserver und andere Systemdienste bereit. Bisher war es so, dass ich einen Teil der ersten Platte mit LVM genutzt habe. Die zweite Platte war für Backups und andere Dinge in Verwendung. Die Performance war in Ordnung, aber auch nicht überragend.

Um diese Situation zu verbessern, hab ich mich im Internet auf die Suche gemacht. Es galt, ohne neue Hardware auszukommen (bei Mietservern unverschämt teuer) und ohne den Server komplett umzukrempeln, wie es z.B. bei einem neu konfigurierten Software-RAID der Fall wäre. Ich bin fündig geworden! Die Lösung funktioniert in meiner Umgebung wunderbar, ist aber grundsätzlich auch problemlos woanders verwendbar:

Das Geheimnis liegt im LVM verborgen. Statt weiterhin nur ein einziges Physical Volume (PV) zu verwenden, in dem die Volume Group (VG) und ihre Logical Volumes (LV) liegen, habe ich einen Teil der zweiten Festplatte zur bereits bestehenden VG hinzugefügt. Das ist erst mal nichts Neues, sondern bei LVM üblich.

Neu für mich war allerdings beim Kommando “lvcreate“, das zum Anlegen neuer Logical Volumes verwendet wird, der Parameter “-i 2“. Dieser Parameter gibt an, auf wie viele Physical Volumes das zu erzeugende Logical Volume aufgeteilt werden soll. In diesem Fall auf 2 PV’s. Auf ganz bequeme Art schaffen wir somit ein Software-RAID-0 für dieses LV. Wichtig ist aber, dass alle PV’s einer VG unbedingt auf separaten Platten liegen müssen, da es sonst zu Performance-Einbußen kommt.

Die Festplatten-Geschwindigkeit meines Xen-Gastes, den ich zum Testen verwendet habe, ist massiv gestiegen.

Hier die Ausgaben von hdparm zu den Lesegeschwindigkeiten:

(“/dev/xvdb” liegt auf einem einzigen PV, “/dev/xvdc” liegt auf 2 PV’s)

3x hintereinander “hdparm -Tt /dev/xvdb” (ALT)

/dev/xvdb:
Timing cached reads:   18416 MB in  1.99 seconds = 9251.71 MB/sec
Timing buffered disk reads:  280 MB in  3.00 seconds =  93.29 MB/sec

/dev/xvdb:
Timing cached reads:   18144 MB in  1.99 seconds = 9114.75 MB/sec
Timing buffered disk reads:  274 MB in  3.00 seconds =  91.24 MB/sec

/dev/xvdb:
Timing cached reads:   17474 MB in  1.99 seconds = 8778.24 MB/sec
Timing buffered disk reads:  276 MB in  3.02 seconds =  91.45 MB/sec

3x hintereinander “hdparm -Tt /dev/xvdc” (NEU)

/dev/xvdc:
Timing cached reads:   17672 MB in  1.98 seconds = 8909.50 MB/sec
Timing buffered disk reads:  552 MB in  3.01 seconds = 183.52 MB/sec

/dev/xvdc:
Timing cached reads:   17226 MB in  1.99 seconds = 8651.80 MB/sec
Timing buffered disk reads:  560 MB in  3.01 seconds = 186.18 MB/sec

/dev/xvdc:
Timing cached reads:   18446 MB in  1.99 seconds = 9267.25 MB/sec
Timing buffered disk reads:  550 MB in  3.02 seconds = 182.30 MB/sec

Und hier noch das “dd”-Kommando bei der Erzeugung von ca. 4 GB großen Dateien:

ALT:

time dd if=/dev/zero of=test1.bin bs=4k count=1000000
1000000+0 records in
1000000+0 records out
4096000000 bytes (4.1 GB) copied, 51.6753 s, 79.3 MB/s

real    0m51.682s
user    0m0.556s
sys     0m10.405s

NEU:

time dd if=/dev/zero of=test1.bin bs=4k count=1000000
1000000+0 records in
1000000+0 records out
4096000000 bytes (4.1 GB) copied, 26.8236 s, 153 MB/s

real    0m26.813s
user    0m0.512s
sys     0m8.845s

Na, wenn das nichts ist… ich find’s großartig! :-)

• Kernel 2.6.32
• Unterstützung für KMS (Kernel-based Mode-Einstellungen)
• Xen 4.0
• Unterstützung von KVM und Hyper-V
• Verbesserungen bei Audio- und Bluetooth-Unterstützung
• und einiges mehr

Die Vorgehensweise:

1. Installation

Ich nutze derzeit openSUSE 11.2 (i586). Leider existiert derzeit noch kein offizielles RPM für AVLD, daher muss es von Hand kompiliert werden. Zur Vorbereitung wurden die RPMs “gcc”, “make”, “patch” und “kernel-source” installiert. Außerdem wurde natürlich die aktuellste Version von AVLD (momentan 0.1.4) heruntergeladen und entpackt.

Das Kommando “make” im entpackten Ordner lieferte direkt einen ernüchternden Fehler… “error: ‘v4l_compat_ioctl32’ undeclared here”. Sollte das schon das Ende sein? Nein, glücklicherweise fand sich in den Weiten des Internets einen Patch für AVLD, der für den Kernel 2.6.31 passt. Der Patch wird in das avld-Verzeichnis kopiert. Daraufhin wird das Kommando “patch -Np1 -i avld_0.1.4-2.6.31.patch_.txt” ausgeführt, wodurch die Datei “video_device.c” angepasst wird. Nun steht dem Befehl “make” und dem danach als root ausgeführten Kommando “make install” nichts mehr im Wege. Damit ist das Kernel-Module “avld.ko” nun nutzbar.

2. Laden und Verwenden des Moduls

Das Modul kann – wie bei Linux üblich – mittels “modprobe avld” geladen werden. An dieser Stelle ist es jedoch sehr wichtig, zu verstehen, dass das Device nur eine fest eingestellte Auflösung beherrscht, sich also nicht automatisch der Quelle (z.B. einem Video – siehe unten) anpasst. Werden dem Modul also keine Optionen mitgegeben, verwendet es standardmäßig eine Auflösung von 340×240 Pixel. Möchte man die Größe direkt beim Laden ändern, ruft man modprobe inkl. Parametern auf:

modprobe avld width=640 height=480 fps=25

Hat man das Modul hingegen bereits geladen, können die Parameter angepasst werden, indem man die Optionen per echo an das entsprechende Device schickt, also so:

echo "width=800 height=600 fps=25" > /dev/video0

(ggf. muss hier die Device-Nr. angepasst werden).

Die Fake-Webcam kann nun bereits verwendet werden. Ein Test kann mit MPlayer durchgeführt werden:

mplayer tv:// -tv "driver=v4l:device=/dev/video0:noaudio:outfmt=rgb24"

Sie sollte als ganz normal Gerät auftauchen und ein schwarzes Bild liefern. Möchte man stattdessen lieber bewegte Bilder präsentieren, kann man auf einfache Weise ein Video an das Gerät senden. Das erfolgt mit dem Programm “mencoder” aus dem MPlayer-Paket:

mencoder MOVIECLIP.XYZ -nosound -ovc raw -vf format=bgr24
-of rawvideo -o /dev/video0

Hat soweit alles geklappt, kann der Spaß beginnen… auch ohne echte Kamera. Mir fiele da z.B. der gute alte Casino-Räuber-Trick ein, bei dem man zunächst ein unscheinbares Video aufzeichnet, das dann statt des echten Webcam-Bildes wiedergegeben wird, um dem Betrachter das eigentliche Geschehen vor zu enthalten. :-)

Ein besonderes Feature ist “TestDrive”. Hier hat man die Möglichkeit, das vorbereitete System online, d.h. im Browser, ausgiebig zu testen, bevor der Download gestartet wird.

Fazit: Ein toller Service, den ich schon oft genutzt habe. Bei bestimmten Anforderungen ist es derzeit jedoch nötig, sich direkt mit KIWI zu beschäftigen und einen eigenen Server zum Erstellen von Images zu nutzen.

Die Lösung: Die zu verwendende Tastenkombination ist “Strg+Alt+Druck“. Nun klappt’s wieder einfandfrei.

Ausschlaggebend für das Problem scheint wohl das verwendete Client-Betriebssystem, denn baue ich die Verbindung über ein System mit openSUSE 11.1 auf, funtioniert alles wie erwartet. Die Behebung des beschriebenen Problems ist durch den Aufruf dieses Befehls innerhalb der NX-Sitzung möglich:

setxkbmap -model evdev -layout $LANGUAGE

also in meinem Fall

setxkbmap -model evdev -layout de

Wird dieser Befehl in die Datei “.bashrc” im Home-Verzeichnis des Users auf dem NX-Server eingetragen, wird er direkt beim Anmelden ausgeführt. Allerdings verursacht dies bei mir wieder Probleme, wenn ich mich nicht mit dem openSUSE 11.2 Client  zum Server verbinde. :-(

#!/bin/bash

###########

TARGET="/dir/to/search"
DATE_MARKER="/tmp/one_hour_ago_$$.txt"
SECONDS_AGO=3600

###########

let DELETE=`date "+%s"`-$SECONDS_AGO

test -f $DATE_MARKER && rm $DATE_MARKER
touch -d "@${DELETE}" $DATE_MARKER

find $TARGET -type f ! -newer ${DATE_MARKER} -exec rm -v {} ;

rm $DATE_MARKER

Bereits vor einigen Tagen tauchten die ISOs auf diversen Torrent-Seiten auf. Wer hier glaubte, der Zeit ein Schnippchen schlagen zu können, wurde arg enttäuscht, da die angebotenen Images eine falsche SHA1-Checksumme enthalten, was auf eine nicht authorisierte Manipulation an den Daten hinweist. Hier ist also höchste Vorischt geboten!

Mein Download läuft, ich bin sehr gespannt!

Die offizielle openSUSE-Homepage zeigt momentan noch das Release 11.0, die aktuelle Version ist z.B. über diesen Mirror erhältlich. Generell wird empfohlen, einen der Mirror-Server aus dieser Liste zu wählen.

Have a lot of fun!

Preface:

Ich betreibe u.a. einen DHCP-Server, einen Proxy-Server und einen Webserver.
Was liegt also näher, als diese drei Dienste miteinander zu koppeln, mit dem Ziel, die Information “Proxy-Server” automatisch zu verteilen, anstatt jedem Browser und jedem System im Netzwerk manuell einen Proxy-Server einzutragen. Außerdem betreibe ich auf verschiedenen Systemen “netz-interne” Webserver, die ich direkt aufrufen möchte, ohne den Proxy zu verwenden.

Hier also die Beschreibung des Zusammenspiels:

Ich arbeite hier mit Diensten unter Linux. Das Ergebnis (die automatische Verteilung der Proxy-Konfiguration) funktioniert für Linux und Windows. Möglicherweise bzw. bestimmt funktioniert das auch für den Mac, aber ich mache hier keine Aussagen zu etwas, das ich nicht selbst getestet habe.

Ziel:

• Verwendung eines Proxy-Servers für alle oder ausgewählte Systeme/Browser
• Subnetz-abhängige Verwendung des Proxy-Servers

Voraussetzungen:

• Linux-System (z.B. openSUSE)
• DHCP-Server (ISC)
• Proxy-Server (z.B. Squid)
• Webserver (z.B. Apache)

Wie diese Voraussetzungen geschaffen werden, ist nicht Teil dieser Anleitung. Ich gehe davon aus, dass diese Dienste eingerichtet sind und funktionieren. Mein Webserver heißt “wpad.mein.privates.netz.de” und der Proxy-Server läuft auf Port 3128 und trägt den Namen “proxy.mein.privates.netz.de”.

Erstellung der WPAD-Datei:

Diese Datei enthält einen “Fahrplan” für den Browser, damit er entscheiden kann, ob und wenn ja, welchen Proxy-Server er verwenden soll. Eine genaue Beschreibung des Aufbaus und der Funktionen einer WPAD-Datei findet sich hier.

Meine sieht folgendermaßen aus:

Das bedeutet: kein Proxy für den eigenen Rechner und kein Proxy für Webserver im eigenen Subnetz.

Diese Datei unter dem Namen “wpad.dat” (case-sensitive) auf dem Webserver abgelegt. Wichtig ist an dieser Stelle, dass die Datei direkt im Web-Root und nicht in einem Unterverzeichnis liegt

Konfiguration des DHCP-Servers:

Ich verteile den Proxy-Verweis für das gesamte Subnet, wer möchte, kann das natürlich auch anders (z.B. pro Host) machen.

Hier die Auszüge aus der /etc/dhcpd.conf:

Ganz besonders wichtig ist das Leerzeichen bei der Pfadangabe “…/wpad.dat ”.

Es existiert unter Umständen das Problem, dass der Internet Explorer beim Verarbeiten des Pfades das letzte Zeichen abschneidet und so die Datei nicht mehr gefunden werden kann. Das Leerzeichen am Ende stellt also einen Workaround dar.

Da nicht alle Browser die DHCP-Optionen abfragen können, ist es sinnvoll, im Nameserver einen Host namens “wpad” anzulegen, dessen Webserver die WPAD-Datei bereitstellt. Somit können “DHCP-unfähige” Browser dennoch eine Proxy-Konfiguration beziehen, denn der Hostname “wpad” wird dabei als Standard verwendet. Leider ist es mit dieser Variante nicht möglich, für Subnetze oder gar einzelne Hosts verschiedene WPAD-Dateien anzubieten. Der gemeinsame Nenner wäre hier das Domain-Suffix des Clients.

Ich habe mittels Wireshark zwei bei mir installierte Browser überprüft:
Der Internet Explorer 7 lässt sich Lease-Informationen vom DHCP-Server geben, um dort die entsprechende WPAD-Option zu erhalten, falls gesetzt. Der Firefox 2.0.0.8 sucht nach einem Gerät mit dem Namen “wpad” im Netz. Dabei werden die auf dem lokalen PC eingetragenen DNS-Suchsuffixe nacheinander abgearbeitet.

Browser-/Systemkonfiguration:

Nun muss dem Browser / dem System nur noch beigebracht werden, dass er die Proxy-Einstellungen automatisch beziehen soll. Im Internet-Explorer wird das über das Aktivieren der Option “Automatische Suche der Einstellungen” bei “Extras -> Internetoptionen… -> Verbindungen -> LAN-Einstellungen” erledigt. Beim aktuellen Firefox geschieht das über “Einstellungen -> Erweitert -> Netzwerk -> Einstellungen (Verbindung) -> Die Proxy-Einstellungen für dieses Netzwerk automatisch erkennen”.

Nachdem DHCP-Server und Browser neu gestartet wurden, kann man nun überprüfen, ob alles wie erwartet funktioniert. Der erste Schritt wäre, eine beliebige URL aufzurufen und im Webserver-Log zu überprüfen, ob die Datei “wpad.dat” erfolgreich vom surfenden Rechner abgerufen wurde. Ist das der Fall, kann man nun anhand des Proxy-Logfiles erkennen, ob der Proxy oder eine direkte Verbindung vom Browser genutzt wird. Dazu werden einfach interne und externe URLs aufgerufen.

Wichtiger Hinweis: Wenn die WPAD-Datei nicht abgerufen werden konnte, arbeiten Mozilla, Firefox und Internet-Explorer stillschweigend mit einer direkten Verbindung.

Nachwort:

Falls jemand diese Anleitung gebrauchen kann/konnte oder einen Fehler gefunden hat, würde ich mich über ein Feedback freuen.

UPDATE:

Bei Problemen mit WPAD und RSS-Feeds könnte eventuell diese Seite helfen.