Negative ServerTown Erfahrungen/Bewertung

serverdown

Das Problem, bei den Informationen die man im Web zu verschiedenen Hosting Anbietern findet, ist dass es sich oft nur um bezahlte Werbung handelt, die nichts mit realen Bewertungen durch Kunden zu tun hat. Problematisch sind auch “Erfahrungsberichte”, die sich nur auf eine “Nutzung” während einer kurzen, mehrwöchigen Probezeit stützen. (Sobald ein “Erfahrungsbericht” Aussagen enthält wie “Anbieter X ist ganz toll und hat bereits Y zufriedene Kunden”, denn ist es vermutlich sowieso nicht mehr als eine bezahlte Schleichwerbung.)

Hier darum ein kurzer Bericht bezüglich einiger höchst unerfreulicher ServerTown Erfahrungen, die ich selbst mit diesem Hoster in den letzten zwei Jahren als Kunde machen musste. Die Probleme gingen dabei meist unmittelbar auf den ServerTown Geschäftsführer zurück, d.h. es ist nicht anzunehmen dass sich daran bei dieser Firma innert nützlicher Frist irgendetwas ändern wird.

Vorab das Positive: Die Infrastruktur lief die meiste Zeit “as designed” (vgl. unten beschriebene IP-Blacklist Einschränkungen) und der eine HW Ausfall von dem meine Domain dieses Jahr betroffen war, wurde innert nützlicher Frist behoben. (Ich überwache meine Domain nicht automatisch, aber ich lese i.d.R. täglich meine Emails via Web-Interface und bemerke so zumindest, wenn dort etwas offensichtlich nicht funktioniert.)

Leider ist es der inakzeptable Umgang mit Problemen, der diesen Hoster aus meiner Sicht zu einem No-Go macht:

1) IP-Blacklist

Die von diesem Hoster verwendete IP-Blacklist ist aus meiner Kunden-/Benutzersicht eine absolute Zumutung: Sobald irgendeine Seite ein nicht existierendes File referenziert (d.h. 404-Fehler: z.B. ein in einem Seiten-Template referenziertes *.gif – was bei gratis WorkPress oder Joomla Komponenten schon mal vorkommt; oder wenn der Benutzer im Browser die “console” geöffnet hat, was den Browser u.U. veranlasst nach zusätzlichen Files mit “debug” Informationen zu suchen – die auf einem produktiven Server i.d.R. nicht deployed werden), dann wird der Benutzer nach dem dritten 404-Fehler (d.h. dem dritten Klick in der entsprechenden Seiten-Navigation) komplett blockiert, d.h. KEINE der gehosteten Seiten ist dann für ihn mehr erreichbar.

Als Kunde passierte mir dies wiederholt in den Admin-Komponenten entsprechender Joomla- und WordPress-Erweiterungen und in der Situation kann man dann nicht mal mehr sein Webmail benutzen um den Support zu kontaktieren, da man dort genauso blockiert wird. Auf der entsprechenden Selbstbedienungs-Freischalt-Seite wird die Sperrung übrigens erst ca. 30 Minuten später überhaupt ausgewiesen, d.h. solange muss man u.U. (ausserhalb der Telefon-Support Zeiten) warten, bevor man sich auf seiner eigenen Domain wieder freischalten kann. Das Problem ist seit langem bekannt, aber mit fadenscheinigen “Security Argumenten” stellt ServerTown hier seine eigene Bequemlichkeit anscheinend über die Bedürfnisse seiner Kunden.

2) inakzeptable “support attitude”

Beispiel 1: “Kostenlose SSL Zertifikate”

Der ServerTown wirbt bei seinem entsprechenden Produkt “Webhosting Easy” explizit mit “Kostenlose SSL Zertifikate”, für die der Kunde auf die “Let’s Encrypt” Erweiterung des Admin-UIs (Plesk) verwiesen wird. Einmal eingerichtet, sorgt diese Infrastruktur normalerweise dafür, dass auslaufende Zertifikate (d.h. alle 2-3 Monate) automatisch durch neue ersetzt werden. Als Kunde hat man hier keinen direkten Administratoren-Zugriff auf die Konfigurations-Dateien (soll heissen, als Kunde kann man die Web-Server Konfiguration nicht manuell zerschiessen – und das ist auch gut so) , sondern ist auf die von ServerTown bereitgestellte, Plesk basierte Funktionalität angewiesen.

