Tag: linuxiuvat

Posted on

Die eigene Homepage: CMS, Blogkompilierer und statisches XHTML

Ich stand vor der Entscheidung wie ich die Homepage für mein neues Spieleserverprojekt gestalten sollte. Ich schwankte anfangs zwischen einem dynamischen Portal für freie Spiele und selbst geschriebenen statischen HTML-Seiten. Ich habe mich schließlich gegen PHP und Datenbanken entschieden und auf statische Inhalte gesetzt, die zum einen durch Chronicle, einen Blogkompilierer, und zum anderen durch manuell erstelltes XHTML erzeugt werden. Die restlichen Statistiken und Graphen für die einzelnen Spiele werden täglich durch das Auswerten von Logdateien und mit Hilfe von Munin dargestellt.

Die Frage bei so einem Projekt ist: Wie viel Interaktion möchte man eigentlich haben?
Linuxiuvat.de ist keine Clan- oder Gildenseite, sondern lediglich das Erscheinungsbild des virtuellen Servers, auf dem einige freie Spiele laufen. Ich übernehme hier die klassischen Aufgaben als Serveradmin und Macher der Homepage, kann aber natürlich nicht alle Mitglieder eines Clans ersetzen.
Meiner Meinung nach sind Foren oder sogar ein Wiki nur dann sinnvoll, wenn man gleichzeitig eine Community rund um die Spiele aufbauen will, die das Projekt mit Leben füllt. In meinem Fall gibt es nur mich und die Idee irgendwann das Ganze abzuschließen und zum Fazit zu kommen, dass die Möglichkeiten des vServers ausgeschöpft sind. Danach möchte ich nur noch das Bestehende weiterpflegen, selbst eine Runde spielen und zum nächsten Projekt weiterziehen.
Vor diesem Hintergrund und der Tatsache, dass der Spieleserver auch ein praktisches Beispiel ist (es macht vor allem Spaß), wie man mit Freier Software, wenig Ressourcen und auch kostengünstig ein Projekt gestalten kann, wollte ich die Interaktion auf das Notwendige und Sinnvolle beschränken.

Hilfreiche Software

Es gibt sehr viele Möglichkeiten die eigene Homepage zu gestalten. Einige Ideen finden sich z.B. bei Debian und Ubuntu mit

aptitude search '~sweb'


In der Sektion "Web" stecken zahlreiche Content-Management-Systeme, Blogsoftware und Hilfsmittel statische Inhalte zu erschaffen. Eigenes Vorwissen, die verwendete Programmiersprache, Performance und verfügbare Angebote des Webhosters spielen natürlich eine Rolle. Bei einem eigenen VPS kann man aus dem Vollen schöpfen, da es keine technischen Beschränkungen gibt.

Bekannte Content-Management-Systeme

Es gibt hervorragende freie CMS darunter die großen Joomla, Drupal, Typo3, Movable Type und WordPress. Allen ist gemein, dass sie hochentwickelt, stark erweiterbar und vielfältig einsetzbar sind. Vom kleinen Linuxblog bis zur Unternehmenskette mit eigenem Franchise ist alles denkbar. Inhalte und Seitengestaltung sind unabhängig voneinander. Wissen über HTML oder Skriptsprachen ist nützlich jedoch nicht zwingend notwendig. Jeder kann Dank des umfangreichen Backends Inhalte einstellen und verwalten.

  • Anforderungen: PHP, MySQL/PostgreSQL
  • Vorteile: Dynamische Inhalte, Interaktion mit Benutzern ist einfach, unzählige vorgefertigte Plugins und Themen, große Gemeinschaft, gute Dokumentation, sehr flexibel
  • Nachteile: Speicherintensiv, Datenbank und PHP wird benötigt, potentielle Sicherheitslücken, komplexe Bedienung, Einarbeitungszeit notwendig

Eher unbekannte Content-Management-Systeme

Dann gibt es die eher unbekannten CMS, die meist weniger Feature als die großen haben, aber nicht weniger geeignet sind, um kleinere dynamische Projekte zu verwirklichen. Mir fielen insbesondere Zine, PyLucid und TDiary auf, da ich ein wenig mit Zine wegen der Programmierung in Python geliebäugelt habe. PyLucid ist ebenfalls in Python geschrieben und benutzt Django, während TDiary in Ruby verfasst wurde. Hier sind Japanisch- und Englischkenntnisse von Vorteil. Eine weitere interessante Alternative ist WebGUI in Kombination mit Perl und MySQL und DotClear. Leider forderten alle mindestens noch die Installation einer zusätzlichen Datenbank.

  • Anforderungen: Python, Ruby, Perl, MySQL/PostgreSQL
  • Vorteile: Dynamische Inhalte, einfache Interaktion mit Benutzern, einige zusätzliche Plugins und Themen, flexibel, interessante Programmiersprachen
  • Nachteile: Relativ speicherintensiv, Datenbank, Python oder Ruby notwendig, potentielle Sicherheitslücken, weniger umfangreich als die großen CMS

Die Welt der statischen Webseitengeneratoren

Ein Trend unter Techies sind sicherlich Webseitengeneratoren wie Jekyll für Ruby und Hyde für Python, die mit Hilfe von Templates aus Text, Markdown oder HTML die komplette Seitenstruktur einer Webseite unabhängig vom Inhalt erstellen können.
Etwas einfacher aufgebaut, aber nicht weniger effektiv, sind z.B PubTal (Python), WebGen (Ruby) und Blazeblogger.
Mein Favorit, für den ich mich schließlich entschieden habe, war Chronicle, den ich im nächsten Beitrag etwas ausführlicher vorstelle.

Was ist so toll an statischen Blogkompilierern und Webseitengeneratoren?

Ich habe mich für diesen Typ entschieden, weil ich sie für sicher, leichtgewichtig und effizient halte. Natürlich kann man auch Plugins für ein CMS benutzen, die den dynamischen Inhalt in statischen überführen (Stichwort: WP-Super-Cache). Ein Blogkompilierer wie Chronicle macht das von Haus aus. Statische Inhalte werden extrem effizient durch den Webserver ausgeliefert, so dass selbst bei einem mickrigen vServer die Performance selbst unter mittelgroßer Last nicht leiden wird.
Ein normales Projekt benötigt nicht einmal ansatzweise alle Funktionen eines CMS. Hier geht es auch darum realistisch zu bleiben. Weniger ist oft mehr. Außerdem sind diese Generatoren einfach zu bedienen und benötigen weder Datenbank noch eine Skriptsprache um zu funktionieren, was im Regelfall gleichbedeutend ist mit mehr Leistung und geringeren Kosten.
Einen Haken hat die Sache. Interaktion ist ohne zusätzliche Software nicht möglich, woraus ein neues Problem erwächst.

