byte-arts.NET

Heute ging Diablo 3 an den Start und eine halbe Stunde nach dem Go-Live wollte ich mich einloggen – man wartet ja erst mal den ersten Ansturm ab – und siehe da … Fehler 37.

Was fängt man nun mit dieser Information an? Kurz gegoogelt und siehe da Fehler 37 bedeutet, dass die Server zur Zeit ausgelastet sind und man doch bitte warten und es anschließend noch mal versuchen soll.

Der Fehler 37 wurde nämlich extra von den Diablo 3-Entwicklern eingebaut, damit die Server nicht überfüllt werden … es war ja auch nicht damit zu rechnen, dass sich Leute dieses Spiel vorbestellen (vor fast einem Jahr!) und dann, wo es nun endlich rauskommt, auch direkt spielen wollen.

Die Vernetzung der einzelnen Spieler über das Internet ist schön und gut, nur sollte es nicht zwingend notwendig sein. Denn was mache ich wenn die Server offline sind? Diese gerade gewartet werden? Ich meinen DSL-Anschluss wechsle? Jemand die Straße aufbohrt und das Kabel beschädigt? Meine Netzwerkkarte kaputt geht oder der Router?

Ohne Internet ist das Spielen nicht möglich. Schade. Nun muss ich warten bis … ja wie lange eigentlich?

UPDATE: Selbst fast 19 Stunden nach dem Launch wird mir immer noch der Fehler 37 angezeigt … Blizzard soll angeblich die Serverkapazitäten erweitern, nur merke ich davon herzlich wenig

UPDATE 2: Jetzt geht’s

UPDATE 3: Wir schreiben den 20.05.2012 16:45 Uhr … mittags das schöne Wetter genossen und jetzt eine Runde Diablo 3, nur hatte ich die Rechnung ohne den Wirt gemacht, Fehler 33 – die Blizzard-Server sind down für Wartungsarbeiten

Wie erstellt man ein SSH-Zertifikat um sich sicher mit einem Linux-Server zu verbinden? Das geht ganz einfach – mit Abstrichen. Folgendes als root über die Konsole/Putty auf dem Server ausführen:

ssh-keygen -t rsa -b 2048

Damit werden der private und öffentliche Schlüssel mit RSA und 2048 Bit erzeugt. Für weitere Einstellungsmöglichkeiten siehe Handbuch. Jetzt wird zuerst gefragt, wo man die Dateien speichen möchte. Wenn nichts angegeben wird, werden die Dateien unter /root/.ssh/ als id_rsa und id_rsa.pub gespeichert. Wenn für einen anderen Nutzer SSH-Schlüssel angelegt werden sollen, dann muss man mit diesem die Schritte ausführen. Dabei werden die Dateien in dem entsprechenden Home-Verzeichnis (/home/$username/.ssh/) angelegt. Danach wird nach einer Passphrase gefragt, welche die Sicherheit natürlich nochmals erhöht – kann aber auch einfach leer gelassen werden.

Als nächstes muss die Datei authorized_keys im selben Verzeichnis angelegt werden. Dieser muss über folgenden Befehl der öffentliche Schlüssel hinzugefügt werden:

cat id_rsa.pub >> /root/.ssh/authorized_keys

Damit sind die Arbeiten, soweit man nicht die Konfigurationsdatei unter /etc/ssh/sshd_config weiter anpassen möchte, auf dem Server abgeschlossen. Weiter gehts auf dem PC. Doch zuvor muss der private Schlüssel auf diesen, bspw. über WinSCP, runtergeladen werden. Der öffentliche bleibt auf dem Server.

Wer jetzt denkt, dass man den Schlüssel einfach in Putty angibt, wird mit der Meldung begrüßt, dass Putty damit nichts anfangen kann. Man muss zuerst den Schlüssel in ein Format konvertieren, was Putty versteht.

