Grundanforderungen an Webhosting

Worauf achten beim Webhosting? Wer sich heutzutage eine Internetpräsenz einrichtet, stellt an den gemieteten Webhoster - egal ob kostenlos, kostengünstig oder teuer - gewisse technische Anforderungen. Viele Anforderungen sind bei professionellen Seiten bereits Standard und könnten sehr leicht für Kunden umgesetzt werden. Das ist bei den meisten Webhosting-Anbietern aber selten der Fall.

Da ich als Informatiker auch inzwischen einen gewissen Standard erreicht habe, möchte ich meine Anforderungen an ein gutes Webspace-Angebot im folgenden darlegen. Die Liste ist erschreckend lang, erhebt dafür aber einen kleinen Anspruch auf relative Vollständigkeit. Die Anforderungen an Webhosting werden sich im Laufe der Zeit ändern. Dennoch hat sich inzwischen eine recht lange Liste ergeben.

Technische Grundlagen

Betriebssystem

Für mich läuft ein Webspace-Angebot ausschließlich auf Linux, oder ausnahmsweise mal auf anderen Unixoiden Systemen (etwa OpenBSD/FreeBSD). Der Vorteil gegenüber einem Windows ist die Leichtigkeit, administrative Aufgaben flexibel zu erledigen. Das beginnt beim Login, welches dank PAM sehr einfach zusätzlich mit SSH-Keys, One Time Passwörtern oder anderen Token gesichert werden kann.

Shell-Zugang

Es setzt sich über die besonders einfache Konfiguration per Shell fort. Sei es eine Datei, die mit wenigen Tastatureingaben mit alten Versionen oder anderen Verzeichnissen verglichen und angepasst ist - ganz ohne grafische Bentuzeroberfläche. Oder das Kopieren von Dateien von einem auf einen anderen Server. Die Shell ist einfach nicht zu ersetzen.

Möchte ich eine Webanwendung installieren, lade ich per wget oder Curl das Archiv herunter und entpacke es. Das ist wesentlich schneller als ein Upload der entpackten Dateien per FTP.  Zudem ist es sicherer, da einige FTP-Tools leere Verzeichnisse auslassen oder Probleme mit der Zeichenkodierung haben könnten. Arbeitet man aber direkt auf dem Zielsystem, ist man von solchen Problemen nicht betroffen.

Shell-Software

Auf dem Webhosting-Server sollte durchaus Software verfügbar sein, die man ab und zu mal braucht. Dazu gehört für mich eine Basisausstattung, die das Installieren, Pflegen und Updaten von Webanwendungen unterstützt bzw. vereinfacht. Aus der folgenden Liste sind einige Anwendungen Pflicht oder zumindest extrem hilfreich.

• 

  Guter Hoster: Shell mit Prozessen

  htop (optional) Prozessanzeige, um Auslastung des Servers durch eigenes Konto gut beurteilen zu können. Ersatz für top.

