Beiträge von kk

    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.

    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

    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

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

    1. im LiveConfig auf den Punkt "SSL-Zertifikate" gehen und dieses Zertifikat zum Bearbeiten anklicken.
    2. Bei "Zertifikat-Anforderung (CSR)" auf den Button "erzeugen" klicken, ggf. die Felder ausfüllen. Bei "Common Name" (CN) am besten so was wie "localhost" oder "Default SSL Certificate" eintragen.
    3. anschließend im Abschnitt "SSL-Zertifikat (CRT)" auf den Button "selbst unterzeichnen" klicken und den Anweisungen folgen.
    4. zum Schluß ganz unten auf den Button "speichern" klicken, um das neue Zertifikat zu übernehmen.

    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:

    Code
    openssl genrsa 4096 >sslcert.pem
    openssl req -x509 -key sslcert.pem -days 730 >>sslcert.pem


    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

    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