Die Meldung besagt eigentlich nur, dass lcsam korrekt (regulär) beendet wurde (siehe Code).
Kann es sein, dass z.B. der OOM-Killer zuschlägt? Ich würde mal schauen was zu so einem Zeitpunkt in /var/log/messages und /var/log/syslog steht, bzw. was journalctl da protokolliert hat.
Viele Grüße
-Klaus Keppler
Ab sofort stehen die PHP-Versionen 8.0.3 und 7.4.16 zum Download bereit. Da wurden die PID-Pfade auch von /var/run/ auf /run/ angepasst.
Bei allen anderen PHP-Paketen werden wir das nur/erst dann anpassen. wenn es dafür noch mal Updates gibt (aus dem inoffiziellen Backport-Repository).
Viele Grüße
-Klaus Keppler
Dieser Fehler tritt auf, wenn mod_php verwendet wird (dann "fehlt" intern eine Variable). Wir kümmern uns darum - wird voraussichtlich mit dem nächsten Update (2.11.3) behoben sein.
Die Kombination "mod_php aber kein php-cli" gab's bislang offenbar noch nie. 
Viele Grüße
-Klaus Keppler
Voraussichtlich diese Woche werden die nächsten PHP-Updates erscheinen, da werden wir das dann direkt anpassen.
Viele Grüße
-Klaus Keppler
Plesk ist halt wirklich deutlich günstiger. Wenn ich sehe, dass bei Ionos das Plesk für den VServer schon für 1 EUR zu haben ist.
Öhm. Naja. Plesk hat in den letzten drei Jahren seine Preise 2x angehoben, teilweise drastisch.
Die "normalen" Preise finden Sie auf der Plesk-Website, und die schauen ganz anders aus...
Die o.g. Preise bei Ionos sind Bundling-Preise, d.h. diese Lizenzen sind an Produkte von Ionos gebunden und somit nicht vergleichbar. Ich weiß (leider) auch von Anbietern, die bestimmte Controlpanels nur aufgrund einer wettbewerbsverzerrenden Exklusivitätsvereinbarung konkurrenzlos günstig anbieten können.
Am besten sagen Sie Ionos, dass die bitte vergleichbare VPS-Produkte auch mit LiveConfig-Lizenzen anbieten sollen (und die sich dazu mal bei uns melden sollen)
Was Let's Encrypt in einer "kleinen" Lizenzversion betrifft wird es im Laufe des Jahres sicherlich was Neues geben.
Viele Grüße
-Klaus Keppler
Exakt. Einfach LiveConfig aktualisieren (tut nicht weh
Wenn es sich um stark veraltete Systeme handelt und ein Upgrade nicht möglich ist, bitte an support@liveconfig.com wenden (auch dafür gibt's ne Lösung).
Das Update (v2.11.2) steht ab sofort in den Repositories online.
Viele Grüße
-Klaus Keppler
Fehler ist bereits behoben, Update läuft gerade durch die Pipeline (2.11.2), sollte in ca. 45 Minuten online gehen.
Für die Unnannehmlichkeiten bitte ich um Entschuldigung.
Die Abfrage, welche PHP-Versionen mit wie vielen Subdomains genutzt werden, enthielt in 2.11.0 einen Fehler (die Standard-Version wurde bei Multi-Server-Systemen als Summe über alle Server gezählt). Den Fehler hatten wir mit 2.11.1 behoben. Wie sich nun gezeigt hat kann es aber Fälle geben, in denen in einer Spalte NULL (statt 0) zurückgegeben wird, was in den JSON-Daten für die Tabelle zu einem Darstellungsfehler führt.
("Standardversion" bedeutet ja dass bei der jeweiligen Domain eben keine konkrete PHP-Version ausgewählt ist - und das mit einem SQL auszuwerten ist nicht ganz trivial
Danke für die Rückmeldung.
Dennoch empfehle ich das eigentliche Problem zu beheben - die langsamen Reverse-DNS-Anfragen.
Nö, LiveConfig hat damit prinzipiell überhaupt kein Problem.
Ein /usr/bin/php wird nur für den AppInstaller benötigt (um die Installation einiger Anwendungen anzustoßen), da spielt NTS/ZTS aber keine Rolle.
Wenn möglich installieren Sie das ZTS-PHP-CLI in einem komplett separaten Pfad (z.B. /opt/php-7.4-ts), dann gibt's auch keine Probleme mit anderen PHP-Versionen oder -Extensions.
Bislang bauen wir bewusst keine ZTS-Version. Diese wird praktisch nie gebraucht (außer eben in einzelnen Sonderfällen). Zudem ist unklar ob Sachen wie der Opcache, ionCube u.v.m. mit Threads zurecht kommen.
Anders formuliert: wer tatsächlich Multithreading innerhalb einer PHP-Instanz benötigt, der hat so spezielle Anforderungen, dass man da mit "Paketen von der Stange" oft nicht weit kommt. Im Shared Hosting spielt pthreads keine Rolle.
Ein Eintrag in der /etc/aliases der Form "mailping: mailping" fuehlt sich falsch an.
Muss man positiv sehen: das bedeutet, dass man Mails an diesen Account explizit akzeptiert.
Sieht natürlich verdächtig nach Rekursion aus, aber da muss man halt die Augen zumachen...
Sie sorgt leider dafuer, dass Mails an Linux-User / System-User (user@$myhostname) abgewiesen werden:
Code-> RCPT TO:<mailping@hostname.fqdn> <** 550 5.1.1 <mailping@hostname.fqdn>: Recipient address rejected: User unknown
Ja, das ist so beabsichtigt (siehe auch Changelog: "E-Mails an lokale Accounts werden abgelehnt, außer wenn diese in /etc/aliases enthalten sind")
Wenn Sie einen lokalen Account für Tests nutzen, nehmen Sie diesen einfach in /etc/aliases auf (und führen ggf. den Befehl "newaliases" aus).
Hintergrund ist: wenn Kunden über den Aufruf von sendmail E-Mails verschicken ohne einen korrekten "Envelope-From" (Paramater "-f") anzugeben, dann gehen diese mit dem Absender <vertrag>@<hostname> raus. Diese Adresse kann aber an sich keine Mails empfangen - daher ist es auch logisch, E-Mails an diese abzulehnen.
Und egal welcher Resolver es wird: er sollte DNSSEC unterstützen.
(persönlich bevorzuge ich die Resolver des RZ bzw Uplinks sofern diese zuverlässig sind)
Bei 8.8.8.8 muss man halt wissen, dass Google die sicherlich nicht bereitstellt um die Welt ein Stück besser zu machen.
Danke für die Rückmeldungen - das Sprachpaket wurde leider nicht ins Release committed. :-/ Update ist bereits in Arbeit.
Wir werden das ins kommende Update (v2.11.1) aufnehmen, wird noch diese Woche bereitgestellt.
Unabhängig davon noch zwei Hinweise:
Hallo,
ab sofort steht LiveConfig v2.11.0 zum Download bereit. Alle weiteren Informationen zu diesem Update finden Sie in diesem Artikel.
Viele Grüße
-Klaus Keppler
Weil dieses Thema hier noch als Issue offen war: LiveConfig setzt den sql_mode für seine eigene Verbindung automatisch auf einen passenden Wert (aktuell: NO_ENGINE_SUBSTITUTION,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER).
Daher verwundert mich die o.g. Fehlermeldung, wir haben das hier auch unter Ubuntu 20 mit MariaDB 10.5 nicht reproduzieren können.
Falls der oben beschriebe Fehler also noch mal auftritt, geben Sie uns bitte Bescheid (am besten an support@liveconfig.com)
Viele Grüße
-Klaus Keppler
Hallo,
eine "Konsolidierung" gibt's aktuell leider nicht nicht. Das Problem ist, dass die Daten auf zwei separate Datenbanken aufgeteilt und zusammengeführt werden müssten (inkl. Prüfung auf doppelte Benutzernamen, Anpassung der User-IDs, usw.).
Es wird aber eine Export/Import-Funktion kommen, mit der so etwas realisiert werden kann - einen fixen Zeitpunkt kann ich aber noch nicht angeben.
Ggf wäre es eine Option, auf dem einen leistungsfähigeren Server zwei VMs (KVM/Xen/...) aufzusetzen und somit die bisherigen Server 1:1 umzuziehen.
Viele Grüße
-Klaus Keppler
Das behebt nicht die Ursache, sondern lindert nur die Symptome.
Ursache ist schlicht ein Mißbrauch des Mailversands, i.d.R. durch veraltete Scripte oder ungepatchte Sicherheitslücken in Webanwendungen.
Ein vorgeschaltetes Mail-Gateway löst das Problem der wachsenden Mailqueue nicht, und wird bei eingehenden Mails zwangsläufig zu Bounce-Problemen führen.
Alle relevanten Informationen finden sich in /var/log/mail.log. Ich würde z.B. einfach mal mit "grep" nach dem ersten Auftreten der entsprechenden Message-ID suchen (grep B5919481832 /var/log/mail.log)
Viele Grüße
-Klaus Keppler