Disqus und Co. sind böse

Wirklich, ist das so? Fakt ist, wenn man auf ausschließlich statische Inhalte setzt, muss man dennoch irgendeine serverseitige Anwendung/Skript installieren, damit Kommentare von Besuchern irgendwie in die Webseite eingebunden werden können. Viele verfallen dann auf externe Dienstleister wie Disqus oder IntenseDebate.
Als Webseitenbetreiber muss man lediglich ein Stück Javascript-Code einbinden und schon werden Kommentare an die Server von Disqus und Co. weitergeleitet und dann auf der eigenen Webseite dargestellt. Disqus macht es wirklich einfach. Keine Spam-Probleme, keine Last auf dem Server, perfekte Integration mit Sozialen Netzwerken. Als Alternative könnten Besucher z.B. eine E-Mail schicken und man bindet dann den Inhalt manuell in die Seite ein, aber hey, wer macht das schon. 😉
Ich bin nicht wirklich der Typ, der hinter jedem erfolgreichen Internetunternehmen den nächsten faschistischen Weltbeherrscher vermutet. Man sollte sich aber schon die Frage stellen, ob man für jede Webseite die Kontrolle über seine Daten an eine externe Stelle abgegeben muss oder nicht. Diese Bedenken hat Jeremy Scheff auf den Punkt gebracht.
Ich persönlich denke, dass man Interaktion und Kontrolle über die Daten auch anders haben kann und das auch nutzen sollte. Im Falle von Chronicle war das z.B. das einfache Einbinden einer einzigen CGI-Datei. Andererseits vielleicht sollten wir einfach an einem wirklich quelloffenen und freien Disqus arbeiten!

Fazit

Die Wahl der Software hängt entscheidend von den eigenen Ansprüchen ab. Wem Geschwindigkeit und Sicherheit wichtig ist, sollte statische Inhalte veröffentlichen, die bevorzugt mit einem Blogkompilierer oder Webseitengenerator erzeugt werden oder auf die händische Methode zurückgreifen. Für mein kleines Projekt werde ich diesen Weg auf jeden Fall weitergehen.

Posted on

Logdateien von Lighttpd auswerten mit Awstats und Awffull

Neben dem ausgezeichneten Piwik existieren zur Darstellung von Benutzerstatistiken und Auswertung von Logdateien noch eine Reihe von sogenannten Log-Analysierern. Da ich die Installation von PHP und MySQL möglichst vermeiden wollte, habe ich mir zwei altbekannte Helfer aus diesem Bereich näher angeschaut. Hier stehen nur noch einmal die wichtigsten Einstellungen, die ich verändert habe und ein kurzes Fazit.

Awstats

Das war meine erste Wahl, da mich die vielfältigen Funktionen auf der Webseite des Projekts überzeugt hatten. Awstats ist hauptsächlich in Perl geschrieben und lässt sich mit Hilfe eines CGI-Skripts in Echtzeit aktualisieren. Diese Funktionalität benötigte ich aber gar nicht und habe deshalb alle Statistikseiten mit Hilfe des mitgelieferten Skripts buildstatic.sh statisch generieren lassen. Die Funktion lässt sich in /etc/default/awstats aktivieren.
Die Konfiguration findet bei Debian z.B. in /etc/awstats/awstats.linuxiuvat.de.conf statt. Man sollte die Standardkonfiguration von awstats.conf für sein eigenes Projekt dementsprechend umbenennen und nach /etc/awstats kopieren. Debian erstellt dann automatisch verschiedene Unterordner in /var/cache/awstats/ auf Basis des Dateinamens. Um die Statistiken später darstellen zu können, müssen diese Ordner für euer gewünschtes Webserver-Verzeichnis freigegeben werden.
Die Konfiguration von Awstats ist äußerst gut dokumentiert. Die meisten Standardeinstellungen konnte ich beibehalten. Lediglich diese hier habe ich geändert oder sind erwähnenswert.

# Pfad zur Logdatei
LogFile="/var/log/lighttpd/linuxiuvat.de/access.log"
# Webserver-Log deshalb Typ W
LogType=W
# Apache Logformat funktioniert auch mit Lighttpd
LogFormat=1
# Eure Domain und Aliase
SiteDomain="linuxiuvat.de"
HostAliases="linuxiuvat.de www.linuxiuvat.de localhost 127.0.0.1"
# Wir wollen die Namen der IP-Adressen nicht auflösen, weil es die Generierung der Statistiken verlangsamt
DNSLookup=0
# Reguläre Ausdrücke können unerwünschte Begriffe oder Benutzeragenten herausfiltern
SkipUserAgents="REGEX[Python-urllib]"
# Awstats lässt sich durch eine Vielzahl von Plugins erweitern. Mit GeoIP lässt sich die Herkunft der Besucher anzeigen
LoadPlugin="geoipfree"

Damit die IP-Adressen nach Ländern aufgelöst werden können, muss entweder die Bibliothek libgeo-ipfree-perl oder libgeo-ip-perl zusätzlich installiert werden.

Statische Seiten generieren und ein kleiner Hack

Debian stellt in /usr/share/awstats/tools/ mit buildstatic.sh ein Skript zur Verfügung, welches zum einen separate Awstats-Unterordner basierend auf den Konfigurationsdateien erstellt und zum anderen awstats_buildstaticpages.pl aufruft.
Die Statistiken werden in weiteren Ordnern nach Monaten sortiert. Damit jeder dieser Monats-Ordner noch eine index.html Datei erhält, muss dieser kleine Codeschnipsel am Ende der Datei hinzugefügt werden.

print "$cpt files built.n";
print "Main HTML page is 'awstats.$OutputSuffix.$StaticExt'.n";
my $command="/bin/cp $OutputDir" . "awstats.$OutputSuffix.$StaticExt $OutputDir" . "index.html";
$retour=`$command 2>&1`;
if ($QueryString =~ /(^|-|&)buildpdf/i) { print "PDF file is 'awstats.$OutputSuffix.pdf'.n"; }
0; # Do not remove this line

Den Tipp habe ich in diesem PDF-Dokument gefunden. Entscheidend ist die Zeile, die mit my $command beginnt und die normale Startseite in index.html umwandelt.
Zusätzlich sollte man noch einen Blick in /etc/cron.d/ werfen und überprüfen, wie oft Awstats und das zugehörige Update-Skript ausgeführt werden sollen. Mir genügte die tägliche Generierung der Statistiken.

Awffull

Awffull ist eine Abspaltung von Webalizer, die einige Verbesserungen mit sich bringt. Awffull ist noch einfacher einzurichten. Es genügt ein typisches
aptitude install awffull
und ein paar Veränderungen in /etc/awffull/awffull.conf.

# Pfad zur Logdatei
LogFile /var/log/lighttpd/linuxiuvat.de/access.log
# Auflösung der IP-Adressen nach Herkunftsland
GeoIP yes
# Pfad zur GeoIP-Datenbank
GeoIPDatabase /usr/share/GeoIP/GeoIP.dat
# 404 - Fehler anzeigen lassen.
Top404Errors 10

Die GeoIP-Datenbank für GeoIP ist frei und kostenlos und kann von maxmind.com heruntergeladen werden.
Sollten die Logdateien sehr groß sein, sollte man in Erwägung ziehen Incremental auf yes zu setzen. Für ein kleines Projekt wie linuxiuvat.de ist das aber (noch) unnötig. 🙂
Die HTML-Dateien mit den Statistiken befinden sich danach in /var/www/awffull/.

Fazit

Beide Werkzeuge erfüllen vollkommen ihren Zweck. Awstats hat mehr Funktionen, ist umfangreicher und lässt sich auch in Echtzeit per CGI-Skript aktualisieren. Awffull ist schlichter, sehr schnell und einfach einzurichten. Ich habe mich schließlich für Awffull entschieden, da für mich der Informationsgehalt vollkommen ausreichend ist. Piwik bietet zusätzlich z.B. noch Angaben über die Bildschirmauflösung und eine Echtzeitfunktion, die ein Programm zur reinen Loganalyse natürlich nicht liefern kann. Für jedes kleine Projekt tun es aber bedenkenlos auch Awstats und Awffull.

Posted on

Urban Terror: Warum frei nicht immer frei ist


Wie will man wissen, was gut ist, wenn man nichts Schlechtes kennengelernt hat? Bevor ich meine derzeit installierten Spiele auf dem Spieleserver vorstelle, wollte ich ein paar Worte darüber verlieren, warum Urban Terror für mein kleines Projekt nicht funktioniert.
Urban Terror ist kein Unbekannter. Frei heraus gesagt: Zu jeder Tageszeit spielen zwanzigmal mehr Menschen Urban Terror als OpenArena. Es gibt E-Sport-Ligen und es existieren mehr als 1000 verschiedene Server. Allein das große Interesse an diesem Spiel macht es für jeden Spieleserver interessant.
Meine erste Begegnung mit Urban Terror liegt schon Jahre zurück. Damals lernte ich es während einer Netzwerkparty unter dem Motto kennen: "Hey, das ist der Mod zu Quake3, der sich genauso wie Counter Strike spielt." An dem Spielprinzip hat sich seitdem natürlich nichts geändert. Das rote Team gegen das blaue Team. Terroristen gegen Polizei. Gut gegen Böse.

Ich denke es gibt kaum jemanden, der schon einmal einen klassischen Ego-Shooter gespielt und noch nie von Counter Strike oder Urban Terror gehört hat. Das Spiel ist taktisch geprägt. Die Bewegungen der Spielfigur sind eher realistisch, man kann sogar bluten und wird dadurch verlangsamt. Die Wahl der Waffen spielt eine entscheidende Rolle. Nicht das Vernichten beliebiger Spieler, sondern das Entschärfen von Bomben und planvolle Vorgehen mit anderen steht im Vordergrund.
Die Grafik war sicher vor Jahren auf der Höhe der Zeit. Heutzutage gibt es natürlich mehr Details und Formen. Für mich war das aber noch nie das entscheidende Argument. Urban Terror eignet sich durch die Spieldynamik hervorragend als Mehrspielerspiel und hat eine weiterhin aktive Gemeinschaft.
Wo ist also das Problem? Zum einen gibt es kein Debianpaket. Die freiwilligen Paketbetreuer waren mal wieder zu nachlässig, könnte man meinen. Die Probleme sitzen tiefer. Urban Terror lässt sich zwar wunderbar unter Linux spielen, es ist aber nicht frei. Schon 2008 war es als Paket für Debian gedacht, woraus aber leider nie etwas wurde.

Das Hauptproblem ist zum einen, dass Urban Terror zwar mittlerweile mit der freien Ioquake3-Engine ausgeliefert wird und somit ohne das Originalspiel Quake3 gespielt werden kann, große Teile stehen aber immer noch unter der Quake3-SDK-Lizenz, die ausdrücklich den Verkauf des Spiels oder Weiterverbreitung durch ein anderes Medium als das Internet verbietet. Software, die aber die kommerzielle Verwendung ausschließt, gilt bei Debian und anderen freien Softwareprojekten als unfrei.
Ein weiterer Punkt ist die schiere Größe des Spiels. Vor vier Jahren wurde in Debian schon diskutiert, wie man große Softwarepakete (>50 MB) eventuell in ein neues Archiv auslagern könne. Fakt ist, dass Urban Terror 1000 MB an Daten mit sich bringt und das normale Archiv zu stark belasten würde.


Zählt man alles zusammen ist Urban Terror zum einen nach Debians Richtlinien nicht frei und hat kein eigenständiges Debianpaket. Außerdem beansprucht es auf meinem vServer 25% des Arbeitsspeichers also ca. 50 MB. Das mag für einen richtigen Root-Server kein Problem sein. Bei mir haben all diese Punkte nach zwei Wochen dazu geführt, dass ich Urban Terror als Kandidaten nicht weiter verfolgt und es zum Schluss wieder vom Server entfernt habe.
Kurzes Fazit: Ein wirklich interessantes und gutes Spiel, dass sich problemlos mit Linux spielen lässt und eines der vielen Beweise dafür ist, welchen Einfluss die Quake3-Engine auf Freie Software hatte. Es erfüllt aber weder die hohen Ansprüche an Freie Software, noch ist es so in Debian integriert und ressourcenschonend, dass es mir leicht gefallen wäre, es für das kleine Spieleserver-Projekt zu nutzen.
[alle Screenshots via urbanterror.info]

Posted on

Kriterien für einen Spieleserver mit Debian GNU/Linux