Das hat bei meiner Domain seit 2017 auch ca 2 Jahre lang problemlos funktioniert. Bis dann am 23. November 2019 der entsprechende ServerTown-Automatismus zwar ein neues Zertifikat bei “Let’s Encrypt” bezog (wie ich dem Support mit den entsprechenden “Lets encrypt” Logs nachgewiesen hatte), dieses aber nicht mehr installierte (mir als Kunden fiel das erst am 23. Dezember auf, nachdem der https Zugriff auf meine Domain wegen des noch immer verwendeten, abgelaufenen, vorletzten Zertifikates nicht mehr funktionierte). Ich versuchte daraufhin manuell (via Plesk) die Aktualisierung des “Lets encrypt” Zertifikates auszulösen. In Plesk schien diese Aktion auch “erfolgreich” durchgeführt zu werden (d.h. keinerlei Fehlermeldungen und das im Plesk angezeigte Zertifikat war tatsächlich neu), verwendet wurde allerdings auch dieses neue Zertifikat von der Domain nicht.

Auf die Support-Anfrage (und noch 10 weitere Emails!) reagierte ServerTown mit kompletter Verweigerung. Orignalton ServerTown Support: “Wenn lets encrypt ein Problem macht kann ich Ihnen nicht helfen denn Lets encrypt ist ein Kostenlos Plugin was von Plesk angeboten wird. Lets encrypt macht häufig Probleme wie man problemlos im Internet nachlesen kann.”.

Nachtrag: Gemäss einer mir inzwischen vorliegenden Richtigstellung von ServerTown wurde die mir als Kunden ursprünglich am 22. November 2019 angekündigte “Migration aller Server auf die Neuste Plesk Version” erst zwei Monate später am 4. Februar 2020 tatsächlich durchgeführt: Es muss darum wohl eine andere Ursache für das geben, was ServerTown schlussendlich eine “aufgehängte Config” nannte (vgl. unten) und das auffällige Zusammentreffen der Ankündigung des Updates und dem Problem genau einen Tag später mag tatsächlich nicht mehr als ein Zufall sein. 

Erkenntnis: ServerTown ist bei Problemen offenbar nicht wirklich gewillt, die beworbene “Kostenlose SSL Zertifikate” Leistung tatsächlich zu gewährleisten: Als Kunde ist man, wenn sich wie in diesem Fall die ServerTown-seitige Server-Config “aufgehängt” hat, dann nicht nur komplett auf sich alleine gestellt, sondern mangels der notwendigen Zugriffsrechte ist man überhaupt nicht in der Lage die Verantwortung selbst zu übernehmen, die ServerTown einem hier frech in die Schuhe zu schieben versucht. Als einzige “Lösung” wurde mir zu dem Zeitpunkt nahe gelegt, doch auf eines der von ServerTown angebotenen Bezahl-Zertifikate umzusteigen (ein Schelm der Böses dabei denkt). 

Erst nach 4 Tagen(!) und meiner letzten/extrem ungehaltenen Email hat sich der ServerTown Support erstmalig tatsächlich mit dem Problem befasst – wenn auch wohl nur mit dem Ziel “mir zu beweisen, dass sowieso alles mein Fehler ist”. Der Support legte dazu eine zusätzliche “Test” Sub-Domain an, für die er erfolgreich ein neues Zertifikat einrichtete. Die entsprechenden Anpassungen führten aber interessanterweise auch dazu, dass das von mir 4 Tage zuvor manuell, erfolglos für meine Domain via Plesk installierte Zertifikat jetzt erstmals ebenfalls korrekt verwendet wurde. Auf meine Frage, was für Anpassungen zu dieser wunderbaren Verbesserung geführt haben, erhielt ich folgende Antwort: “Ich habe nur die Subdomain erstellt… Kann sein das sich bei Ihnen eine Config aufgehängt hat die dann auch neu erstellt wurde…”

