© tomertu, 123RF

Hiawatha gilt als leichtfüßiger Webserver mit vielen Features und hat eine treue Fangemeinde. Eine Vielzahl von Eigenschaften unterscheidet ihn von den großen Vorbildern wie Apache.

Die meisten Admins denken beim Wort Webserver intuitiv zunächst an Apache (Abbildung 1). Das Programm gehört nicht nur zu den dienstältesten seiner Art, sondern hat sich im Laufe der Jahre auch einen Ruf als versiertes und sehr stabiles Produkt erarbeitet.

Freilich gibt es auch andere Optionen: In den Augen vieler Admins ist Nginx längst zur besseren Option avanciert. Wer mit dem massiven Funktionsumfang von Nginx oder Apache nichts anfangen kann, landet regelmäßig bei Lighthttpd, der sich in vielerlei Hinsicht auf das Nötigste beschränkt. Eher selten dringen Admins bis zu Hiawatha (Abbildung 1) durch, was möglicherweise auch mit dessen Namen zu tun hat, der gewisse Zungenbrecherqualitäten aufweist.

Abbildung 1: Die Umfrage-Website W3 Techs verzeichnet für Hiawatha nur ein paar wenige Installationen – das wird den Fähigkeiten des Servers aber nicht mal im Ansatz gerecht. Quelle: W3 Techs

Dennoch bietet Hiawatha [1] durchaus eine valide Alternative zu Apache, Nginx, Lighthttpd und vielen anderen Webservern, wenn man keine exotischen Features benötigt. Dieser Artikel stellt Hiawatha vor, geht auf seine Entstehungsgeschichte ein und beschreibt, wie Admins mit der Lösung schnell an den Start kommen.

Was Hiawatha kann

Wer nach Hiawatha googelt, wird mit einer Vielzahl von möglichen Erklärungen für die Herkunft des Worts konfrontiert. So handele es sich um einen Gesellschaftstanz der 20er-Jahre, den mythischen Anführer der irokesischen Five Nations irgendwann zwischen dem 15. und 18. Jahrhundert oder auch um die irokesische Umschreibung für den, “der früh aufsteht”. Zwar liegt die Vermutung nahe, dass der Indianerhäuptling Pate stand, doch bleibt unklar, wieso der Autor der Software sich ausgerechnet für diesen Namen entschied.

Zumindest steht zweifelsfrei fest, wer Hiawatha programmiert hat: Der damalige Informatikstudent Hugo Leisink aus den Niederlanden fing 2002 mit der Arbeit an dem Programm an. Das tat er, anders als Linus Torvalds gut ein Jahrzehnt zuvor, nicht aus Jux und Tollerei. Vielmehr verhagelten ihm die seinerzeit verfügbaren Webserver, allen voran Apache, aus mehreren Gründen gehörig die Laune.

Wer sich in jene Zeit zurückversetzt, erinnert sich an eine Epoche, in der es leistungsstarke Skriptsprachen wie PHP zwar gab, die aber weder die Qualität noch die Verbreitung aufwiesen, die sie heute haben. Wer im Kontext eines Webservers Code ausführen wollte, nahm dazu CGI-Skripte, denen Webserver aber praktisch nach Belieben freie Hand gewährten. Apache etwa definierte keine maximale Dauer, die ein CGI-Skript brauchen durfte, bis es wahlweise einen positiven oder negativen Wert zurückgab. Wer CGI-Skripte also mit Geschick angriff, konnte über ein einzelnes Skript einen ganzen Webserver lahmlegen.

Das trieb Leisink so auf die Palme, dass er einen neuen Webserver ersann. Die Idee zu Hiawatha war geboren, und das Programm sollte besonders jene Security-Features liefern, die Leisink bei der Konkurrenz so sehr vermisste. Obgleich das Tool bis heute für sich in Anspruch nimmt, ein sehr schlanker, flinker Server für HTTP(S) zu sein, kamen über die Jahre einige Features hinzu.

CGI und FastCGI

