Beiträge von kk

  • LiveConfig Templates ändern

    Am HTML können überhaupt keine Änderungen vorgenommen werden.
    Die beigefügte HTML-Datei dient lediglich der Entwicklung und dem Test des eigenen CSS. Der eigentliche HTML-Code wird durch LiveConfig dynamisch erzeugt.
    Wenn Sie etwas am HTML-DOM ändern müssen, dann wäre das über JavaScript (jQuery) möglich - einem eigenen Template können Sie ja auch eigenen JavaScript-Code beifügen.
    Allerdings raten wir prinzipiell von so etwas ab, da Sie Ihr Template dann bei jedem LiveConfig-Update testen müssen (ob noch alles funktioniert).


    Viele Grüße


    -Klaus Keppler

  • MX-Record trotz deaktivierter Mail-Funktion

    Hallo,


    dieses Verhalten konnte nun aufgeklärt werden. Was passiert sein dürfte:

    • es wurde ein Angebot ohne E-Mail angelegt
    • basierend auf diesem Angebot wurde ein Vertrag angelegt
    • für diesen Vertrag wurden Domains hinzugefügt
    • später wurde E-Mail für dieses Angebot aktiviert (egal ob dauerhaft oder nur kurzzeitig)
    • wurde danach die Zone modifiziert (egal ob durch eine einzelne RR-Änderung oder z.B. durch ein Massen-Update aufgrund einer SOA-Änderung im DNS-Template), dann wurde der MX-Eintrag für diesen "neu" aktivierten Mailserver automatisch angelegt


    Beim Aktivieren von E-Mail in einem bestehenden Angebot wurden bislang automatisch für alle vorhandenen Domains mit leerem Hostnamen (also z.B. für "example.org", nicht aber für "www.example.org") nachträglich automatisch E-Mail mit aktiviert, sofern nur ein einziger Mailserver im System vorhanden war.
    Das war gut gemeint (laut Changelog kam das sogar über einen Change Request erst nachträglich dazu), um beim nachträglichen Aktivierern von E-Mail im Angebot das nicht manuell für alle Domains aktivieren zu müssen.


    Ab LiveConfig v2.6 gilt dieses Verhalten nicht mehr. Aktiviert man dann E-Mail nachträglich im Angebot, werden bestehende Domains grundsätzlich nicht modifiziert ("Prinzip der geringsten Überraschung"). Statt dessen wird es in Kürze möglich sein, mehrere (Sub-)Domains gleichzeitig zu bearbeiten und somit E-Mail bequem für mehrere Subdomains einzuschalten.
    Wir werden das auch entsprechend in die Dokumentation mit aufnehmen.


    Viele Grüße


    -Klaus Keppler

  • Return-Path: <mailer-daemon> - Fehler bei MS-POP3-connector

    Zitat von aziegler

    Dann hoffen wir mal, dass "<>" genauso wenig Probleme macht wie <MAILER-DAEMON@$hostname>.


    Zumindest ist das im RFC eindeutig geregelt (der bisherige Weg von Postfix, dort nur den unqualifizierten Namen "MAILER-DAEMON" einzutragen, ist technisch betrachtet falsch - hatte aber natürlich auch seine Gründe).


    Zitat

    Wird die master.cf automatisch neu generiert oder müssen wir das wieder einmal auf unserer großen Zahl an servern überall manuell anstoßen?
    (gut, für die recipient delimiter Änderung müssen wir das vermutlich sowieso, ich tippe die wird default off sein)


    null_sender soll während des Upgrades automatisch geändert werden (steht dann auch so im Changelog), recipient_delimiter ist eine Feature-Änderung die wir nicht automatisch aktivieren ("Prinzip der geringsten Überraschung"). Längerfristig soll das über CLI möglich sein - aber erst eins nach dem anderen...

  • Return-Path: <mailer-daemon> - Fehler bei MS-POP3-connector

    Ich möchte das Thema noch mal kurz aufgreifen. Ein Anwender hat uns darauf hingewiesen, dass das RFC 5321 ganz klar für Fehlermeldungen einen leeren Absender (<>) erfordert:[INDENT]If there is a delivery failure after acceptance of a message, the receiver-SMTP MUST formulate and mail a notification message. This notification MUST be sent using a null ("<>") reverse-path in the envelope. The recipient of this notification MUST be the address from the envelope return path (or the Return-Path: line).
    [/INDENT]
    LiveConfig wird ab v2.6 also die "null_sender"-Option in der master.cf (beim pipe-Befehl) auf einen leeren Wert setzen und nicht auf MAILER-DAEMON@$hostname.


    Viele Grüße


    -Klaus Keppler

  • Webspace Berechnung ohne Quota

    Zitat von pitgrap

    Daher ist mein Feature-Request, dass man per Setting ggf. die Berechnungsart ändert kann, z.b. auf "du".


    Ich verstehe Ihr Problem, allerdings ist Quota nunmal genau dafür gedacht (und optimiert), den Speicherverbrauch jederzeit mitzuprotokollieren und zu prüfen. "du" ist da eher eine Dampfwalze (mit massivem I/O) und etlichen Einschränkungen.


    Ein Workaround um ein "ordentliches" Quota herum ist nicht geplant.


    Zitat

    Oder gibt es die Möglichkeit, dass ich per Shellskript selber die Werte berechne und an eine API weiterreiche? Das würde mir auch schon reichen.


    Nein, eine Quota-API (zum Schreiben) gibt es nicht. LiveConfig verwaltet die Werte intern in Round-Robin-Tabellen (RRA_DISK/RRD_DISK). Die könnten *theoretisch* auch "extern" befüllt werden, das ist aber alles andere als trivial, und wir können dazu keinen Support geben (schließlich *gibt* es mit Quota ja eine äußerst schlanke, schnelle und zuverlässige Lösung).


    Wenn der Hoster Virtuozzo einsetzt, kann er mit wenig Aufwand Quota für die VPS-Instanz aktivieren. Ansonsten gibt es auch viele andere vServer-Anbieter, die auf einer anderen technischen Plattform arbeiten und aufgrund eines höheren Abstraktionsgrades auch eigene Kernel (und somit Quota) erlauben.


    Viele Grüße


    -Klaus Keppler

  • LC ind Endlosschleife !!

    Zitat von aci

    Vielen Dank für die schnelle Antwort. Es gab wirklich einen Eintrag. Habe diesen gelöscht und jetzt scheint alles wieder soweit zu klappen.


    Wo kam denn dieser Eintrag her? Durch LiveConfig selbst, oder durch Software von Ihnen?


    Zitat

    Seit ein paar Tagen habe ich das Problem, dass sehr viele DNSSEC abgelaufen sind.
    Warning : The following zones have expired DNSSEC signatures


    Wo genau wird das gemeldet?
    Die DNSSEC-Signaturen werden vom Primary DNS automatisch aktualisiert (BIND macht das). Wenn diese Meldungen auf einem Secondary auftauchen, dann klappt vielleicht die DNS-Kommunikation nicht zwischen diesen beiden Servern.


    Zitat

    Gibt eine Möglichkeit alle DNS-Einträge von LC erneut schreiben zu lassen ??


    Das nutzt nichts ohne zu wissen, warum die DNSSEC-Signaturen nicht erneuert werden.

  • LC ind Endlosschleife !!

    Sehr merkwürdig. Dem Stack Trace nach zu urteilen liegt das Problem darin, dass eine Subdomain mit SD_HOST=NULL existiert (beim Start von LiveConfig werden ausstehende DNS-Updates verarbeitet). Das dürfte eigentlich gar nicht passieren.


    Wenn möglich, öffnen Sie mal die LiveConfig-Datenbank und prüfen mit "SELECT SD_ID FROM SUBDOMAINS WHERE SD_HOST IS NULL", ob tatsächlich eine solche Subdomain existiert.
    (bzw. mit "SELECT D_NAME FROM SUBDOMAINS, DOMAINS WHERE SD_DOMAINID=D_ID AND SD_HOST IS NULL" erhalten Sie Namen der Domains mit ungültigen Hostnamen)


    Sie könnten den Eintrag dann ändern ("UPDATE SUBDOMAINS SET SD_HOST='' WHERE SD_HOST IS NULL") um den Programmabbruch an dieser Stelle zu vermeiden.


    Bei weiteren Fragen wenden Sie sich bitte am besten direkt an support@liveconfig.com.


    Viele Grüße


    -Klaus Keppler

  • Debugging Single Sign On

    Thank you for your hint regarding the manual - we've updated this for the next release, the instructions at GitHub are actually the most recent ones.


    Zitat

    In both cases I get: The request to verify the token failed. Please try again!


    Does your LiveConfig run with a self-signed certificate? If yes, is "PMA_DISABLE_SSL_PEER_VALIDATION" set to "FALSE"? (lc-sso.php)
    If using an official certificate: is it possible to run eg. "curl https://url-to-your-liveconfig:8443/" without any certificate warnings? (some older distributions may not have current CA certificates)


    I've updated the lc-sso.php script at GitHub for better error handling, maybe try this new version.


    Best regards


    -Klaus

  • Liveconfig einrichten

    Nein, an Debian liegt das nicht.


    Zuerst müssen Sie die Verwaltung der einzelnen Dienste aktivieren (Serververwaltung -> Web/Mail/Datenbanken/...). Siehe Handbuch.


    Anschließend können Sie im einfachsten Fall unter "Mein Hosting" einen Hostingvertrag anlegen. Dem können Sie dann Domains hinzufügen, und somit danach auch E-Mail-Adressen, Datenbanken etc. anlegen.

  • GitHub

    Ich vermute mal so was wie "push to deploy".
    Auch das ist aktuell mit Hausmitteln bereits realisierbar (Stichwort: "post-receive hook"), eine Integration in die GUI steht aber schon auf der Wunschliste.

  • Wildcard-Zertifikate

    Zitat von lebenszeit

    DNS-Validierung kann die Bereitstellung beschleunigen


    Nicht wirklich. Auf die Geschwindigkeit der Zonen-Updates (vom Master zu den Secondaries) hat man nur begrenzt Einfluss - das kann u.U. länger dauern als ein Webserver-Reload.


    Zitat

    die Reloads der Webserver reduzieren


    Das möchten wir mittelfristig ohnehin anders lösen (komplett ohne Webserver-Reload).


    Zitat

    und auch Zertifikate bereitstellen, wenn http://example.com deaktiviert ist und nur https aktiv ist.


    Da ist ein Argument für DNS-Validierung, nicht aber für Wildcard-Zertifikate. ;)

  • PHP 5.6.35, 7.0.29, 7.1.16 und 7.2.4

    Hallo,


    die PHP-Pakete für Debian/Ubuntu wurden auf die Versionen 5.6.35, 7.0.29, 7.1.16 und 7.2.4 aktualisiert.


    Diese Pakete installieren erstmals in /etc/liveconfig/lua.d/php##.lua Scripte zur automatischen Registrierung - diese werden ab LiveConfig v2.6 berücksichtigt. Details dazu sowie zur Kompatibilität mit bestehenden Anweisungen in custom.lua folgen in einem separaten Beitrag.
    Künftig muss man "zusätzliche" PHP-Versionen aus dem LiveConfig-Repository also nicht mehr manuell in einer custom.lua registrieren - das geschieht dann automatisch bereits während der Installation.


    Viele Grüße


    -Klaus Keppler

  • Wildcard-Zertifikate

    Wildcard-Zertifikate sind aktuell mit LiveConfig nicht möglich.
    Hierfür muss die Domainvalidierung per DNS erfolgen (d.h. die betroffene Domain muss durch LiveConfig im DNS verwaltet werden). Aktuell unterstützt LiveConfig noch keine DNS-Validierung für Let's Encrypt (ist aber geplant, zusammen mit einer offeneren SSL-Schnittstelle - mehr dazu wenn das soweit fertig ist).


    Uns ist bislang auch kaum ein sinnvoller Anwendungsfall für Wildcard-Zertifikate bekannt. Aus Serversicht es es völlig egal, ob für jede gewünschte Subdomain ein einzelnes Zertifikat angelegt wird, oder ob ein Wildcard-Zertifikat für mehrere Subdomains genutzt wird.


    Viele Grüße


    -Klaus Keppler

  • Postfix Whitelist smtpd_client_restrictions

    Zitat von antondollmaier

    So ungern ich Ausnahmen pflegen und dadurch die Großen bevorzugen möchte (die definieren ja auch keine Ausnahmen für uns!) - auf das wird's rauslaufen müssen.


    Ich stelle dann mal ganz kätzerisch die Frage, ob diese Blacklists jeweils so geeignet sind. Eigentlich sollte dann z.B. Spamcop mal eine Ausnahme für T-Online definieren.


    Am schrecklichsten finde ich persönlich derzeit die IronPort-Sache von Cisco (https://www.talosintelligence.com/). Damit haben wir derzeit die größten Probleme - am einen Ende sitzen (oft kommunale :p) Kunden, die sich so ne IronPort zur Spam-Abwehr anschaffen aber die dann quasi unkonfiguriert mit "FooBar"-Standard-Zertifikaten betreiben, am anderen Ende fühlt sich niemand Verantwortlich für's Blacklisting oder De-Listing (es gibt da schlicht keine Ansprechpartner, keine Dokumentation und keine Verantwortung... ein Blacklisting erfolgt scheinbar willkürlich...).
    So, das musste mal raus... :mad: