Vor Jahren war der Shared Hosting-Anbieter Cyon ein Lichtlein am Horizont — klasse Design, einfach zu bedienende Admin-Oberfläche ohne irgendwelchen Schnick-Schnack.
In den letzten Monaten hat der Anbieter bei mir leider viel Goodwill eingebüsst; es scheint, als passe Cyon bald im Monatsrhythmus seine Infrastruktur an, und der Leidtragende ist der Kunde:
- Web Application Firewall. Unter dem Motto „Wir machen Web-Hosting noch sicherer!“ wurde primär einfach mal mein auf PHP und MySQL basierendes Site Management Tool zerschossen, welches seit bald 15 Jahren bei unzähligen Hostern produktiv läuft (und von mir auch regelmässig angepasst wird). PHP-Code darf nun nicht mehr per HTTP POST übermittelt werden, denn das sei grundsätzlich einmal ein Sicherheitsrisiko. Und überhaupt. Was zur Folge hat, dass meine Daten sowie diejenigen meiner betroffenen Kunden auf einen anderen Web-Server gezügelt werden mussten, welcher von einer nicht so paranoiden WAF abgeschirmt wird.
- Lüpfen ohne Vorwarnung oder Testsystem. Ungefähr jedes halbes Jahr lüpft der Anbieter über Nacht die PHP-Standardversion. Finde ich im Grunde Klasse und äusserst fürsorglich. Wenn dann die Sysadmins dort wenigstens ein wenig Hirn walten lassen würden und meine für Cyon adaptierte php.ini ebenfalls von Version zu Version portieren würden. Aber nein, bei jedem PHP-Upgrade kriegt man eine liebevoll von Cyon vorbereite php.ini vorgesetzt, welche natürlich alle selber vorgenommenen Spezialeinstellungen nicht enthält. Ohne irgendwelche Vorwarnung, teilweise um 10 Uhr morgens. Dann heisst es auf der Arbeit, alles liegen und stehen lassen, irgendwie per SSH Verbindung zum Web-Server aufnehmen und die zerschossene php.ini mit einer Sicherheitskopie überschreiben. Dasselbe passierte übrigens mit oben genannter Problematik: Von einem Tag auf den anderen waren alle meine Web-Sites plötzlich wieder hinter einer amoklaufenden WAF aufgeschaltet und funktionierten wieder einmal nicht mehr. Nach Interventionen und langer Wartezeit bequemte sich ein System Engineer dort, den althergebrachten Zustand wieder herzustellen.
- Kommunikation? Vergesst es. In der heutigen Zeit wäre es mittels E-Mail, Blog und RSS-Feeds ja echt keine Sache, die professionellen und semi-professionellen Kunden über geplante Änderungen zu informieren. Mit genügend Vorlaufzeit, damit das Datum im Kalender markiert werden kann und allenfalls bereits Anpassungen am Code vorgenommen werden können. Aber bei Cyon lebt man nach dem Grundsatz „Was der Kunde nicht weiss, macht ihn nicht heiss.“ Was halt leider dazu führt, dass der Kunde immer wieder aus heiterem Himmel eine grundlegende Anpassung vorgesetzt erhält.
Was mich zu meinem eigentlichen Problem führt: Es scheint, als hätte Cyon kürzlich den Web-Server von LiteSpeed auf Apache gewechselt (ich kämpfe derzeit mit Zeichensatzproblemen, weil AddDefaultCharset utf-8 in .htaccess nicht mehr beachtet werden). Nun gut und recht. Zusammen mit diesem Wechsel kommt auch die SSH-Shell komisch daher.
Insbesondere nervte mich tödlich, dass ich neuerdings das aktuelle Terminal-Fenster nicht mehr mittels Ctrl-l löschen konnte (analog zum Befehl clear, halt simpler und schneller). Wenn ich die Tastenkombination betätigte, erschien einfach eine neue Zeile mit der Befehlseingabe.
Nach einigen längeren Nachforschungen und Pröbeleien (wohl so eine Eigenheit von bash mit .bash_profile und .bashrc) löste folgender Eintrag in .bashrc mein Problem.
... # User specific aliases and functions bind -x $'"\C-l":clear;'
Quelle: To bind clear to ^l in Bash
5 Kommentare Kommentare
Nur so zur Info: das Feed hier hab ich schon ewig in meinem reader: https://www.cyon.ch/status/feeds/index.rss2
Manchmal ist es trotzdem ein bisschen kurzfristig, aber so zwei/drei Tage vor dem Upgrade wird eine Änderung dort angekündigt.
Ist es nicht umgekehrt, die haben (ohne das ich informiert worden wäre) von Apache auf LiteSpeed gewechselt? Danke für den Blogpost, mir geht es unglücklicherweise genau gleich wie dir =(…was haben wir für alternativen, kotzt mich eigentlich an von cyon wegzugehen, aber langsam wirds für mich als Webentwickler schädlich, weil meine Kunden nicht wissen, das der Hoster es „versaut“ hat und nicht ich…
Lieber Mario,
besten Dank für Deine konstruktive Kritik. Es macht mir natürlich schon weh, dass wir bei Dir in den letzten Monaten Sympathiepunkte eingebüsst haben. Ich werte es aber als positiv, dass Du Dir die Zeit nimmst, ausführlich darüber zu schreiben. Offenbar ist es Dir nicht einfach Wurst was wir machen und wir werden alles geben, damit das “Lichtlein” für Dich wieder seine volle Strahlkraft zurück erhält.
Nun zu den einzelnen Punkten:
Web Application Firewall:
Ja, die Einführung der Web Application Firewall verlief teilweise rumplig und wir würden im Nachhinein ein paar Dinge anders machen. Wir haben alle uns gemeldeten Probleme so rasch als möglich korrigiert und zu scharfe Regeln deaktiviert. Und natürlich wurde die Web Application Firewall auch getestet und etappenweise ausgerollt. Auch lässt sich die Web Application Firewall für das gesamte Webhosting oder einen einzelnen Ordner mit einem Eintrag in der .htaccess komplett deaktivieren. Inzwischen hat sich das Ganze sehr gut eingependetlt – wir erhalten praktisch keine Anfragen mehr zum Thema. Und im Gegenzug spüren wir einen markanten Rückgang an gehackten CMS – was auch auf unser automatisches Patchen zurückzuführen ist.
Als nicht betroffener sind die Probleme von gehackten CMS kaum sichbar. Im Hintergrund hatten wir jedoch täglich mehrfach damit zu kämpfen. Zum Einen fehlt es verständlicherweise regelmässig an einem entsprechenden Bewusstsein und auch Verständnis auf Seiten des CMS-Betreibers (O-Ton: “Eure Server sind unsicher”) – zum Anderen resultieren daraus viele hässliche Folgeerscheinungen wie Defacements, platzierte Malware, hinterlegte Phishingsites und natürlich der Klassiker: Spam-Versand. Das hat dann bei einem Listing auf einer RBL Auswirkungen auf alle Kunden auf dem Server – ein Problem, welches wir inzwischen allerdings sehr gut im Griff haben.
Kurzum: Wir haben die Web Application Firewall nicht einfach zum Spass eingeführt sondern damit ein akutes Problem bekämpft. Dabei hat es auch Misstöne gegeben, das wollen wir nicht schön reden.
Wechseln der PHP-Version:
Du beschreibst hier ein Problem, dass wir vor wenigen Wochen gelöst haben. Bislang wurden eigene php.inis der Kunden immer komplett angelegt und darin wurden dann die gewünschten Änderungen der Kunden hinterlegt. Dem neuen Webserver-Stack sei Dank speichern wir neu nur noch das Delta, sprich, die einzelnen Zeilen, die gegenüber der systemweiten php.ini abweichen. Neu können wir also die benutzerspezifischen Änderungen parsen und sauber auf die höheren Versionen von PHP migrieren.
Kommunikation:
Kennst Du https://www.cyon.ch/status/feeds/index.rss2? Darüber kommunizieren wir seit 2004 sämtliche Störungen und technische Änderungen. Darüber hinaus gibt es noch weitere Kanäle. Ich liste Dir anhand der Umstellung auf PHP 5.5 gerne unsere getroffenen Kommunikationsmassnahmen auf – Verbesserungsvorschläge sind natürlich willkommen.
– Am 17. September 2014 haben wir im Blog über die Umstellung der PHP-Standardversion auf PHP 5.5 mit Datum 18. November 2014 informiert – also mit rund zwei Monate Vorlauf. Verfügbar ist PHP 5.5 bei uns seit dem 26. Juni 2013 und seit diesem Tag kann bei uns jeder Kunde diese Version im my.cyon auswählen und damit alles testen. Ein Zurückschalten benötigt, so wie das Hochschalten, zwei Mausklicks und dauert keine Sekunde.
– Parallel dazu haben wir über den erwähnten RSS-Feed ebenfalls informiert. Die Meldung ist heute noch abrufbar: https://www.cyon.ch/support/#ticket_587
– Am 15. Oktober 2014 haben wir auch per Newsletter über die Umstellung informiert: http://us1.campaign-archive2.com/?u=30acb02f491fa64d45277b7c7&id=cc1c41fdd0
– Begleitet wurde die Umstellung auch auf twitter & Co, z.B. hier https://twitter.com/cyonstatus/status/534618119227314176
Wenn Du eine Idee hast, wo und wie wir sonst noch besser kommunizieren können, dann lass mich das wie gesagt gerne wissen. Übrigens: Ein überarbeitetes Notification-System ist in Planung. Wir möchten Statusmeldungen z.B. im my.cyon einblenden können.
Wie wir das im Allgemeinen mit den Release-Zyklen von PHP handeln, haben wir hier publiziert: https://www.cyon.ch/support/a/254/bis-wann-kann-ich-eine-php-version-benutzen
Tastenkombination Ctrl + L:
Diese Neuerung hat nichts mit dem Webserver-Stack zu tun. Wir haben in Deinem Blogpost das erste mal davon gehört und haben die Ursache gefunden. Wir werden diese Einstellung demnächst wieder aktivieren.
In einem Wiederholungsfall kannst Du uns auch gerne kontaktieren, damit wir Dir die Sucherei hoffentlich ersparen können.
Noch einmal Merci für Deine Rückmeldungen. Lass mich wissen, falls ich noch Weiteres genauer erläutern kann.
Besten Gruss,
David Burkardt
Gründer und Geschäftsführer von cyon
Tja, da habt Ihr echt recht. Keine Ahnung warum immer alle schreiben, cyon ist so super. Gut schlecht sind die nicht. Aber eine Firma die immer mehr und immer mehr Supportleute einstellen muss, sollte sich fragen ob da nicht an was anderem liegt.
Wer immer mehr Supportleute anstellt, könnte ja auch eine wachsende Kundschaft haben…