• GNU screen Ein Terminalmultiplexer, der also mehrere Terminalfenster erlaubt und nebenbei auch SSH-Sitzungen erhält.
• drush (Drupal Shell) Ermöglicht Updates der Websoftware Drupal aus der Shell heraus. Das spart nicht nur Zeit, sondern ist auch sicherer. Hintergrund: PHP-Prozesslimits werden nicht so schnell erreicht, und die ausgereifte Prüfung ist nicht auf die GUI angewiesen.
• wget, curl, tar, bzip2, etc. Tools, um Archive herunterzuladen, zu entpacken etc. - für Webhosting mit Shell-Zugriff unerlässlich.
• mail, mutt (Mail-Clients) Mutt ist wohl der de-facto-Standard, wenn es um Mailclients auf der Linux-Shell geht. Er ist prima geeignet, wenn man seine Mails einmal ohne Webinterface gegenlesen möchte.
• Midnight Commander (Dateimanager) Selten verwendet, aber manchmal doch praktisch: Der Midnight Commander. Beim Webhosting praktisch, um Dateien zu übertragen oder zu verschieben.
• ImageMagick (Grafikbearbeitung) Grafikbearbeitung auf einer Shell? Das ist kein Widerspruch, denn IM arbeitet vollständig Konsolenbasiert. Mit diesem Tool lassen sich Grafiken und Bilder schnell vergrößern, verkleinern, beschneiden, etc.
• GnuPG (Verschlüsselung, Kryptografie) Unerlässlich zur Verifikation von Archiven oder zur sicheren Kommunikation: GnuPG. Auch wenn man seinen primären privaten Schlüssel nicht bei einem Share-Hoster vorhalten sollte, bieten sich doch viele intelligente Anwendungsmöglichkeiten mit dem GNU Privacy Guard.
• OptiPNG (PNG-Kompression) Für mich unerlässlich - alle PNGs noch einmal komprimieren. Von Zeit zu Zeit sammelt sich eine Reihe unkompremierter PNG-Dateien, die mit OptiPNG noch etwas auf Platz getrimmt werden können - ohne Qualitätsverlust natürlich.
• Git (Versionsverwaltung) Eigentlich unerlässlich: GIT zur Versionsverwaltung. Nicht nur, dass man so seinen eigenen Versionierungsserver betrieben kann -- man kann z.B. auch mit Leichtigkeit Plugins seiner Webanwendung aus github-Repositories einspielen. Damit kann man sein Webhosting auch als Versions-Hosting verwenden.

Cronjobs für Webhosting

Ist der Shell-zugriff nicht weiter eingeschränkt, hab man über den Befehl crontab -e  auch Zugriff auf Cronjobs. Diese sind nicht durch technische Maßnahmen beschränkt, sondern es lassen sich - im guten Vertrauen - unendlich viele Cronjobs anlegen. Benutzt ein WebHoster etwa Plesk (ehem. Confixx), so ist der Shellzugang üblicherweise verstümmelt. Cronjobs lassen sich dann nur im Webinterface anlegen, wobei man oft eine gewisse Flexibilität verliert. Dazu gehört auch das Vergleichen oder Übertragen der Crontab per Shell.

Conrjobs sind heute bei vielen Webanwendungen unerlässlich - seien es geplante Posts bei Wordpress oder auch regelmäßige Updates inkl. Mailversand. Die Updates im RSS-Reader gehören aber auch genauso dazu wie bei Piwik die Generierung der Statistiken. So oder so: Ohne Cronjobs geht Webhosting nicht mehr. Und davon braucht man schnell mal mehrere.

Während einige Anbieter die Anzahl der Cronjobs noch beschränken, bieten andere für Webhosting wiederum schon mächtigere Alternativen wie runwhen an.

PHP-Einstellungen verändern

Ein absolutes No-Go bei den »üblichen Verdächtigen« ist das Verändern von PHP-Einstellungen. Diese werden in den Dateien .htaccess  oder .user.ini  ignoriert, sofern diese Dateien überhaupt etwas bewirken. Aber gerade diese Einstellungen können für anspruchvolles Webhosting wichtig sein. So lief das Update auf Wordpress 3.7.0 erst nach Erhöhung der PHP max_execution_time  auf 120 Sekunden(!) fehlerfrei durch.

Solche Skripte bieten natürlich das Potential,  das shared Hosting empfindlich zu stören. Ein gut angelegtes Hosting kommt damit auch ausnahmsweise mal klar. Diese Einstellungeng lassen sich auch auslesen, um einen User - treibt er es mal zu weit - gezielt darauf anzusprechen. Das ist immer noch ein besserer Weg, als diese Werte von vornherein auf ein unangemessen geringes Niveau zu reduzieren.

PHP per FCGI mit suExec

