Beiträge von kk

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

Zitat

Jan 18 00:00:03 s41.de logrotate[14869]: gzip: stdout: Disk quota exceeded
Jan 18 00:00:03 s41.de logrotate[14869]: error: failed to compress log /var/www/web36/logs/priv/php_errors.log.1

Wir planen, die Anweisung "su" in der LiveConfig-Logrotate-Konfiguration von "su <Vertrag> <Vertrag>" in "su <Vertrag> root" zu ändern. Somit werden die Logs während der Komprimierung nicht dem Quota des Kunden zugeordnet. Anschließend soll die Gruppe dann (per "postrotate"-Anweisung) wieder der Kunden-Gruppe zugeordnet werden, damit die Logs letztendlich wieder dem Quota zugezählt werden.

Zitat von Totenfluch

ich möchte eine React Anwendung auf meiner Webspace laufen lassen. Diese Anwendung besitzt jedoch verschiedene routen, welche über einen internen router in der Anwendung zu verschiedenen Seiten in der Anwendung führen.

Am einfachsten und wartungsfreundlichsten ist es tatsächlich, die paar RewriteRules in eine .htaccess zu packen. Einfach die <Directory>-Anweisung noch entfernen, und das ganze als .htaccess in's Webspace-Verzeichnis (~/htdocs/.htaccess) schreiben:

RewriteEngine on
    # Don't rewrite files or directories
    RewriteCond %{REQUEST_FILENAME} -f [OR]
    RewriteCond %{REQUEST_FILENAME} -d
    RewriteRule ^ - [L]
    # Rewrite everything else to index.html to allow html5 state links
    RewriteRule ^ index.html [L]

Viele Grüße

-Klaus Keppler

Es gibt die Möglichkeit, die Quell-IPs bei BIND explizit zu konfigurieren.
Bearbeiten Sie testweise mal die Datei /etc/bind/named.conf.options und fügen dort im options-Abschnitt folgende Einstellungen ein:

transfer-source { 169.254.12.34; };
notify-source { 169.254.12.34; };
transfer-source-v6 { 2001:db8::1; };
notify-source-v6 { 2001:db8::1; };

IPs natürlich entsprechend anpassen. Danach BIND neu starten und beobachten, ob damit alles wie gewünscht funktioniert.
Wenn ja, dann nehmen wir das gerne in ein kommendes Update mit auf.

