Laut Ihrem Ticket handelte es sich da um die Version 2.9.3 - das heißt, dass auf diesen Servern LiveConfig seit über einem Jahr nicht mehr aktualisiert wurde.
Den Grund hierfür wird Ihnen nur Ihr System-Administrator erklären können. LiveConfig kann nichts dafür, wenn es nicht aktualisiert wird.
Irgendwie ist alles so ruhig in letzter Zeit...
Und was genau wollen Sie damit sagen, und was hat das mit dem Thema zu tun?
Hmm, ich habe das eben getestet und kann das (noch) nicht reproduzieren.
Um was für einen Account/Vertrag handelt es sich bei dem Hauptbenutzer? Ist das direkt der "admin"-Account, oder ein Kunde?
Wenn Kunde, ist da ein Reseller dazwischen oder ein direkter Webspace-Kunde?
Hat der zugewiesene Vertrag die Eigenschaft "SSL-Verwaltung" aktiviert?
Viele Grüße
-Klaus Keppler
Schwierig.
In "unserem" PHP-7.3 ist XMLRPC enthalten. XMLRPC wurde/wird aber seit einiger Zeit nur stiefmütterlich gepflegt, ohne separate Patches war das schon mit PHP 7.3 nicht mehr zum Laufen zu bekommen. Für PHP 7.4 haben wir das aufgrund mangelnder Nachfrage bislang noch nicht angepasst. In PHP 8 ist XMLRPC übrigens aus PHP rausgeflogen und steht nur noch via PECL (also als "externe" Erweiterung) zur Verfügung.
Schnellste Lösung wäre also PHP 7.3 (statt 7.4) zu nutzen, oder das aus PECL für PHP 8 zu compilieren.
Wir können uns das für PHP 7.4 gerne mal anschauen - da hierfür aber ein Patch geschrieben/angepasst werden muss wird das sicher 1-2 Tage dauern bis wir ein angepasstes Paket bereitstellen können.
Viele Grüße
-Klaus Keppler
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:
