Ohne zu wissen welcher Prozess die Last verursacht, kann man leider NICHTS machen.
Prozessliste: "ps aux".
Ohne zu wissen welcher Prozess die Last verursacht, kann man leider NICHTS machen.
Prozessliste: "ps aux".
Hello,
we've just updated our PHP 7.3 packages for Debian/Ubuntu to version 7.3.0-RC6. Also the APCu and ImageMagick extensions for PHP 7.3 are now available through our repositories.
PHP 7.3 "stable" is expected to be released on 12/06/2018.
Best regards
-Klaus Keppler
Hallo,
wir haben eben die Debian/Ubuntu-Pakete für PHP 7.3 auf die Version 7.3.0-RC6 aktualisiert. Außerdem stehen für PHP 7.3 ab sofort auch die APCu- und ImageMagick-Extensions in den Repositories bereit.
Wenn nichts dazwischen kommt, soll PHP 7.3 "stable" am 06.12.2018 (Nikolaus) erscheinen.
Viele Grüße
-Klaus Keppler
Log in as "admin", and go to "Server Management" -> "Databases". In the box with the MySQL properties, look at the status message (right column). What is displayed there? "Status: Connected"?
In most cases when LiveConfig can't create a database, the MySQL credentials have changed and weren't updated at LiveConfig.
Hallo,
ab sofort steht LiveConfig v2.7.2 als Preview bereit. Neben einem trivialen Bugfix (Wildcard-Subdomains können nun wieder angelegt/verwaltet werden) wurde mit diesem Update auch die Kommunikation zwischen LiveConfig-Client und -Server-Prozess verbessert.
Wer mag, kann das Update jederzeit risikofrei einspielen. Unsere Tests sind alle problemlos durchgelaufen, im Zweifelsfall ist aber ein Downgrade auf 2.7.1 jederzeit möglich (am Datenbankschema hat sich nichts geändert).
Auch die von einigen Anwendern gemeldeten Probleme beim Download von Backups (auf Single-Server-Systemen) könnten damit behoben sein.
Viele Grüße
-Klaus Keppler
(Tech-speak: unter bestimmten Bedingungen (sehr schnelle Systeme, schneller I/O, viele LiveConfig-Threads, viele LiveConfig-Jobs - insbes. DNS-Updates) konnte es dazu kommen, dass aufgrund mangelnder Thread-Synchronisation die Kommunikation "durcheinander kam" (das gab dann Fehlermeldungen mit Hinweis auf's LCCP-Protokoll).
Wir haben ein mögliches Problem in der Client-Server-Kommunikation von LiveConfig behoben. Die Preview von LiveConfig v2.7.2 steht bereits zum Download bereit, ein separater Hinweis dazu erfolgt gleich hier im Forum.
Danke für den Hinweis!
Der Fehler wurde eben mit v2.7.1-r5125 behoben (stand ebenfalls im Zusammenhang mit der neuen Domainvalidierung).
Nein, da hat sich nichts geändert (war schon immer so).
Es muss technisch betrachtet auch die Spam-Einstellung der Ursprungsadresse greifen - denn wie sollte sich der Mailserver verhalten, wenn an a@firma.de zugestellt werden kann, nicht aber an b@firma.de?
(Bounces dürfen/sollen ja nicht generiert werden, eine Ablehnung zum SMTP-Zeitpunkt ist technisch nur vor der Weiterleitung möglich)
Viele Grüße
-Klaus Keppler
Das Release v2.7.1 wurde eben noch mal aktualisiert (r5119 -> r5120).
In r5119 hatte sich noch ein Fehler bei der neuen Gültigkeitsprüfung für Subdomains eingeschlichen (es waren keine "einfachen" Subdomains erlaubt) - das ist mit dem Update nun behoben.
Bitte entschuldigen Sie die Unannehmlichkeiten; wir hatten uns zu sehr auf exotische Testfälle konzentriert. ![]()
Viele Grüße
-Klaus Keppler
Die Entwicklung läuft voll auf Hochtouren, aktuelle Schwerpunkte sind in der Tat Backup und Mail.
Hallo,
ab sofort steht LiveConfig v2.7.1 (r5119) zum Download bereit.
Es handelt sich bei diesem Update primär um Bugfixes und Verbesserungen - eine Liste aller Änderungen findet sich wie immer im Changelog.
Viele Grüße
-Klaus Keppler
Hello,
our PHP packages for Debian/Ubuntu have just been updated to version 7.1.24 and 7.2.12.
Best regards
-Klaus Keppler
Hallo,
unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Version 7.1.24 bzw. 7.2.12 aktualisiert.
Viele Grüße
-Klaus Keppler
Ich glaube das geht um das Default Server-Zertifikat für SSL für den Webserver - steht in der Liste der SSL-Zertifikate mit der Bemerkung "Default SSL-zertifikat für SNI"
Dieses Zertifikat sollte im Normalfall ohnehin niemand zu Gesicht bekommen (wird ja nur dann ausgeliefert, wenn man per HTTPS auf eine Domain zugreifen will, die zwar in LiveConfig angelegt ist, für die aber kein eigenes Zertifikat existiert). Also über "opportunistisches HTTPS", oder falsche Verlinkung.
Wie auch immer - der Austausch ist sogar noch wesentlich einfacher. ![]()
Welches Zertifikat genau? Das von der LiveConfig-Weboberfläche?
Dieses SSL-Zertifikat ist unter /etc/liveconfig/sslcert.pem gespeichert.
Wenn Sie kein "offizielles" SSL-Zertifikat nutzen sondern ein neues selbst-signiertes Zertifikat anlegen möchten, verwenden Sie folgende Befehle:
Anschließend LiveConfig neu starten.
Eine Domain xyz.com kann nur einem Webspace (server 1) zugeordnet werden, somit kann mail.xyz.com (Mailserver auf server 2) nicht mehr unter selber domain verwaltet werden.
Da gibt es eine einfache Lösung.
Wird DNS für diese Domain auch durch LiveConfig verwaltet?
Wenn ja:
im LiveConfig den Vertrag öffnen, in dem die Domain (xyz.com) bislang liegt. Eine neue Subdomain "mail" (.xyz.com) anlegen. In den Subdomain-Einstellungen Webspace und E-Mail deaktivieren, und nur einen manuellen DNS-Eintrag (A-Record) mit der IP-Adresse des Mailservers anlegen.
Wenn nein: (externer DNS-Server)
einfach beim DNS-Anbieter eine Subdomain "mail" (.xyz.com) anlegen, dort die IP-Adresse des Mailserver hinterlegen.
Wenn Sie diese neue Subdomain (mail.xyz.com) nun in irgendeinem anderen Vertrag nutzen sollen, fügen Sie die einfach wie eine normale Domain hinzu - als DNS-Server wählen Sie aber dann "externer DNS".
Verstehe ich das also richtig, dass unter mail.xyz.com sowohl E-Mail (Postfix/Dovecot) als auch Webmail laufen soll?
Die einfachste Lösung wäre, Webmail einfach auf einer separaten Subdomain laufen zu lassen ("webmail.xyz.com")...
Ansonsten bliebe nur die Möglichkeit, auf dem Mailserver einen Apache/NGINX aufzusetzen, damit dort ein Webmail gehostet werden kann (wenn man aber einen dedizierten Mailserver betreibt, will man da meistens keinen Webserver mit aufsetzen).
UPDATE:
Anscheinend werden die Rechte auf diesem System falsch gesetzt (Der Ordner wurde automatisch angelegt)
Danke für die Info. Offenbar haben Sie eine recht restriktive umask für Init-Scripte (077 statt 022). Wir prüfen das mal, ggf. werden die Init-Scripte (für non-systemd) noch mal entsprechend angepasst.
Viele Grüße
-Klaus Keppler
Zur Info: die Init-Scripte unserer PHP-Pakete wurden eben aktualisiert.
Hallo,
die PHP-Pakete für Debian/Ubuntu (5.6/7.0/7.1/7.2/7.3) wurden eben aktualisiert - die Init-Scripte unterstützen nun auch den Start von PHP-FPM wenn auf dem jeweiligen System kein systemd installiert ist.
Es wurden also lediglich die Dateien /etc/init.d/php##-fpm modifiziert - mehr ändert sich mit dem Update nicht.
Viele Grüße
-Klaus Keppler