Dazu braucht man PuttyGen. Zuerst muss der Schlüssel in das Programm geladen werden, dazu wird, falls bei der Generierung eine angegeben wurde, nach der Passphrase gefragt. Danach speichert man den privaten Schlüssel ab und gibt diesen dann in Putty an. Und schon klappt die sichere Verbindung zum Server.

Optional kann in der Konfigurationsdatei die Anmeldung per Passwort verboten werden, oder dass ein anderer Port verwendet wird, was Angriffe verringert.

Heute mal wieder etwas technisches. Wer einen Server sein eigen nennt und diesen, sei es als physischen Server oder als virtuellen Client, mit Linux/Debian bestückt hat, kennt das eventuell auch den Maildienst Exim. Bei Debian 5 ist die Version 4 des Daemons dabei. Einzurichten ist er relativ einfach über die Konsole, jedoch kann es passieren, dass trotzdem keine Mails verschickt werden können. Ein Blick in das Log (/var/log/exim4/) zeigt dann auch warum, nämlich:

… jon.do@example.com: Unrouteable address

Die Einrichtung also erneut über folgenden Befehl starten:

dpkg-reconfigure exim4-config

Soweit so gut, doch was hat man falsch gemacht? Typischer Fall von RTFM, denn bei Schritt 4 heißt es, dass man eine kommaseparierte Liste von Domains eingeben soll, um die sich Exim selbst kümmern soll. Wer da nun eine Domain eingetragen hat, wie bspw. Google.com, hat was falsch gemacht, denn nur, wenn der Server die Verteilung und Annahme als richtiger Mailserver übernehmen soll, dann müssen hier die entsprechenden Domains eingetragen werden. Wer also einfach nur möchte, dass Mails nach außen verschickt werden können, bspw. über ein Kontaktformular, welches auf einem Webserver läuft, dann muss dieses Feld leer bleiben.

Wenn die Konfiguration abgeschlossen ist, muss der Dienst nur neu gestartet werden und sollte funktionieren.

/etc/init.d/exim4 restart

Quelle & mehr: exim4 unrouteable address error: A Lesson in RTFM

byte-arts.NET bietet schon seit über einem Jahr einen kostenlosen und frei zugänglichen TeamSpeak Server an. TeamSpeak Server sind speziell für die Kommunikation über das Internet beim Spielen ausgelegt, da die Bandbreite, sowie die Prozessorlast sehr gering sind und damit keinen unnötiger Traffic im Gegensatz zu bspw. Skype erzeugt wird. Mehr Informationen findet ihr auf der Webseite von TeamSpeak.

Zuerst in der Version 2, nun in der Version 3 (zur Zeit noch Beta) ist unser Server über die Adresse ts.byte-arts.net erreichbar. Einfach die Adresse (Port ist der Standardport) im TeamSpeak 3 Client angeben und los gehts. Unser Server bietet Platz für bis zu 32 Clients und besitzt im Moment 12 Channels, unter anderem für Left 4 Dead 2, Alien Swarm, Call of Duty: Modern Warfare 2 und Homeworld 2.

Wenn Ihr die Möglichkeit dazu habt, ist die Installation und Verwaltung eines TeamSpeak Servers nicht schwer. Für Hardcore-Gamer lohnt es sich auf jeden Fall.

In diesem Artikel wird beschrieben wie man ein SSL-Zertifikat erstellt und unter Apache 2.x auf Debian 5 installiert. Zuerst erzeugt man mit OpenSSL den Private-Key.

Falls OpenSSL noch nicht installiert ist, wird dies mit diesem Befehl nachgeholt:

apt-get install openssl

Erstellen eines SSL-Zertifikats

Einen 1024 Bit RSA Private-Key erzeugt man über:

openssl genrsa -out /pfad/zum/private-key/dateiname.key 1024

Natürlich kann auch ein anderer Verschlüsselungsalgorithmus, bspw. DSA, oder eine andere Verschlüsselungsstärke, bspw. 2048 Bit (zwingend erforderlich für Extended-Validation-Zertifikate), gewählt werden.

