Wer des Öfteren mit Linux innerhalb einer virtuellen Maschine (bspw. VirtualBox) arbeitet und dabei auf Programme setzt die Zufallswerte benötigen, ist wahrscheinlich schon einmal auf ein spezielles Problem gestoßen: Das Programm stellt die Arbeit ein, weil nicht genügend Zufallsdaten vorhanden sind und setzt sie erst wieder fort, wenn genügend Entropie gesammelt wurde.
Zum Sammeln von Entropie werden meistens Mausbewegungen oder Tastatureingaben herangezogen, weil diese nicht vorhersagbar sind. Weiterhin kann auch eine statistische Rauschquelle herangezogen werden.
Kurioserweise scheint dies in einer virtuellen Maschine nicht einwandfrei zu funktionieren. Das Problem kann auch bei einer Remote-Verbindung zu einem Rechner (per SSH) auftreten, weil Mausbewegungen natürlich nicht mit übertragen werden.
Unter Linux kann man dem Abhilfe schaffen, indem man ein kleines Programm mit dem Namen rngd einsetzt.
Ein Auszug aus der Manpage zu rngd:
This daemon feeds data from a random number generator to the kernel's random number entropy pool, after first checking the data to ensure that it is properly random. http://linux.die.net/man/8/rngd
rngd kann man unter Debian-basierenden Linux-Distributionen wie Ubuntu einfach über
sudo apt-get install rngd
installieren. Anschließend sagt man dem Tool noch, dass es seine Entropiedaten aus dem Linux-eigenen Zufallsgenerator beziehen soll:
rngd -r /dev/urandom
Danach kann man das Programm, welches viele Zufallsdaten benötigt einwandfrei und ohne entropiebedingte Unterbrechungen ausführen.
Konkret ist dieses Problem bei mir beim Erzeugen von OpenPGP-Schlüsseln aufgetreten. Mit rngd konnte ich das Problem jedoch beseitigen.
Im Netz haben sich zwei Lager etabliert, die seit längerem über einen speziellen Aspekt von URLs im Internet streiten. Die Initiative www. is not deprecated setzt sich für ein „www“ in der URL ein, wenn ein Webserver identifiziert werden soll, beispielsweise www.example.com. Die Anhänger von www. is deprecated votieren entsprechend dagegen, also nur example.com. Doch worum genau geht es in diesem Streit?
Ich habe mir einmal die Argumente beider Lager angesehen und versucht die echten objektiven Vorteile bzw. Nachteile eines „www“ in der URL herauszufinden.
Argumente für www
- Bessere Wiedererkennung
Im Allgemeinen ist eine Internetadresse (sei es in der Werbung, auf Visitenkarten oder anderen Webseiten) mit vorangestelltem www für Menschen leichter als solche zu erkennen.
- Automatiserte Verarbeitung
Eine Internetadresse mit www-Präfix lässt sich über automatiserte Systeme (z.B. reguläre Ausdrücke) besser erkennen und verarbeiten.
- Suchmaschine und Verlinkung
Der durchschnittliche Internetnutzer neigt durch jahrelange „Erziehung“ dazu, jede URL vorsichtshalber mit einem www zu versehen. Dies führt dazu, dass ein Webmaster, der der Argumentation von no-www.org folgt, von Suchmaschinen abgestraft wird, weil seine Seite von diesen Menschen immer mit vorangestelltem www verlinkt wird. Suchmaschinen unterscheiden jedoch sehr genau zwischen Adressen mit und ohne www.
Argumente gegen www
- Browser sind intelligent
Moderne Webbrowser finden in den meisten Fällen die korrekte URL, ob mit oder ohne www. Wenn ein Benutzer aus Bequemlichkeit nur example.com eingibt, wird der Browser zunächst versuchen den Server unter http://example.com zu erreichen, bevor er auf http://www.example.com ausweicht. http:// wird also immer ergänzt, wenn es nicht explizit angegeben wird. Warum also noch ein www anfügen, wenn es im Fall der Fälle sowieso ergänzt würde? Dies geht einher mit dem nächsten Punkt.
- Erleichterung für den Benutzer
Seitenbetreiber haben oft das Problem, dass Subdomains von Benutzern nicht erreicht werden (können), weil diese gewohnheitsmäßig immer ein www voranstellen (s.o.). Demnach würde ein Benutzer einer Subdomain sub.example.com ein www-Präfix geben, wodurch er versuchen würde auf die nicht existierende Subdomain www.sub.example.com zuzugreifen. Dem Nutzer sollte also klar gemacht werden, dass www nur eine überflüssige Subdomain ist. no-www hätte in diesem Fall also erzieherische Wirkung.
- www ist kein Protokoll wie HTTP oder FTP
Daher kann das www in der URL weggelassen werden, wenn damit ein Webserver identifiziert werden soll. Für andere Dienste, wie FTP, sind die Protokollangaben in der URL zuständig. http://example.com für einen Webserver und ftp://example.com für einen FTP-Server. Ebenso ist ftp://www.example.com denkbar, was unsinnig erscheint.
Nichts forcieren!
Nun ist es leider nicht so einfach der einen oder anderen Seite einen Vorzug zu geben und deren strikte Forderung durchzusetzen. Diese zielt darauf ab, nur eine URL mit www oder ohne zuzulassen und die andere unerreichbar zu machen (sog. Class C Compliance bei no-www).
Doch längst nicht jeder Internetnutzer ist technisch versiert und kann den Unterschied ausmachen. Im schlimmsten Fall würde er die Seite für nicht erreichbar halten, weil die Variante mit www nicht funktioniert.
Daher sollte man sich aus Kompatibilitätsgründen für eine Methode entscheiden und eine Umleitung für die andere einrichten (Class B Compliance).
# no-www für Apache-Webserver
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.(.+)$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]
Entsprechend kann man dies auch für yes-www erreichen:
# yes-www für Apache-Webserver
RewriteEngine On
RewriteCond %{HTTP_HOST} ^example.com$ [NC]
RewriteRule ^(.*)$ http://www.example.com/$1 [R=301,L]
So verhindert man nebenbei auch doppelte Inhalte (sog. Duplicate Content), die sonst entstehen könnten, weil Suchmaschinen www.example.com und example.com wie zwei verschiedene Adressen behandeln.
Abseites von beiden Lagern hat sich eine vermutlich Parodie auf diese Problematik etabliert. www.www.extra-www.org setzt sich für ein zusätzliches www in jeder URL ein. :-)
In diesem Blog habe ich mich für die no-www-Variante entschieden und lasse alle Anfragen nach www.blogeum.de auf blogeum.de umleiten.
Wie geht Ihr mit dieser Angelegenheit um? Seid Ihr Anhänger von no-www oder yes-www oder ist es Euch egal?
Im vorigen Eintrag habe ich von Windows Vista „geschwärmt“ und welche Vorteile es hat. Alles ganz gut und schön bis zu dem Zeitpunkt, an dem ich die Entwicklungsumgebung mit Apache, PHP und MySQL (WAMP) installieren wollte. MySQL weigerte sich partout mit PHP zusammen zu arbeiten, obwohl der MySQL-Server zweifelsfrei im Hintergrund lief und auch über die Kommandozeile ansprechbar war.
Im Netz der Netze gibt es zahlreiche Lösungsvorschläge: Von libmysql.dll nach SysWOW64 anstatt System32 zu kopieren bis zu der Benutzung von libmysql.dll aus dem PHP-Package anstatt der aus dem MySQL-Package. Doch keiner der Vorschläge konnte das Problem beseitigen.
Also entschloss ich mich kurzerhand mit VirtualBox einen virtuellen Server auf der Basis von Windows 2000 Professional (über MSDNAA) aufzuziehen. Windows 2000 deshalb, weil es den Komfort von Windows XP besitzt aber nur rund halb so ressourcenhungrig ist.
Die Installation funktionierte einwandfrei. Dennoch scheint es zur Zeit (und nicht nur bei mir) wieder einige Probleme mit der im MySQL-Package mitgelieferten libmysql.dll zu geben. Letztendlich half es, die libmysql.dll aus dem PHP-Package zu nehmen und die Sache lief.
Ein wenig rumprobieren musste ich allerdings bei den Netzwerkeinstellungen von VirtualBox. Mit „Bridged Netzwerk“ fand sich aber schließlich die richtige Einstellung. Der NETGEAR-Router erkennt nun den virtuellen Server quasi durch den realen NVIDIA-Netzwerkadapter und weist ihm über DHCP eine IP-Adresse zu. Somit ist er auch für Vista wie ein ganz normaler Computer im Netzwerk ansprechbar.
Ich muss sagen, dass mir diese Lösung ganz gut gefällt. Wenn der Server nämlich nicht gebraucht wird, belegt er keine Ressourcen und auch der Start von Vista ist dadurch noch schneller, weil er eben nicht mitgeladen werden muss. Desweiteren muss nicht bei jeder Neuinstallation von Windows auch der Server zwangsläufig neu installiert werden. Einfach die virtuelle Festplatte sichern und später wieder zurück kopieren.
Nachdem ich die Blog-Software einigermaßen fertiggestellt hatte, war ich der Meinung, es könnte nicht schaden, den Entwicklungsserver neu aufzusetzen. Ging auch eigentlich ziemlich problemlos, bis zu dem Punkt, an dem ich MySQL und cURL zum Laufen bringen wollte.
Nach ein wenig rumsuchen fand ich dann aber doch die Lösung. Deshalb soll dieser Eintrag auch als Gedächtnisstütze für mich fungieren.
- Apache Server runterfahren
libmysql.dll aus dem MySQL-Ordner nach %windir%/system32 kopieren- In diesem Zuge auch
libeay32.dll und ssleay32.dll aus dem PHP-Ordner dorthin kopieren - Apache Server wieder starten
Danach noch die Erweiterungen in der php.ini aktivieren und schon sollte alles wie gewohnt laufen.
11. Juli 2010, am späten Nachmittag · 
0 Kommentare · 
linux, openpgp, server, verschluesselung, zufall