Bis heute bietet Hiawatha umfassenden Support für CGI und FastCGI. Die Einschränkungen, die Hugo Leisink bereits 2002 ersann und in die Software einbaute, stehen dabei nach wie vor zur Verfügung. Wer als Admin etwa CGI-Skripte auf eine bestimmte Laufzeit beschränken will, konfiguriert das in Hiawatha. Schlägt ein Skript über die Stränge, rückt Hiawatha ihm mit dem berüchtigten »kill -9« zuleibe, ganz ohne Eingriff durch einen Administrator. Doch das ist nicht das einzige sinnvolle Feature der Lösung.

Hiawatha gehörte etwa auch zu den ersten Webservern, die Large-File-Support in ihr Pflichtenheft schreiben konnten. Freilich klingt das heute nicht sonderlich spektakulär, doch es gibt immer noch Webserver aus dem Segment der Kleinlösungen, die bei größeren Dateien ins Straucheln geraten.

Reverse Proxies sind leicht

Ein dem Thema Sicherheit geschuldeter immer häufiger auftretender Use Case für Webserver ist der Einsatz als Reverse Proxy. Ein Proxy-Server dient ja eigentlich einem Client in einem privaten Netz, der darüber eine Verbindung in die Außenwelt herstellt. Viele Firmennetze werden heute indes so stark von Firewalls geschützt, dass es kaum möglich ist, von außen überhaupt auf Ressourcen hinter den diversen Firewalls zuzugreifen.

Hier kommen Reverse Proxies ins Spiel: Sie nehmen auf der einen Seite eine eingehende Verbindung aus dem Internet an und haben selbst eine Route in das Netz, in dem der Zieldienst steht. Über diese Route wickelt der Reverse Proxy als transparenter Vermittler dann den Datenverkehr zwischen Client und Dienst ab. Für Unternehmen bietet das auf der einen Seite eine attraktive Alternative dazu, die Firewall in Schweizer Käse zu verwandeln, weil es weniger Aufwand verursacht. Andererseits ermöglicht es manche Anwendungsfälle überhaupt erst, die man andernfalls wegen zu rigider Sicherheitsmaßnahmen gar nicht umsetzen könnte.

Apache und Nginx beherrschen den Einsatz als Reverse Proxy aus dem Effeff. Es wirkt allerdings leicht übertrieben, den riesigen Funktionsumfang der beiden Server nur dafür zu installieren, eine verhältnismäßig leichte Aufgabe abzuwickeln. Das dachte sich auch Hugo Leisink und implementierte den Support als Reverse Proxy in Hiawatha bereits früh. In ein paar Tausend Zeilen Code lässt sich so realisieren, was andernfalls über den Umweg Apache oder Nginx das System erheblich aufblähen würde.

Von wegen keine Features

Wer von Hiawatha als leichtfüßigem Webserver hört und dabei an stark reduzierte Funktionalität denkt, ist gründlich auf dem Holzweg. Das komplizierte Umschreiben von URLs, das Lösungen wie WordPress oder Joomla oft voraussetzen, beherrscht auch Hiawatha. Der Server verwendet dazu das URL Toolkit, eine eigene Hiawatha-Komponente, die die Umschreibelogik für URLs bündelt.

Das bedeutet, dass Hiawatha sich hervorragend eignet, um Anwendungen des Web 2.0 wie eben WordPress zu betreiben. Das kann auch verschlüsselt erfolgen, denn der Webserver verfügt über eine komplette Implementation von TLS. Grundlegende HTTP-Anmeldung mittels Digest oder Basic Authentication sieht Hiawatha ebenfalls vor, was zum Beispiel für den Zugriff auf die Admin-Schnittstellen vieler Webprojekte nötig ist.

Der Datenflut keine Chance

Zu den weiteren Features aus der Security-Ecke zählt die Möglichkeit, auf Webserver-Ebene ein Throttling für Verbindungen einzurichten. Dabei legt der Admin für einzelne Clients fest, mit welcher Geschwindigkeit sie Uploads vornehmen dürfen. Das verhindert, dass Nutzer einzelne Webserver-Instanzen außer Gefecht setzen, indem sie deren Leitung über gezielte, parallele Mehrfach-Uploads saturieren.

