Druckbare Version
Ich will nur schon mal vorwarnen, dass hier denächst was Größeres anstehen könnte. Gerade hat einer meiner Kunden bei Webgo (GoPaket Platin), eine Mail erhalten, dass Anfang Februar ein Umzug auf neue Hardware ins neue Rechenzentrum in Hamburg ansteht. Dabei wird sich auch die IP des Servers ändern - besonders interessant für Kunden mit externen Domains - und MySQL 5.7 wird es nicht mehr geben, alles wird umgestellt auf MySQL 8.
Danke. Bin mal gespannt, wie sich das auswirkt. Einer der Hauptvorzüge bei Webgo war für mich bisher die Geschwindigkeit, die ja – Webgo zufolge – an der kurzen Anbindung am Frankfurter Backbone lag.
Naja, auch, aber nicht nur. Außerdem sehe ich gerade im Internet, der Umzug nach Hamburg läuft schon mindestens seit Mitte November. Da hat der Umzug im ersten Anlauf nicht geklappt, ich hoffe sie haben damals noch geübt. Ich werde morgen mal den Support einige Dinge fragen. Werde dann im Februar zumindest rechtzeitig mal die TTL im DNS-Server runtersetzen.Zitat:
Zitat von amateur
Das hatte ich vor geraumer Zeit auch schon vor der Brust... und ich hatte nur externe Domains. Das, die ausschließliche Umstellung auf MySQL 8 und die relativ kurzfristige Terminsetzung (bei mir deutlich unter 2 Wochen !) fand ich damals auch nicht so erfreulich und hab das dort auch mitgeteilt.
Ich mag die eigentlich, aber in letzter Zeit schleifen ein paar Sachen, vor allem weil lange versprochene Dinge einfach nicht passieren, wie z.b. Einstellbare PHP Versionen pro Verzeichnis oder Domain...
VG Thomas
Gesendet von iPad mit Tapatalk
Bin ja gespannt wann das meine Webgo-Kunden trifft. Schon mal beruhigend, dass ich nur noch zwei Kunden dort habe und die sind ohne externe Domain. MySQL 8 und Contao 4.9 sollte ja eigentlich laufen, aber wie gesagt habe ich bis jetzt noch keine Info von meinen Kunden weitergeleitet bekommen.
Vor Problemen mit Contao graut es mich weniger, ob die Seiten jetzt nachts mal 3 Stunden down sind, das juckt da keinen. Aber ich sehe schon ein paar Problemchen mit den E-Mails auf mich zurollen. Liest sich zwar gut, was die dazu so schreiben aber "Allein, mir fehlt der Glaube". Das passt eher auf Inklusivdomains als auf externe. Das betrifft gut 10 Postfächer und vielleicht 15 E-Mail-Adressen aus drei externen Domains. Ich hoffe, sie sind clever genug, die alten Postfächer noch eine Weile per IMAP über die IP zugreifbar zu lassen. Oder noch besser dass sie selbst dafür sorgen, dass wirklich keine Mail verloren geht.
Nach dem Desaster mit den gelöschten Webinhalten vor 2-3 Jahren bin ich skeptisch. Meine Kunden und ich sind ja damals recht glimpflich davon gekommen - kleine Installationen von denen ich lokal ein aktuelles Backup hatte und auch keine Shopsysteme. Da waren die teilweise eine Woche Ausfall zu verklraften. Ich selbst bin damals von denen weg. Viele meiner Kunden haben das Desaster damals ebenfalls sehr kritisch gesehen und sind inzwischen auch weg von Webgo.
Ich war neugierig :rolleyes: und habe mir ein Webgo CMS Power in der SSD-Version geholt. Ich ging davon aus, dass wenn alle Webhostings in ein neues Rechenzentrum auf neue Server umgezogen werden, ein neu angelegtes Webhosting sehr wahrscheinlich direkt auf einem neuen Server landet. Um einen ersten Eindruck zu gewinnen, habe ich mal das neue Contao 4.11.0 installiert. Bei den Vorbereitungen sind mir dann einige Dinge aufgefallen.
Da in der Ankündigung an meinen Kunden drinstand, dass das neue Rechenzentrum in Hamburg steht, während das alte in der Nähe von Frankfurt lag, war meine Befürchtung, dass die Anbindung des neuen Rechenzentrums langsamer sein könnte. Test mittels ping von meinem PC aus bestätigt das auch, dauert schon deutlich länger :(
Dann Contao-Manager runtergeladen, OMG, hat vergleichsweise ewig gedauert, ca 500 KB/s. :(
Dann den tollen webgo Webspace-Manager aufgerufen. Sieht auch weitgehend gleich aus wie der alte mit ein paar (kleinen) optischen Unterschieden. Naja.
Externe Domain aufgeschalten, zuerst dummerweise eine icu-Domain versucht -> unzulässig, kenn ich nicht :(
Dann fiel mir ein, das ist bei Webgo im älteren Webhosting genauso. Naja, besser wird es davon auch nicht. Also habe ich eine de-Domain aufgeschaltet, was dann auch funktioniert hat.
Document Root eingestellt und SSL-Zertifikat (Let's Encrypt) geholt.
PHP 8.0 ausgewählt und den Manager gestartet. Servercheck lief alles glatt.
Neuste (Neueste?) Contao-Version installieren lassen mit Cloud. Das lief dann doch sehr flott, weshalb ich dann doch von mehr als 500 KB/s ausgehe.
Im nächsten Schritt eine Datenbank angelegt, MySQL 8 wie erwartet. Aber: Keine MariaDB mehr zur Auswahl! Ich weiss noch nicht, ob ich darüber jetzt glücklich sein soll ;). Immerhin kann ich sagen, die Datenbank war ratzfatz aktualisiert, habe ich auch schon um einiges langsamer erlebt.
Admin angelegt und ins Backend und festgestellt, dass ich 4.10 installiert hatte und nicht wie geplant 4.11. Meine Dussligkeit oder der Manager kann es noch nicht, Webgo kann ich es jedenfalls nicht anlasten. Also ein Update auf 4.11 gemacht und gleich mal BackupDB mitinstalliert. Auch das ging wieder sehr flott und problemlos.
Das Backend ohne irgendwelche Inhalte reagiert gefühlt vergleichsweise sehr schnell, die Seiten sind blitzschnell aufgebaut. Werde also morgen mal ein Update einer etwas umfangreicheren Installation da durchführen um zu sehen ob sich das bestätigt. HTTP/2 gibt es jetzt auch endlich, lang genug hats gedauert :rolleyes::D.
Zuletzt habe ich mir über den Manager noch die PHP-Informationen angeschaut:
- PHP 8.0.2
- APCu ist enabled, das ist aber nichts Neues.
- OPCache enabled, das ist neu und sehr positiv.
- open_basedir disabled :)
- Imagick 3.4.4, neben zahlreichen unterstützten Bildformaten auch WEBP. Fehlt mir auf den ersten Blick nichts Wichtiges.
- intl, mbstring tidy, zip und sodium (Hurra! ;) )
Jetzt bin ich mal gespannt, wie sich das dann in den nächsten Tagen anlässt.
Tja, da ich gerade etwas im Stress bin wegen PC-Problemen meines Lieblingskunden bin ich hier noch nicht besonders weit gediehen. Immerhin, ich dachte mir, ich setze mal eben eine Nextcloud auf und schaue wie das läuft. Erste Antwort: Gar nicht! Es gab irgendein Problem mit einer Library, was dann so endete:Zitat:
Zitat von tab
Der Support hat das Problem aber mittlerweile gefixt und jetzt rennt die Cloud und hat mittlerweile auch nichts mehr zu meckern bei den Sicherheits- & Einstellungswarnungen: Alle Prüfungen bestanden.Code:** (process:627): WARNING **: Error loading plugin: /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: g_variant_dict_ref
Segmentation fault
Ich hoffe mal, dass immer noch die alte Regel gilt, dass jeder Server ein Unikat ist und ich nicht beim Umzug des Kunden nächste Woche das selbe Ticket nochmal aufmachen muss.
So, fast 8 Wochen später mal wieder ein Update hierzu. Und die Message ist: Im Westen (Norden) nichts neues! Beim Kunden ist nur das passiert, dass zunächst eine Meldung kam, der Umzug würde verschoben. Der neue Termin kam heran, ich kontaktierte vorsichtshalber den Support per Chat um einige Fragen meinerseits zu klären. Der Supportmitarbeiter teilte mir dann nach einiger Zeit mit, dass da momentan kein Umzug anstehe, der sei verschoben und es gäbe noch keinen neuen Termin. Es sei ein entsprechendes Mail an meinen Kunden rausgegangen. Also den Kunden befragt und tatsächlich war eine Mail angekommen, die mir praktischerweise niemand weitergeleitet hatte. Da stand dann was von Erweiterung der neuen Rechenzentrumsfläche noch nicht abgeschlossen, noch nicht zu 100% nutzbar, um weitere Verschiebungen zu vermeiden gibts einen neuen Termin erst, wenn er auch sicher eingehalten werden kann. Die Mail war vom 27.02.21, mittlerweile nichts mehr davon gehört. Ich hoffe, es wird noch was mit dem Umzug vor Weihnachten! Und damit meine ich Weihnachten 2021 :rolleyes:.
Währenddessen ist mein neues Webhosting mitsamt dem Hostwsystem auf die neue Rechenzentrumsfläche umgezogen worden. Das hat jedenfalls problemlos über Nacht geklappt. Naja, Kunststück, die Hardware ist die selbe geblieben und auch die Software darauf inklusive IP-Adresse. Trotzdem positiv eine Runde Applaus vom Balkon! :D Mit dem CMS Power SSD bin ich auch weiterhin sehr zufrieden, das rennt sehr ordentlich. Bin mal gespannt ob mein "altes" CMS Power noch den Umzug nach Hamburg erlebt. Stand jetzt werde ich den Vertrag wohl Mitte Mai kündigen und alles auf das SSD-Hosting umziehen bzw bei der Gelegenheit gleich mal gründlich überdenken, welche Webhostingpakete ich behalte und was ich dann am besten auf welchem unterbringe. Manches vom alten CMS Power wird dann wohl ganz woanders landen ;), viele alte Testinstallationen werde ich auch gar nicht mehr umziehen, sondern löschen :rolleyes:. Alles in allem war ich mit meinem alten CMS Power aber immer sehr zufrieden, jetzt ist eben das Bessere der Feind des Guten und es muss der SSD-Variante weichen, wenn nicht anderswo bis dahin noch irgendwelche Rechenzentren abbrennen :rolleyes:.
Tja, kaum schreibt man was, schon kommt die Mail mit der Ankündigung. Irgendwann Ende Mai soll der Umzug jetzt stattfinden, der genaue Termin wird dann noch vorher bekanntgegeben. Schau mer mal, dann seh mer scho...Zitat:
Zitat von tab
Mittlerweile ist der Mai fast schon zuende ;), und seit heute ist das Platin-Paket eines Kunden im neuen Rechenzentrum auf der neuen Hardware. Der Umzug hat im Großen und Ganzen gut funktioniert, die Daten scheinen jedenfalls alle da zu sein. Hatte natürlich gestern Nachmittag noch mal ein komplettes Backup gezogen und konnte mich dann erst einmal entspannt zurücklehnen :). Gestern Abend schon die IP geändert bei den externen Domains. Heute Morgen dann um 7 Uhr - da hätte normalerweise alles fertig sein sollen - mal reingeschaut, aber da ging noch nicht viel, nur der SSH-Zugang. Um 9 Uhr ging dann der Zugriff auf die E-Mails wieder per IMAP und es konnten Mails versandt werden, also mailtechnisch ok. Allerdings im Webspace-Admin im Menü noch Links für beide Webmailer drin, Horde sollte ja eigentlich rausgenommmen werden. War er in Wirklichkeit auch, über den Horde-Link gab es Roundcube und über den Roundcube-Link ein 404. ;)
Bei den Websites sah es nicht ganz so gut aus, beim Aufruf kam eine Fehlermeldung, dass meine Installation mindestens PHP 7.4 braucht. Das dachte ich eigentlich auch eingestellt zu haben, aber Pustekuchen! Webspace-Admin zeigte mir PHP 5.6 eingestellt. Das konnte natürlich nicht klappen. Beim Versuch PHP 7.4 einzustellen hatte ich dann den Aha-Effekt, dass nur PHP 5.6 bis 7.3 zur Auswahl stand, was wohl auch erkärt, warum die PHP-Version beim Umzug von 7.4 auf 5.6 umgestellt wurde. Also ein Ticket aufgemacht, heute Abend ca 18 Uhr war dann auch PHP 7.4 und 8.0 auswählbar und jetzt funktionieren die Websites und die Nextcloud auch wieder. Dass bei so einem Umzug eine Menge schiefgehen kann ist klar. Ich weiss auch nicht, ob das jetzt einer der ersten umgezogenen Server mit alten Webhostingpaketen war, ansonsten sollten die aufgetretenen Probleme ja eigentlich schon früher beim Umzug anderer Server aufgefallen sein. Allerdings waren die Server vorher schon alle Unikate und sind es wohl auch geblieben ;).
Jedenfalls bin ich erst mal froh, dass alles wieder läuft, inklusive HTTP/2, OPCache und APCu, ein paar Feinheiten der neuen Umgebung muss ich morgen nochmal näher untersuchen.
Also der erste Eindruck von der neuen Hard- und Software des umgezogenen Webhhostingpakets (GoPaket Platin) ist bisher durchweg positiv. Damit kann man arbeiten, da warte ich auch gern noch eine Weile bis die kaputten Links im Webspace-Admin gefixt sind. Ohne irgendwelche Messungen gemacht zu haben läuft die Nextcloud gefühlt deutlich schneller als vorher und bringt auch keine Warnungen mehr beim Systemcheck. Ich warte jetzt einfach mal, bis das Update auf NC 21 angeboten wird. Könnte man freilich auch sofort manuell machen, aber hat ja keine Eile. Die Websites waren vorher schon schnell, da merke ich den Unterschied nicht, dazu müsste man wohl schon Vergleichsmessungen durchführen. Pech für Webgo ;), eine Notwendigkeit auf die SSD-Variante umzusteigen sehe ich da momentan nicht. Aber gut zu wissen, dass es die SSD-Variante im Bedarfsfall gäbe. Vielleicht dann beim Relaunch der Websites oder wenn die Nextcloud mal mehr genutzt wird ;).
Edit: Kaum schreibt man es, schon ist das NC 21 Update Geschichte. Auch das hat dank MySQL 8 problemlos funktioniert.
Bei einem von meinen Kunden (Hoster Webgo) soll in Kürze auch auf MySQL 8 umgestellt werden und es wird die Alternative mit Maria-DB nicht mehr geben.
Gibt es inzwischen bei Euch noch neue Erkenntnisse zu zu erwartenden Problemen?
Konkret ist es eine aktuelle Installation Contao 4.9 mit Catalogmanager.
Also der Kunde mit dem umgestellten Platin-Paket hat keine Probleme - wenn man davon absieht, dass seit mittlerweile über einer Woche keine Mails an Microsoft durchgehen :) :rolleyes:
Habe jetzt mal angefragt, ob sie mir vorab ein Test-Account mit MySQL 8 zur Verfügung stellen. Mal sehen wie sich Webgo dazu äußert.
Wer will denn schon Mails bei Microsoft haben :D.Zitat:
Zitat von tab
Naja, es soll Menschen geben, die haben nur eine E-Mail Adresse und das ist dann noch hotmail.de oder so ein Zeug. Und wenn ihm solche Kunden dann Mails schicken auf die er nicht antworten kann, dann ist er halt genervt. Ich vertrete ja die Meinung, wer nur ein E-Mail Konto bei Microsoft hat, der will nicht per Mail erreichbar sein.
Da ich auf Hardware von Webgo entwickle und meine Testysteme dort liegen, werde ich mir das natürlich verfolgen. MariaDB nutze ich nicht, aber eine größere Installation mit CatalogManager läuft dort. ich kann dann gern berichten.
Mit welcher Mysql-Version?Zitat:
Zitat von amateur
mysql Ver 15.1 Distrib 10.3.31-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2 –– was ich aber nicht wirklich verstehe …
Das dürfte dann Maria-DB als DB sein und nicht MySQL.
Was müsste man denn testen und wie? Kann ja eigentlich nur darum gehen ob der CatalogManager mit MySQL 8 klarkommt. Bin eigentlich zuversichtlich, dass Webgo da einen Testaccount rausrückt, alle neu erstellten Webhostingpakete sind ja wohl eh mit MySQL8.
Ja genau, ich will lieber einen Live-Test direkt bei Webgo mit dem Catalog Manager und den in dieser Installation verwendeten Tabellen machen um nachher bei der Umstellung nicht in Hektik reagieren zu müssen.
OFF-TOPIC: Das Problem hier https://t3n.de/news/y2k22-bug-micros...ampaign=050122Zitat:
Zitat von tab
Ja, das ist bekannt. "Ein wenig peinlich" ist wohl die Untertreibung des Jahrhunderts. Das ist megapeinlich, geht gar nicht. Da sieht man mal wieder, wie Software bei Microsoft produziert wird. Qualitätskontrolle ungenügend, falls überhaupt - außer auf dem Papier - vorhanden. Wozu auch, dafür hat man doch Kunden. Hat aber mit dem ganz "normalen" Abweisen von Mails aus ganzen IP-Subnetzen (man könnte es auch Sippenhaft nennen) durch Microsofts Filter nichts zu tun.Zitat:
Zitat von mlweb
Webgo hat das Problem jetzt endlich gelöst, allerdings wohl nicht so, wie sich Microsoft das vorgestellt hatte. Ich schätze, sie haben da die Geduld mit Microsoft verloren. Sie leiten ausgehende Mails jetzt über einen anderen IP-Bereich weiter, bei meinem Kunden über die IP, die der Server vor dem Umzug hatte. Die ist offenbar nicht in Microsofts Blockliste. Für bei Webgo registrierte Domains haben sie auch den SPF-Record angepasst, so dass die alte IP wieder berechtigt ist Mails zu senden. Da der Kunde aber extern registrierte Domains bei Webgo aufgeschaltet hat, ging das nicht und die Mails wurden deshalb von meinem Mailserver abgewiesen. Also habe ich es eben selbst umgestellt. So kann man die Nacht vom Samstag auf Sonntag freilich auch verbringen. Immerhin, Webgo hat eine pragmatische Lösung für das Problem gefunden. Ob temporär, bis die derzeitige IP des Servers aus der Blockliste ist, oder ob das jetzt dauerhaft so bleibt, weiss ich nicht. Da wäre eine Ankündigung seitens Webgo sicher auch hilfreich gewesen, vielleicht hat sie ja auch der Kunde entsorgt. Ich bin jedenfalls froh, dass ich es relativ schnell mitbekommen habe, sonst wäre am Montag wohl ein mittleres Chaos ausgebrochen.
Webgo ist für mich beim Hosting inzwischen keine Empfehlung mehr
Kleiner Nachtrag zu meinem Versuch einen Testaccount zu bekommen. Den gab es nicht wirklich. Meine Kundin hat ein neues Paket bestellt, was dann auf einem aktuellen Server mit MySQL 8 landet. Sie hat ein Widerrufsrecht von 14 Tagen. In dieser Zeit kann ich testen.
Technisch gesehen tritt nur ein Problem im Debug-Modus auf. Da bin ich dran (s.u.).
Was mich aber wieder mal in meiner inzwischen skeptischen Haltung gegenüber Webgo bestätigt hat, ist folgende Tatsache:
Eine Paketbestellung generiert ja gleich eine interne "Webgo-Sub-Domain". Mit dieser Domain wollte ich testen, leider war die Domain erst mal nicht erreichbar. Also gewartet weil man das ja kennt, dass es manchmal etwas dauert bis die Domains erreichbar sind. Als sich nach 24h noch immer nichts getan hat, habe ich Webgo kontaktiert und auch sehr schnell (innerhalb von ca. 30min.) eine Antwort bekommen. Das System hat einen falschen Link generiert und damit war die URL der Testdomain falsch. Also wieder mal ein falsch konfigurierter Algorithmus so wie damals auch bei den fehlerhaften Löschungen. Dieses Mal Gott sei Dank nicht mit so katastrophalen Folgen. Man kann Fehler nicht gänzlich vermeiden, aber mein damals nachhaltig gestörtes Vertrauen in diesen Hoster hat sich damit leider nicht verbessert.
Von meiner Fehlermeldung im Debugmodus bin ich leider auch noch nicht sicher, ob das ein Problem mit MySQL 8 ist oder ein Konfigurationsproblem beim Hosting. Der Fehler wurde hier Forum schon mal diskutiert und damals als Konfigurationsproblem beim Hoster diagnostiziert. Allerdings war die Fehlermeldung damals grundsätzlich da und nicht nur im Debugmodus.
Ich werde dann mal berichten wo die Ursache lag.
Und jetzt werde ich richtig sauer auf Webgo.
Originaltext der Mail von Webgo:
Bedauerlicherweise gibt es kein Test-Zugang zur neuenMySQL-Version. Es wäre höchstens möglich, ein neues Hosting-Paket IhremKundenkonto dazu buchen, um es so testen zu können. Sie hätten dort auch eineTest-Domain zur Verfügung. Neu gebuchte Verträge landen immer auf neuerenServern mit den neueren Versionen.
Test auf der Konsole:
:eek:Code:mysql -V
mysql Ver 15.1 Distrib 10.3.31-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
Das dürfte ja nach meinem bescheidenen Verständnis Maria DB sein und nicht MYSQL 8.
Warum bin ich eigentlich nicht sofort meinem skeptischen Impuls gefolgt?
Einmal mit Profis arbeiten :mad:.
Im übrigen verstehe ich jetzt erst recht nicht warum der Debug-Modus einen Fehler zeigt.
Nicht schön, aber das ist die Client-Version. Die sieht bei mir genauso aus. Aber ich habe mich mal der Konsole angemeldet mitZitat:
Zitat von mlweb
Da kommt dannCode:mysql --user=user_name --password=your_password db_name
Also habe ich mir mal die entsprechenden Variablen angeschaut:Code:Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MySQL connection id is 172653724
Server version: 8.0.22 MySQL Community Server - GPL
Der Server ist also MySQL 8.0.22, wie das zusammenpasst, darfst du mich aber auch nicht fragen.Code:MySQL [web75_db6]> show variables like '%version%';
+--------------------------+------------------------------+
| Variable_name | Value |
+--------------------------+------------------------------+
| admin_tls_version | TLSv1,TLSv1.1,TLSv1.2 |
| immediate_server_version | 999999 |
| innodb_version | 8.0.22 |
| original_server_version | 999999 |
| protocol_version | 10 |
| slave_type_conversions | |
| tls_version | TLSv1,TLSv1.1,TLSv1.2 |
| version | 8.0.22 |
| version_comment | MySQL Community Server - GPL |
| version_compile_machine | x86_64 |
| version_compile_os | Linux |
| version_compile_zlib | 1.2.11 |
+--------------------------+------------------------------+
12 rows in set (0.003 sec)
Ok danke schon mal. Dann ist das bei mir auch MySQL 8. Wieder etwas gelernt. So tief musste ich da sonst nie einsteigen, weil man bei anderen Providern die Version auch in phpMyAdmin ablesen kann.
Dann habe ich an dieser Stelle Webgo wohl unrecht getan. Tut mir leid.
Nachtrag: Habe eben von Webgo auch eine Antwort bekommen, dass es sich dann wohl um einen Anzeigefehler handelt. Kann ich mir zwar schwer vorstellen, da Du mir gerade erklärt hast, dass ich mit meiner Abfrage nur die Client-Version angezeigt bekommen habe.
Aber wie auch immer. Zu mindestens war mein Test nicht für die Katz und der Sonntag ist halbwegs gerettet.
Naja, Anzeigefehler ist gut ... Ich habe da im Moment auch noch gemischte Gefühle mit einigen Dingen, obwohl sich stellenweise auch was getan hat. Also wenn die Performance für das Geld nicht so gut wäre, obwohl das noch nicht mal SSD-Pakete sind, würde ich zumindest erwägen, die Kunden woanders hin umzuziehen. Wäre aber auch nicht einfach, weil ich nicht wüsste wohin. Hostingwerk wäre von der Performance her genial, aber da kämen einige Kunden mit der Größe des Webspace nicht klar. Einer belegt derzeit knapp 60 GB :rolleyes:. Würde sie dann eher auf meinen Server nehmen, mit allen positiven und negativen (für mich) Konsequenzen. Da wäre es bei Problemen halt nicht damit getan, ein Ticket bei einem Hoster aufzumachen. :rolleyes:;) Mittelfristig ist das von mir zwar sowieso angedacht, aber das zieht dann halt schon einiges nach sich.
Ich habe im Moment ganz gute Erfahrungen mit All-Inkl. und dort die meisten meiner Kunden untergebracht. Ein paar wenige bei Netcup, ein paar noch bei Webgo und noch immer einen bei Strato - zu Testzwecken immer gut.
Hostingwerk ist schon genial, aber klar, da ist der Platz arg limitiert. Meine Kunden möchten außerdem fast alle nicht noch zusätzlich Kosten und einen extra Vertrag für die Domain haben.
Haha, ja, ein Kunde sammelt Domains :). Normalerweise schaue ich darauf, dass die Domains woanders registriert sind, damit es bei Umzügen kein so großes Problem gibt. Das ist mir bei Webgo gestern abend aber zum zweiten Mal auf die Füsse gefallen. Zum ersten Mal beim Serverumzug und jetzt bei der Mail-Umstellung. Wären es Inklusivdomains gewesen, hätte gestern ebenso wie damals beim Serverumzug kein Handlungsbedarf bestanden, weil Webgo alles automatisch im DNS angepasst hat. Das hat zumindest der Blick ins DNS bei einer Inklusivdomain ergeben, da war beim SPF die neue/alte IP zusätzlich eingetragen. Bei einer externen Domain fällt das für Webgo halt schwer, da muss dann eben ich ran :(.
Schlecht ist es halt, wenn man von nichts weiss, das hätte mir morgen früh wohl einige Anrufe eingebracht.
Genau das ist der in meinen Augen gelegentlich mindestens gedankenlose Umgang, den ich bei Webgo schon mehrfach festgestellt habe. Ich hatte auch einen Kunden, der damals beim Umzug nach Hamburg erst am Tag des Umzugs über den genauen Termin informiert wurde. Website schon nicht mehr erreichbar und damit externes eigenes, tagesaktuelles Backup leider nicht mehr möglich.
Mein Problem im Debug-Modus ist nach einer kompletten Neuinstallation und Verwendung einer anderen Datenbank übrigens auch weg. Ob es die Neuinstallation oder die andere DB war - keine Ahnung, mag ich auch nicht tiefgreifend weiter untersuchen. Auf jeden Fall weiß ich jetzt definitiv, dass der Catalog Manager mit MySQL 8 problemlos läuft. Wenigstens das Ziel der ganzen Übung ist erreicht.