Erläuterung Server-Config: Als ServerTown Kunde hatte ich vor Jahren initial via Plesk die Einstellungen für meine Domain wothke.ch erstellt und aufgrund meiner dazumaligen Admin-GUI Einstellungen wurde ServerTown-seitig eine entsprechende Web-Server Config generiert – die dem Web-Server unter anderem sagt, welches SSL Zertifikat er für meine Domain verwenden soll, welche Datenbanken es gibt, welche PHP Version benutzt werden soll, in welchem Verzeichnis er nach den “Dokumenten” für diese Domain suchen soll, etc. D.h. der Kunde spezifiziert via Admin-GUI bestimmte Web-Server Eckdaten und die ServerTown Infrastruktur generiert daraus eine hoffentlich funktionstüchtige Web-Server Config.

Das was Hoster mitunter die “Web-Seite des Kunden” bzw. deren Programmierung nennt, hat nur marginal mit der Server-Config zu tun (vgl. DB, PHP, etc Einstellungen die via Plesk zugänglich sind), sondern bewegt sich primär im entsprechenden “Verzeichnis mit den Dokumenten” bzw. im Inhalt der Datenbanken. Eine “aufgehängte” Server-Config wie hier ist gänzlich ausserhalb dessen, was ein Kunde “programmiert”, sondern es ist das was die Hoster-Infrastruktur allenfalls falsch generiert oder geladen hat.

Ich habe keinen Einblick darin, wie/wann ServerTown die entsprechende Server Config generiert und allenfalls aktualisiert – die automatische/periodische Aktualisierung der SSL Zertifikate ist jedenfalls ein deutliches Indiz dafür, dass es ServerTown/Plesk-seitige Mechanismen gibt, welche die Server Config – ohne Zutun des Kunden – periodisch verändern.

Die generierte Web-Server Config war ursprünglich OK und hat bei meiner Domain ca. 2 Jahre lang funktioniert bevor sie sich – ohne dass ich in den vorangehenden Monaten irgendwelche Änderungen im Admin-GUI gemacht hätte – anscheinend um den 23. November herum spontan “aufhängte” und einen Monat lang in diesem Zustand blieb. Im Admin-GUI war für mich als Kunden zu diesem Zeitpunkt nicht zu erkennen, dass sich die ServerTown-seitige Server Config aufgehängt hatte und ich hatte im entsprechenden Plesk-GUI auch keine Funktion gefunden die man zur Reparatur einer “aufgehängten” Server-Config benutzen könnte. Anscheinend ist bei der von ServerTown benutzten Infrastruktur das Anlegen einer zusätzlichen “Test” Sub-Domain ein Workaround, mit dessen Hilfe ein Update der Server-Config angestossen werden kann. Dass nach Verwendung dieses Hacks das Problem einer “aufgehängten Config” auch bei der regulären Domain verschwindet, zeigt primär dass die entsprechenden von Kunden definierten Domain-Einstellungen (d.h. die “Programmierung” des Kunden) nicht das Problem waren und ohne ServerTown-Support braucht sich ein Kunde wohl nicht vorzuwerfen, dass er diesen Hack nicht kennt.

Fazit: Auslöser des Problems war wohl eine korrumpierte Konfiguration auf Seiten des Hosters ServerTown (auf die man als Kunde keinen direkten Zugriff hat und die nicht durch eine Kundeninteraktion ausgelöst wurde). Es war wohl kein Fehler des Kunden und auch kein Fehler der vom ServerTown Support reflexartig beschuldigten “Lets encrypt” Infrastruktur und es hat ganze 4 Tage (und 11 frustrierte Kunden-Emails) gedauert, bis der ServerTown Geschäftsführer/Support dies “als Möglichkeit” schlussendlich eingeräumt und das Problem (wohl eher unbeabsichtigt) behoben hat.

