Beiträge von kk

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.

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.

Ja, aktuell führt LiveConfig die Paketerkennung nur beim Start aus.

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.

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 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

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:

Aktuell sehen die smtpd_client_restrictions ja etwa so aus:

smtpd_client_restrictions =
    permit_mynetworks,
    check_sasl_access hash:/etc/postfix/sasl_access,
    permit_sasl_authenticated,
    reject_invalid_hostname,
    reject_unknown_reverse_client_hostname,
    reject_rbl_client ix.dnsbl.manitu.net

Ich schlage vor, dass wir nach "permit_sasl_authenticated" noch eine (manuell pflegbare) Liste für's Server-Whitelisting aufnehmen:

smtpd_client_restrictions =
    permit_mynetworks,
    check_sasl_access hash:/etc/postfix/sasl_access,
    permit_sasl_authenticated,
    [COLOR=#ff0000][B]check_client_access hash:/etc/postfix/client_exceptions,[/B][/COLOR]
    reject_invalid_hostname,
    reject_unknown_reverse_client_hostname,
    reject_rbl_client ix.dnsbl.manitu.net

Diese Liste enthält dann die IP-Adressen oder Hostnamen von Servern, die man immer durchlassen möchte, z.B.:

mailout01.t-online.de OK
mailout02.t-online.de OK
...

wobei statt "OK" evtl. ein "DUNNO" angebracht wäre, das müssten wir noch testen. Schließlich sollen die restlichen Prüfungen (insbes. Antivirus) ja weiterhin ausgeführt werden.

Dann macht es aber vermutlich mehr Sinn, eine separate Liste mit "Blacklisting-Ausnahmen" zu pflegen, statt die DNS-Whitelist dafür zu verwenden.
DNS-Whitelists sind i.d.R. weniger dynamisch als Blacklists, daher macht es IMHO schon Sinn, akute Spam-Fluten weiterhin über Blacklists abzuhalten.

Wir schauen uns die Postfix-Konfiguration mal an, mir schwebt da so was wie "/etc/postfix/blacklist-exceptions.db" vor, in die man dann (manuell) die auszunehmenden Mailserver eintragen kann.

Die Idee hinter der aktuellen Konfiguration ist wie folgt:

• Ein Server, der auf einer Blacklist steht, wird grundsätzlich abgelehnt.
  Es ist nicht vorgesehen, einzelne Ausnahmen zu schaffen. Steht ein Server auf einer Blacklist, dann wird er auch an andere Mailserver nicht senden können - Ausnahmen verkomplizieren die Sache dann erheblich.
• Danach greift das Greylisting.
• Ausnahme: wenn ein Server auf einer DNS-Whitelist geführt wird, dann wird das Greylisting übersprungen. Ziel hierbei ist, unnötiges Greylisting "bekannter" Mailserver (gmail, GMX, usw.) zu verhindern.

Aus diesem Grund kann man die DNS-Whitelist im LiveConfig auch nur dann pflegen, wenn Greylisting aktiviert ist.

Kurz aber knapp: geht nicht, weil MySQL nur /8, /16 und /24 unterstützt.
(daher auch die Einschränkung in der GUI, statt einem freien Textfeld)

Diese Meldungen können Sie ignorieren (ich glaube sogar dass diese in v2.6 entfernt wurden/werden). LiveConfig führt vorsorglich "chcon" aus (falls vorhanden), um die Attribute für SELinux zu setzen.

Ist eigentlich keine große Sache, können wir gerne mit einschieben.
Ich hatte kurzfristig überlegt, direkt /etc/skel als Vorlage zu verwenden - denke aber es ist sinnvoller, ein separates Skeleton hierfür zu nutzen.

Zitat von Mogwais

Gab es dann aber nicht das Problem das die Sachen überschrieben wurden wenn jemand die Urlaubsfunktion von LC genutzt hat?

Das wird weiterhin bestehen (LiveConfig überschreibt für den Autoresponder die Sieve-Datei).
Aber:

• man kann den Autoresponder im LiveConfig deaktivieren (ist dann sinnvoll, wenn alles per ManageSieve gepflegt wird)
• wir haben vor, im erweiterten Postfach-Tab auch eigene Sieve-Regeln hinterlegen zu können - das wird aber noch bis mind. Herbst warten müssen (der Zeitplan ist bereits recht voll)

Aktuell (v2.5.3) gibt es übrigens noch das Problem, dass beim Aktualisieren von Postfacheinstellungen durch LiveConfig eventuelle ManageSieve-Scripte in manchen Fällen deaktiviert werden, das ist in v2.6.0 behoben (das tritt dann auf, wenn ManageSieve einen Symlink auf's Sieve-Script erstellt - LC prüfte wiederum nur, ob das eine "echte" Datei ist).

Ja, das ist hier beschrieben:
https://www.liveconfig.com/de/handbuch/advanced.web.xhtml

Bestehende Verträge wenn möglich bitte löschen und neu anlegen, ansonsten müssten deren Verzeichnisse in der LiveConfig-Datenbank manuell angepasst werden.

Viele Grüße

-Klaus Keppler

Zitat von weltmeister

Auch häufig von Kunden gewünscht: den Zeitrahmen für eine automatische Antwort festlegen zu können, zB. vom 1. - 15. März 2018, nach dem 15. März wird der Autoresponder automatisch deaktiviert.

Diese Funktion ist schon fertig (kommt also in v2.6.0), allerdings lässt sich nur das Enddatum festlegen, der Starttermin nicht.

Hallo,

wir sind derzeit fast alle auf dem CloudFest, daher telefonisch nur eingeschränkt erreichbar.
In der Liste unter "Serververwaltung", wird da in der Spalte "Verbunden seit" etwas (plausibles) angezeigt?
Oder wo genau hakt es denn? Schicken Sie bitte ggf. einen Screenshot an support@liveconfig.com

Viele Grüße

-Klaus Keppler

Auch dieses Jahr ist LiveConfig wieder Partner auf dem CloudFest (ehemals "WHD.global" bzw. "WorldHostingDays").
Vom Dienstag 13.03. bis Donnerstag 15.03. finden Sie uns im Foyer am Stand H09.
Einen Lageplan sowie kostenlose Eintrittskarten gibt's unter
https://www.liveconfig.com/de/veranstaltungen/cloudfest-2018

An unserem Stand stehen wir für alle Fragen rund um LiveConfig zur Verfügung.
Außerdem gibt es ein paar Goodies/Swag und täglich ab ca. 17:00 richtiges Bier.

Viele Grüße & bis nächste Woche!

-Klaus Keppler

Mit der nächsten LiveConfig-Version (v2.6) wird die o.g. "null_sender"-Einstellung dann direkt durch LiveConfig gesetzt.

Viele Grüße

-Klaus Keppler

Das Problem ist inzwischen behoben.
Ursache war in diesem Fall, dass die MySQL-Datenbanken nicht gelöscht werden konnten ("can't rmdir './<Datenbank>/', errno: 17"). Beim Neustart von LiveConfig wurde das wiederum nicht richtig abgefangen, so dass man hier in einer Fehlerschleife landete. Wir haben das bereits für das nächste Update mit aufgenommen.
Der Fehler beim Löschen der Datenbank wird bislang leider nicht in der GUI angezeigt (nur im LiveConfig-Log), das werden wir auch noch ändern.

Viele Grüße

-Klaus Keppler