Übliche Webhoster lassen PHP über das Apache-Modul mod_php  laufen. Das mag für einzelne Benutzer in Ordnung sein. Da aber PHP-Skripte nun als Apache-User ausgeführt werden, lassen sich auch Verzeichnisse anderer User auslesen! Das lässt sich zwar mit mod_suphp  umgehen, ist aber durch die dauernden Interpreteraufrufe unerträglich langsam. Zudem verhinden diese beiden Varianten das schnelle und moderne Threading-Modell des Apache 2.

Zudem erlaubt es den einfachen Einsatz verschiedener PHP-Versionen. Wer also einmal eine ältere Web-Anwendung nutzen möchte, kann für diese recht einfach eine andere PHP-Version nutzen. Diese Einstellung lässt sich entweder per Webinterface oder per Shell/Konfigurationsdatei ändern. Als Gültigkeitsbereich entweder pro VHost, oder pro Account.

IPv6 für alle!

Nicht unwesentlich ist auch der Punkt der IPv6-Anbindung. Während mancherorts die IPv4-Adressen bereits ausgegangen sind, wird in Deutschland oft nur IPv4 angeboten. Da IPv6 in naher Zukunft aber auch bei Heimgeräten verfügbar sein wird, darf man diese Anforderung auch gerne an den Webspace stellen.

Der Webspace sollte über mindestens eine IPv6-Adresse verfügbar sein. Idealerweise sollte jede Domain (bzw.: jeder VHost) eine eigene IPv6-Adresse besitzen. Webhosting mit einer IPv6 hat zudem den Vorteil, dass man einen minimalen Pluspunkt im Google-Ranking erhält, so ein Gerückh.

Sicherheit und Freiheit

Konfiguration des DNS

Viele Hoster erlauben es nicht, fremdgehostete Domains aufzuschalten. Ich selbst hoste meine Domains bei Inwx, um bei der Wahl des Webspaceanbieters unabhängig zu bleiben. Ich kann also den Webspaceanbieter ausfallsfrei wechseln, in dem ich einfach an den Ressource-Records (Typ A, AAAA und CNAME) Änderungen vornehme.

Zudem erlaubt es dem Anwender, die Mails an beliebige Anbieter zuzustellen. Die sogenannten MX-Records geben das Ziel für E-Mails an. Auch hier muss der Anbieter des Webspaces nicht derjenige sein, über den die E-Mails abgewickelt werden.

Auch weitere Freiheiten werden oftmals verwehrt. So sind oft die Anzahl der Subdomains begrenzt, oder nur gegen Aufpreis erweiterbar. Technisch gesehen ist das Geldschinderei: Für eine Subdomain werden lediglich ein paar Zeilen Text in diversen Konfigurationsdateien angelegt. Die Tatsache, dass das alles automatisiert passiert, unterstreicht die Unterstellung nur.

Mailkonfiguration

Komplexe Mailkonfigurationen lassen sich über diverse Interfaces nicht abbilden. Flexibler sind hier .courier oder .qmail-Dateien, mit dem für jede einzelne Adresse bestimmt werden kann, ob sie ein Alias ist, die E-Mails weitergeleitet werden, der Spamfilter aktiv ist, oder auch eigenständige Postfächer sind.

Auch wichtig ist die Anbindung an Antispam-Software, wie etwa SpamAssassin. Ist diese ungünstig eingestellt, werden einige E-Mails möglicherweise nicht angenommen. Ist diese zu lasch eingestellt, kommt zu viel Spam durch. Viele Sharehoster bieten oftmals gar keinen Spamfilter an, um sich die Konfiguration zu sparen. Damit spart der Webhoster auch am Support, da garantiert jede E-Mail zugestellt wird.

Mailkonfiguration ist eine weitaus komplexere Angelegenheit, als ich in diesen zwei, drei Absätzen geschrieben habe. Dennoch werden oftmals gerade auf den ersten Metern - also bei grundlegenden Konfigurationsschritten - fundamentale Fehler begangen. Das ist besonders ärgerlich, da man so schnell auf Spamlisten landet. Diese Webhoster sind also für professionelles bzw. anspruchsvolles Webhosting schnell ungeeignet.

(Fast) beliebige Prozesse starten

An der oben aufgezählten Software merkt man schon: Es lassen sich bereits viele Prozesse starten. Auf einem guten Sharehoster lassen sich auch weitere Prozesse und sogar Daemons (Hintergrunddienste) starten. Damit werden Anwendungen möglich, die zuvor auf einem Sharehoster nicht abbildbar erschienen:

• Offen bleibende, gespeicherte SSH-Sitzungen via Screen
• Kleine Serverdienste, etwa ein eigener Tomcat oder andere Application-Server
• IRC-Bouncer, Video-Server, Fernzugänge etc.

Natürlich ist ein Sharehoster in erster Linie auf Webhosting ausgelegt. Daher sollte man darauf achten, nicht übermäßig viel Ressourcen zu belegen. Ansonsten könnte sich die Anschaffung eines eigenen VServers lohnen.

Bei einem guten Hoster wird man auf diesen Umstand zunächst aufmerksam gemacht, bevor der Accout stillgelegt wird. Auch im Zweifelsfall sollte immer nur der entsprechende Teil des Accounts deaktiviert werden - also möglicherweise nur ein Prozess bzw. eine Binary verschoben werden. Andere Webhosting-Anbieter gehen hier oft weniger feinfühlig vor und sperren gleich das gesamte Benutzerkonto.

Aktuelle Software

Egal ob PHP, der Apache Webserver, Bibliotheken oder der SSH-Daemon: Software muss für Webhosting aktuell sein. Halbwegs zumindest - und das heißt nicht älter als ein Jahr, maximal zwei nach Erscheinen. Der Grund ist, dass sich das Web rasant weiterentwickelt. Sei es, dass Wordpress inzwischen PHP 5.2.4 benötigt (Supportende übrigens 2011, erschienen 2008) oder Veränderungen in verschiedenen Protokollen - https mit SSLv2 und SSLv3, Zertifikate (z.B. per SNI). Auch Perfect Forward Secrecy ist spätestens seit der NSA-Affähre ein Thema für jeden Internetnutzer.

Auch kryptografische Bibliotheken weisen von Zeit zu Zeit Schwachstellen auf. Auch diese Lücken machen sich Angreifer zu Nutze. Das Ausspähen von Daten oder der Aufbau eines Botnets könnten die Folge sein. Das möchte man weder als Hoster, Anwendungsbetreiber oder Endbenutzer.

In den allerwenigsten Fällen kann man die installierte Software überprüfen. Viele Provider verweigern den Zugriff auf den Paketmanager. Wenn doch stellt sich oft schreckliches heraus - nicht jeder Provider für Webhosting wie auf dem Bildschirmfoto hat aktuelle Software installiert.

SNI für viele Zertifikate

Eine großartige Technik ist SNI - Server Name Indication bei SSL. Damit ist es dem normalen Benutzer möglich, ohne den Zukauf bzw. die Zumietung von IP-Adressen mehrere kryptografische Zertifikate für seine Webanwendungen (genauer: unterschiedliche Domains) zu nutzen. Die Kostenersparnis beim Webhosting ist immens.

SNI existiert seit etwa 2003 als Spezifikation und wird von vielen Browsern seit langem Unterstützt. Dazu gehören lt. Wikipedia:

• Mozilla Firefox 2.0 erschienen ca. Oktober 2006.
• Google Chrome, erste Version erschienen September 2008.
• Internet Explorer 7 erschienen Oktober 2006 aus unerfindlichen Gründen SNI nicht unter Windows XP.
• Google Android 4.0 erschienen 2011.
• Apple iOS 4 erschienen 2010.

Gut, das Problem ist in diesem Fall Android. Da der Browser Mozilla Firefox aber bereits 2006 sehr viele Benutzer zu verzeichnen hatte, kann diese Technik seit spätestens 2008 bedenkenlos eingesetzt werden. Hinzu kommt, dass die geforderte Internetseite durch fehlende SNI-Unterstützung nicht unerreichbar wird - es wird lediglich das falsche Zertifikat übertragen.