Freilich gilt, dass gegen breitangelegte DDoS-Angriffe der Schutz auf Software-Ebene nicht ausreicht – hier muss man stattdessen am Netzwerk ansetzen. Zumindest kleine Angriffe unterbindet Hiawatha auf diese Weise jedoch zuverlässig. Das eingebaute Caching ermöglicht es dem Server zudem, eingehende wie ausgehende Requests schneller und ressourcenschonender abzuarbeiten. In dieses Horn stößt auch die Unterstützung für HTTP-Komprimierung mittels Gzip, die Hiawatha ebenfalls seit einigen Jahren bietet.

XSS- und CSRF-Angriffe unterbinden

Ein klassischer Angriffsweg gegen Webserver ist das sogenannte Cross-Site-Scripting. Die Gefahr dafür besteht potenziell überall dort, wo Webanwendungen mit dem Input von Benutzern hantieren. Im Falle eines Angriffs handelt es sich dabei meist um automatisch agierende Roboter.

Bei XSS-Attacken greift der Angreifer vereinfacht ausgedrückt auf Infrastruktur hinter dem Webserver zu. Dazu nutzt er Schwachstellen in der jeweiligen Webapplikation, die den illegitimen Zugriff nicht konsequent unterbindet. Gibt es in einer Weblösung etwa eine Suchmaske für Benutzernamen, die im Hintergrund einen MySQL-Aufruf auslöst, bestünde ein typischer XSS-Angriff darin, ein MySQL-Kommando in die Suchmaske einzugeben. Diese spezielle Form eines XSS-Angriffs hat, weil sie recht häufig vorkommt, sogar einen eigenen Namen: SQL-Injection. Ist die Software nicht gegen XSS-Angriffe gewappnet, leitet sie den illegalen Befehl direkt an die Datenbank weiter, wo er zur Ausführung gelangt. Umgekehrt geht es bei Cross-Site Request Forgery (CSRF) zu: Hier nutzen Langfinger die Rechte von legitim angemeldeten Nutzern beziehungsweise deren Browser-Sessions aus, um Befehle an Webserver zu senden, die die legitimen Nutzer eigentlich gar nicht senden wollen.

Das Problem bei diesen Angriffsarten und ähnlichen Attacken: Webserver haben diesen Angriffsvektor lange Zeit praktisch komplett ausgeblendet und sich für nicht zuständig erklärt. Hiawatha ist seit langer Zeit eine deutliche Ausnahme von dieser Regel: Der Server verfügt über Code, der XSS- und CSRF-Angriffe anhand verschiedener Parameter zu erkennen versucht und sie unterbindet, falls laufende HTTP(S)-Sessions die Angriffskriterien erfüllen.

Das Framework, das Angriffe zu erkennen versucht, beherrscht in Hiawatha sogar noch mehr: Es achtet nicht nur auf XSS- und CSRF-Anzeichen, sondern erkennt auch Clients, die in kurzer Zeit viel Traffic produzieren oder eigenartige HTTP-Anfragen senden. Einzelne Parameter für die Engine, die Angriffe erkennt, definiert der Admin in der Konfigurationsdatei des Servers.

Monitoring im Lieferumfang

Während praktisch jede moderne Software Metrikdaten zu ihrer eigenen Nutzung sammelt und über eine standardisierte Schnittstelle zur Verfügung stellt, haben Webserver sich im Hinblick auf das Thema Trending lange Zeit vornehm zurückgehalten. Hiawatha geht auch hier einen Sonderweg: Das Tool schreibt viele von seinem Autor definierte Metrikdaten nämlich mit. Zum Webserver gehört zudem eine auf PHP basierte Mini-Anwendung namens Hiawatha Monitor, die die gesammelten Metrikdaten vom Webserver abruft und an den Admin ausgibt.

