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
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.
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.
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.
ZitatAnsonsten 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
Log-Dateien prüfen?
Ist der schnellste und einfachste Weg. Akute Spammer springen normalerweise sofort ins Auge.
"Ausgehende Spam-Listen" gibt's nicht. Sie können aber den SpamAssassin mit LiveConfig so einrichten, dass auch ausgehende E-Mails analysiert und ab einer bestimmten Punktzahl abgewiesen werden.
Hierfür müssen Sie das Tool "lcsam" mit den Parametern "-a" (ausgehende Mails scannen) und "-A <Punktzahl>" (ablehnen ab bestimmter Punktzahl) starten - alle Details finden Sie in der man-Page zu lcsam.
Auf systemd-basierten System führen Sie hierzu den Befehl "systemctl edit lcsam.service" aus und tragen dann folgende Zeilen in die Override-Datei ein:
[Service]
ExecStart=
ExecStart=/usr/lib/liveconfig/lcsam -g spamd -U postfix -a -A 6Danach lcsam neu starten (systemctl restart lcsam). Das macht aber alles nur Sinn, wenn ein Admin da auch ein Auge drauf hat.
Der Versand ausgehender Mails kann subjektiv etwas langsamer werden, da die Mails noch während der SMTP-Verbindung gescannt werden - von einem Dauereinsatz rate ich also ab.
Viele Grüße
-Klaus Keppler
Wie kommt Liveconfig an diese alte Resolver-Adresse?
LiveConfig fragt direkt bei den zuständigen Nameservern an und nutzt normalerweise keine Resolver. Auf diese Weise stellt LiveConfig sicher, dass z.B. DNSSEC korrekt konfiguriert ist (falls aktiviert).
LiveConfig kann aber in Ausnahmefällen so konfiguriert werden, dass es für DNS-Anfragen trotzdem den System-Resolver verwendet (z.B. wenn keine ausgehenden DNS-Requests erlaubt sind).
Mit welchen Web-Anwendungen lässt sich das Problem reproduzieren?
Genügt z.B. eine WordPress-Standardinstallation?
Wenn ja, dann können wir das gerne mal auf anderen Servern testen.
Edit: Sofern das kein Limit durch MariaDB/SQL ist: Bitte längere Namen ermöglichen
Das ist leider tatsächlich ein historisch bedingtes Limit von MySQL selbst: bis v5.7.8 sind nur 16 Zeichen für Benutzernamen erlaubt, ab 5.7.8 liegt das Limit immerhin bei 32 Zeichen.
Da der Wunsch schon mehrfach von anderer Seite geäußert wurde, werden wir das in einem der kommenden Updates angehen.
(ist nicht ganz trivial, weil LiveConfig somit prüfen und "wissen" muss, welche DB-Version zum Einsatz kommt und welche Limits die jeweils hat).
Das selbe gilt übrigens auch für IP-Limits bei den Zugriffsberechtigungen (nur neuere DBs unterstützen etwa IPv6-Adressen).
Viele Grüße
-Klaus Keppler
Mit v2.10.0 wird das Limit von 512 auf 4096 Zeichen erhöht (gilt für alle Text-Einstellungen in php.ini) - das sollte das Problem also beheben.
Eine eigene php.ini kann man derzeit nicht anlegen/einbinden (bei FPM sind die php.ini-Einstellungen zudem ja in der Pool-Konfigurationdatei).
Workarounds wären:
- wenn Sie FPM einsetzen: die Änderung direkt in der FPM-Pool-Konfiguration vornehmen (z.B. /etc/php-fpm/php73-fpm.d/<Vertrag>.conf) und diese Datei mittels "chattr +i" gegen Überschreiben schützen
- im Datenbankschema mittels "ALTER TABLE ..." die Zeichenbegrenzung von 512 auf 4096 vergrößern und die gewünschten Daten direkt in der Datenbank bearbeiten (wie immer bei Datenbankeingriffen: bitte seeehr sorgfältig arbeiten)
Beide Varianten "beißen" sich nicht mit dem anstehenden v2.10-Update.
Viele Grüße
-Klaus Keppler
Guten Morgen,
sehr merkwürdig - das klingt danach dass irgendwie ältere Dateien zurückgespielt wurden (evtl. eine häßliche Nebenwirkung eines korrupten Journaling-Filesystems?)
Am besten nehmen Sie sich testweise mal irgendeine der betroffenen Domains her. Bearbeiten Sie im LiveConfig einfach den zugehörigen Vertrag (d.h. den Vertrag oder irgendeine Domain/Subdomain dieses Vertrags neu speichern) - das führt dazu, dass LiveConfig die vHost-Konfiguration und alle zugehörigen Zertifikate neu schreibt. Nach 60 Sekunden einfach mal ausprobieren ob die Zertifikate dann stimmen.
Wenn das geklappt hat, bearbeiten Sie unter Server -> Serververwaltung -> Web die IP-Gruppe(n) (es genügt z.B. an den Namen der IP-Gruppen z.B. einen Punkt anzufügen). Das führt dazu, dass alle vHost-Konfigurationen neu geschrieben werden.
Viele Grüße
-Klaus Keppler
Durchaus möglich dass das allgemein PHP 7.4 betrifft. Ohne weitere Log-Infos zum eigentlich Fehler wird man da aber nicht weiter kommen.
Mein Verhältnis zum OpCache ist etwas zwiegespalten (die Tatsache, dass bei FPM der Shared Memory zwischen allen Pools geteilt wird, ist einfach unterirdisch und weltfremd).
Wenn's mit PHP 7.3 funktioniert und mit 7.4 nicht mehr (ich nehme an, bei der selben Website?), dann deutet das wohl auf ein Problem in PHP selbst hin. LiveConfig hat damit tatsächlich nichts am Hut. 
Was Sie machen können:
... und dann mal schauen ob irgendwelche weiteren Informationen in den Logs auftauchen.
Die Apache-Meldung "Connection reset by peer" bedeutet i.d.R. dass der PHP-Prozess während der Verarbeitung der Anfrage abgeraucht ist. Das sollte prinzipiell auch nicht ohne Log-Einträge passieren. Manchmal taucht auch was in den System-Logs auf (/var/log/messages, /var/log/syslog; insbes. wenn ein SEGFAULT aufgetreten ist).
Eine vielleicht "blöde" Frage: wo findet man diese PHP-Paket und bedeutet dies, das man IonCube nicht mehr manuell (in die php.ini) einbinden muss?
So blöd ist die Frage gar nicht, ich sehe dass das noch gar nicht dokumentiert ist. Wird gleich nachgeholt.
Die Pakete nennen sich "php-x.y-opt-ioncube" und sind in unseren "normalen" PHP-Repositories enthalten. Mit der Installation werden diese auch automatisch in die php.ini mit aufgenommen (via /opt/php-x.y/etc/conf.d/ioncube.ini).
