Beiträge von antondollmaier

Zitat

Zu den falsch konfigurierten Zwischenzertifikaten: wir erweitern LiveConfig aktuell, dass es beim Start alle SSL-Intermediates prüft und auf abgelaufene Zwischenzertifikate oder fälschlicherweise konfigurierte Root-CA-Zertifikate hinweist.

yeah!

Zitat

Ursprünglich wollten wir diese auch automatisch löschen, das ist aber nicht ganz trivial, da eventuelle Ketten damit ungewollt unterbrochen werden könnten. Wir lassen uns da aber auch etwas einfallen.

Eventuell als Idee:

https://github.com/zakjan/cert-chain-resolver

Nimmt das Zertifikat und sucht die CA-Chain selbst raus.

Nicht als Reseller den Endkunden-Vertrag editieren, sondern als Admin den Reseller-Vertrag bearbeiten.

Dort gibt es dann unterhalb des "eigene DNS-Einträge erlaubt/verboten"-Dropdown auch die Auswahl der DNS-Vorlage (in Version 2.9 gerade verifiziert).

Zitat von geistervogel

ich habe hier eine Multiserver Umgebung mit eigenen NS. Wenn der Admin Domains für sich oder für Kunden anlegt, werden die internen NS zur Auswahl angeboten, wenn dies ein Reseller tut, gibt es nur die Option externe NS.

Ja:

Reseller-Vertrag bearbeiten, Tab Domains. Dort dann die DNS-Vorlage, die der Reseller nutzen darf, auswählen.

Funktioniert hier alles problemlos.

Zitat von hermann

Die SOAP-API kenne ich noch nicht, gibts da irgendwo eine Dokumentation dazu?
(Sorry, wenn ich jetzt die Abkürzung nehme - ich gebe zu, noch nicht danach gesucht zu haben)

im Handbuch, ja:

https://www.liveconfig.com/de/handbuch/api.soap.xhtml

Zitat

Allerdings halte ich das für nicht ganz ungefährlich, Programmierfehler hätten da möglicherweise ziemlich schräge Folgen.

Deshalb testet man solche krassen Eingriffe normal auch erst in der Dev-Umgebung mit einigen wenigen Accounts

Aber ja, das ist eher ein Workaround und keine echte Lösung.

Zitat von hermann

Ich möchte/muss (DSGVO) jetzt die Mails und Accounts vom Server löschen, da sie ja hier nicht mehr gebraucht werden.

Ergänzende Anmerkung: das Vorgehen ist auch nötig, damit der Web/Mailserver selbst den externen MX verwendet und somit auch andere Domains auf dem selben Mailserver die nun externe Domain erreichen können.

Mit der SOAP-API könnte das mit Code umgesetzt werden. Alternativ könnte die Domain auch komplett aus dem Vertrag gelöscht werden - allerdings entfernt das dann auch alle Web-Konfigurationen.

Zitat von aziegler

Was spricht dagegen, MariaDB zu benutzen statt MySQL?

Shopware6 und Akeneo PIM empfehlen beide den Einsatz von MySQL, da MariaDB bei einigen Abfragen (JSON) fehlerhafte Antworten gibt.

Hi,

Zitat von mgoeben

ich hatte die virtual_alias und virtual_domains Textvariante nicht mitkopiert, in dem Gedanken dass Liveconfig die eh neu schreibt, aber es wird nur bei Änderungen nur genau die Änderung geschrieben.

Dass hier eine Kopie angelegt wird, war aus dem Beitrag allerdings nicht ersichtlich.

Zitat

:thumpup für eine Option in liveconfig alle Konfigdateien neu zu genieren.

Das ist - beispielsweise bei den Postfächern in Dovecot - nicht möglich, da LiveConfig die Passwörter nicht selbst speichert, sondern diese nur in der passwd von Dovecot abgelegt werden.

LiveConfig schreibt in die virtual_alias bzw virtual_domains nur bei Änderungen. Ansonsten werden die Konfigurations-Dateien nicht angefasst.

Die virtual_*-Dateien werden auch beim Reload bzw "Konfiguration neu schreiben" nicht mehr neu erzeugt.

Zitat von robert

Ich benötige die Deaktivierung nur für einen Vertrag, nicht für die komplette IP-Gruppe.

Nur auf IP-Ebene möglich, es sei denn:

https://httpd.apache.org/docs/…/mod_ssl.html#sslprotocol

Not possible.

This is caused by permission issues for resellers and is affecting not just php settings.

Zitat von kk

Die Validierung für solche Zertifikate müsste via DNS erfolgen, und das ist leider recht anfällig für Probleme (hauptsächlich das Caching).

Reicht es nicht, vor dem Anstoßen der Validierung durch LE sicherzustellen, dass alle aktiven Nameserver tatsächlich mit dem korrekten Record antworten - ohne einen Resolver zu bemühen?

Zitat

Es gibt zudem kaum ernste Anwendungsfälle für Wildcard-Zertifikate - in der Regel tun's ja auch "normale" Zertifikate.

Jain:

- Große Anzahl an Subdomains
- Domains, die auf interne IP-Adressen zeigen (HTTP-Validierung nicht möglich, DNS aber schon)

Sind beides, auch im Kontext mit LiveConfig, IMHO valide Gründe.

Zitat von Nobbi

Die Pakete php und php-fpm sind allerdings installiert

php-cgi fehlt dann.

Zitat von WebOscar

Versuche ich nun ein apt-get install liveconfig, wird eine Neuinstallation initiiert, statt ein Upgrade durchzuführen.

Blöder Vorschlag:

- Daten sichern (betrifft ja nur die liveconfig.db bzw. mySQL-Datenbank)
- Paket neu installieren
- Dienst stoppen
- Backup zurückfahren
- Dienst wieder starten
- sicherstellen, dass die Daten tatsächlich da sind

Ggf. nochmals die Neu-Erstellung der Konfigurationsdateien/Services anstoßen, damit auch wirklich das Upgrade durch läuft.

Das sollte stressfreier gehen als jetzt manuell in der dpkg-Datenbank rumzufriemeln.

Zitat von BMK-Media

Also würde das ganze so aussehen?

Möglich - funktioniert der Code nicht?

Der Override funktioniert hier doch wie bei allen anderen LUA-Funktionen auch:

dovecot.USERDB_SIEVE = "userdb_sieve=/var/mail/%C/%I/default.sieve"
function dovecot.addMailbox(cfg, opts, data)
end

Zitat von leonex

auf einem Debian Jessie System

Debian Jessie ist End of Life seit 2018, die LTS wird ihr EoL auch in 3 Monaten erreichen.

Wäre ein Upgrade nicht sinnvoll?

Vielen Dank für eure schnelle Reaktion!

Zitat von Mathias_Thielen

Ich habe gerade erfahren, dass der SSH-Zugang nur für den einen FTP-Account vom Account-Typ "System-Benutzer" möglich sein soll. Ist das so?

Korrekt.

Zitat

Kann ich nicht einen zusätzlichen Benutzer anlegen der nur SSH-Loginrechte hat?

Nein.

bis dahin in die dovecot.local.conf einfügen:

service stats {
  unix_listener stats-writer {
    user = mail
    group = mail
  }
}

Kann man ja schön mit Puppet/Ansible/Salt automatisieren.

Zitat von kk

Bei Google Mail ist es ein zunehmendes Problem, dass Mails voreilig im Spam-Ordner landen und somit beim Empfänger faktisch nicht ankommen.

Nicht nur dort, auch bei Hotmail.

IMHO: Bouncen oder Taggen. Fertig.

Bei SpamAssassin kann der Bounce-Score ja auch direkt auf den Taggen-Score gesetzt werden: Somit kommt eine E-Mail entweder als "kein Spam" direkt in den Posteingang, oder wird gar nicht erst angenommen.

Wir haben aktuell des öfteren den Fall, dass SpamAssassin eine Mail nur als Spam markiert hat, die T-Online bei der Weiterleitung allerdings gebounced hat.

Das hat natürlich eigene Folgen, zeigt allerdings auch, dass bei einem Bounce statt dem Tagging die Mail nicht zum Problem geworden wäre.

Zitat

Aber für "unbelehrbare" werden wir dieses Feature dann wohl mit einem der nächsten Updates einführen. Beim Setzen der Checkbox ("verdächtige Mails in Spam-Ordner verschieben") wird dann einfach eine entsprechende Sieve-Regel erzeugt.

Können wir dafür in der Mailverwaltung oder beim Account das Feature deaktivierbar haben?

Und den Default auf "nicht verschieben", so dass der Nutzer/Kunde das explizit für jedes Postfach aktivieren muss?