Weil Hiawatha Monitor auf Banshee [2] basiert, bereitet das Tool die empfangenen Nutzungsdaten auch optisch auf. Das lässt sich in Form und Umfang zwar nicht mit der Datensammelei vergleichen, die etwa die Kombination aus Prometheus und Grafana leistet, ist aber immerhin besser als nichts. Hiawatha lässt sich ohnehin nicht sinnvoll mit Prometheus verbinden, weil es keinen passenden Exporter gibt, der die in Hiawatha vorhandenen Metrikdaten an Prometheus ausgeben könnte.

Tomahawk als Kommando-Shell

Alle relevanten Hiawatha-Parameter lassen sich per Konfigurationsdatei festlegen; Änderungen daran bedingen aber den Neustart des Tools. Das ist je nach Situation nicht immer möglich, weshalb Hiawatha auch mit einer eigenen Kommandozeile aufwartet. Über die lassen sich auch per Shell die Metrikdaten auslesen, die Hiawatha aktuell vorliegen.

Wichtiger jedoch ist, dass die Kommando-Shell namens Tomahawk die Rekonfiguration des Webservers im laufenden Betrieb ermöglicht. IPs, die auf Hiawathas interner Bannliste gelandet sind, lassen sich hier dauerhaft entfernen – andernfalls würde Hiawatha diese Clients schlichtweg nicht mehr bedienen. Mittels des Befehls »kick« lassen sich sämtliche aktuellen Verbindungen beenden.

Mit Hiawatha loslegen

In Summe steht fest: Mit Hiawatha lässt sich unter Aufwand sehr weniger Ressourcen ein leistungsstarker Webserver realisieren, der den Vergleich mit der Konkurrenz von Apache oder Nginx nicht zu scheuen braucht. Weniger schön ist dabei allerdings die Art und Weise, wie der Admin zu einer laufenden Instanz des Diensts kommt, denn anders als für Apache und Nginx liegen den meisten Distributionen für Hiawatha keine Pakete bei. Man kommt also nicht um etwas Bastelei herum. Als Lohn winkt jedoch eine sehr übersichtliche, leicht zu bearbeiten Konfiguration.

Im ersten Schritt steht die Installation von Hiawatha selbst auf dem Programm. Wie der Admin diese idealerweise bewerkstelligt, hängt von der Distribution ab, die er nutzt. Da Hiawatha nicht sonderlich verbreitet ist, sucht man fertige Pakete für die gängigen Distributionen oft vergeblich. Passende Debian-Pakete für das aktuelle Release “Buster” liegen in einem eigenen Paket-Verzeichnis [3]. Nach dessen Aufnahme in die Paketquellen und der Aktivierung des GPG-Schlüssels für das Repository holt der Befehl »apt install hiawatha« das Paket samt aller Abhängigkeiten auf das System.

Schön könnte das Leben theoretisch auch im CentOS-Kontext sein. Findige Hiawatha-Fans pflegten dafür vor ein paar Jahren Pakete ein; die Veröffentlichung erfolgte über das Anku-Verzeichnis [4] mit Erweiterungen für CentOS und RHEL. Dort findet sich momentan aber nur ein Paket für das angestaubte Hiawatha 10.8.4, und selbst das nur für CentOS 7. Pakete der aktuellen Version 10.11 für CentOS 8 fehlen.

Ähnliche Probleme gibt es unter Ubuntu: Das einzige Hiawatha-PPA liefert nur für Ubuntu 18.04 Pakete in einem prähistorischen Zustand aus. Etwas besser treffen es die Nutzer von MacOS oder den verschiedenen BSD-Derivaten, weil Hiawatha dort zum Port-Systems gehört und sich damit automatisch aus den Quellen übersetzen lässt.

Kompilieren

