Verisign liefert ein Tool, mit welchem man unter Eingabe eines Domain-Namens testen kann, ob der Betreiber des Nameservers der Domain DNSSEC unterstützt:
Antwort in meinem Fall für Cyon (April 2017): Leider nein.
Freitag, 28. April 2017
Posts Tagged ‘Hosting’
Samstag, 6. Juni 2015
Ctrl-l bei Cyon SSH-Zugängen wieder zum Laufen bringen (sowie: Kritik an Cyon)
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
Tags: Bash, clear, Ctrl-l, Cyon, Fenster, Hosting, Kritik, Kunde, Kundensupport, Kundenzufriedenheit, Schweiz, Shared Hosting, Web, Window
Labels: IT
Freitag, 27. Juni 2014
.ch-Domains zu cyon transferieren
Heute schreckte mich Blogging Tom auf Facebook mit der Meldung auf, dass SWITCH/nic.ch per 1. Januar 2015 keine .ch-Domains mehr verwaltet. Bis spätestens zu diesem Stichdatum müssen .ch-Domains zu privaten schweizerischen Anbietern gezügelt werden.
Ich besitze ein halbes Dutzend .ch-Domains und lasse diese bereits alle auf meinen Shared Server bei der Cyon GmbH in Basel zeigen. Zum Glück hat der dortige Support in seiner Knowledgebase bereits eine bebilderte und „dubelisichere“ Anleitung aufgeschaltet, an Hand derer ich den Transfer innert 5 Minuten hingekriegt habe:
Wie kann ich meine Domain von SWITCH zu cyon transferieren?
ACHTUNG: Die ursprüngliche Google-Suche leitete mich auf folgenden Artikel, welcher diesen Spezialfall leider nicht behandelt:
Tags: .ch, Cyon, Domains, Hosting, NIC, nic.ch, Switch
Labels: Web
Mittwoch, 18. September 2013
Hostpoint: Immer mal wieder zickt die Datenbank …
Irgendwann ab den frühen 2000ern habe ich alle meine Web-Projekte über das Shared Hosting von Hostpoint AG im Internet bereitgestellt, und dort sind sie in den meisten Fällen noch heute.
Spätestens seit ich diese mit eMeidi.smt laufenden Web-Sites jede Minute mit Pingdom überwache, realisiere ich, wie instabil Hostpoints Hosting ist. Verglichen mit einem an der Uni Bern gehosteten virtualisierten Root-Server (Debian und VMware ESX) und eMeidi.com, welches beim Hoster meines Vertrauens Cyon GmbH in Basel läuft, haben wir es bei Hostpoint mit einem hostingmässigen Drittwelt-Land zu tun.
Dank den vom eMeidi.smt im Dateisystem abgelegten Fehlermeldungen lässt sich rückwirkend jeweils rasch eruieren, wo denn das Problem des Pingdom-Alarms lag. Als Beispiel sei hier der Ausfall vom 13. September 2013 zwischen 8:47 und 9:23 erwähnt:
#2003: Can't connect to MySQL server on 'sekneueg.mysql.db.internal' (13) in /home/sekneueg/public_html/irgendwo/mysql.class.php:240 for URI </> with referer <unknown>
Tjach, dumm gelaufen, ne? In den letzten 30 Tagen betrug die Uptime für diese spezifische Web-Site nur 99.68%, was Ausfällen von insgesamt 2 Stunden und 21 Minuten entspricht. Die längsten Ausfälle fanden am 26. August (57 Minuten), 13. September (36 Minuten) und am 22. August (11 Minuten) statt. Erbärmlich, zumal es sich dabei nicht etwa um Wartungsarbeiten mitten in der Nacht gehandelt hat, sondern um Ausfälle während Bürozeiten.
Der Fall ist klar: Die Profis von heute hosten bei der Cyon GmbH. Da hilft es auch nichts, wenn der Ausfall-anfällige Konkurrenzhoster aus Rapperswil-Jona den bloggenden Tom anheuert – dessen Lohn (sorry, Tom!) würde man lieber in bessere und stabilere Hard- und Software stecken als unnütze Gutfühl-PR.
Mittwoch, 2. Juli 2008
Hostpoint-Problem des Monats: Zeichensalat
Kein Monat vergeht, in dem Hostpoint nicht eine Überraschung parat hat. Während ich im Juni das erste Mal seit langem etwas Positives berichten durfte, war klar, dass im Juli garantiert wieder etwas kaputt gehen musste.
Und tatsächlich: Heute erhalte ich ein Mail eines Kunden, der über komische dargestellte Sonderzeichen flucht. Nach dem ich die Homepage angesurft habe, kann ich das Problem bestätigen: Irgendwie scheinen da UTF-8 und ISO-8859-1 durcheinander gekommen zu sein. Seit sechs Jahren hat die Web-Site keine Probleme mit Zeichensätzen aufgewiesen, doch nun ist über Nacht wohl etwas „kaputt“ gegangen.
Soweit ich erkennen konnte, liegt das Problem darin begründet, dass mysql_query() neu nicht mehr ISO-8859-1-kodierte Zeichensätze zurückliefert, sondern UTF-8. Das HTML-Dokument sagt von sich aber, dass es in ISO-8859-1 kodiert ist – und htmlentities() erwartet auch ISO-8859-1. Ah, und die Tabellen-Spalten weisen ebenfalls latin1_german1_ci als Kodierung auf (jedenfalls sagt mir das phpMyAdmin so).
Temporärer Workaround
mysql_query("SET NAMES latin1");
… zuoberst in der index.php (natürlich nach dem Initialisieren der Datenbankverbindung!)
Jetzt klappt es wieder mit den Zeichensätzen.
Mal schauen, was sich Hostpoint für den kommenden Monat einfallen lässt.
Tags: Hosting, MySQL, PHP, Web-Entwicklung
Labels: Schweiz
Dienstag, 17. Juni 2008
Wie Hostpoint PHP beschleunigt
… kann ich auch nicht so genau sagen. Nachfolgend sollen erste Hinweise auf die Technologie gegeben werden, die ich über einige dort gehostete Web-Präsenzen in Erfahrungen bringen konnte:
- FastCGI: incomplete headers (0 bytes) received from server "/var/run/hcgi/4444" So lautete die Fehlermeldung, die sich bei einer meiner Präsenzen im Apache error.log wiederfand. hcgi scheint der Name des im Einsatz stehenden PHP-Beschleunigers zu sein. Ob es sich bei 4444 um die PID oder die Kundennummer handelt, weiss ich nicht.
- Es scheint sich um eine Eigenentwicklung zu handeln:
Das Hostpoint-Engineering-Team hat einen PHP-Website-Beschleuniger entwickelt. Websites, welche auf PHP-Script aufgebaut sind, laufen nun massiv schneller.
- php.ini-Dateien im Web-Root werden nun nicht mehr interpretiert. Hierzu muss man im Hostpoint Control Panel auf Explorer/Web-Einstellungen wechseln, wo man einerseits sog. PHP-Profile (im Grunde nichts anderes als ein GUI für php.ini-Einstellungen) erstellen/anpassen, sowie diese Profile bestimmten Web-Verzeichnissen zuweisen kann. Leider führte eine von mir „from Scratch“ erstellte Konfiguration zu einem HTTP 500er, weshalb ich schlussendlich eine Kopie des Profils typo3 anlegte und dort allow_url_fopen aktivierte. Für professionelle Web-Entwickler ist diese Oberfläche deutlich komplizierter zu bedienen, als eine gewöhnliche php.ini im Text-Editor anzupassen und dann via FTP auf den Server zu laden.
- Das PHP-Profil wird über .htaccess-Dateien aufgerufen, die folgenden Inhalt erhalten:
HcgiPhpProfileName php5 typo3 #@__HCP_END__@# # Anything after the comment above is left alone ...
Für einmal darf ich Hostpoint gratulieren: Seit der Beschleuniger im Einsatz ist, sind auf PHP basierende Web-Applikationen (in meinem Fall: MediaWiki, so sehr man sich über die Code-Qualität und Performance-Eigenschaften des Produktes streiten kann) spürbar schneller geworden.
Tags: Hosting, Web-Entwicklung
Labels: Schweiz, Web
Donnerstag, 6. März 2008
Neuer Chef-Kostümierer bei Hostpoint
Yvan Knapp wird beim Hosting-Unternehmen Hostpoint am 1. April seine Tätigkeit als CCO (Chief Costumer Officer) aufnehmen. […]
Quelle: Hostpoint holt Head of Webhosting von Swisscom
Die Einführung der neuen Corporate Identity (neudeutsch auch „Erscheinungsbild“ genannt), welches zufälligerweise auch mit der betriebsweiten Entdeckung des „Du“ einher geht hat Herrn Knapp wohl den Rest gegeben, weshalb er sich einer neuen Stelle zuwendet. Wenn der verheissungsvolle Stellenbeschrieb stimmt, wird er aber erst wieder an der Fasnacht 2009 richtig viel zu tun kriegen …
PS: Hostpoint ist meiner Meinung nach nicht zu retten, indem man neue, gutbezahlte Köpfe ins Boot holt. Das Geld hätte man besser in die Erweiterung der Server-Infrastruktur gesteckt und die Zahl der VirtualHosts pro Server verringert … Und so lädt meine Mediawiki-Installation weiterhin in gähnend langsamen 5 Sekunden pro Seite. Juhu!
Dienstag, 29. Januar 2008
Bravo, Hostpoint?
Der Hosting-Anbieter Hostpoint steigerte 2007 den Umsatz um 1,5 Millionen auf 6,5 Millionen Franken, die Kundenzahl stieg von 10’000 auf 55’000.
Quelle: Hostpoint meldet einen Umsatz von 6,5 Millionen Franken
Schön für Hostpoint, doch leider hat sich nichts an der Tatsache geändert, dass Mediawiki- und Drupal-Sites auf Hostpoint-Servern saulangsam ausgeführt werden. Ladezeiten von 5-10 Sekunden für eine einzige Seite sind schlicht nicht vertretbar.
Letztes Wochenende dann das nächste Problem: Mediawiki scheiterte an Uploads. Nach einigem Pröbeln stand die Ursache rasch fest: Festplatte voll. Toll.
Sonntag, 9. September 2007
Hostpoint sucks!
Wenn Fredy drüben bei blogg.ch Prognosen über den Hosting-Markt Schweiz macht (ich stimme ihm voll und ganz bei), dann könnte ich doch auch wieder einmal etwas über die unangefochtene Nummer 1, Hostpoint, berichten.
Beginnen wir mit statistischem Zahlenmaterial:
20 queries. 13.484 seconds.
Woher stammen diese Angaben zu Datenbank-Abfragen? Am Freitag habe ich für eine Bekannte das Shared Hosting-Paket bei Hostpoint geordert und darauf umgehend WordPress 2.2 installiert. Momentan läuft das Blog mit dem Standard-Theme und beinhaltet einen äusserst kurzen Artikel (Titel & eine Zeile Text) sowie vier statische Seiten.
Lasst es mich klipp und klar sagen: Ladegeschwindigkeiten in der Grössenordnung sind inakzeptabel, insbesondere, wenn es sich um die Nummer 1 auf dem schweizerischen Markt handelt!
Ich scheine nicht der einzige zu sein, der solche Schwächen ertragen muss:
Ich habe mich in letzter Zeit immer mit einer sich langsam aufbauenden Seite & Blog herumgeschlagen, wusste nicht, woher das Problem kam. Vermutlich einfach, weil ich eine grosse Menge Daten , wie auch Film und Bildmaterial auf dem Server habe. […]
Quelle: :::Hostpoint – Performance::: (PS: Was sollen die blöden Pünktchen im Titel?!)
Aber klar doch … ich vermute eher, dass Hostpoint das von den ISPs bekannte „Overbooking“ auch auf seinen Servern anwendet. Dies wird meiner Meinung nach verschärft durch den Web 2.0-Boom (die SonntagsZeitung von heute enthält übrigens einen Zerriss dieses Unwortes) mit all seinen Applikationen. WordPress, Gallery etc. – allesamt Web-Applikationen auf Basis von PHP/MySQL – erfordern ein vielfaches an Performance. Heute, 2007, liefert ein Hoster halt kaum mehr statische Web-Sites aus. Inwiefern auch mod_rewrite seinen Anteil an der Performance-Schwäche hat, kann ich zu wenig beurteilen.
Mittwoch, 30. Mai 2007
Hostpoint tut endlich etwas gegen das Spam-Problem!
Eine kurze Leitung kann man dem wohl grössten Schweizer Hoster Hostpoint nicht vorwerfen. Am 2. Januar 2006 schrieb ich zum leidigen Thema Spam:
Spam
Bei Genotec werkelt seit einiger Zeit ein sehr zuverlässiger Spam-Filter – ich werde kaum noch von unerwünschten Mails belästigt. Auch in dem IMAP-Ordner ‚Spam‘ findet sich kaum je noch eine Nachricht. Bravo.
Nicht so bei Hostpoint – verschiedene Kunden haben sich bei mir über das gehäufte Spam-Aufkommen der letzten Zeit beklagt. Dies betrifft insbesondere Adressen, die bei Hostpoint als Forwards eingerichtet sind. Anscheinend werden eingehende Nachrichten einfach durchgeleitet, ohne irgendwelche Spam-Tests durchzuführen.
[…]
Mein Vorschlag an Hostpoint, mittels Grey- und Blacklisting zu arbeiten und auch Forwards auf Spam-Verdacht zu überprüfen wurde aber abgelehnt:
Greylisting sehen wir nicht als Option, weil dadurch nur sich falsch
benehmende Spam-Mailer blockiert werden. Gegen einen Spammer der ein reguläres
Mailsystem (wie z.b. die gängigen Unix-Mailer Exim, Postfix oder Qmail)
benutzt oder missbraucht hilft es nicht im geringsten. Es ist nur
Pflästerlipolitik gegen einige momentane Spambots.Quelle: Peter Keel an Mario Aeby vom 13. Dezember 2005, 16 Uhr 30.
Quelle: Hostpoint am Arsch
Verspätete Einsicht
Im heute verschickten Newsletter erreicht mich endlich die seit mehr als einem Jahr erwartete Botschaft, dass Hostpoint das Problem doch noch erkannt und etwas dagegen unternommen hat:
Haben Sie gewusst, dass wir vor einem Monat eine neue Technik zur Spamabwehr eingeführt haben? Erweiterte Tests prüfen die Nachricht vor der Annahme durch unsere Server. Damit haben wir das eingehende Spamvolumen um zwei Drittel reduziert.
Quelle: Hostpoint Newsletter – Mai 2007 vom 30. Mai 2007
Anscheinend hat also ein Umdenken eingesetzt. Ob Hostpoint nun wirklich Greylisting einsetzt (das bei Genotec immer noch erstaunlich gut funktioniert, wenn auch vermehrt „Aktien-Tipps“ und „Gartenfakeln“ eintreffen) oder die Nachricht empfängt und mit einem Wortfilter testet, ist mir hingegen nicht bekannt.