Für mein Projekt habe ich ein paar Kriterien aufgestellt. Normalerweise sollte so etwas am Anfang stehen und am besten alle relevanten Ideen zu einem Spieleserver mit Debian/GNU Linux chronologisch erzählt werden. Graue Theorie. Ich verspreche aber, dass ich zum Schluss, schon aus Eigeninteresse :), alles übersichtlich ordnen werde.
An einigen Stellen habe ich mir mehr Gedanken als sonst gemacht, wie groß das Projekt überhaupt werden sollte, was man damit lernen kann und wie man sicherstellt, dass nicht nach einem Monat schon wieder alles vorbei ist, weil man die Lust daran verloren hat. Angefangen hat es mit der Vorgeschichte wie man den passenden vServer finden kann.
Für den Spieleserver sprach schließlich auch der Spaßfaktor. Doch welche und wie viele Spiele sollten es schließlich sein?

  • Quantität: Ich wollte so viele Spieleserver wie möglich installieren, ohne dass die Spielqualität auf den Servern darunter leidet. Es sollte also weder der Ping in die Höhe schnellen noch Lags auftreten.
  • Arbeitsspeicher: Spiele, die genügsam mit den Ressourcen umgingen, wurden von mir bevorzugt. Besser drei kleine und interessante Spiele als ein großes.
  • Freie Software: Ein ganz wichtiger Punkt war die Freiheit des Spiels. Wenn man sich mehr mit der Thematik beschäftigt, stellt man schnell fest, dass das Wort Freiheit immer wieder anders interpretiert wird. Als Maßstab habe ich mich an Debians Gesellschaftsvertrag gehalten. Kurz gesagt: Jedes Spiel, dass sich in Debians Main-Repositorien befindet erfüllt all diese Bedingungen, die ich persönlich wichtig finde und auch als eine Art von Auszeichnung und Qualitätsmerkmal für Freie Software ansehe. Dennoch ist es das Thema wert mehr Worte darüber zu verlieren und das Wort "Freiheit" mal kritischer zu hinterfragen.
  • Abwechslung: Quake3 war und ist für Freie-Software-Spiele ein sehr einflussreiches Spiel. Ich wollte aber nicht nur Ego-Shooter installieren, sondern etwas Abwechslung anbieten und auch anderen Genres eine Chance bieten.
  • Qualität: Ohne Frage sollte ein vollständiges, von der Gemeinschaft akzeptiertes Spiel eine hohe Priorität eingeräumt werden. Qualität hat viele Facetten. Gute Spielengine, tolle Grafik, Spielspaß und -tiefe, berauschende Klänge und Musik. Im Zweifelsfall sollte meiner Meinung immer der Spaß gewinnen.
  • Neueinsteiger: Ich bevorzuge Spiele, die schon fix und fertig in Debian gepackt sind. Das macht es für jeden Serveradmin einfacher und gleichzeitig ist das auch ein Indiz für eine gewisse Spielqualität. Auf der anderen Seite gibt es noch einige Spiele, die noch nicht in Debian auftauchen. Jedes Spiel, dass interessant genug ist, sollte unabhängig von der Distribution eine Chance verdienen.

Alle Faktoren sollten irgendwie optimiert werden. Bei nur 225 MB RAM war klar, dass nicht jedes Ziel erreicht werden konnte. Trotzdem dachte ich mir, es ist besser wenige Spiele zu haben, die man auch tatsächlich versteht und betreuen kann als einen Haufen von Anwendungen, zu denen man gar keinen Bezug hat.
Wenn ihr wissen wollt, was ihr überhaupt für eine Auswahl mit Debian und seinen Derivaten habt, dann hilft das folgende Kommando im Terminal schnell weiter.

aptitude search '~sgames'


In Squeeze sind das immerhin 1183 Pakete aus dem Bereich "Spiele".

aptitude search '~sgames' | wc -l


Für einen öffentlichen Spieleserver kamen aber nur diese in Frage.

aptitude search '~sgames server'


Damit wird die Auswahl schon ziemlich eingeschränkt. Natürlich kamen nur Spiele mit Mehrspielermodus in Betracht. Für alles andere hätte ich keinen vServer mieten müssen. Der letzte Befehl spuckt trotzdem noch genug Kandidaten zum Ausprobieren aus. Nach einem Monat kann ich sagen, dass die Auswahl an Spielen in Debian groß genug ist, man aber auch nicht übersehen kann, wie groß der Einfluss von Quake3 und seinen Derivaten im Mehrspielerbereich ist.

Posted on

Monit: Der Wachhund für deinen Server

Man kann seinen favorisierten Terminalemulator anwerfen, Screen starten und darin dann nützliche Applikationen für die Konsole ausführen, die jedes Detail des eigenen Rechners auf Schritt und Tritt überwachen. Die Methode verliert jedoch ihren Reiz, sobald man schlafen muss oder mehr als nur eine Handvoll Daten im Blick behalten möchte.
Um meinen Server zu überwachen benutze ich zur Zeit Munin und Monit, die sich gegenseitig sehr gut ergänzen. Ersterer überwacht alle wichtigen Aspekte des Systems wie Systemlast, Speicherverbrauch, Festplattenbelegung, Traffic, ja sogar die Anzahl der Spieler und kann all das mit Hilfe von Graphen anschaulich visualisieren, wodurch sich Trends frühzeitig erkennen lassen. Monit hingegen ist ideal dafür geeignet um Prozesse zu überwachen, diese gegebenenfalls neuzustarten und beim Erreichen kritischer Schwellwerte Alarm per E-Mail-Benachrichtigung auszulösen.
In diesem Beitrag beschreibe ich in Kürze, was Monit auf meinem Spieleserver mit Debian für Aufgaben hat und wie man ihn unkompliziert einrichtet.

Installation

aptitude install monit

Damit Monit bei jedem Neustart automatisch gestartet wird, muss folgende Variable in /etc/default/monit gesetzt sein.

startup=1

Konfiguration

Die zentrale Konfigurationsdatei von Monit liegt in /etc/monit/monitrc und ist genauso wie das Handbuch, man monit, ausgezeichnet dokumentiert. Die offizielle Dokumentation ist ausführlich und mit vielen Beispielen gespickt.

set daemon 120
Überprüft die Dienste alle 120 Sekunden.
set logfile syslog facility log_daemon
Alle Nachrichten werden nach syslog vom Benutzer Munin geloggt. Hier könnte auch der volle Pfad zu einer separaten Logdatei stehen.
set idfile /var/.monit.id
Der Ort, wo die einzigartige ID der Monitinstanz gespeichert wird
set statefile /var/.monit.state
Diese Datei speichert den aktuellen Zustand der überwachten Prozesse, welcher durch die persistente Speicherung auch nach einem Neustart von Monit wiedererkannt wird.
set mailserver localhost
Hier wird ggf. ein Backupserver und externer Mailserver eingetragen. Ich habe mir einen eigenen aufgesetzt.
set alert root@localhost
Die E-Mail-Adresse, welche in einem Problemfall alarmiert werden soll.

