Beiträge von kk

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.

Zitat von ksmx

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...

Zitat von ksmx

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:

• Sie können auch eigene Anweisungen in die proftpd.conf aufnehmen die LiveConfig nicht überschreibt - ist ab sofort im Admin-Handbuch dokumentiert.
• das Reverse-DNS-Problem sollte trotzdem geklärt werden, da das sowohl beim Mailempfang als auch bei Kundenwebsites Probleme machen kann. Ggf. "tote" Resolver entfernen oder andere Resolver verwenden (/etc/resolv.conf)

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

Falls es jemand noch nicht über die einschlägigen Security-Mailinglisten mitbekommen hat: in "sudo" ist ein kritischer Fehler bekannt geworden, der es praktisch jedem Benutzer ermöglicht, "root"-Rechte zu erhalten:

https://security-tracker.debian.org/tracker/CVE-2021-3156

Betroffene Systeme sollten also dringend aktualisiert werden.

Wer aktuell noch Debian 8 einsetzt, sollte spätestens diese Sache als Anlass nehmen, seine Server zeitnaher zu aktualisieren. Ein Upgrade tut (meistens) nicht weh und verschont vor viel größeren Problemen.
Für Debian 8 (und älter) gibt es keinen Fix für den sudo-Bug! Einziger Workaround dort ist, das sudo-Paket vom Server zu entfernen.

Viele Grüße

-Klaus Keppler

Hallo,

wir beobachten derzeit Störungen bei Let's Encrypt (also bei der CA). Validierungsanfragen bleiben lange auf "pending", die HTTP-Abfragen zur Prüfung laufen in Timeouts. (fairerweise muss man sagen dass das nicht mal direkt Let's Encrypt betrifft, sondern das davor geschaltete CloudFlare).

LiveConfig-Installationen mit SQLite-Datenbank können dadurch etwas "träge" wirken, weil Datenbankabfragen dadurch blockiert werden. Das werden wir auf jeden Fall optimieren.

Viele Grüße

-Klaus Keppler

Zitat von weltmeister

Über sinn und unsinn kann man sich streiten, aber die Kunden wollen es so.

Ständig kommen Mails und Anfragen wie:

"Wo ist der Spamordner", "Warum ist der Spamordner leer", "Bei anderen Providern gibt es Spamordner nur bei Ihnen nicht"... ich kann es schon nicht mehr lesen.

Das ist der Punkt, wo man sich als Provider auch von anderen Anbietern hervorheben kann, in dem man den Kunden das schlüssig erklärt.
Wenn ich einen Kunden frage, warum er lieber Spam-Mails in einen Ordner erhalten möchte, in den er eh nie reinschauen will, statt dass der Provider dafür sorgt dass einfach grundsätzlich nahezu kein Spam mehr eintrifft, dann hat's bislang jeder verstanden.

Vielleicht ein Vergleich: was soll der Verkäufer eines E-Autos machen, wenn der Käufer unbedingt eine Flasche Motoröl zum Nachfüllen haben will? ("Bei allen anderen Autos gibt's sowas auch!" "Das hatte ich schon immer so!" usw...)?

Zitat von Mogwais

Um mich nochmal selbst zu zitieren:

GMX/Web.de haben (meiner persönlichen Meinung nach) die mit Abstand schlechteste Spam-Filterung, während Google bisweilen alle E-Mails von bis dato unbekannten Kontakten in den Spam-Ordner verschiebt.

Würde man die Energie statt in die Spamordner lieber in das Tuning der Spam-Filter stecken, würde sich das alles von selbst erledigen.

Wir haben den Feature Request aufgenommen, einen eventuellen Termin kann ich aktuell aber noch nicht versprechen.

Zitat von mjk

Spielt die Reihenfolge der Upgrades eine Rolle, sollte beispielsweise der Server mit der Business-Lizenz zuerst an die Reihe kommen? Oder ist das nicht relevant und wir können das beliebig durchgehen? Gibt es sonst etwas in Bezug auf Liveconfig zu beachten?

Was die LiveConfig-Versionen betrifft spielt das eigentlich nur dann eine Rolle, wenn es um sehr große Versionssprünge geht - das ist im Changelog jeweils vermerkt, und auch LiveConfig lehnt dann ggf Verbindungen zu "inkompatiblen" Systemen ab.

Im Allgemeinen empfehlen wir immer erst die Clients zu aktualisieren, und ganz zum Schluß den LiveConfig-Master. Grund hierfür ist, dass bei manchen Updates Aktualisierungen der Konfigurationen angestoßen werden - somit werden die auf den Clients dann gleich in der aktuellsten Version ausgeführt.

Zitat

Wir würden im Rahmen der Upgrades natürlich auch bei den PHP-Versionen ein wenig "aufräumen" wollen. Gehe ich richtig in der Annahme, das LiveConfig als Default-Version immer die installierte PHP-Basisversion von Debian nutzt? Wenn man ein älteres php-opt Paket entfernen möchte, müssen die jeweiligen Domains immer noch manuell in der MySQL-Datenbank von LiveConfig entsprechend abgeändert werden, oder gibt es hierzu bereits einen anderen Mechanismus?

Seit LiveConfig 2.10 haben Sie unter Serververwaltung -> Web eine Box "PHP-Version" - da sehen Sie welche PHP-Versionen noch mit wie vielen Subdomains genutzt werden. Demnächst wird da auch eine Anzeigemöglichkeit dieser Subdomains dazu kommen.
Es gibt ab LiveConfig 2.11 (aktuelle Preview) zudem die Möglichkeit, alte PHP-Versionen nicht mehr für neue Subdomains zu Verfügung zu stellen. Somit können "alte" Konfigurationen weiter betrieben werden und die entsprechende PHP-Version so langsam aber sicher aussterben.

Zur Standard-Version: siehe https://www.liveconfig.com/de/…d-php-version-%C3%A4ndern
Infos zum Upgrade von Debian 8 auf 9: https://www.liveconfig.com/de/kb/debian-upgrade-8/ (den Abschnitt zu PHP 7 beachten)

Viele Grüße

-Klaus Keppler

Danke für den Hinweis! Der Fehler wurde eben behoben, mit dem nächsten Update ist das also erledigt.

Ab LiveConfig v2.11.0 wird die logrotate-vhosts-Konfiguration nun so geschrieben, dass die Kompression auch klappt wenn das Quota eines Benutzers ausgeschöpft ist. Die bestehende Logrotate-Konfiguration wird während des Upgrades entsprechend gepatched.

Die Preview-Version wird heute Nachmittag entsprechend aktualisiert.

Viele Grüße

-Klaus Keppler