Hiawatha nutzt Cmake und hat nicht sonderlich viele Parameter, die der Admin beim Bauen angeben muss. Die dringende Empfehlung lautet freilich, gleich ein Paket von Hiawatha zu bauen, statt die Software auf Produktionssystemen selbst zu kompilieren. Dazu lädt der Admin von der Hiawatha-Website zunächst den Quelltext herunter. Der Kompiliervorgang besteht im Anschluss aus den Befehlen »mkdir build; cd build; cmake ..; sudo make install/strip«.

Ein Blick in die Datei »INSTALL« im Quelltext verrät, welche Parameter Cmake für Hiawatha grundsätzlich unterstützt (Abbildung 2). Vorrangig geht es dabei um die Pfade im Dateisystem, die Hiawatha nutzen soll. Hier lässt sich aber auch festlegen, ob Tomahawk gebaut und Unterstützung für TLS gegeben sein soll und ob Hiawatha seine Erweiterung für den Betrieb als Reverse Proxy braucht. Die meisten Parameter stehen ab Werk ohnehin auf »ON«, was die jeweilige Funktion aktiviert. Dem Admin steht es aber frei, die Werte nach eigenem Gusto zu ändern – ein Feature, das man von vornherein nicht benötigt, muss das Binary von Hiawatha nicht unnötig aufblähen.

Abbildung 2: Während andere HTTP-Server ihre Konfigurationsdateien in viele Einzelteile aufteilen, begnügt Hiawatha sich mit einer eher kleinen Anzahl notwendiger Zeilen.

Nach Abschluss des Kompiliervorgangs steht die Konfiguration auf dem Plan. Das folgende Beispiel geht davon aus, dass »/etc« als »CONFIG_DIR« festgelegt ist, sodass Hiawatha seine Konfigurationsdatei in »/etc/hiawatha/hiawatha.conf« erwartet. Außerdem setzt es voraus, dass schon beim Kompilieren »/var/www/« als »WEBROOT_DIR« festgelegt wird, in dem Hiawatha die Webinhalte sucht (der Parameter lässt sich per Konfiguration später allerdings noch ändern).

Der einfachste Webserver

Wer Hiawatha lediglich mit einem SSL-Zertifikat auf Port 443 lauschen lassen will, erreicht das mit einer denkbar einfachen Konfigurationsdatei. Ein Beispiel für den entsprechenden Vierzeiler zeigt Listing 1.

Binding {
  Port = 443
  TLScertFile = /etc/ssl/www-certificate.pem
}

Anders als etwa Apache erwartet Hiawatha alle Komponenten, die zum SSL-Zertifikat gehören, in derselben Datei. Die referenzierte »ssl-certificate.pem« muss also neben dem SSL-Zertifikat selbst auch den zu ihm gehörenden SSL-Schlüssel sowie eventuell nötige SSL-CA- und SSL-Intermediate-CA-Zertifikate enthalten. Dabei ist die Reihenfolge wichtig: Erst muss die Datei den privaten Schlüssel enthalten, dann das Zertifikat und dann zusätzliche CA- oder Zwischenzertifikate. Passt das, ist die Konfiguration an dieser Stelle aber bereits abgeschlossen, und was immer im »WEBROOT_DIR« liegt, lässt sich über Hiawatha abrufen.

Diese Grundkonfiguration dürfte die meisten Admins allerdings nicht sehr glücklich machen – ein paar Parameter fehlen für den Regelbetrieb vermutlich noch. So möchte man den Webserver in aller Regel nicht mit den Rechten des Systemadministrators root betreiben, sondern unter einem weniger privilegierten Nutzer-Account. Das klappt mittels »ServerId« in der Konfigurationsdatei. Über »SystemLogFile« und »GarbageLogFile« lassen sich die Log-Dateien definieren, die Hiawatha verwendet.

Virtuelle Hosts

Eines der am häufigsten genutzten Apache-Features dürften virtuelle Hosts sein. Die Idee dahinter ist, viele Webadressen auf eine IP-Adresse zeigen zu lassen. Der Webserver liefert dann anhand der aufgerufenen URL die richtige Website aus. Auch Hiawatha bietet diese Funktion, und sie ist vergleichsweise leicht einzurichten.

Zusätzlich zum bereits erwähnten »Binding«-Statement genügt der Abschnitt aus Listing 2, um in Hiawatha einen »VirtualHost« für »www.example.net« zu definieren, der PHP-Dateien ausführen kann. Wichtig: Das »TLScertFile«-Statement wandert aus dem »Binding«- in das »VirtualHost«-Statement, damit Hiawatha unterschiedliche SSL-Zertifikate für verschiedene virtuelle Hosts nutzen kann.

CGIhandler = /usr/bin/perl:pl
CGIhandler = /usr/bin/php-cgi:php
CGIhandler = /usr/bin/python:py
CGIhandler = /usr/bin/ruby:rb
CGIhandler = /usr/bin/ssi-cgi:shtml
CGIextension = cgi
FastCGIserver {
  FastCGIid = PHP7
  ConnectTo = /run/php/php7.0-fpm.sock
  Extension = php
}
VirtualHost {
  Hostname = www.example.net
  WebsiteRoot = /var/www/example.net/public
  StartFile = index.php
  AccessLogfile = /var/www/example.net/log/access.log
  ErrorLogfile = /var/www/example.net/log/error.log
  TimeForCGI = 5
  UseFastCGI = PHP7
  TLScertFile = /etc/ssl/example-net.pem
}

Sicherheitseinstellungen

Außen vor blieben in den Beispielen bisher die Sicherheits-Features und die Betrugserkennung von Hiawatha, auf die der Admin im Alltag nicht verzichten sollte. Im VirtualHost-Blob würden die folgenden Zeilen die Erkennung von Angriffen aktivieren:

PreventCSRF = yes
PreventXSS = yes
PreventSQLi= yes

Um außerdem noch das automatische Bannen von Clients zu aktivieren, packt der Admin außerhalb des »VirtualHost«-Blocks in »hiawatha.conf« noch die Zeilen aus Listing 3. In nicht einmal 50 Zeilen (Listing 4) hat der Admin so eine vollständige Konfiguration eines Webservers inklusive diverser Sicherheitsfunktionen, basiert auf einer sehr leichtfüßigen Webserveranwendung.

BanOnGarbage = 300
BanOnMaxPerIP = 60
BanOnMaxReqSize = 300
KickOnBan = yes
RebanDuringBan = yes
BanOnSQLi = 60
BanOnFlooding = 10/1:15

ServerId = www-data
ConnectionsTotal = 150
ConnectionsPerIP = 10
SystemLogfile = /var/log/hiawatha/system.log
GarbageLogfile = /var/log/hiawatha/garbage.log
Binding {
  Port = 443
  MaxRequestSize = 128
  TimeForRequest = 3,20
  SSLcertFile = hiawatha.pem
}
BanOnGarbage = 300
BanOnMaxPerIP = 60
BanOnMaxReqSize = 300
KickOnBan = yes
RebanDuringBan = yes
CGIextension = cgi
CGIhandler = /usr/bin/perl:pl
CGIhandler
 = /usr/bin/php-cgi:php
CGIhandler = /usr/bin/python:py
CGIhandler = /usr/bin/ruby:rb
CGIhandler = /usr/bin/ssi-cgi:shtml
FastCGIserver {
  FastCGIid = PHP5
  ConnectTo = 127.0.0.1:2005
  Extension = php
}
UrlToolkit {
  ToolkitID = banshee
  RequestURI isfile Return
  Match ^/(favicon.ico|robots.txt|sitemap.xml)$ Return
  Match .*\?(.*) Rewrite /index.php?$1
  Match .* Rewrite /index.php
}
Hostname = 208.77.188.166
WebsiteRoot = /var/www/hiawatha
StartFile = index.html
AccessLogfile = /var/log/hiawatha/access.log
ErrorLogfile = /var/log/hiawatha/error.log

Ideal für Container