Allgemeine Systemressourcen

Hier werden Systemlast, Speicherauslastung und CPU-Beanspruchung überprüft. Die Syntax ist sehr übersichtlich und selbsterklärend. Wenn ein Wert einen Schwellwert überschreitet soll alarmiert werden.

check system localhost
if loadavg (1min) > 2 then alert
if loadavg (5min) > 1 then alert
if memory usage > 75% then alert
if cpu usage (user) > 70% then alert
if cpu usage (system) > 45% then alert
if cpu usage (wait) > 45% then alert

Prozesse überwachen

Die meisten Einträge sehen bei mir wie der untere aus. Der OpenArena-Server wird automatisch neugestartet, wenn der Verfügbarkeitstest auf Port 27960 mit dem UDP-Protokoll fehlschlägt. Der Konfigurationsblock lässt sich leicht auf Dienste wie SSH, Lighttpd oder Exim übertragen. Sollte der Prozess fünf Mal innerhalb von fünf Zyklen neugestartet worden sein, soll Monit die Versuche einstellen.

check process openarena-server with pidfile /var/run/openarena-server.pid
start program = "/etc/init.d/oa_ded start"
stop program = "/etc/init.d/oa_ded stop"
if failed host 134.0.24.218 port 27960 type udp then restart
if 5 restarts within 5 cycles then timeout
alert root@localhost but not on { instance pid }

Möchte man nur über bestimmte Warnmeldungen per Mail informiert werden, hilft die Konstruktion alert but not on weiter.

Apache Webserver

Das Beispiel stammt direkt aus der monitrc und verdeutlicht noch einmal wie logisch die Konfiguration aufgebaut ist. Monit ist z.B in der Lage pro Prozess die CPU-Auslastung zu überwachen und bei 60% zu alarmieren und dann bei 80% den Webserver neuzustarten und bestehende Verbindungen somit zu trennen. Des Weiteren lässt sich das auch auf den Speicherverbrauch und Kindprozesse anwenden.

check process apache with pidfile /usr/local/apache/logs/httpd.pid
start program = "/etc/init.d/httpd start" with timeout 60 seconds
stop program = "/etc/init.d/httpd stop"
if cpu > 60% for 2 cycles then alert
if cpu > 80% for 5 cycles then restart
if totalmem > 200.0 MB for 5 cycles then restart
if children > 250 then restart
if loadavg(5min) greater than 10 for 8 cycles then stop

Dateitests

Besonders nützlich sind auch Dateitests. Zum einen ist es ein Sicherheitswerkzeug. Geänderte Dateiberechtigungen an wichtigen Systemdateien können sofort erkannt werden, ein veralteter Zeitstempel könnte auf ein Problem mit einem Dienst hindeuten. Außerdem kann die Dateigröße überwacht und z.B. ein Skript ausgeführt werden, welches die Datei an einen anderen Ort verschiebt.

check file openarenalog with path /home/openarena/.openarena/baseoa/games.log
if failed permission 700 then alert
if failed uid openarena then alert
if failed gid openarena then alert
if timestamp > 15 minutes then alert
if size > 100 MB then exec "/usr/local/bin/meinskript.sh" as uid openarena and gid openarena

Monit im Browser anschauen

set httpd port 2812 and
allow admin:monit

Monit bringt einen eigenen Webserver mit, der auf Port 2812 die überwachten Prozesse übersichtlich darstellt. Dabei ist es möglich diese Dienste im Webinterface neuzustarten oder Monit anzuweisen die Überwachung kurzfristig auszusetzen. Den Port muss man mit der Firewall nicht freigeben. Man kann z.B einen SSH-Tunnel zum Betrachten nutzen und dann mit http://localhost:2812 im eigenen Browser als Benutzer admin mit dem Passwort monit sich das Ganze ansehen. Z.B.
ssh -p 44443 -L 2812:deinserver:2812 user@deinserver

Fazit

Monit ist leicht zu installieren und ebenso leicht zu konfigurieren. Ist das einmal erledigt verrichtet er unaufdringlich im Hintergrund seine Arbeit und schlägt sofort an, wenn ein Grenzwert überschritten wurde. Ich vermisste an der Version in Debian Squeeze nur die Möglichkeit die Überwachung auch mal für einen kurzen Zeitraum zu unterbinden, wenn z.B ein Backup gemacht wird und deswegen einige Werte kurzzeitig überschritten werden. Die Funktion ist in Wheezy aber vorhanden und findet sich unter "Service Poll Time".

Posted on

Opfer und Täter zugleich: Wenn der Spieleserver für eine DoS-Attacke missbraucht wird

Behauptete ich an irgendeiner Stelle, dass das mit dem Spieleserver ein kleines Projekt werden solle, dem nicht viel Zeit gewidmet würde? Ich muss im Delirium gewesen sein. Zugegebenerweise es geschieht nicht jeden Tag, dass ich plötzlich entdecke, dass mein OpenArena-Server als Verstärker und Waffe in einer DoS-Attacke auf Webserver und andere unbescholtene Dienste im Internet dient.
Als ich am Samstag auf meinem Server einloggte um ein paar Webseiten von linuxiuvat.de anzupassen, wollte ich kurz den monatlichen Traffic-Verbrauch überprüfen. Ein nützliches Werkzeug dafür ist z.B. slurm, das ich letzten Sommer mal mit meinen anderen favorisierten Systemmonitoren für die Konsole vorgestellt habe. Slurm zeigt übersichtlich den ein- und ausgehenden Netzwerkverkehr in Echtzeit an, konzentriert sich dabei aber nur auf das Wesentliche. Eine detaillierte Aufschlüsselung des Traffic lässt sich mit iftop darstellen, was sich kurz danach noch als nützlich erweisen sollte.
Zu meiner Überraschung signalisierte slurm, dass mein ausgehender Traffic bei 2-3 MB/s lag. Ok, hier werden die Systemadministratoren von Ex-Megaupload sicher schmunzeln, für meinen kleinen vServer war das aber schon eine ganze Menge.
Nur zum Vergleich: Ich habe 1000 GB Traffic frei im Monat, danach wird die Anbindung von 100 Mbit auf 10 Mbit gedrosselt. Momentan liegt mein monatlicher Verbrauch bei ca. 20 GB, obwohl ich vier Spieleserver und einen Webserver online habe. Da ist also noch etwas Luft nach oben...

Netzwerkanalyse

Fasziniert starrte ich also auf slurm und konnte mir über diese Zahl keinen richtigen Reim machen, weswegen ich mir mit iftop die Sache genauer anschaute.


Interessanterweise zeigte sich hier, dass von Port 27960 viel Netzwerkverkehr in Richtung mehrerer Webserver ging, die allesamt keine wirkliche Beziehung zu meinem OpenArena-Server hatten, der auf Port 27960 lauschte. Mit Hilfe von tcpdump konnte ich herausfinden, dass eine Unmenge von getstatus-Kommandos an den OpenArena-Server gesendet wurden, der daraufhin anstandslos Servervariablen und die Anzahl der Spieler an den Webserver übermittelte, womit dieser natürlich gar nichts anfangen konnte. Eine gute Einführung zu tcpdump gibt es im Wiki von ubuntuusers.de.
tcpdump -i eth0 udp and port 27960 -w traffic.log
Mit diesem Befehl lassen sich sämtliche UDP-Pakete, die von und zu Port 27960 geschickt werden "mitschneiden". Ein grafisches Netzwerkanalyse-Werkzeug wie Wireshark, kann später bei der Analyse der Daten helfen.


Wie diese Variablen für meinen Server aussehen, lässt sich z.B. auf der Statusseite von dpmaster.deathmask.net nachschauen.

Nachforschungen

Nach kurzer Recherche im Internet fand ich schon mehrere Beiträge, die ähnliche Probleme beklagten. So zum Beispiel im OpenArena-Forum, bei ioquake.org und im Forum von UrbanTerror. Allen war gemein, dass es sich hier immer um auf Quake3 basierende Spiele handelte.
Hier fiel dann auch das Stichwort: DRDoS-Attacke, was für Distributed-Reflected-Denial-of-Service-Attacke steht. Dabei wurde meinem OpenArena-Server eine falsche Absenderadresse mitgeteilt (IP-Spoofing), so dass dieser die normalerweise harmlose getstatus-Abfrage an einen Webserver leitete. Durch die hohe Anzahl von Anfragen und die relativ großen Pakete, die verschickt wurden, entstand ein Verstärkungseffekt, der noch größer ausgefallen wäre, wenn ich mehrere verwundbare OpenArena-Server installiert gehabt hätte.
Die Täuschung beschränkte sich aber nicht nur auf einen Webserver, sondern gleich auf mehrere, was den Traffic natürlich in die Höhe schnellen ließ. Ich schrieb daraufhin einen Fehlerbericht für Debian mit der Nummer #665656. Innerhalb kürzester Zeit konnte der Paketbetreuer für OpenArena einen Patch einspielen, der die getstatus-Anfragen an den Server begrenzt. Eine Sicherheitsankündigung gab es hierzu auch schon.

Fazit

Ich war ehrlich gesagt überrascht, dass ich derjenige war, der diesen Fehler schließlich an Debian gemeldet hat, obwohl es den Anschein hatte, dass einige vor mir Betroffene auch Debian benutzen. Der Paketbetreuer reagierte sehr schnell und ich denke durch den Fehlerbericht und die Sicherheitsankündigung ist das Problem prominent sichtbar gemacht worden. Der Bug betraf nicht nur OpenArena, sondern praktisch alle Spiele, die eine ungepatchte Quake3-Engine benutzen, so z.B. auch Tremulous.
Ich hatte vor kurzem notwendige Firewallregeln für den Spieleserver vorgestellt, die auch in dieser Form berechtigt sind. Um den Server aber gegen solche DRDoS-Angriffe abzusichern, braucht man auch hinreichende Regeln, die am besten automatisch und dynamisch hinzugefügt werden. Trafficbegrenzung per IP fällt mir hier als Stichwort neben fwlogwatch ein, dass ich schon einsetze.
Insgesamt gibt es gerade zur Netzwerkprotokollierung und -überwachung noch eine Menge zu lernen. Das Ganze soll nicht darüber hinwegtäuschen, dass bisher alles andere wunderbar funktioniert hat und das Projekt wirklich Spass macht. Auf der anderen Seite ist man aber auch dafür verantwortlich, dass der Server nicht Amok läuft und für finstere Zwecke missbraucht wird. Denial-of-Service-Attacken fallen in Deutschland unter Computersabotage und können mit bis zu drei Jahren Freiheitsstrafe geahndet werden. Ich hoffe der Richter lässt in diesem Fall Milde walten. 😉

Posted on

Debian-Server mit der unkomplizierten Firewall ufw absichern

Zwischen dem Sperren des Root-Zugangs für SSH und dem Installieren des ersten Spieleservers musste ich eine Firewall einrichten. Ich bin noch kein Firewall-Experte, weswegen ihr genau überlegen solltet, ob die folgende Anleitung euren Ansprüchen genügt. Fakt ist aber, dass ich damit momentan meinen Spieleserver mit Debian schütze und ich damit bisher zufrieden sein kann. 😉
Die Errichtung einer Barriere mit Hilfe von netfilter und iptables unterstützen heute viele Werkzeuge. Ich hatte mir ufw und arno-iptables-firewall als mögliche Kandidaten ausgesucht und mich dann für die "unkomplizierte Firewall" entschieden.
Ursprünglich von Ubuntu entwickelt bietet ufw eine einfache Möglichkeit nur die Dienste freizugeben, die tatsächlich öffentlich verfügbar sein sollen.

Installation

aptitude install ufw

Konfiguration

ufw enable


Aktiviert die Firewall. Bestehende SSH-Verbindungen können unter Umständen getrennt werden. Standardmäßig werden eingehende Verbindungen geblockt und ausgehende Verbindungen erlaubt. Bevor man die Firewall aktiviert, kann man z.B. mit

ufw allow proto tcp from any to any port 22


explizit Port 22 für den SSH-Zugang freigeben.

ufw allow 44443/tcp


In der vergangenen Erklärung konnte man sich über Port 44443 per SSH einloggen, also muss zuerst dieser Port mit allow freigeschaltet werden. Dabei lässt sich mit /udp oder /tcp die Erlaubnis auf bestimmte Protokolle eingrenzen oder ohne auf beide ausdehnen.

ufw limit 44443/tcp


Noch mehr Sicherheit bietet die Limit-Funktion von ufw, mit der die Anzahl von eingehenden Verbindungen pro IP begrenzt wird, wodurch Brute-Force-Attacken deutlich erschwert werden.

ufw default deny


Im Prinzip der wichtigste Schritt, da dadurch standardmäßig alle eingehenden Verbindungen abgewiesen werden. (Genauer, jedes eingehende Packet wird kommentarlos verworfen. DROP)

ufw status verbose


Zeigt den Status der Firewall an. Oder einfach nur ufw status.

ufw allow 27960/udp


Gibt den UDP Port 27960 für OpenArena frei.