Beispiel 2: “WebServer Fehlfunktion”

Rechtzeitig vor dem neuen Jahr und direkt im Anschluss an das obige Problem, hat mir ServerTown gleich nochmal ein weiteres Beispiel zum Thema Support geliefert: Ich habe seit langem keinerlei Anpassungen mehr an meinen Web-Seiten gemacht und es gibt entsprechend keinen Grund dass sich an der bestehenden Funktionalität spontan irgendetwas ändern sollte. Am 28.12. hatte ich mittags noch problemlos meine “webmail” Sub-Domain (Teil der von ServerTown bereitgestellten Infrastruktur) benutzt, doch als ich abends nochmal Mails checken wollte, erschien statt des gewohnten “Horde” Logins plötzlich nur eine mir bis dato unbekannte “Plesk Template Seite” (wohl eine Art von “Platzhalter-Web-Seite” die Plesk beim Anlegen einer neuen Sub-Domain generieren würde). Doch nicht nur die “webmail” Seite war weg, sondern auch mein gesamter Web-Auftritt. Egal ob mit Firefox oder Chrome, egal auf welche Folder meiner Domain ich zuzugreifen versuchte, ServerTown lieferte nur noch dasselbe “Plesk Template”. Beim Zugriff auf spezifische Files meldete der Browser 404-er Fehler (obschon meine Überprüfung per FTP zeigte, dass alle entsprechenden Files noch an ihrem Platz waren). Das Problem hielt ca. 3-4h an (in denen ich meine Zeit mit dem Versuch verschwendete herauszufinden was los war, bzw von ServerTown irgendwelche Unterstützung zu erfahren), bevor es genauso spontan verschwand wie es aufgetaucht war.

Ich hatte nach dem ersten Auftreten der Störung den ServerTown Support angeschrieben und hatte später auch das mysteriöse Verschwinden der Störung gemeldet.

Trotz meiner vorherigen schlechten Erfahrungen mit dem ServerTown Support (der erst 2 Tage zuvor die Möglichkeit einer “korrupten/aufgehängten Web-Server Konfiguration” eingeräumt hatte!), erstaunte mich dessen Antwort auch dieses Mal aufs Neue: “Bitte eröffnen Sie keine unnötigen Tickets wenn Sie PC Probleme haben.. Gerne werden wir jedes weitere Ticket nach AGB in Rechnung stellen.” Bei soviel Hilfsbereitschaft wird einem doch gleich ganz warm ums Herz…

Alles klar, es sind “PC Probleme” wenn der Browser vom ServerTown Server falsche Daten geschickt bekommt (der PC bildet sich die Plesk Seiten mit dem ServerTown Logo vermutlich nur ein)… Logisch, dass “PC Probleme” genau eine Domain betreffen und alle anderen Web-Seiten zu dem Zeitpunkt problemlos funktionieren… Logisch, dass diese “PC Probleme” spontan verschwinden, ohne dass auch nur der Browser neu gestartet worden wäre. Dass dieses Problem auftrat nachdem ServerTown nur 2 Tage zuvor eine “aufgehängte” Config seines Servers eingeräumt hatte, ist sicher nur reiner Zufall…  Ich denke da braucht man nicht mehr dazu zu sagen und nachdem die wirkliche Ursache für all die Probleme – soweit ich informiert bin – von ServerTown bisher nicht mal untersucht wird, ist es wohl nur eine Frage der Zeit, bis das nächste Symptom zuschlägt.

Wie man bei entsprechenden Hoster-Vergleich Kommentaren sieht (vgl. z.B.: https://www.marchionni.ch/webhosting-vergleich/) bin ich anscheinend nicht der einzige der mit dem ServerTown Support unzufrieden ist).

Ich werde den laufenden Vertrag bei diesem Anbieter wohl vorzeitig abbrechen und kann nur dringend empfehlen, sich von diesem Anbieter fern zu halten!