Hoster Webgo

[Andreas]

Ich habe das zwar noch nicht probiert, aber mir ist letztens aufgefallen, dass ich bei easybill den Benutzernamen anstatt web42p1 auf web42 einstellen musste.

Ansonsten habe ich im Thunderbird

• Port 465
• SSL/TLS
• Authentifizierung: Passwort normal

In der Hilfe sieht man bei Authentifizierung soll man "Automatisch erkennen" einstellen, das hat mein Thunderbird aber nicht.

[mlweb]

Mit normalen Versand hab ich kein Problem. Trage ich allerdings die Daten entsprechend in die parameters.yml ein wird das Kontaktformular nicht versendet. Versand über php Mail funktioniert.

[tab]

Kannst Du mal sagen, was Du bei Webgo für Contao 4 in die parameters.yml eingegeben hast. Mir ist es bis jetzt nicht gelungen SMTP-Versand einzurichten.
Cache hatte ich natürlich über die Konsole bzw. den Manager nach jeder Änderung gelöscht.

Das muss ich erst mal testen, der Kunde hat bisher nur Contao 3 Websites. Da geht es problemlos mit

SMTP-Hostname: sxxx.goserver.host
SMTP-Benutzername: webyyyp2
SMTP-Passwort: <Das Passwort eben>
SMTP-Verschlüsselung: SSL
SMTP-Portnummer: 465

Also einfach die gleichen Daten die ich auch in Thunderbird oder Windows Live-Mail oder MS Outlook eingebe.

[tab]

Hmm, ich hoffe, mein Kunde hat einfach ein wenig Pech. Erst steigt die Downloadzeit in den Crawling-Statistiken durchschnittlich von ca 220ms auf ca 430ms. Und vorhin als ich mir gerade mal eben die SMTP-Einstellungen im Backend ansehen wollte, war das Zertifikat abgelaufen, obwohl automatische Verlängerung angehakt war. Als Laufzeit war im Webspace-Admin der 13.12.2017, also heute, angezeigt. Es besand aber offenbar kein gültiges Zertifikat mehr. Keine Ahnung, ob da ein Mißverständnis zwischen Let's Encrypt und WebGo bzgl. der tatsächlichen Gültigkeitsdauer besteht und das Zertifikat in Wirklichkeit eventuell nur bis zum 12.12.2017 lief und von Webgo heute noch automaisch verlängert worden wäre. Jetzt habe ich es jedenfalls manuell gemacht und alles läuft wieder.

Da werde ich wohl morgen mal den Support auf die beiden Probleme ansprechen müssen, wobei das mit der Downloadzeit auch andere Ursachen haben könnte. Zum Beispiel das Contao-Update auf 3.5.31, der Zeitpunkt des Anstiegs korreliert auffallend gut mit dem Termin des Updates. Hat da sonst noch jemand etwas Ähnliches bemerkt?

[mlweb]

Mit mailer_encryption ssl hat es bei mir jetzt auch geklappt. Danke @tab. Ich hatte es wegen dieser Info https://www.e-recht24.de/news/abmahn...abmahnung.html über tls versucht. Bisher habe ich mich für die Kontaktformulare bei den kleinen Seiten meist mit php-Mail zufrieden gegeben.

[Spooky]

Gestern Abend hat WebGo bei allen Servern unserer Kunden, die ein Shared Hosting Paket von WebGo benutzen, ohne Vorwarnung die Imagick Extension entfernt . Das hatte zur Folge, dass alle Contao 4 Installationen plötzlich nicht mehr funktioniert haben - da beim Aufbauen des Symfony Cache registriert wird, welche Bildbearbeitungsbibliothek benutzt wird.

[tl_richard_user]

So, bei mir seh ich das auch gerade
"Ein Fehler ist aufgetreten"

Bist du an dem Problem dran?

EDIT: Der Support hat einen System-Check durchgeführt (das kann man auch im Webspace-Admin machen), nun läuft es wieder.

[mlweb]

Ja ich habe bei einem Paket seit einiger Zeit auch meine Probleme. Nach einer Serverwartung wegen Performanceproblemen um den 20.01 rum gingen keine Updates mehr. Weder ssh noch Contao-Manager. Auch wenn das im Grund nicht ganz so problematisch ist, man kann es ja manuell auf der eigenen Entwicklungsumgebung machen. Trotzdem hatte ich ausgiebig Kontakt mit dem Support. Gestern nach dem noch einmal etwas umgestellt wurde - was genau erfährt man ja nie - dann auf der Konsole folgende wenig erbauliche Meldung auf der Konsole

The "[URL]https://packagist.org/packages.json[/URL]" file could not be downloaded: SSL operation failed with code 1. OpenSSL Error messages:

  error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed Failed to enable crypto failed to open stream: operation failed [URL]https://packagist.org[/URL] could not be fully loaded, package information was loaded from the local cache and may be out of date

