Heute nach den Wartungsarbeiten von netcup am Wirtssystem, funktionierte alles wieder wie vorher!
Was geändert wurde, weiß ich nicht!
Heute nach den Wartungsarbeiten von netcup am Wirtssystem, funktionierte alles wieder wie vorher!
Was geändert wurde, weiß ich nicht!
Weitere Schritte bzgl. socket-Timeout:
Ich habe jetzt in der PHP-Datei mit dem socket-Aufruf den default-socket-Timeout direkt gesetzt. Also ini_get('default_socket_timeout') einfach durch 600 ersetzt, da das über die .htaccess nicht möglich ist.
Das hatte zur Auswirkung, dass ich erstmal die Meldung "504 Gateway Time-out" erhielt :disappointed: .
Aber in der Folge haben die Installer-Aufrufe mit einer Verzögerung von ca. 120-130s funktioniert. Hat die Antwortzeit 180s überschritten, dann erschien wieder "504 Gateway Time-out".
Zwischendrin erfolgte der Aufruf nach einigen ms ... und dann brauchte es wieder 120s.
Zumindest konnte ich so mit etwas Geduld die AddOns aktualisieren!
Außerdem habe ich inzwischen neue Informationen von netcup bekommen:
In keiner der Mails war der Hinweis enthalten, dass dies irgendwie mit meiner Support-Anfrage zusammenhängt.
Na! Mal abwarten, ob das an meinem Problem irgendetwas ändert.
So! Netcup hat sich per E-Mail gemeldet:
Quoteausgehende Verbindungen werden von unserer Seite nicht blockiert. Auch ein eigener Test auf dem Server konnte erfolgreich Daten von https://www.redaxo.org:443/ abrufen.
Ja! Dieser Test funktioniert. Das hatte ich selbst schon getestet.
ABER in den Serverlogs steht ja dass der Fehler beim Öffnen einer Socket-Verbindung mit der PHP-Funktion stream_socket_client() auf die URL ssl://www.redaxo.org:443 nicht funktioniert.
Das sollten sie doch eigentlich testen
Noch eine E-Mail an den Support geschickt.
Hatte von Euch schon einmal ein ähnliches Problem mit socket-Verbindungen nach extern?
Auf einem Webhosting-Paket läuft das CMS Redaxo (https://radaxo.org).
Untenstehenden Fehler habe ich heute auch an den netcup-Support gemeldet.
Vielleicht hat aber jd. von Euch bereits vorab einen Tipp, woran das liegen könnte.
Fehlermeldung im Backend von Redaxo beim Aufruf vom Installer (Installation von AddOns):
QuoteDer Webservice ist zurzeit nicht erreichbar
Parallel dazu erfolgt in den Serverlogs der Domain folgender Eintrag:
QuoteApache-Fehler:
mod_fcgid: stderr: Die Wartezeit f\xc3\xbcr die Verbindung ist abgelaufen (110), referer: https://www.meine-domain.de/re…hp?page=system/log/redaxo
Ich habe dann versucht den Fehler mit PHP-Debug-Meldungen weiter einzugrenzen:
Quotestream_socket_client(): Unable to connect to ssl://www.redaxo.org:443 (Die Wartezeit für die Verbindung ist abgelaufen)
Es dürfte ein Timeout sein, der nach 60s auftritt!
Da ich noch auf ein weiteres netcup-Webhostingpaket Zugriff habe, machte ich dort auch einen Test:
Dort läuft Redaxo ohne Probleme und dieser Fehler kommt nicht.
Kann es sein, dass Redaxo manche Webhosting-Server unterschiedlich konfiguriert sind?
--- andere Firewall-Einstellungen? (Blockieren von socket-Verbindungen?)
Hat jd. von Euch schon mal ähnliches erlebt.
Wer weigert sich, was zu tun? Leider kann ich deinem Bild von der aktiven Liste nicht entnehmen, ob du eine Hauptdomain oder eine Subdomain geöffnet zeigst. Das Kreuzsymbol "Subdomain entfernen" erscheint natürlich nur bei einer Subdomain. Es ist bei mir auch in der aktiven Liste bei ausnahmslos jeder Subdomain vorhanden.
Stimmt! Bei der Darstellung "aktive Liste" ist das zu sehen!
ABER leider nicht bei der neuen Darstellung "dynamische Liste". Da fehlt diese Option
Es gibt zwar "Subdomain deaktivieren" ... aber das hat eine andere Funktion.
Bei mir funktioniert das noch, so wie oben beschrieben.
Was war nun das Problem?
Ich habe den Beitrag auch als Reminder für netcup.de geschrieben
Nachdem das nun doch schon mehr als 1 Jahr bekannt ist, fragte ich mich, warum das nicht bereits entsprechend für die neue Ansicht hinzugefügt wurde.
Webhosting // Plesk:
Die Möglichkeit "Subdomain entfernen" fehlt in Ansicht "Dynamische Liste".
Der Button "Subdomain entfernen" existiert nur in der Ansicht "Aktive Liste". ==> Warum?
Just for information my settings ...
Maybe some of the settings are not necessary. I do not know.
But as long it works, I leave as it is ...
1. My php settings:
2. in the web folder httpdocs/domain.example/cloud/nextcloud
I have a symlink to httpdocs/domain.example/cloud/nextdata
3. httpdocs/domain.example/cloud/nextcloud/config/config.php
4. httpdocs/domain.example/cloud/nextcloud/config/data.config.php
I installed "Nextcloud Hub II (23.0.0)" on Webhosting 4000.
I have similar settings, but I do not have a tmp folder in httpdocs and no tmp folder in httpdocs/domain.example/cloud/nextcloud.
My data folder is: httpdocs/domain.example/cloud/nextdata.
Updates work ... upload works ... and there are no error messages in the log file
Wenn mich nicht alles täuscht, gibt es beim Webhosting diff und patch, man könnte also einfach den verlinkten Pull Request anwenden...
OK! Ja, das ist sicher möglich. ... und gut, wenn es einigen von Euch hilft
Ich will aber am Produktivsystem das aktuell nicht durchführen.
Solange alles funtioniert trotz der Fehlermeldungen, warte ich einfach auf die nächste Version mit den Änderungen.
Habe folgendes Issue auf github gefunden:
==> https://github.com/nextcloud/server/issues/27759
Siehe folgenden Kommentar:
==> https://github.com/nextcloud/s…59#issuecomment-884633434
Es ist mir aber zu viel Aufwand, das jetzt per Hand zu ändern ...
Ich habe Nextcloud 20.0.11 auf einem "Webhosting 4000 SE de a1" Paket laufen.
Die genannte Fehlermeldung erscheint bei mir ebenso im Log-File:
QuoteError: file_exists(): open_basedir restriction in effect. File(/templates/) is not within the allowed path(s): (/var/www/vhosts/hostingxxxxxx.xxxxx.netcup.net/:/tmp/:/var/lib/php/sessions) at /var/www/vhosts/hostingxxxxxx.xxxxx.netcup.net/httpdocs/mydomain.tld/cloud/nextcloud/lib/private/Template/Base.php#68
Weiterer Fehler:
QuoteError: file_exists(): open_basedir restriction in effect. File(/img/app.svg) is not within the allowed path(s): (/var/www/vhosts/hostingxxxxxx.xxxxx.netcup.net/:/tmp/:/var/lib/php/sessions) at /var/www/vhosts/hostingxxxxxx.xxxxx.netcup.net/httpdocs/mydomain.tld/cloud/nextcloud/lib/private/Template/IconsCacher.php#132
Bisher habe ich keine Möglichkeit gefunden diese Fehler zu beheben ...
Abgesehen davon läuft Nextcloud 20 bisher ohne Probleme.
MIttlerweile ist Nextcloud 22 draußen und es läuft interessanterweise weiterhin ohne jegliche erkennbare Probleme mit MySQL 5.7.
Das will ich nun doch lieber nicht riskieren
@Admin-Team / @[netcup] / @Support :
Gibt es hier etwas neues?
Ich habe das bei mir in RainLoop aktiviert.
Server = Mail-Server / Port = 4190
Wäre wirklich schön, wenn hier der Port 106 geöffnet wird für POPASSD.
Diesen Wunsch habe ich auch!
Habe das Template umgeschrieben und ein Link zum Passwort ändern, hinzugefügt.
... und leider muss man mit jedem Update von RainLoop das Template wieder neu anpassen.
Gibt es inzwischen eine Möglichkeit von RainLoop aus das Mail-Passwort zu ändern?
Wenn ja, welche Methode ist da erlaubt?
Vielen Dank,
Guido
Bei mir ist das auch noch immer so:
bash-4.3$ /usr/local/php72/bin/php --version
PHP 5.6.40-0+deb8u1 (cli) (built: Feb 17 2019 01:19:33)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies
bash-4.3$
Ich habe das jetzt ebenfalls über CCP gemeldet.