Hat jemand praktische Erfahrungen mit den Hostingpaketen von Webgo?
Druckbare Version
Hat jemand praktische Erfahrungen mit den Hostingpaketen von Webgo?
Hallo,
bin erst vor kurzen zu Webgo mit einigen Projekten umgezogen.
Es läuft alles schnell und problemlos, in der kurzen Zeit einmal Kontakt mit dem Support gehabt der auch sehr kompetent wirkte.
Ich hatte nur bei der Einrichtung den Fehler begangen alles mit dem Haupt-FTP User anzulegen. Als ich jetzt zusätzliche FTP-User für einzelne Domains anlegen wollte habe ich festgestellt das dann einige Rechteprobleme auftreten.
Also wenn nötig für jede Domain einzelne FTP-Zugänge anlegen. Vielleicht läßt sich das Problem auch anders lösen, aber ich kann damit leben.
Offtopic:
War vorher bei TopHoster und eigentlich sehr zufrieden, bis auf einmal die PayPal-Kommunikation in einem Shop nicht mehr funktionierte.
TopHoster reagierte so träge das ich es leid war und zu Webgo umzog.
Gruß Michael
Bin schon seit Jahren bei Webgo, bin zufrieden. Guter Service.
Mich überzeugen gerade LetsEncrypt-Integration und SSD-Hosting. Was ich nicht so cool finde, ist, dass im Webhosting Domains inklusive sind. Sowas mag ich persönlich ja nicht.
Bevor ich umziehe: hat noch jemand mehr Erfahrungswerte?
Wer nutzt Composer über die Kommandozeile? Gibt es darüber keine PHP-Restriktionen (memory_limit etc)?
Funktioniert die Lets-Encrypt-intergration easy?
Externe Domains können easy und ohne Extrakosten aufgeschaltet werden?
Gibt es eine max. Postfachgröße. Diese ist ja frei wählbar. Ist der Postfachspeicher extra oder wird der Speicher des Hostings genommen?
Gleiche Frage für Datenbanken.
Bin seit einigen Monaten bei https://www.serverprofis.de/ und super zufrieden.
Transparente Daten, erstklassiger Support, Umstellung auf https problemlos.
VG
KDF
@KDF - die Frage war, ob jemand praktische Erfahrungen mit den Hostingpaketen von Webgo hat und nicht welchen Webhoster empfiehlt ihr.
Einfacher geht es nicht, läßt sich über das Kundenportal schnell und easy umsetzen und steht relativ schnell zur verfügung.Zitat:
Funktioniert die Lets-Encrypt-intergration easy?
Gruß Michael
Ich bin seit ein paar Wochen bei Webgo und musste den Support schon etwas nerven (weil immer bestimmte Tabellen beim Import von WordPress Datenbank unterschlagen wurden). Die Herren waren immer freundlich und schließlich haben Änderungen gegriffen. Let’s encrypt funktioniert schnell und einfach. Schnell ist überhaupt das Aufälligste. Komme aber auch von Strato. Angeblich soll es demnächst auch domainspezifische PHP-Versionen geben. Contao funktioniert bislang unauffällig.
So long
Michael
Hier ein paar Antworten auf meine eigenen Fragen ;-)
Hätte ich noch weiter geschaut, dann hätte ich erfasst, dass Webhostone ziemlich das gleiche bietet (auch gleiches Admin Panel etc), aber statt 6 kostenlosen Domains nur 1 kostenlose Domain bietet. Die Pakete sind dann auch günstiger. Ein Testaccount hat dann aber ergeben, dass bei Webhostone scheinbar die OpenSSL-Version oder so zu alt ist. Kann mich aber auch täuschen. Naja, ich drifte ab.
Ich verwende sowieso nur composer install und nicht composer update und kann mich deswegen nicht beschweren. Der Prozess "php" zeigt auf eine PHP5.6 Version, es stehen aber unter "/usr/bin" von "php55" bis "php71" alle denkbaren PHP-Versionen zur Verfügung. Und das trotz der chroot-Umgebung bei webgo. Bei 1&1 gab es auch eine chroot-Umgebung und ich hatte nur eine PHP 4-Executable zur Verfügung. Ging natürlich gar nicht, und das war der Kündigungsgrund für dieses eine Projekt.
An sich ja, aber keine Third-Level-Domains. Also wenn man nur eine Subdomain dort hosten will. Das ist sehr schade! Der Hoster geht wohl doch davon aus, dass man bei ihm die ganzen Domains registrieren will.
EDIT: alles in allem bin ich gerade zufrieden. Und wenn man sich ein bisschen bei den Hostern umschaut, dann weiß man, wie schwer es ist, einen guten Hoster zu finden. Ich persönlich habe echt lange gesucht. Das Admin-Panel wirkt noch etwas antiquar, aber der Support hat sich bereit gezeigt, meine Verbesserungsvorschläge zu berücksichtigen.
Sind die Pfade irgendwo auf der webgo Website dokumentiert? Gibt es für die Benutzung mit dem detached mode noch weiteres, was man bei webgo beachten kann oder muss? Wenn ja, bitte ergänzen: https://github.com/contao-community-...on-modes#webgo
Ist das wirklich so? Ich habe zwar auch festgestellt, dass man im Kundenportal direkt über Domains hinzufügen keine Subdomains angeben kann. Das ist für mich durchaus wichtig und wäre ein Argument gegen ein separates Hosting der Domains. Aber ich habe festgestellt, dass man für die hinzugefügten Domains auch Subdomains hinzufügen kann. Wer hindert mich also daran, meine externe Domain hier hinzuzufügen, die gewünschte Subdomain zu erzeugen und dann im DNS des Domainhosters nur die Subdomain an meinen Webgo-Server weiterzuleiten und die Domain selbst da zu lassen wo sie ist? Ich werde das nachher mal ausprobieren, bevor ich entscheide, wo ich mit meinen Domains hingehe.
Test erfolgreich beendet. Es funktioniert mit der Einstellung wie oben beschrieben. Ich habe jetzt eine bei 1&1 gehostete Domain, bei der die Hauptdomain auf den 1&1 Webspace zeigt, eine Subdomain auf meinen Uberspace und die andere Subdomain auf den Webgo-Webspace. Also alles gut und ich kann meine Domains beruhigt separat hosten.
Man kann den Hoster alle Nase lang wechseln, ohne die Domains umziehen zu müssen. Denn wenn man einmal einen guten Domain-Registrar gefunden hat, bleibt man da erfahrungsgemäß länger als bei jedem Hoster. Man ist flexibler und die Kosten sind transparenter.
Außerdem kannst du verschiedene "Teile" der Webseite bei verschiedene Hostern hosten. Brauch die www-Seite nur einen Billighoster, für eine Subdomain brauchst du aber ein Cloud-App-Hosting? No
Hier noch weitere Lektüre: https://wiki.uberspace.de/philosophy:domains
Hmm, wahrscheinlich habe ich jetzt den ersten Fall für den Webgo-Support. Ich habe eine meiner bestehenden Websites von Uberspace bei Webgo "dupliziert". Wollte einfach mal sehen, wie das mit der Performance aussieht. Das war anfangs auch ganz gut, jetzt habe ich plötzlich immer einen Fehler "502 Bad Gateway" und drunter steht in kleinerer Schrift "nginx". Hatte das schon mal jemand bei Webgo oder ist das eine Störung?
Ich habe mittlerweile festgestellt, dass ich auf statische Dateien noch zugreifen kann, nur dynamisch erzeugte gehen nicht. Soweit ich das glaube zu verstehen, ist nginx bei Webgo als Loadbalancer zwischen den Apache und das Internet geschaltet und für die Auslieferung von statischen Inhalten zuständig, während der Apache die dynamischen Inhalte liefert - oder eben auch nicht. Auch ins Backend meiner Contao 4.4.0 Testinstallation komme ich nicht mehr, auch wenn da eine andere Fehlermeldung - von Contao - kommt. Auch das hat schon mal funktioniert. Die contao-manager.phar.php kann ich aufrufen, Backend und Installtool nicht. Auch nicht über den Manager.
Aha, hängt wohl mit der eingestellten PHP-Version zusammen. PHP 5.6 und 7.0 funktioniert, 7.1 nicht - obwohl angeblich alle "stable" sind. Hatte vorhin die PHP-Version hochgesetzt zwecks Geschwindigkeitsvorteil, dabei aber den Apache nicht neu gestartet. Das hat er dann wohl zwischendurch mal selbst erledigt und danach ging dann nichts mehr.
PHP 7.1 hat in irgendeiner alpha oder frühen beta prinzipiell funktioniert, aber immer mit einer Fehlermeldung wegen fehlendem ioncube_loader. Die Fehlermeldung hatte ich auch schon in der 3er-Version mit Composer. Kann sein dass Andreas das irgendwann mit abgefangen hat.
Die 3.5.27 funktioniert da aber auch nicht mit dem PHP 7.1. Ist zwar mit Composer, aber ich habe den Paketmanager noch nicht angerührt hier bei Webgo. Wenn man wenigstens wüsste, woran es scheitert. Das Server Errorlog sagt nur
Code:[Fri Jun 30 22:11:32 2017] [notice] [client AH00052: child pid 9912 exit signal Segmentation fault (11)
Die 3.5.27 habe ich bei Webgo mit Composer laufen. Bei der Paketinstallation kommt halt immer die ioncube-Loader-Warnung.
Vielleicht muss ich auch nur mal die Erweiterungen updaten, habe ich länger nicht mehr gemacht. Vielleicht ist auch eine komplett inkompatibel damit. Teste ich heute nach dem Frühstück mal. Komisch ist allerdings, dass auch das Installtool und das Backend meiner frisch mit dem Contao-Manager installierten 4.4.0 mit der PHP 7.1 bei Webgo nicht laufen.
Ich teste nacher noch einmal eine ältere Version des Managers. Ich glaube da ging die 7.1. Aber eventuell hat Andreas irgendwann den fehlenden ioncube Loader mit abgefangen beim Manager.
Komische Sache, habe mir gerade mal die phpinfo der beiden PHP Versionen 7.0 und 7.1 aufgerufen und gespeichert, um sie in Ruhe zu vergleichen. Dann habe ich die 3.5.27 Website nochmal aufgerufen mit PHP 7.1 - und es hat funktioniert! Kein "502 Bad Gateway" mehr. War dann wohl doch eine Störung.
Dafür habe ich jetzt festgestellt, dass die Testinstallation Contao 4.4.0 immer noch nicht wieder läuft, allerdings auch nicht mit PHP 7.0 :confused:. Da scheint also grundsätzlich was nicht mehr zu funktionieren. Fehlermeldung sieht so aus:
Mit PHP 5.6 kann ich das Installtool aufrufen. Ich glaube, PHP 5.6 war auch aktiv, als ich Contao über den Manager installiert habe. Kann es damit was zu tun haben?Code:[2017-07-01 22:39:22] app.CRITICAL: An exception occurred. {"exception":"[object] (Doctrine\\DBAL\\Exception\\ConnectionException(code: 0): An exception occured in driver: SQLSTATE[HY000] [2002] No such file or directory at /home/www/meine-domain.de/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php:103, Doctrine\\DBAL\\Driver\\PDOException(code: 2002): SQLSTATE[HY000] [2002] No such file or directory at /home/www/meine-domain.de/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:47, PDOException(code: 2002): SQLSTATE[HY000] [2002] No such file or directory at /home/www/meine-domain.de/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:43)"} []
Gerade mal bei den anderen Beta-Testern gefragt: Antwort von @Bugbuster: "Der soll das merken und anpassen. Wird wohl öfters geprüft. Hatte ich hier auch schon gefragt."
Ansonsten mal in der manager.json nachschauen und ggf. den Pfad anpassen.
Ich habe gerade noch mal in meine Tests geschaut und folgendes gefunden. Reproduzierbar konnte ich bei webgo feststellen, dass ich bei PHP 7 nur mit MariaDB das Installtool aufrufen konnte. Da das Installtool selbst aber nicht zum Manager gehört, sind wir dieser Ursache auch nicht weiter auf den Grund gegangen.
Der Manager selbst funktioniert ja, auch nachdem ich die PHP-Version wechsle. Aber das installierte Contao funktioniert dann halt nicht mehr, da kann der Manager ja auch nichts dran machen, ohne dass er aufgerufen wird. Falls es wirklich an der PHP-Version liegt, die zur Installation verwendet wurde, was wäre dann die korrekte Vorgehensweise nach Änderung der PHP-Version, damit Contao wieder läuft?
Nach einer Änderung der PHP Version musst du potentiell auch ein composer update mit der richtigen PHP Version durchführen - bzw. die Platform Definition in der composer.json ändern und dann ein composer update durchführen (egal mit welcher PHP Version). Kommt aber einfach auf die Abhängigkeiten an, ob das notwendig ist.
Was du bei einer PHP Versions Umstellung aber in jedem Fall machen solltest ist den internen/Symfony Cache zu löschen.
Zu deinem aktuellen Problem: die Datenbank Verbindung funktioniert nicht. Rufe das Install Tool mal mit app_dev.php auf.
Ich bin da jetzt grade wieder dran, nachdem meine Webspace- und Domain-Umzugsaktionen weitestgehend abgeschlossen sind. Das Problem besteht nach wie vor. Contao und das Installtool laufen nur mit PHP 5.6. Contao wurde über den Manager mit PHP 5.6 installiert. In der composer.json steht nichts zum Thema "platform". Wie update ich den Composer und den internen symfony cache? Ist das das Zeug unter /var/cache/prod? Das habe ich alles gelöscht und es wurde neu aufgebaut. Und wie rufe ich das Installtool mit app_dev.php auf? Wieso kommt da die Datenbankverbindung nicht zustande? Ich glaube nicht, dass die Datenbankzugangsdaten nicht stimmen. Vielleicht ist es das einfachste, ich lösche das ganze Zeug und installiere nochmal komplett neu mit 7.1. Ist ja eh noch nicht viel passiert außer der Installation und den Systemeinstellungen.
Habe ich gerade auch gemacht. Auf webgo mit dem Manager Contao installiert. Nimm PHP 7.0. In der 7.1 fehlen noch ein paar Dateien bzgl. ioncube und no-debug-non-zts-20160303/ssh2.so.
Die Installation verlief einwandfrei, so wie im Video von Christian https://www.youtube.com/watch?v=Ov0JTctrbSE gemacht. Der Pfad zu PHP ist /usr/bin/php70.
Edit: Ging aber auch vorher mit PHP 5.6.
Hmm, ja, ionCube Loader hatte ich vorhin auch mal ne Meldung mit 7.1. Dann auf 7.0 umgestellt, aber da bekomme ich meine bestehende Installation auch nichts ans laufen. Ich lösche mal eben alles bis auf die contao-manager.phar...
Hast du ne MySQL oder mariaDB? Du weißt ja, dass bei der mariaDB der Host und der Port anders sind.
Host 127.0.0.1
Port 3307
Ich gebe auf für heute :mad:. Bei der Installation hatte ich wieder Meldungen dass irgenwelche Abhängigkeiten die falsche Version haben.
Trotzdem lief die Installation durch und ich konnte das Installtool aufrufen. Aber jetzt ist die Datenbankverbindung fehlgeschlagen, obwohl die Verbindungsdaten definitiv alle stimmen. Mit den Einstellungen komme ich z.B. per phpMyAdmin an die Datenbanken ran. Ich benutze überall den Hauptbenutzer, der sollte doch eigentlich für alle Datenbanken das selbe Passwort haben?!?!? :confused: Wahrscheinlich ist es einfach zu heiß hier, da funktioniert das Gehirn nur noch mechanisch :D.Code:Failed loading /usr/local/ioncube/ioncube_loader_lin_7.0.so: /usr/local/ioncube/ioncube_loader_lin_7.0.so: undefined symbol: zval_update_constant_inline_change
SourceGuardian requires Zend Engine API version 220131226.
The Zend Engine API version 320151012 which is installed, is newer.
Contact SourceGuardian Ltd. at http://www.sourceguardian.com/ for a later version of SourceGuardian.
Failed loading /usr/local/ZendGuardLoader-php-7.0-linux-glibc23-x86_64/ZendGuardLoader.so: /usr/local/ZendGuardLoader-php-7.0-linux-glibc23-x86_64/ZendGuardLoader.so: undefined symbol: zval_used_for_init
Bei meinen Tests mit dem Manager habe ich mir aufgeschrieben, dass es bei PHP 7 Probleme mit MySQL gab und ich habe deshalb in allen Installationen 7.0 (siehe Anmerkung von Andreas) und MariaDB im Einsatz. PHP 5.6 hatte ich nur mal in einer ganz frühen Phase des Managers der Vollständigkeit halber getestet (dort mit MySQL). Lief problemlos.
Meine Probleme sind mit 7.0 und 7.1, allerdings nicht mit MariaDB. PHP 5.6hat jedenfalls schon mal funktioniert. Mit dem neuesten Contao-Manager und PHP 5.6 probiere ich die Installation heute später nochmal.
ich werde heute auch mal das ganze testen... habe einige webgo goPakete.. von kleine bis ganz große...
mal schauen, ob es mir gelingt..
Hallo,
vom Webgo Support habe ich heute die Information bekommen, dass "im laufe der kommenden Woche die Ioncube und Zend-Guard Loader Meldungen bei Webgo behoben werden".
VG
André
Das sind gute Neuigkeiten, ich warte jetzt einfach mal. Die Fehlermeldungen bei PHP 7.0 ändern sich gerade mal wieder. ich habe aktuell seit heute Morgen noch eine zusätzliche Warnung bzgl. ImageMagick:
Ich hoffe doch, dass ImageMagick irgendwann wieder geladen werden kann, damit sich die Vorteile der neuen Contao-Version diesbezüglich auch auswirken können.Code:webxx@sxxx ~ # php70 -v
Failed loading /usr/local/ioncube/ioncube_loader_lin_7.0.so: /usr/local/ioncube/ioncube_loader_lin_7.0.so: undefined symbol: zval_update_constant_inline_change
SourceGuardian requires Zend Engine API version 220131226.
The Zend Engine API version 320151012 which is installed, is newer.
Contact SourceGuardian Ltd. at http://www.sourceguardian.com/ for a later version of SourceGuardian.
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/share/extensions/no-debug-non-zts-20151012/imagick.so' - libMagickWand-7.Q16HDRI.so.0: cannot open shared object file: No such file or directory in Unknown on line 0
PHP 7.0.16 (cli) (built: Feb 22 2017 14:17:42) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
Edit: Wobei man natürlich erst mal testen muss, ob sich die Auswirkung nicht nur auf die Kommandozeile beschränkt und ansonsten alles läuft.
Bei mir ist PHP 7.0 eingestellt und Contao läuft auf einer MariaDB. Nachdem mir der Webgo Support heute freundlicherweise das Problem mit dem ZendLoader im WebHosting behoben hat, habe ich aktuell gar keine Fehlermeldungen.
Ist vielleicht auch abhängig von den Erweiterungen.
Ist bei mir momentan alles Standard wie von Webgo vorgegeben. Das mit imagick.so hatte ich gestern noch nicht auf der Kommandozeile. Wahrscheinlich werden sie deine Änderungen jetzt nach und nach auf die anderen Server übertragen. Deswegen warte ich jetzt erst mal ab, solange meine 4.4.1 Testinstallation läuft und keine Zicken macht.
Im Webspace-Admin kann man unter
Server - php.ini Konfiguration - Eigene php.ini Kofiguration
nachsehen, welche Erweiterungen aufgesetzt sind. Das unterscheidet sich, je nachdem, welche PHP-Version man eingestellt hat.
Letzte Woche war der ioncube_loader in 5.6 und 7.1 aufgesetzt. In 7.1 lief er nicht (Fehlermeldung), weil die Dateien für 7.1 noch nicht existieren. Für 7.0 war er nicht aufgesetzt.
Falls man da jetzt keine Fehlermeldungen bekommt, kann es auch daran liegen, dass ioncube_loader nicht mehr geladen wird ;). Also einfach mal in den php.in im Webspace-Admin nachsehen.
Die Dateien kann man per FTP sehen in
usr/local/
oder auch in
usr/share/extensions/
ssh2.so gab bei mir auf 7.1 auch ne Fehlermeldung weil die Dateien für 7.1 noch nicht verfügbar sind.