Nun wird das CSR (Certificate Signing Request) erzeugt. Dazu bitte folgende Zeile in die Konsole eingeben:

openssl req -new -key /pfad/zum/private-key/dateiname.key -out /pfad/zur/csr-datei/dateiname.csr

Nun werden ein paar Informationen abgefragt die man wahrheitsgemäß angegeben sollte.

Country Name (2 letter code) [AU]: (Zweistelliger Ländercode, bspw. DE für Deutschland)
State or Province Name (full name) [Some-State]: (Vollständiger Name des Bundeslandes/Staates, bspw. Schleswig-Holstein)
Locality Name (eg, city) []: (Vollständiger Name der Stadt, bspw. Berlin)
Organization Name (eg, company) [Internet Widgits Pty Ltd]: (Vollständiger Firmen-/Personenname)
Organizational Unit Name (eg, section) []: (Vollständiger Abteilungs-/Bereichsname)
Common Name (eg, YOUR name) []: (Vollständiger Domainname, bspw. www.example.com, subdomain.example.com)
Email Address []: (Gültige E-Mail-Adresse)
A challenge password []: (Optional: Passwort)
An optional company name []: (Optional: Zusätzlicher Firmen-/Personenname)

Auf die unter dem Common Name angegebene Domain wird das Zertifikat validiert und gilt ausschließlich nur für diese Adresse. Es kann jedoch auch ein sogenanntes Wildcard-Zertifikat ausgestellt werden, indem man anstatt der Subdomain (www ist auch nur eine Subdomain) einfach ein Sternchen (*) angibt. Bspw:

Common Name (eg, YOUR name) []: *.example.com

Dieses Zertifikat würde dann für alle Subdomains gelten. Wenn Sie bei A challenge password ein Passwort eintragen, kann der Apache nach der Einbindung des Zertifikats nur noch nach Eingabe des Passworts gestartet werden.

Das CSR überprüft man mit folgendem Befehl:

openssl req -noout -text -in /pfad/zur/csr-datei/dateiname.csr

Wenn das CSR die vollständig richtigen Angaben enthält, können Sie dieses nun an eine Zertifizierungsstelle weitergeben. Bei normalen Zertifikaten erfolgt dann eine E-Mail-Validierung. Das bedeutet, es wird eine E-Mail an die im CSR angegebene Adresse geschickt, welche einen Link zu Bestätigung enthält. Hat man das Zertifikat bestätigt, bekommt man selbiges von der Zertifizierungsstelle zugesand und kann es anschließend in den Apache integrieren. Kostenlose Zertifikate werden z. Bsp. von StartCom angeboten. Dafür ist eine Anmeldung und die Angabe der persönlichen Daten, wie Name und Anschrift notwendig.

Sollte man kein offizielle Zertifikat benötigen, bspw. für eine Entwicklungsumgebung, kann man es auch selbst signieren. Selbstsignierte Zertifikate erzeugen bei den meisten Browsern eine Warnung und der Besucher muss eine Ausnahme hinzufügen, um die Seite verschlüsselt ansehen zu können.

So signiert man ein 1 Jahr gültiges Zertifikat selbst:

openssl x509 -req -days 365 -in /pfad/zur/csr-datei/dateiname.csr -signkey /pfad/zum/private-key/dateiname.key -out /pfad/zum/zertifikat/dateiname.crt

Man kann natürlich den Zeitraum auch verkürzen oder verlängern.

Nun wird das CSR nicht mehr benötigt und kann gelöscht werden. Vom Private-Key sollte man nun ein Backup erstellen, damit bei Verlust oder Umzug ohne Probleme ein neues Zertifikat erstellt werden kann.

Einrichten eines SSL-Zertifikats

Es wird davon ausgegangen, dass eine Konfiguration für einen (virtuellen) Host bereits existiert und dieser nun zusätzlich noch über SSL erreichbar gemacht werden soll. Dazu muss lediglich die Konfigurationsdatei kopiert und folgende Änderungen umgesetzt werden:

NameVirtualHost *
<VirtualHost *:80> [wird zu] <VirtualHost *:443>
ServerName www.exampl.com [wird zu] ServerName www.exampl.com:443

Das Sternchen kann natürlich durch eine IP ersetzt werden. Optional können, für eine bessere Zugriffsübersicht, separate Log-Dateien angelegt werden.

Nun werden der Pfad zum Private-Key, zum Zertifikat, sowie die Aktivierung des SSL-Modus hinzugefügt.

SSLEngine on
SSLCertificateKeyFile /pfad/zum/private-key/dateiname.key
SSLCertificateFile /pfad/zum/zertifikat/dateiname.crt

Abschließend muss nur noch der Apache neu gestartet bzw. die Konfiguration neu geladen werden. Das geschieht über folgenden Befehl:

/etc/init.d/apache2 reload

Sollten die Einstellungen nicht übernommen worden sein wiederholen Sie den Befehl, ersetzen aber reload durch restart.

Als Hinweis ist noch zu sagen, dass pro Domain/Zertifikat eine IP erforderlich ist. Ein Wildcard-Zertifikat gilt nur für alle Subdomains einer Domain.

Eigene Fehlerseiten erhöhen die Benutzerfreundlichkeit einer Webseite enorm, da immer die Möglichkeit besteht, dass z. Bsp. eine Seite nicht angezeigt werden kann oder dem Besucher der Zugriff auf eine Seite nicht erlaubt ist. In diesem Artikel wird beschrieben, wie man die Standardfehlerseiten von Apache, ab Version 2.0 (für ältere Versionen siehe unten) unter Debian 5, durch eigene ersetzt.

Man benötigt dazu das Recht die Konfigurationsdatei des Apache, zu finden unter /etc/apache2/, bearbeiten zu können. Eine Konfiguration über eine .htacces-Datei ist leider nicht möglich, da diese nicht global, sondern nur ordnerspezifisch arbeitet. Fehlerseiten können für jeden (virtuellen) Host definiert werden. Dazu muss man folgende Zeilen in die Konfiguration des entsprechenden (virtuellen) Host eintragen:

ErrorDocument 401 ‘Zugriff verweigert!’
ErrorDocument 403 ‘<p style=”color: red;”>Aktion nicht erlaubt!</p>’
ErrorDocument 404 /pfad/zu/den/eigenen/fehlerseiten/fehler_500.html
ErrorDocument 500 http://interner_fehler.example.com/

Die Direktive ErrorDocument ### (Die Rauten stehen für einen HTTP-Statuscode) teilt dem Apache mit, dass wenn der Fehler mit diesem Statuscode eintritt, soll entweder eine einfache Textmeldung, ein mit CSS formatierter HTML-Text, eine eigene Fehlerseite oder eine beliebige URL angezeigt werden.

Abschließend muss nur noch der Apache neu gestartet bzw. die Konfiguration neu geladen werden. Das geschieht über folgenden Befehl auf der Konsole:

/etc/init.d/apache2 reload

Sollten die eigenen Fehlerseiten nicht angezeigt werden wiederholen Sie den Befehl, ersetzen aber reload durch restart.

Bei der Version 1.3 des Apache ist zu beachten, dass die beginnenden/beendenden Zeichen keine doppelten (“”) einfachen (”), sondern einfache (”) doppelte (“”) Anführungszeichen sein müssen. Ansonsten ist die Syntax identisch.

UPDATE (17.08.2010): Bei meinen Tests haben die absoluten Pfadangaben nicht funktioniert. Erst als ich einen Alias für den Ordner, in dem sich die Fehlerseiten befanden, angelegt hatte lies sich der Apache neu starten. Ebenfalls kam bei den Tests heraus, dass es anscheinend nicht möglich ist bei einem 401er-Fehler eine Weiterleitung zu einer vollständigen URL anzugeben. Bei den anderen ging dies jedoch problemlos.