ufw allow 40000:40009/udp


Gibt die Ports von 40000 bis 40009 für UDP frei (XPilot-ng)

ufw allow http


Eine andere Schreibweise um Standard-Port 80 für den Webserver freizugeben

ufw logging on und ufw logging medium


Der erste Befehl schaltet die Logfunktion der Firewall ein (standardmäßig auf niedrig). Weiterhin gibt es noch medium, high und full.

ufw delete allow 44443/tcp


Mit der Delete-Funktion lassen sich Regeln im laufenden Betrieb auch wieder löschen.

Ausgehende Verbindungen

Ausgehende Verbindungen werden standardmäßig erlaubt. Im meinem Fall bin ich der einzige Benutzer mit Shellzugriff auf meinem Server und es gibt bisher weder CGI noch PHP-Anwendungen, die man manipulieren könnte um diese Einstellung zu missbrauchen. An dieser Stelle scheiden sich die Geister. Tatsache ist, man kann sein System so fest zuschnüren, dass nicht einmal ausgehende Verbindungen erlaubt sind oder einen Mittelweg finden.

ufw deny out to any


Blockiert alle ausgehenden Verbindungen

ufw allow out 80,443/tcp


Erlaubt ausgehende TCP-Verbindungen für Port 80 und 443.

IPv6

UFW blockt standardmäßig alle Anfragen mit IPv6. Damit ufw mit IPv6 zusammenarbeitet muss in /etc/default/ufw die Variable IPV6 auf Yes gesetzt und die Firewall einmal mit ufw reload neu gestartet werden.

Fazit

Die unkomplizierte Firewall macht ihrem Namen alle Ehre. Das Prinzip ist immer das gleiche. Alle eingehenden Verbindungen verwerfen und nur die tatsächlichen Dienste freigeben, die man wirklich braucht. Wie restriktiv man ausgehende Verbindungen behandelt, hängt vom eigenen Benutzerszenario ab. Die Regeln lassen sich noch deutlich verfeinern. Mehr Informationen verrät man ufw oder die folgenden Links.

Links

Ubuntu ufw Documentation
Firewall Ubuntu Servers

Posted on

Dein Name sei Debianspiele: Ein Exkurs in Markenrecht

Jedes tolle Online-Projekt braucht seine eigene Webseite. Ich grübelte eine Weile, was ich genau mit meinem vServer anstellen wollte. Schließlich entschied ich mich die Themen begrenzte Ressourcen, Debian und Spiele miteinander zu verbinden. Ich wollte Spieleserver anbieten mit ausschließlich freien Spielen, die Debian GNU/Linux in seinen Repositorien führt. Es sollte also zum einen Debian bekannter machen, vielleicht sogar etwas voranbringen, aber ebenso auch einfach nur ein Angebot für Spieler zum Spielen sein. Und schließlich sollte beim Konfigurieren und Bereitstellen natürlich auch wieder etwas dazugelernt werden.
Ich kam dann auf die Idee eine zweisprachige Seite in Englisch und Deutsch zu machen, da gerade Onlinespiele ein internationales Publikum anziehen und man mit Englisch noch die größten Chancen hat, dass jemand versteht, was man eigentlich vorhat. Mir kreisten die ganze Zeit dann die Domainnamen debiangames.de und debianspiele.de im Kopf herum. Wäre das nicht ein wirklich passender Name für eine Seite über freie Spiele mit Debian?
Auf der anderen Seite aber, warum gibt es noch keine offizielle Seite, die so heißt? Durfte ich die Domains einfach registrieren? Immerhin waren sie noch frei verfügbar.
Ich wollte es genauer wissen und fand bei debian.org die Trademark-Seite. Dort erfährt man, dass Debian seit dem 21. Dezember 1999 eine eingetragene Marke ist und auch in Europa mittlerweile geschützt ist. Ausdrücklich wird Firmen ein "vernünftiger Gebrauch" der Marke Debian eingeräumt. So richtig viel Erhellendes zum Thema Domains stand dort aber nicht.
Ich beschloss daraufhin eine E-Mail an trademark@debian.org zu schreiben und es einmal darauf ankommen zu lassen. Der Wortlaut war:

Ladies and Gentlemen
My name is Markus Koschany and i intend to register the domains
debiangames.de and debianspiele.de. Before i go ahead i would like to
ask for your permission and if there are any objections against the
registration.
Both websites will be for private and non-commercial use. At the moment
i am hosting a Debian powered vServer which provides games included in
Debian.
My goal is
- to promote games available in Debian
- to provide statistics for gamers on the server
- to post short news about game development in Debian
- to present free software games
- to give gamers the opportunity for feedback
- to learn more about server administration
- last but not least: having fun
The content will be available under CC-BY-SA.
I would be glad to hear about a positive reply.
Yours sincerely
Markus Koschany

Nur zwei Tage später an einem Sonntag antwortete mir der aktuelle Projektleiter, Stefano Zacchiroli. Er bedankte sich für das Interesse an Debian, müsse aber leider meine Anfrage ablehnen. Debian sehe es lieber, wenn Domains, die den Namen Debian führen, offiziell wären oder von offiziellen Repräsentanten geführt würden. Stattdessen schlug er vor, dass ich das Debian-Games-Team kontaktieren solle, um meine Idee eines "debian games portal" zu verwirklichen.
Gut, ich gebe zu, ein Spieleportal schwebte mir gar nicht vor und ich hätte den privaten Charakter des Projekts in der Mail mehr herausstellen sollen. Ansonsten überraschte mich seine Entscheidung aber nicht und ich hätte an seiner Stelle wahrscheinlich genauso entschieden. Bevor irgendein unbekannter Fremder die Erlaubnis erhält Debian im Domainnamen zu führen, macht es tatsächlich mehr Sinn, das in offizielle Kanäle zu lenken. Vermutlich ist es auch genau das, was ein guter Projektleiter machen sollte.
Wie ich später herausfand ist die Regelung des Markenrechts bei Debian gerade im Umbruch. Auf debian-devel-announce hatte Stefano Zacciroli hierzu nämlich schon Änderungen angekündigt und auch, dass die Domain debian.eu widerrechtlich als Webseite eines Computershops verwendet worden war.

Wenn nicht Debian dann...

Blieb schließlich nur noch das Problem, wie das Baby heißen sollte. Ich entschied mich für

linuxiuvat.de

