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