Bis dahin lässt sich das über z.B. /etc/liveconfig/lua.d/bind.lua mit folgendem Inhalt einrichten (siehe Handbuch

bind.LOCALOPTIONS = {
  ['transfer-source'] = "{ 169.254.12.34; }",
  ['notify-source'] = "{ 169.254.12.34; }",
  ['transfer-source-v6'] = "{ 2001:db8::1; }",
  ['notify-source-v6'] = "{ 2001:db8::1; }"
}

Viele Grüße

-Klaus Keppler

CentOS 8 Stream wird derzeit von LiveConfig noch nicht unterstützt (ist für Q2/2021 eingeplant).
Aber danke für den Hinweis!

Leute, wir sind hier i.d.R. auf Shared Webhosting Systemen unterwegs. Das sind die Server, bei denen man für ein zeitgemäßes WordPress auch ein zeitgemäßes PHP braucht. Was nutzt da z.B. ein CentOS 6 (das "erst" seit knapp 4 Wochen EOL ist), wenn das standardmäßig PHP 5.3 mitbringt?

(E)LTS ist was für abgeschottete Spezialserver, aber nicht für prinzipiell "offene" Multi-User-Systeme.

Und um mal einen kleinen Rant aus Entwicklersicht los zu werden: so uralte und ewig lang künstlich am Leben erhaltene Distributionsversionen sind eine einzige Katastrophe. Um die Software anständig zu testen betreiben wir z.B. für jede Distri eine eigene VM, die jeweils aktualisiert und gepflegt werden muss (aktuell sind das übrigens über 15 Server nur für Tests). Will man nun moderne Sicherheitsfunktionen (ASLR etc.) nutzen oder einfach "nur" modernere Sprachen (C++ 11/15/17/20) muss man schauen inwiefern auf der jeweiligen Plattform überhaupt passende Compiler verfügbar sind. Spoiler: C++11 auf CentOS 6 kann man knicken.
Um also nicht sicherheitsmäßig auf dem kleinsten gemeinsamen Nenner arbeiten zu müssen (also auf dem technischen Stand von vor knapp 10 Jahren), muss man einen gewaltigen Aufwand in die Build-/Test-Chain und die Pflege von Servern mit uralten Distributionen stecken. Für uns bedeutet das also z.B. dass wir uns moderne Compiler selber auf Altsystemen einrichten (selber bauen) müssen. Spätestens uralte glibc-Versionen stellen dann aber eine nicht mehr überschreitbare Grenze dar.
Ich persönlich bin daher froh um jede Distribution, die ihr EOL erreicht hat. Bei Debian finde ich das Release-Intervall persönlich sehr angenehm, und die Upgrades sind meist völlig reibungslos.

Werden auf dem Server eventuell ausgehende Verbindungen blockiert?

Auf den ersten Blick klingt diese Fehlermeldung danach, dass der Webserver keine OCSP-Stapling-Tickets von der jeweiligen SSL-CA abrufen kann.

Zitat von alex007

/var/www/<Vertrag>/conf/fpm.conf funktioniert leider immer noch nicht!

Haben Sie nach Änderungen in der fpm.conf den Vertrag (bzw. irgendeine Domaineinstellung) auch neu gespeichert?
Die fpm.conf wird beim Schreiben der (aktualisieren) vHost-Konfiguration jedenfalls berücksichtigt.

Falls nicht: welche Einstellungen genau haben Sie darin gemacht?

Zitat

Gut wäre wenn man die Einstellungen direkt im Interface machen könnte!

Steht bereits auf der ToDo-Liste - die PHP-Verwaltung soll insgesamt umstrukturiert werden.

Wurde mit v2.10.2 erledigt - siehe Changelog.

Jein. LiveConfig läuft prinzipiell mit CloudLinux 7, die speziellen Features wie CageFS sind aber derzeit nicht über die GUI steuerbar. Das hat schlicht damit zu tun, dass hierzulande CL noch relativ wenig verbreitet ist.
Die meisten Vorteile von CL kann man dennoch problemlos nutzen (also inbes. die Sicherheitsvorteile, Kernel Patching usw.)

Wir haben eine CloudLinux7-Testumgebung am Laufen, mit der wir testen & entwickeln, und haben auch einen recht guten Draht zu den CL-Entwicklern, bei Problemen können wir also i.d.R. weiterhelfen.
CloudLinux8 steht bereits auf unserer Agenda - aber erst gegen Q2/2021, wenn wir auf eine neue Testumgebung migrieren. CentOS 8 bzw. deren Nachfolger/Derivate werden wir nach Möglichkeit weiter unterstützen. Eine "offizielle" Stellungnahme zur Zukunft mit CentOS 8 ist für die nächsten Wochen geplant (wenn sich der Staub um die CentOS8-Entwicklung etwas gelegt hat).

Viele Grüße & frohe Weihnachten

-Klaus Keppler

Zitat von sTeaLth

Weiß hier jemand ob man den Spamfilter für alle E-Mail Adressen eines Kunden aktiveren kann, ohne dabei die Einstellung in jeder E-
Mail Adresse manuell durchführen zu müssen?

Das geht nur über einen Eingriff in die LiveConfig-Datenbank:

UPDATE MAILBOXES SET MB_SA_ENABLED=1, MB_SA_WARN=300, MB_SA_REJECT=500, MB_STATUS=9
  WHERE MB_SA_ENABLED=0 AND MB_STATUS=1;

Anschließend LiveConfig neu starten - damit sollten die Postfächer serverseitig aktualisiert werden (ggf. Blick in liveconfig.log werfen).

Zitat

Und kann man irgendwo den Default so setzen dass bei jeder neuen E-Mail der Spamfilter aktiviert wird?

Das geht über die LCDefaults:

INSERT INTO LCDEFAULTS VALUES ('mail.spam.enabled', '1');

Auch hier LiveConfig anschließend neu starten, da diese Einstellungen nur beim Start gelesen werden.

Viele Grüße

-Klaus Keppler