Ich weiß, das ist sicher nicht der Name, der die nächsten Jahre zu einem Synonym des Internets werden wird, aber er beschreibt mein kleines Projekt am besten und ich darf ihn legal benutzen.
Da ich die Domain nicht als Marke benutzen werde (es sei denn natürlich damit lässt sich unverschämt viel Geld verdienen 😉 ) war es kein Problem Linux im Namen zu führen, die Linux Foundation gab grünes Licht.
Tja und iuvat ist lateinisch und bedeutet hilft. Oder wie ein alter Römer mir versichern konnte:

iuvat: a-Deklination
iuvare: helfen
Endung auf t: 3. Person Singular.
Frei übersetzt: Linux iuvat = Linux hilft.

Mit Latein hatte ich das Deutsch/Englisch-Problem umgangen und verprelle nun somit beide Muttersprachler. 😛
Im Moment sind alle Informationen nur auf Englisch verfügbar. Sobald die Seiten so statisch und endgültig sind, wie ich mir das vorstelle, übersetze ich sie natürlich noch auf Deutsch.

Posted on

Ein Projekt nimmt Gestalt an: Der passende vServer

Eigentlich sollte an dieser Stelle mein Artikel zu Haiku erscheinen. Wie ich es aber im Moment anstelle, ich verliere mich dabei zu sehr in Details. Habe ich eine interessante Anwendung mit Haiku entdeckt, suche ich in der Dokumentation nach weiteren Hinweisen, nur um bald festzustellen, dass ein anderes Stichwort in die entgegengesetzte Richtung führt. Dazu muss natürlich alles noch auf dem Inspiron 4000 Laptop getestet werden, Screenshots dürfen auch nicht fehlen und schließlich muss irgendwer noch die ganzen Gedankenstränge in ein elektronisches Medium hacken. Ich habe mich entschieden nach Haiku besser zwei kurze Artikel zu schreiben als einen großen, um diesen Teufelskreis zu durchbrechen und mit dem Projekt fortzufahren, dass in den vergangenen Wochen Gestalt angenommen hat.

Die Gemeinsamkeiten alter Hardware und eines virtuellen Servers

Eher durch Zufall bin ich auf die Idee gekommen mir einen eigenen vServer zu mieten und damit die Themen dieses Blogs zu verbinden und auf eine andere Weise anschaulich zu machen.
Schaut man nämlich genauer hin, erkennt man viele Parallelen zwischen einem vServer und älterer Hardware. Augenscheinlich haben die meisten Einsteigerangebote durch Virtualisierung bei bestimmten Kennwerten nicht mehr Leistung zu bieten als manch älterer Laptop. Wenn ich davon schreibe, dass man nur die richtigen Anwendungen und Betriebssysteme auswählen muss, um auch ältere Hardware produktiv zu nutzen, gilt das im gleichen Maße auch für einen vServer. Es sind die gleichen Techniken und Konsolenprogramme, die beide wieder zum Leben erwecken.
Ich habe mich schließlich für ein Produkt von serverway.de, den root VPS X0, entschieden. Die Wahl war nicht einfach und ich denke niemand kann mit absoluter Bestimmtheit vor dem Kauf eines solchen Produkts sagen, dass es das Richtige ist, wenn er vorher noch keine Erfahrungen mit dem Anbieter gemacht hat.
Mir waren verschiedene Dinge wichtig

  • Herausforderung. Es ist genauso wie mit dem neuen Hexacore-Rechner, den man nur kauft, weil das neuste Spiel angeblich nicht mehr ruckelfrei laufen würde. Genauso kann jeder einen 4 GB VPS mit allem Drum-und-Dran mieten, ihn mit automatischen Werkzeugen konfigurieren und ihn dann entweder mit vollkommen überflüssigen Diensten betreiben oder aber im Gegenteil unterfordern. Ich habe mich absichtlich für die kleinste Version mit 256 MB RAM entschieden, weil ich sie für ausreichend halte, um mehrere Spieleserver mit Homepage zu betreiben und den Server soweit mit Extras auszustatten, dass ich den Server überwachen kann und gleichzeitig einen akzeptablen Service für alle Nutzer bieten kann. Es ist sicher eine Herausforderung, aber es soll ja auch Spaß machen. 🙂
  • Preis. Ein positiver Nebeneffekt des Ganzen, es muss nicht viel kosten. 3,90 € pro Monat sind ein fairer Preis. Natürlich darf man sich dann nicht beschweren, dass die Leistung nicht ausreicht, wenn der 20. Spieleserver an den Start geht und das System nur noch vor sich hinswapt. Wichtig ist mir nur, dass die versprochene Leistung auch tatsächlich eingehalten wird.
  • RAM ist nicht alles. Man schielt immer zu sehr auf den RAM bei vServern, dabei sind die anderen Komponenten nicht minder wichtig. Für die CPU-Leistung vergibt serverway ein Sternchen und verwendet für den realen Server eine Quad-Core CPU von Intel. Das sagt zum Beispiel noch nicht viel. Weiterhin lässt sich aber zwischen vielen bekannten Linuxdistributionen wählen, selbst Arch Linux und Gentoo werden angeboten. Gut gefiel mir, dass die Virtualisierungslösung angegeben wurde, es gibt eine Backupmöglichkeit und 1 TB Traffic mit einer 100 MBit Anbindung sind für ein kleines Projekt erst einmal ausreichend. Insgesamt erschien mir das Preis- Leistungsverhältnis angemessen und fair zu sein.

Wie schon geschrieben, es gibt nicht nur einen Anbieter von vServern da draußen und auch andere hatten gute Angebote. Mein erster Eindruck von serverway.de war auf jeden Fall positiv. Nach dem Ausfüllen des Online-Formulars dauerte es nur wenige Sekunden bis ich eine Bestätigungsmail erhielt, diese mit einer SMS bestätigte und danach sofort Zugang zum vServer hatte.
Die Einzugsermächtigung konnte unterschrieben und eingescannt als PDF-Datei per E-Mail eingereicht werden. Das war es auch schon. Nach zwei Stunden hatte ich die wichtigsten Sicherheitsvorkehrungen getroffen und meinen ersten Spieleserver am Laufen.
Der Server ließ sich zum Test problemlos über das Webinterface neustarten, seit drei Wochen läuft er nun ununterbrochen. Einziger Makel war bisher ein fehlgeschlagenes Backup mit Rsync als der Backupserver nicht verfügbar war. Der Helpdesk antwortete aber innerhalb von 30 Minuten auf meine E-Mail-Anfrage.
Ich denke fairerweise muss man den Service und die Zuverlässigkeit längerfristig beobachten, um ein echtes Urteil abgeben zu können. Im Moment bin ich aber zufrieden.
Natürlich brauchte das Projekt auch einen Namen, womit ich plötzlich bei Debians Markenrechten gelandet war.