Das Hiawatha-Beispiel lässt sich sogar noch etwas weiter spinnen: Aufgrund seiner übersichtlichen Größe ist Hiawatha auch ein guter Kandidat als Webserver im Container, der beliebige Websites anzeigen kann. Hat der Admin, wie beschrieben, ein Hiawatha-Paket gebaut, lässt sich damit auf Basis eines bestehenden Distributionsabbilds für Docker oder Podman schnell ein Hiawatha-Container-Image zaubern. Stattet der Admin es per Bind-Mount mit Zugriff auf eine Konfigurationsdatei in »/etc« des Host-Systems sowie mit Ordnern für das Ablegen von Log-Dateien aus, mutiert Hiawatha zum generisch nutzbaren Webserver-Container.

Der Vorteil: Apache oder Nginx, die entsprechende Container-Abbilder oft aufblähen, kommen nicht zum Einsatz. Hiawatha selbst hat nur ungefähr 1,5 MByte Quelltext; hinzu kommen circa 5 MByte Quelltext für die »mbedTLS«-Implementierung, die Hugo Leisink mit Hiawatha ausliefert. Das Hiawatha-Binary kann man im Hinblick auf seine Größe praktisch vernachlässigen. Weil Hiawatha zudem deutlich weniger Abhängigkeiten aufweist als Apache und Konsorten, hat der Admin es in Summe mit viel weniger losen Teilen zu tun. Das reduziert auch den administrativen Aufwand insgesamt, nicht nur jenen für den Betrieb des Webservers selbst.

Interessant für Embedded

Mindestens ebenso interessant ist Hiawatha als Webserver im Embedded-Umfeld. Zwar leiden aktuelle Raspberry-Pi-Implementierungen (Abbildung 3) nicht mehr so akut unter Defiziten hinsichtlich der CPU und des Arbeitsspeichers, es zählt hier aber noch immer jeder nicht benötigte CPU-Zyklus und jedes nicht benötigte Megabyte RAM.

Abbildung 3: Kleincomputer wie der Raspberry Pi und viele Geräte aus dem Embedded-Umfeld haben wenige Hardware-Reserven. Hier spielt Hiawatha seine Stärken voll aus. Quelle: Wikipedia

Da kommt Hiawatha sehr gelegen, und noch mehr, wenn man nicht den RasPi als Referenzplattform betreibt, sondern Hardware mit noch deutlich weniger Ressourcen (Abbildung 4). Die Sparsamkeit, mit der Hiawatha zu Werke geht, macht den Dienst für Einsätze im Embedded-Umfeld wie geschaffen.

Abbildung 4: Auch auf eingebetteten Systemen wie dem Open Source Router Turris Omnia bietet Hiawatha eine Möglichkeit, ressourcenschonend einen Webserver zu betreiben. Quelle: Turris

Fazit

Hiawatha ist ein tolles Projekt und hochinteressant für Einsatzgebiete, in denen es auf einen einfachen, gut funktionierenden Webserver mit grundlegenden Security-Features ankommt. Viele Installationen, in denen Apache, Nginx oder vergleichbar komplexe Lösungen zur Anwendung kommen, bräuchten eigentlich nur eben jene Features, die Hiawatha anbietet: Die Möglichkeit, CGI im Hintergrund aufzurufen (in der Regel für PHP), die SSL-Fähigkeit sowie virtuelle Hosts, um mehrere Websites auf einem Server zu betreiben.

Hiawatha genehmigt sich für diese Aufgabe einen deutlich kleineren Schluck aus der Ressourcen-Pulle als die Konkurrenz mit den großen Namen. Besonders in Umgebungen, in denen CPU-Zyklen und RAM nicht in im Überfluss zur Verfügung stehen, ist der Webserver deshalb sehr interessant, etwa im Embedded-Umfeld. Wer Hiawatha jedoch zu einer Quasi-Bastellösung für eingeschränkte Einsatzbereiche erklärt, tut dem Tool unrecht: Es handelt sich um einen ausgewachsenen Webserver mit einem Feature-Set, das für die meisten Anforderungen völlig ausreicht. (jcb/jlu)