Beiträge von kk

Ich denke wir haben die Ursache gefunden. LiveConfig prüft über das Schema der Benutzerdatenbank, wie die Passwörter zu aktualisieren sind. Wenn z.B. MariaDB von 10.3 auf 10.4 aktualisiert wurde, dann kann das zu einer "falschen Entscheidung" führen.
Ein Update ist gerade in Arbeit, ich gebe Bescheid sobald es bereit steht.

Sie können den Status auf "Datenbank erfolgreich angelegt" setzen:

UPDATE DBS SET DB_STATUS=1 WHERE DB_NAME='usr_web30_2';

Problematisch wird es aber, wenn via LiveConfig die erstbeste Datenbank des Benutzers "web30" gelöscht wird - dann wird dieser Benutzer nämlich mit gelöscht.
Ich kläre das gleich mal ab; LiveConfig müsste vor dem Löschen eines Benutzers lediglich prüfen, ob er ggf. noch weitere Datenbanken hat.

Ich habe das eben mit LiveConfig 2.10.1 und MariaDB 10.4.14 unter CentOS 8 getestet - klappt einwandfrei.
Datenbank in LiveConfig angelegt, Anmeldung mit mysql-Cient (via SSH) getestet, klappt.
Datenbankpasswort via LiveConfig geändert, dann wieder via mysql-Client angemeldet, klappt auch.

Handelt es sich bei Ihnen um eine Multi-Server-Installation, oder läuft der Datenbankserver lokal?
Wie haben Sie die Anmeldung getestet? Nur via phpMyAdmin oder auch mal lokal (mit dem mysql-Client)?

Wir haben das Repository heute neu signiert (da der alte Schlüssel ja zum 19.09. abgelaufen ist), die Daten müssen noch synchronisiert werden.

In ca. 30 Minuten sollte wieder alles fehlerfrei funktionieren.

Wir haben das Repository eben aktualisiert, nun steht v2.10.1 zum Download bereit, welche diesen Fehler behebt. Bitte einfach das Update einspielen, dann stimmen die Berechtigungen wieder.

Hintergrund war: die Funktion, welche ggf. die OpCache-Verzeichnisse anlegt (also falls "opcache.file_cache" verwendet wurde und daraufhin ein passendes Verzeichnis angelegt werden musste), rief eine Bibliotheks-Funktion auf, welche wiederum die sogenannte "umask" des Prozesses auf einen zu großzügigen Wert gesetzt hatte. Andere Konfigurationsdateien, die danach vom selben Prozess erzeugt wurden, hatten somit möglicherweise zu offene Berechtigungen.
Das Update (v2.10.1) behebt diesen Fehler und aktualisiert automatisch in diesem Fall alle von einer v2.10.0 geschriebenen Dateien, so dass die Berechtigungen wieder passen.

Ok, danke für die Rückmeldung.
Kurzfristige Lösung: chmod 0600 /etc/logrotate.d/liveconfig-vhosts

Wir prüfen eben wo/warum diese Berechtigung gesetzt wird, ich gebe dann gleich noch mal Bescheid.

Das betrifft offenbar die Datei /etc/logrotate.d/liveconfig-vhosts. Diese hat aber schon immer den Mode 0600, daher kann das mit dem LiveConfig-Update nichts zu tun haben.
Ich höre von dieser Meldung eben auch zum ersten Mal. Was genau liefert denn der Befehl

ls -l /etc/logrotate.d/liveconfig-vhosts

und welche Linux-Distribution/-Version läuft auf dem Server?

Ich habe den Beitrag in ein neues Thema verschoben, es bringt nichts solche Fragen an 8 Jahre alte andere Beiträge anzuklemmen.

Zum Problem: nein, es gibt keine neueren Versionen. Ein lauffähiges Beispiel finden Sie in der LiveConfig-Demo (als admin/admin anmelden).
Die IFRAME-API wird von vielen Kunden aktiv genutzt, der Fehler wird also vermutlich in Ihren Scripten/Webseiten liegen.
Starten Sie als Basis einfach mit den von uns bereitgestellten Beispielen (examples-20120814.zip).

Viele Grüße

-Klaus Keppler

Ab sofort steht LiveConfig v2.10 bereit.
In den "Release Notes" gehen wir dabei auch auf den OpCache ein:

https://www.liveconfig.com/de/blog/2020/09/liveconfig-v2.10/

Viele Grüße

-Klaus Keppler

Es gibt in der Datenbank bislang noch keine Möglichkeit, hier einen entsprechenden Zusatztext zu speichern.
Ich habe das als Feature Request aufgenommen. In dem Bereich wird derzeit ohnehin gearbeitet (das "end-of-life"-Datum wird bereits gespeichert), da sollte also in Kürze was kommen...

Viele Grüße

-Klaus Keppler

Hallo,

das LiveConfig-Team freut sich bekannt geben zu dürfen, dass Version 2.10 ab sofort zum Download bereit steht.

Ausführliche Informationen ("Release Notes") dazu finden Sie hier:
https://www.liveconfig.com/de/blog/2020/09/liveconfig-v2.10/

An dieser Stelle möchte ich mich auch für die vielfältigen Rückmeldungen und die Unterstützung bei der Suche nach Problemen bedanken!

Mit der v2.10 und dem Website-Relaunch haben wir nun zwei "große Brocken" mit teils sehr komplexen Abhängigkeiten erfolgreich ausgerollt, in den nächsten Wochen liegt der Fokus somit wieder ganz auf der Weiterentwicklung von LiveConfig selbst.

Viele Grüße

-Klaus Keppler

Zitat von rex2

