Beiträge von aziegler

  • PREVIEW: LiveConfig v1.7.4

    Zitat von kk

    Kein Problem, lässt sich einrichten. Wir nehmen das einfach als zusätzlichen (optionalen) Parameter in die addPHP-Funktion (Lua) auf. Dürfte es sogar noch in die 1.7.4 schaffen. :)


    Danke


    Zitat

    Wenn der Warn-Schwellwert auch auf 999 gesetzt wird, werden nur die Header hinzugefügt.


    Also Warnschwellwert=Blockschwellwert, egal ob 5 oder 999, in Ordnung


    Zitat

    Ein Fall für LCDEFAULTS. :) Wird in die ToDo-Liste aufgenommen.


    Danke. Konkret ist das auch ein Problem beim Import unserer Confixx-Server:
    bisher hatten die User Greylisting, Web-Login und Spamassassin - und müssen es nun alle manuell wieder aktivieren nach einem Import, wie wir soeben testweise nachgeprüft haben :(


    Zitat

    An sich wären diese Einstellungen ohnehin nur durch den "admin"-Account änderbar (wichtig z.B. für "Managed Server"). Werden wir mal im Auge behalten.


    ich bin mir nicht sicher, ob wir uns da richtig verstanden haben:
    Dass natürlich diese Datenbank und deren Werte nur durch den Admin änderbar sind, ist vollkommen klar.
    Die Frage ist, ob man die Werte (optional!) für alle Postfächer/Kunden/Verträge zur Pflicht machen kann, sodass diese keine Einstellmöglichkeiten bzgl. z.B. Logging haben, sobald der Admin einen bestimmten default-Wert als verpflichtend deklariert.

  • PREVIEW: LiveConfig v1.7.4

    PHP-Versionen
    Wir wünschen uns dringend anpassen zu können, was dem User für die PHP-Version angezeigt wird.
    Aktuell steht dort z.B. auf einem Debian-7-System "5.4.4" als Versionsnummer dabei.
    Dies ist aber quatsch, da die Debian-PHP-Version NICHT das gleiche ist wie die php.net-PHP-Version. Unter Debian wäre die korrekte Bezeichnung "5.4.4-14+deb7u12".
    Viel besser fänden wir aber aus Support-Sicht, wenn dort nur "5.4" stünde als Version, analog für selbst kompilierte Varianten eben "5.3", "5.5" usw.


    Spamassassin
    1) Besteht die Möglichkeit, den Subject-Rewrite ganz wegzulassen und stattdessen nur entsprechende Header zu setzen? Wenn die Mail fälschlich über dem Schwellwert für den Subject-Rewrite war hat man nun diesen nervigen Präfix im Betreff der Mail :(


    2) Kann man einstellen, dass dies standardmäßig aktiv ist? (was ja bei Greylisting leider auch nicht geht... evtl. siehe unten)


    LCDEFAULTS
    eine GUI ist hierfür wirklich nicht wichtig, aber eine Liste der möglichen Einstellungen!
    Ist hiermit auch einstellbar, dass Werte nicht von Kunden überschrieben werden dürfen? Das würde auch einiges an Support-Arbeit ersparen.

  • LiveConfig 1.7.3 freigegeben

    Zitat von kenny_g


    so nun möchte ich auch gerne aktualisieren, aber ich bin neu mit Liveconfig unterwegs und Plesk geschädigt. Mag mir mal bitte einer sagen wie ich ein Update bei Liveconfig mache und was ich evtl. vorbereiten / beachten muss etc.? Ich habe bisher eine Standard Lizenz auf einem Vserver mit Ubuntu 12.04 64 bit.


    apt-get update
    apt-get upgrade


    fertig, nichts vorzubereiten, wenn du (nicht empfehlenswert!) nur LiveConfig und nichts anderes aktualisieren willst, dann:


    apt-get update
    apt-get install liveconfig --only-upgrade

  • BUG!! SSL Zertifikat Autodiscover

    besonders interessant heutzutage (immer mehr User nutzen primär ihr Mobilgerät) auch, wie es der Samsung-Mailclient, der iOS-Mailclient und ähnliche machen - aber das wären zumindest die 2 verbreitetsten im Mobilbereich
    ich weiß nur, dass iOS es nicht wie Mac OS macht, aber wie genau... primär herstellerseitige Liste der großen Mailprovider vermutlich

  • BUG!! SSL Zertifikat Autodiscover

    ein später Nachtrag:
    sofern man eben Webhosting betreibt, wo jeder Kunde Mails unter einer eigenen Domain, aber aber verständlicherweise nicht jede Domain in's Zertifikat packen möchte, ist die Lösung von bfal ein guter Start.
    Aber:
    Der Kunde bekommt dann immer noch eine Zertifikatswarnung, da Outlook zuerst den HTTP-Request auf autodiscover.example.com versucht und danach erst bei Fehlschlag den SRV-Record. Immerhin klappt die Outlook-autodiscovery dann aber, egal ob der Kunde die Warnung mit "nein" oder "ja" schließt.


    Aktuell überlegen wir, um die Warnung komplett zu vermeiden, den CNAME für autodiscover.example.com zu entfernen sowie den bei uns immer vorhandenen Wildcard-A/AAAA-Record, sodass auch in Outlook keine Fehlermeldung kommt (wie in Thunderbird).
    Die Frage ist nur:
    gibt es Mail-Clients, die NUR den HTTP-Request auf autodiscover.example.com ausprobieren und nichts anderes?


    Weiterhin frage ich mich, welche E-Mail Clients schon den RFC6168 unterstützen, sodass es sich lohnen würde, das zusätzlich einzusetzen?


    Würde mich über Feedback freuen :)

  • Backup möglichkeiten und APPS

    Zitat von arnoldB

    So oder so, wichtige bzw. kritische Anliegen von uns zahlenden Kunden werden i.d.R. über den telefonischen Weg oder per E-Mail schnell bearbeitet.


    Für wirklich kritische Themen trifft das großteils zu, gerade diese Woche hatten wir einen solchen Fall, 2 Tage später kam ein Workaround, ab morgen ist der Fix auch in der Lab-Version.
    Würde das nicht klappen, wären wir aber auch längst weg ;)


    Dennoch gibt es Punkte, die z.B. nichteinmal in das redmine-Tracking aufgenommen werden, obwohl mehrere User das Feature fordern. Oder aber Sachen gammeln - mittlerweile muss man sagen jahrelang - dort im Tracker, ohne bearbeitet zu werden - dafür werden andere Sachen gemacht die nirgendwo im Forum oder Tracker standen.
    Wer weiß, vielleicht gibt es Großkunden die sich hier nicht zu Wort melden und die diese Dinge fordern...


    Wir wollen ja auch keine Featureitis: am wichtigsten ist, dass es keinerlei Bugs gibt.
    Auf dem zweiten Platz folgt, dass umgesetzte Features auch gut und sinnvoll und konsequent durchgezogen sind, dies ist aus unseren Augen z.B. nicht der Fall bei Passwörtern (man kann nicht überall eines generieren - Postfächer - und man kann keine Komplexität vorschreiben), bei den Log-Einstellungen (enforcen für Kunden), bei den Anwendungen (einzeln für Kunden verbieten), bei den PHP-Einstellungen (nicht für Angebote möglich), bei den Usern/Kontakten (umbenennen des Haupt-Users im Vertrag nicht möglich, Kontakte bearbeiten nur über Umweg), sowie bei den PHP-Versionen (aktuell nur händisch, nicht via Interface).
    Das sind Sachen bei denen mir wohl fast jeder der LC-Kunden zustimmen wird.
    Danach erst, wenn das alles passt, kommen auf unserer Prioritätsliste neue/zusätzliche Features.

  • Einstellungen zum Webserver-Log als Default oder gar unveränderlich

    Mittelfristig wäre es gut, wenn man die Einstellung bzgl. des Webserver-Loggings (Dauer des Rotationszeitraums, Anzahl aufzuhebender Logs, Anonymisierung)

    1. als default setzen könnte für alle neu anzulegenden Verträge auf einem Server
    2. den Nutzern verbieten könnte, diese Einstellungen anzupassen


    nicht dringend, gibt vieles wichtigeres, aber damit ist es nun hier abgelegt