Neben der Verfügbarkeit und der verfügbaren Hardwareressourcen spielt bei der Wahl des richtigen Server-Pakets bei einem Hoster natürlich auch die Netzanbindung eine bedeutende Rolle. Nur mit einer schnellen und zuverlässigen Anbindung lassen sich Fluten von Anfragen bewältigen. Da bei Hostern hier und da gerne getrickst oder nicht die erwartete Leistung bereitgestellt wird, ist ein kurzer Test der Netzwerk-Bandbreite zu empfehlen.
Für Desktop-Computer und Smartphones wird gerne das speedtest.net Netzwerk zusammen mit der gleichnamigen Website genutzt. Eine Flash-freie Alternative dazu wäre speedof.me, das auf HTML5 basiert. Da fähige Admins einen Linux Server natürlich niemals mit GUI administrieren würden ;) , sind die beiden Browser-basierten Speedtests jedoch uninteressant. Für speedtest.net gibt es zwar eine Python-Anwendung für das CLI – allerdings misst diese die Bandbreite für Up- und Downlink völlig unzuverlässig.
Vor ein paar Tagen habe ich mir einen Yubikey Neo zugelegt. Dabei handelt sich um eine Kombination aus One-Time-Passwort-Generator (OTP-Generator) und PGP-Smartcard. Außerdem können auch statische Passwörter hinterlegt werden. Der Yubikey unterstützt eine Fülle an Authentifizierungsmechanismen, egal ob online, über fremde oder eigene Server, oder offline.
In diesem Beitrag soll es um den Login an einem Arch Linux Rechner gehen – abgesichert mit dem Yubikey, oder Passwort + Yubikey (Two-Factor-Auth). Für eine PAM-basierende Authentifizierung, wie wir sie unter Linux und Mac OS haben, stellt Yubico ein Open Source PAM Modul zur Verwendung mit dem Yubikey bereit. Das Modul kann in zwei verschiedenen Betriebsmodi genutzt werden: Entweder in Kombination mit dem Yubico-OTPs über Yubico-eigene Server oder über ein HMAC-SHA1-basiertes Challenge-Response Verfahren, das auch offline (und damit unabhängig von Servern) funktioniert. Ich ziehe die offline-Methode vor, denn der große Nachteil der online-Variante ist: Wenn die Server offline sind (oder mein Rechner) kann ich mich nicht mehr einloggen.
In einigen Fällen ist es sinnvoll, den Zugriff auf vestimmte Verzeichnisse einer Website nur für bestimmte Nutzer zu erlauben. Die einfachste Möglichkeit für einen Passwortschutz ist die sog. HTTP Base Auth. Dabei wird dem Benutzer beim besuch einer bestimmten URL vom Browser ein Eingabefenster für Benutzername und Passwort angezeigt. Stimmen die Daten überein bzw sind im System vorhanden, wird der Zugriff ermöglicht – ansonsten wird er abgewiesen.
Meine TVHeadend Instanz Zuhause sollte über das Internet erreichbar werden. Hinter dem DSL Router ist ein Webserver erreichbar, den ich dafür als Proxy zu meinem TVHeadend-Server nutzen will. Über den Webserver laufen allerdings noch ein paar andere Dienste, sodass ich TVH nicht das Rootverzeichnis überlassen will. Das THV Webinterface soll stattdessen über ein Unterverzeichnis „/tv/recorder“ erreichbar sein, also z.B. so: https://server.tld/tv/recorder.
TVHeadend läuft auf dem Server mit der IP 192.168.2.111 auf Port 9981. Die Konfiguration von Nginx kann z.B. so aussehen:
In der Nginx Konfiguration kann neben dem default Rootverzeichnis „root“ auch für jedes Unterverzeichnis ein root-Pfad gewählt werden. Das ermöglicht es z.B. für http://server.tld/ die Dateien unter /var/www zu lagern, während sich die Dateien für http://server.tld/webuser/ unter /home/webuser/ befinden. Realisieren lässt sich das über die „alias“ Direktive:
server {
server_name server.tld;
listen 80;
listen [::]:80;
root /var/www;
location /webuser {
alias /home/webuser;
}
}
Natürlich muss dabei sichergestellt werden, dass das Zielverzeichnis für den User, unter dem Nginx läuft, zugänglich ist.
Gestern habe ich die Arch Linux Installation auf meinem Asus UX31a Ultrabook erneuert. Eine Schwierigkeit bei dem Ultrabook ist dabei das UEFI System. Mein vorheriges Arch Linux Setup auf dem Gerät war ziemlich kompliziert (wie sich herausgestellt hat: unnötig kompliziert), aber inzwischen habe ich einfachere Wege gefunden, die ich mit diesem Beitrag mit euch teilen will. Das UEFI Setup ist gar nicht mehr so schwierig, wenn man die richtige herangehensweise gefunden hat. Statt 4 Partitionen werden nur noch 2 benötigt und das Setup ist wesentlich kompakter. Der Großteil des Betriebssytems (alles außer /boot) wird via LUKS verschlüsselt auf der SSD abgelegt.
Auf meinen Server setze ich mittlerweile nur noch den Nginx-Webserver ein. PHP gibt es dafür nicht als Modul (so wie bei Apache), sondern es läuft als Extra-Prozess mit Socket, über den Nginx mit dem PHP-Prozess kommuniziert. In den letzten Monaten hatte ich immer wieder Probleme mit PHP. Der PHP-FPM Prozess verabschiedete sich immer wieder spontan und ohne Fehler in den Logs. Nach viel Recherche bin ich schließlich auf den rettenden Tipp gekommen: Man solle doch mal APC für PHP deaktivieren.
Dazu wird in der Datei /etc/php5/fpm/conf.d/20-apcu.ini die Zeile „extension=apcu.so“ mit einem vorangestellten Semikolon „;“ einfach auskommentiert und der PHP-FPM Service neu gestartet.
Seit der Deaktivierung von APC habe ich keine PHP-Abstürze mehr und der Webserver tut seinen Job wieder zuverlässig.
Da in unserem Haus leider nicht jeder einen Linux-Rechner hat, sondern auch Windows 7 noch im Einsatz ist, beherrscht unser Storage-Server im Keller nicht nur den Dateizugriff via sftp, sondern auch Windows-Freigaben via Samba. Gestern musste ich feststellen, dass die Windows-Rechner auf einen bestimmten Ordner innerhalb einer Freigabe nicht zugreifen konnte, obwohl die Zugriffsrechte für den entsprechenden Benutzer einwandfrei waren. Der Zugriffsfehler kam daher, dass das Folgen von symbolischen Links in Samba per default nicht aktiviert ist.