Da sichere Verbindungen (HTTPS) im Zeitalter von PRISM und Datensicherheit quasi ein Muss geworden sind, möchte ich auf dieses Feature nicht mehr verzichten. Es ist daher auch eine Anforderung beim Webhosting, auf die man achten muss.

Eigene Zertifikate nutzbar

Einige Anbieter weigern sich, beliebige Zertifkate einzuspielen. Diese bieten lediglich an, für teures Geld ein Zertifikat von einem der großen Certification Authorities (CAs) zu kaufen. Die Preise gehen mitunter in den mittleren dreistelligen Bereich.

Das ist nicht nur unwirtschaftlich, sondern grenzt auch an Abzocke. Für die Anwendungsfälle der meisten Benutzer genügt es völlig, ein kostenloses Zertifikat von CACert oder StartSSL zu nutzen. Daneben lassen sich gegen eine Jahresgebühr von derzeit € 60,- auch beliebig viele Class 2-Zertifikate erstellen. Das ist für die meisten Benutzer schon mehr, als erforderlich. Umso mehr wird aber ersichtlich, wie unnötig teuer die Zwangszertfikate einiger Provider sind.

In der Köngisklasse spielt ein Provider, wenn…

• … wenn das Zertifikat sehr leicht einzuspielen ist.
• … wenn der CSR automatisch generiert wird.
• … wenn eine Anzeige des Ablaufdatums erfolgt.
• … wenn eine Benachrichtigung zum Ablauf erfolgt.

Backups der Webhosting-Daten

Backups sind toll, vor allem, wenn man sich nicht selbst darum kümmern muss! Der Webspaceanbieter sollte alle Dateien aus dem Userverzeichnis sichern. Liegen die Dateien vom Webspace an anderer Stelle, natürlich ebenso diese. Das Backup sollte zumindest für den Fall eines Serverausfalls kostenlos sein und vom Betreiber wieder eingespielt werden.

Dienstleistung

Keine versteckten Kosten

Von den genannten Anforderungen erfüllen einige Provider doch recht viele. Oftmals ist es die Shell, die fehlt. Manchmal, aber eher selten, ist auch SNI verfügbar. Fremdregistrierte Domains sind fast überall aufschaltbar. Aber genau dort liegt der Haken: Bei einigen Providern steht in einem sehr schwer zugänglichen Preis- und Leistungsverzeichnis: Diese Funktion kostet extra. Warum? Technisch gesehen ist das nicht zu beantworten - der Konfigurationsaufwand ist sogar geringer als bei "intern" registrierten Domains, da die Ressource Records im DNS nicht gesetzt werden müssen.

Eine weitere Frechheit ereilte mich beim Anbieter Evanzo vor vielen Jahren. Dort wurde der Server plötzlich sehr langsam - entweder durch zu viele Kunden auf dem Server, oder weil mein Konto auf einen anderen Server verlegt wurde. Die genaue Ursache kenne ich nicht. Statt nun jedoch die Ursache zu prüfen, wurde mir lediglich angeboten, gegen Zahlung einer Jahresgebühr auf einen anderen Server zu wechseln. Es folgte selbstverständlich die Kündigung bei Levanzo.

Ein ähnlicher Fall ereilte mich bei Greatnet und auch bei Evanzo.Dort wurde mein Account gehackt - der Angreifer erlangte Root-Zugriff. Es war mir als Nutzer nicht mehr möglich, die Index-Files zu löschen, auch diverse Ordner blieben im Webspace. Da dieses - wie geschrieben - mit root-Rechten geschah, konnte das unmöglich durch mein Benutzerkonto verursacht sein. Bei beiden Hostern war man - zumindest damals - anderer Ansicht. Ich möge bitte besser auf mein Kennwort aufpassen. Das beide Anbieter auch heute noch nur unverschlüsseltes FTP anbieten, lässt die Forderung nur wie ein Hohn wirken. Es folgte folgerichtig die Kündigung.

