Schau mal in die contao-manager/manager.json. Wenn du die PHP-Version umstellst, dann muss da bestimmt auch immer der entsprechende Wert drin stehen. Beispiel:
Vielleicht Testweise mal mit ner MariaDB probieren.Code:"php_cli": "\/usr\/bin\/php70",
Druckbare Version
Schau mal in die contao-manager/manager.json. Wenn du die PHP-Version umstellst, dann muss da bestimmt auch immer der entsprechende Wert drin stehen. Beispiel:
Vielleicht Testweise mal mit ner MariaDB probieren.Code:"php_cli": "\/usr\/bin\/php70",
Perfekt!
Vielen Dank - das war es. Jetzt lassen sich die Erweiterungen wieder installieren :)
Was war es denn? MariaDB oder "php_cli"?
"php_cli" musste angepasst werden ;)
Ah, das ist gut, dass es nicht die DB war.
Auf dem Server s131 funktionieren momentan keine SSL Verbindungen. zB:Code:# wget https://getcomposer.org/download/1.5.2/composer.phar
converted 'https://getcomposer.org/download/1.5.2/composer.phar' (ANSI_X3.4-1968) -> 'https://getcomposer.org/download/1.5.2/composer.phar' (UTF-8)
--2017-09-13 19:16:17-- https://getcomposer.org/download/1.5.2/composer.phar
Resolving getcomposer.org (getcomposer.org)... 87.98.253.108, 2001:41d0:a:7b19::2
Connecting to getcomposer.org (getcomposer.org)|87.98.253.108|:443... connected.
ERROR: The certificate of 'getcomposer.org' is not trusted.
ERROR: The certificate of 'getcomposer.org' hasn't got a known issuer.
Darüberhinaus ist kein vi verfügbar:Code:# /usr/bin/php71 composer.phar update --prefer-dist --no-dev --optimize-autoloader
Loading composer repositories with package information
[Composer\Downloader\TransportException]
The "https://packagist.org/packages.json" file could not be downloaded: SSL operation failed with code 1. OpenSS
L Error messages:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Failed to enable crypto
failed to open stream: operation failed
Code:# vi composer.json
-shell: vi: command not found
Ist nun gefixed :)
Das Problem bestand wohl nur bei einem Teil der Server oder diesem speziellen Server. Server 124 und 129 hatten jedenfalls dieses Problem nicht. Allmählich entdecke ich immer wieder Dinge, die bei 1&1 geklemmt haben und jetzt plötzlich richtig funktionieren. Zum Beispiel der E-Mail Versand per SMTP. Bei 1&1 musste man einen speziellen SMTP-Server benutzen, also einen anderen als mit dem Mail-Client. Dieser hat SSL nicht unterstützt und war ar***langsam :rolleyes:. Die Weiterleitungsseite kam erst nach einer gefühlten halben Minute, unglaublich. Deswegen hatte ich SMTP deaktiviert, was wegen Spamfiltern gelegentlich auch nicht ganz unproblematisch sein kann. Jetzt, nach dem Umzug des Kunden, klappt das Senden per SMTP und SSL problemlos, die Weiterleitungsseite kommt praktisch sofort.
ja schon klar, das war mir bewusst ;). Wir haben auch noch einige anderer Server bei webgo wo das Problem nicht besteht (oder bereits behoben wurde).Zitat:
Zitat von tab
Was war denn das Problem? Ein Unix ohne vi ist ja fast nicht vorstellbar :D.
Naja, der Pfad zur vi executable muss für den jeweiligen Benutzer in der Umgebung eingetragen sein. Das war wohl nicht der Fall.
Zur Zeit ist das Zertifikat für *.goserver.host abgelaufen ...
Eigentlich peinlich. Aber jetzt scheint’s erneuert worden zu sein …
Ja, jedenfalls ist mein Email-Client jetzt wieder zufrieden :):D
Auf Server s131 noch nicht.Zitat:
Zitat von amateur
In der E-Mail, die ich schon vor 11 Uhr auf meine Anfrage erhalten habe, steht u.a.:
Wenn also das Problem auf deinem Server noch besteht, würde ich empfehlen das zu melden bei webgo. Denn dann ist dein Server bei der manuellen Verlängerungsaktion möglicherweise "übersehen" worden. Bei mir und meinen Kunden ging es jedenfalls bereits wieder, schon bevor die E-Mail bei mir eintraf. Und ich habe die Kundenserver bei meiner Anfrage nicht explizit erwähnt, so dass sie eigentlich nur "meinen" Server kennen konnten.Zitat:
Leider ist es beim automatischen Verlängern der SSL-Zertifikate für vereinzelte Server zu einem Fehler gekommen. Die Technik konnte dies bereits nachhaltig lösen und die Zertifikate manuell verlängern. Der E-Mail Verkehr ist wieder wie gewohnt möglich und auch der Webspace Admin ist in Kürze wieder erreichbar. Sollte Ihr E-Mail Client noch Fehlermeldungen ausgeben, hilft ein Neustart des Programms bzw. Handys um das Problem zu lösen.
Sorry - ich noch einmal :(
Ich hoffe, ich bin in diesem Thread richtig - so ganz weiß ich nicht genau, auf welcher Baustelle ich mich nun befinde.
Das zuvor beschriebene Projekt geht gerade weiter. Ich benötige jetzt die Erweiterung "contao-calendar-ical-bundle".
Die Contao-Version ist inzwischen bei 4.4.5 - PHP läuft mit 7.0
Bei der Installation mit dem Manager bekomme ich als Fehlermeldung:
#11 /home/www/domainname.de/contao-4-x/web/contao-manager.phar.php(55): require('phar:///home/ww...')
#12 {main}
--------------------------------------------------------
Process terminated with exit code 1
Reason: General error
Wie mache ich an dieser Stelle weiter?
Hier gab es ein ähnliches Problem - https://community.contao.org/de/show...with+exit+code - aber so wie ich den Verlauf verstanden habe, war es letztendlich hosterbezoges Problem ... ??
Du hast die eigentliche Fehlermeldung nicht gepostet.
Sorry - Vielleicht war Fehlermeldung der falsche Begriff. :(
Bei der Installation durch den Manager bricht diese irgendwann ab mit der Meldung:
Konsolentask beendet!
Der Hintergrundprozess wurde abgebrochen oder unerwartet beendet. Bitte prüfen Sie das Konsolenprotokoll.
Und am Ende in der Konsole steht eben folgende Meldung:
Process terminated with exit code 1
Reason: General error
Oder ist mit Konsolenprotokoll etwas anderes gemeint?
Du hast von der Fehlermeldung nurgepostet. Da fehlt noch #0 bis #10 des Stack trace und die eigentliche Fehlermeldung (vor #0) ;).Code:#11 /home/www/domainname.de/contao-4-x/web/contao-manager.phar.php(55): require('phar:///home/ww...')
#12 {main}
--------------------------------------------------------
Das Problem liegt an den Sicherheitszertifikaten, die bei Webgo automatisiert sind, aber manchmal einfach nicht eingespielt werden. Gerade auf einem neuen Account gibt es deswegen Probleme und ein Support-Mitarbeiter muss manuell nochmal nachhelfen.
Bin seit kurzen bei Webgo und froh, das es keinerlei Probleme mit Contao 4 gibt und auch alle Features funktionieren.
Oh - vielen Dank für die Geduld.
Ich habe jetzt noch einmal versucht zu installieren, damit ich die komplette Konsolenausgabe einmal rauskopieren konnte - und diese habe ich mir jetzt nochmal angeschaut (das hätte ich auch gleich machen können - aber man lernt ja mit seinen Aufgaben ... )
Ich vermute mal folgende Aussage ist die entscheidende (bevor ich jetzt alles reinkopiere):
[RuntimeException]
Contao Manager Plugin "Craffft\ContaoCalendarICalBundle\ContaoManager\Pl ugin" was not found.
// d.h. das Plugin ist nicht verfügbar und daher läuft die Installation ins Leere?
Scheinbar habe ich mit meiner Aktion noch mehr zerschossen *seufz*
... auf der Manager-Seite ist derzeit folgende Meldung:
ERROR 500 Unknown installation status
Some files were found on your server but no known Contao version could be detected.
You must either manually repair your application or remove the following files and folders to install Contao:
- .gitignore
- README.md
- app
- assets
- composer.json
- composer.lock
- files
- system
- templates
- var
- vendor
Ich habe eben schon im Forum geschaut - da liefen bei den Betroffenen aber trotzdem noch die Live-Seiten. Diese ist bei mir komplett weiß - ebenso kann ich mich nicht ins Backend einloggen.
Ich hoffe echt, das sind gerade persönliche Startschwierigkeiten mit Contao 4 ... :(
Hallo allerseits,
also ich habe gerade ein paar Projekte auf Contao 4.4.8 aktualisiert und es gab keine Probleme, weder mit dem Manager, noch mit den von mir eingesetzten Extensions.
Insofern bin ich sehr zufrieden mit webgo. SSD-Festplatten, SSH, Git, Anpassbarkeit der php.ini, was will man mehr von einem Shared Hosting Paket?
Viele Grüße
Jay
Oops, das Beste habe ich glatt vergessen, den Support.
Keine endlosen Warteschleifen, keine "Ich frage mal in der Technik nach"-Hotline-Dummies, sondern echte Techniker mit Ahnung von der Materie.
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.Zitat:
Zitat von tab
Cache hatte ich natürlich über die Konsole bzw. den Manager nach jeder Änderung gelöscht.
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.
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.
Das muss ich erst mal testen, der Kunde hat bisher nur Contao 3 Websites. Da geht es problemlos mitZitat:
Zitat von mlweb
Also einfach die gleichen Daten die ich auch in Thunderbird oder Windows Live-Mail oder MS Outlook eingebe.Code:SMTP-Hostname: sxxx.goserver.host
SMTP-Benutzername: webyyyp2
SMTP-Passwort: <Das Passwort eben>
SMTP-Verschlüsselung: SSL
SMTP-Portnummer: 465
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?
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.
Gestern Abend hat WebGo bei allen Servern unserer Kunden, die ein Shared Hosting Paket von WebGo benutzen, ohne Vorwarnung die Imagick Extension entfernt :mad:. 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.
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 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
Dürfte doch wohl ein Zertifikate Problem sein. Damit ist natürlich auch der manuelle Weg verbaut wenn ich das richtig sehe.Code:The "https://packagist.org/packages.json" 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 https://packagist.org could not be fully loaded, package information was loaded from the local cache and may be out of date
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. :mad:
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.
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.Zitat:
Zitat von Spooky
Habe ich auch schon. Aber es fängt an zu nerven.
Ich habe jetzt bei den Installationen von mir erst mal kurzerhand den Cache neu aufgebaut. Damit laufen die Seiten auch erst mal wieder.Zitat:
Zitat von tl_richard_user
Auf solche Überraschungen kann ich aber auch gern verzichten. :D
Dank @Spooky hat es bei mir anscheinend noch kein Kunde bemerkt.
Ist nach dem Systemcheck Imagick Extension eigentlich wieder da?
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.Zitat:
Zitat von tl_richard_user
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:Zitat:
Zitat von mlweb
Da sollte dann "imagick" auftauchen bspw.Code:php71 -m | grep -i magick
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.Zitat:
Zitat von mlweb
Schon klar. Ich wollte nur schleunigst die Websiteiten wieder laufen haben, bevor ich Kundenbeschwerden habe.Zitat:
Zitat von Spooky
Ist ja interessant.Zitat:
Zitat von Spooky