Interessant ist, dass wohl bei den meisten anderen Provider die LiveConfig einsetzen, das Problem nicht auftritt.

Das Problem tritt ja nur auf, wenn man von PHP <7.4 auf PHP 7.4.x umstellt, und zu diesem Zeitpunkt Daten im Opcache (auf Festplatte, nicht ihm Shared Memory!) liegen. Im Produktivbetrieb macht das kaum jemand ohne zwingenden Grund ("never change a running system"...). Und ich schätze mal, dass wenn jemand merkt dass unter PHP 7.4 ein Fehler auftaucht, er einfach wieder auf 7.3 zurückstellt und das nicht weiter hinterfragt. Kleine Websites, bei denen die Daten komplett in den Shared Memory passen, werden eventuell auch nicht auf dieses Problem stoßen.

Den PHP-Leuten müsste ja eigentlich klar sein, dass PHP häufig in verschiedenen Versionen parallel eingesetzt wird. Wenn der Opcache dann inkompatibel zu alten Versionen ist, sollte er das doch eigentlich selber prüfen...

Prüfen Sie bitte einen solchen betroffenen Vertrag. Sind da alle Domains auf PHP 7.4 umgestellt, oder sind verschiedene PHP-Versionen aktiv?

Wir bereiten derzeit vor, dass LiveConfig pro PHP-Version ein separates OpCache-Verzeichnis nutzt.

Hallo,

unsere PHP-Pakete für Debian/Ubuntu wurden auf die Versionen 7.3.22 und 7.4.10 aktualisiert.

Außerdem stehen ab sofort Pakete bereit, um PHP 8.0 (beta3) zu testen - und zwar bequem für alle unterstützten Distributionen. Weitere Details siehe Blog/News.

Viele Grüße

-Klaus Keppler

Hmm, sehr interessanter Hinweis - das wäre tatsächlich eine plausible Erklärung.
Der OpCache speichert seine Daten in ~/tmp/<32_Zeichen>/... - wenn da der von PHP 7.3 "compilierte" Opcode herumliegt und dann plötzlich durch PHP 7.4 wiederverwendet wird könnte es krachen.
weltmeister: Sie könnten testweise mal auf PHP 7.4 umschalten und direkt danach das tmp-Verzeichnis komplett leeren:

rm -rf /var/www/<Vertrag>/tmp/*

(bitte vorher natürlich prüfen dass da keine anderen wichtigen Dateien wie z.B. Session-Files o.ä. herumliegen)

Ein Segfault sollte nichts mit Einstellungen in der fcgid.conf zu tun haben.

Richten Sie bitte auf einem betroffenen Webserver eine phpinfo() ein, und schicken uns den Link an support@liveconfig.com, dann gleiche ich das mal mit der phpinfo() eines unserer Testserver ab.

Zitat von weltmeister

Korrekt, das Problem tritt z.B. auch bei einer WP-Installation ohne Plugins oder weiteren Anpassungen auf.
Ansonsten auch bei anderer Software, z.B. Shops usw., die jedoch unter 7.3 tadellos mit OPCache funktionieren.

Äh...?
Bei einer WP-Standard-Installation (wie eben beschrieben) habe ich keine Fehler feststellen können. Ich habe testweise mal das Theme "generatepress" und die ersten 10 der o.g. Plugins installiert - auch ohne Probleme.

Es fällt mir daher etwas schwer zu glauben, dass das tatsächlich auf verschiedenen Servern (separate Hardware) unter Standardbedingungen auftritt. Eine WordPress-Website mit >20 Plugins ist auch schon fast kriminell, trotzdem sollte das keine Segfaults verursachen.

Fazit: ich kann leider keinen Fehler reproduzieren, daher kann ich auch nicht weiterhelfen.
Am besten auch mal auf anderer Hardware (bei VMs also auf einem separaten Host) testen.

Zitat von weltmeister

Auch auf komplett neu aufgesetzten Servern besteht das Problem leider. (Wurde auf 2 neuen Servern getestet) Ich denke mal, das diese Fehler mit dem Bug zusammenhängen müssen.

War auf diesen frisch aufgesetzten Servern auch ionCube aktiviert?

[Nachtrag] ich sehe eben, auf unseren Testservern (Ubuntu 20, Debian 10) war ioncube auch jeweils aktiviert. Scheint nicht zwingend damit zusammenzuhängen.

Zitat

Ansonsten laden Sie in die WP-Installation mal ein paar Themes oder Plugins, der Fehler muss dann jedenfalls auftreten.

Wäre prima wenn Sie eine exakte Anleitung (also konkrete Themes/Plugins) zum Reproduzieren nennen könnten. Eine frische WordPress-Installation (via Appinstaller) läuft problemlos.

Wir haben das inzwischen mal auf folgenden Plattformen getestet:
- Ubuntu 20.04 LTS mit dem "mitgelieferten" PHP 7.4.3
- Ubuntu 20.04 LTS mit dem von LiveConfig bereitgestellten PHP 7.4.9
- Debian 10 mit LiveConfig PHP 7.4.9

in allen Varianten via FPM, OpCache aktiviert (Standardeinstellungen). WordPress installiert und sowohl Frontend als auch Backend aufgerufen - ohne einen einzigen Fehler.

Haben Sie noch irgendwelche anderen PHP-Erweiterungen aktiviert? (insbes. sowas wie ionCube-Loader, Zend Optimizer o.ä.)
Lässt sich das auf anderen Servern (z.B. einer frisch installierten VM) reproduzieren?

Hallo,

der Fehler ist mit LiveConfig v2.10.0-dev20200907-1 behoben, Preview wird in den nächsten 60min aktualisiert.

Viele Grüße

-Klaus Keppler