Keine falschen Versprechungen

Bei einigen Anbietern wird damit geworben, dass pro Host maximal n Kunden angelegt werden. Das ist reine Augenwischerei. Zum einen lässt sich ein Server beliebig klein oder groß skalieren, damit die Gewinnmarge auf Kosten der Performance beliebig vergrößert oder verkleinert werden kann. Zum anderen ist die Performance des Webspaces neben der Hardware auch vom Nutzungsverhalten aller User, sowie von der Serverkonfiguration abhängig.

Oben habe ich über FastCGI geschrieben. FastCGI hat längere Startzeiten, ist aber sicher und sehr schnell. Den Konfigurationsaufwand scheuen allerdings viele Administratoren. Leider. Webhosting profitiert aber immens von diesem Setup, weshalb man durchaus auf diesen Punkt achten sollte.

Zahlungs- und Kündigungsintervalle

Üblich ist bei Webhosting ein Zahlungs- und Vertragsintervall von zwölf 12 Monaten im Vorraus. Bei 12 Monaten handelt es sich um einen überschaubaren, aber doch sehr langen Zeitraum. Wählt man auf Grund diverser Mängel einen anderen Anbieter, so muss man für die bisherige Dienstleistung noch weiterzahlen, bis der Vertrag ausgelaufen ist.

Ein guter Hoster hat ohne Aufpreis mindestens eine vierwöchige Kündigungsfrist zum nächsten Quartalsende, teilweise aber auch eine zweiwöchige Kündigungsfrist zum Monatsende. Ein möglicher Testzeitraum des Webhostings von bis zu einem Monat sollte nicht berechnet werden.

Suppport per Mail und mit PGP

Was viele fortgeschrittene Benutzer an speziellen Hostern schätzen ist der Support. Wichtig sind schnelle Antwortzeiten von weit unter zwei Tagen, bei Bedarf auch telefonisch. Auch gewisse Services, wie etwa Update-Dienstleistungen oder ähnliches sollte zumindest gegen Bezahlung erhältlich sein.

Des weiteren ist GnuPG fast schon eine Mindestanforderungen an den Support, spätestens wenn man Aufträge einreicht. Nur so lässt sich verifizieren, dass die vorliegende Mail auch ein echter Kundenauftrag an des Webhosting ist.

Backups

Man kann es nicht oft genug erwähnen!  :-D Regelmäßige Backups sind das Credo eines jeden Informatikers. Es sollte natürlich keine versteckten Kosten enthalten, darf aber durchaus bei erweiterten Anforderungen gegen Gebühr verfeinert werden.

Besonders praktisch beim Webhosting ist es, wenn die Backups auf dem gleichen Server zu finden sind (z.B. per SAN/NAS eingebunden). Somit hat man immer schnellen Zugriff auf einzelne Dateien und kann diese per rsync/cp einfach zurückkopieren. Diesen Service bieten aber leider die wenigsten Anbieter.

Fazit

Anforderungen an Webhoster bzw. das Webhosting sind umfangreich und nicht einfach umzusetzen. Dennoch gibt es einige Hoster, die sich auf genau diese Nische spezialisiert haben. Wenn der Markt funktioniert, gehen demnächst größere Hoster trotz ihrer Werbung baden. Leider funktioniert der Markt erfahrungsgemäß nicht besonders gut, so dass die großen Platzhirsche wohl eher noch ein Weilchen ihre - aus meiner Sicht unangemessenen - Konditionen für Webhosting anbieten werden.

Nichtsdestotrotz gibt es bereits jetzt bezahlbare, technisch hochentwickelte Alternativen. In meinem Blog habe ich diese bereits mehrmals erwähnt. Wer noch weitere Kriterien hat, darf sie gerne als Kommentar hinterlassen - ich freue mich sehr darüber, diese Liste zu erweitern.