Dürfte doch wohl ein Zertifikate Problem sein. Damit ist natürlich auch der manuelle Weg verbaut wenn ich das richtig sehe.

Imagemagick ist bei dem betroffenen Server nicht das Problem aber bei allen anderen Installationen.

Wird es mal wieder Zeit umzuziehen? Die Probleme häufen sich. Leider.

[Spooky]

Ja, die Probleme mit SSL Verbindungen über die Konsole treten immer wieder mal auf den Servern von WebGo auf. Das musst du dem Support sagen, die müssen das fixen. Du kannst ihnen das auch mit einem normalen wget deutlich machen.

[tab]

Gestern Abend hat WebGo bei allen Servern unserer Kunden, die ein Shared Hosting Paket von WebGo benutzen, ohne Vorwarnung die Imagick Extension entfernt . Das hatte zur Folge, dass alle Contao 4 Installationen plötzlich nicht mehr funktioniert haben - da beim Aufbauen des Symfony Cache registriert wird, welche Bildbearbeitungsbibliothek benutzt wird.

Oops, das ist ein absolutes NoGo! Nicht, dass ich das Imagick für alle Kunden unbedingt brauchen würde, die ich eigentlich nach und nach im Zuge des Updates auf Contao 4 nötigenfalls zu Webgo umziehen wollte. Aber einfach so ohne Vorwarnung entfernen, das geht nun wirklich nicht. Ich will mal hoffen, dass das ein einmaliger "Unfall" ist und bald behoben wird.

[mlweb]

Habe ich auch schon. Aber es fängt an zu nerven.

[mlweb]

EDIT: Der Support hat einen System-Check durchgeführt (das kann man auch im Webspace-Admin machen), nun läuft es wieder.

Ich habe jetzt bei den Installationen von mir erst mal kurzerhand den Cache neu aufgebaut. Damit laufen die Seiten auch erst mal wieder.


Auf solche Überraschungen kann ich aber auch gern verzichten.

Dank @Spooky hat es bei mir anscheinend noch kein Kunde bemerkt.

Ist nach dem Systemcheck Imagick Extension eigentlich wieder da?

[Spooky]

So, bei mir seh ich das auch gerade
"Ein Fehler ist aufgetreten"

Bist du an dem Problem dran?

EDIT: Der Support hat einen System-Check durchgeführt (das kann man auch im Webspace-Admin machen), nun läuft es wieder.

Ja, ich bin im Kontakt mit dem Support. Sie prüfen gerade ein globales Roll-Out, damit man nicht selbst überall den System Check anstoßen muss.

[Spooky]

Ich habe jetzt bei den Installationen von mir erst mal kurzerhand den Cache neu aufgebaut. Damit laufen die Seiten auch erst mal wieder.

Dadurch wird jetzt allerdings nur die GD verwendet. Wenn du wieder die Imagick haben willst, müsstest du den Cache neu aufbauen, sobald Imagick beim Web Prozess und auf der Konsole verfügbar ist. Beim Web Prozess überprüfst du das mit phpinfo();, auf der Konsole zB so:

php71 -m | grep -i magick

Da sollte dann "imagick" auftauchen bspw.

Ist nach dem Systemcheck Imagemagick eigentlich wieder da?

Im Web Prozess ja, zumindest bei den Accounts die ich zur Hand habe. Auf der Konsole nicht, das musst der Support fixen. Bzw. das eigentlich Problem war, dass sie zwei verschiedene PHP CLIs hatten: /usr/bin/php71 (das hatte ich immer verwendet) und /usr/bin/php7.1. Letzteres ist die neueste PHP CLI, wo auch Imagick aktiv ist, bei ersterem nicht (mehr) seit gestern. Auf den von mir getesteten Servern sollte /usr/bin/php71 nun auch ein Symlink auf /usr/bin/php7.1 sein.

[mlweb]

Dadurch wird jetzt allerdings nur die GD verwendet. Wenn du wieder die Imagick haben willst, müsstest du den Cache neu aufbauen.

Schon klar. Ich wollte nur schleunigst die Websiteiten wieder laufen haben, bevor ich Kundenbeschwerden habe.

Bzw. das eigentlich Problem war, dass sie zwei verschiedene PHP CLIs hatten: /usr/bin/php71 (das hatte ich immer verwendet) und /usr/bin/php7.1. Letzteres ist die neueste PHP CLI, wo auch Imagick aktiv ist, bei ersterem nicht (mehr) seit gestern. Auf den von mir getesteten Servern sollte /usr/bin/php71 nun auch ein Symlink auf /usr/bin/php7.1 sein.

Ist ja interessant.