In case of an accidental deletion of a mailbox, you will be able to recover for (by default) 5 days. This depends on the MAILDIR_GC_TIME parameter in mailcow.conf.
A deleted mailbox is copied in its encrypted form to /var/lib/docker/volumes/mailcowdockerized_vmail-vol-1/_data/_garbage.
@@ -2443,8 +2443,8 @@
To restore make sure you are actually restoring to the same mailcow it was deleted from or you use the same encryption keys in crypt-vol-1.
Make sure the user you want to restore exists in your mailcow. Re-create them if they are missing.
Copy the folders from /var/lib/docker/volumes/mailcowdockerized_vmail-vol-1/_data/_garbage/[timestamp]_[domain_sanitized][user_sanitized] back to /var/lib/docker/volumes/mailcowdockerized_vmail-vol-1/_data/[domain]/[user] and resync the folder and recalc the quota:
On the destination (in this case /external_share/backups) you may want to have snapshot capabilities (ZFS, Btrfs etc.). Snapshot daily and keep for n days for a consistent backup.
Do not rsync to a Samba share, you need to keep the correct permissions!
-
To restore you'd simply need to run rsync the other way round and restart Docker to re-read the volumes. Run docker compose pull and docker compose up -d.
+
To restore you'd simply need to run rsync the other way round and restart Docker to re-read the volumes. Run docker-compose pull and docker-compose up -d.
If you are lucky Redis and MariaDB can automatically fix the inconsistent databases (if they are inconsistent).
In case of a corrupted database you'd need to use the helper script to restore the inconsistent elements. If a restore fails, try to extract the backups and copy the files back manually. Keep the file permissions!
@@ -2539,7 +2539,7 @@ In case of a corrupted database you'd need to use the helper script to restore t
Last update:
- 2022-06-02 14:32:36
+ 2022-06-23 15:17:00
diff --git a/backup_restore/b_n_r-backup_restore-maildir/index.html b/backup_restore/b_n_r-backup_restore-maildir/index.html
index e06fe86cb..2fc159c5c 100644
--- a/backup_restore/b_n_r-backup_restore-maildir/index.html
+++ b/backup_restore/b_n_r-backup_restore-maildir/index.html
@@ -2428,13 +2428,13 @@
This line backups the vmail directory to a file backup_vmail.tar.gz in the mailcow root directory:
cd /path/to/mailcow-dockerized
-docker run --rm -i -v $(docker inspect --format '{{ range .Mounts }}{{ if eq .Destination "/var/vmail" }}{{ .Name }}{{ end }}{{ end }}' $(docker compose ps -q dovecot-mailcow)):/vmail -v ${PWD}:/backup debian:stretch-slim tar cvfz /backup/backup_vmail.tar.gz /vmail
+docker run --rm -i -v $(docker inspect --format '{{ range .Mounts }}{{ if eq .Destination "/var/vmail" }}{{ .Name }}{{ end }}{{ end }}' $(docker-compose ps -q dovecot-mailcow)):/vmail -v ${PWD}:/backup debian:stretch-slim tar cvfz /backup/backup_vmail.tar.gz /vmail
You can change the path by adjusting ${PWD} (which equals to the current directory) to any path you have write-access to.
Set the filename backup_vmail.tar.gz to any custom name, but leave the path as it is. Example: [...] tar cvfz /backup/my_own_filename_.tar.gz
To find the pathes of your source volumes we use docker inspect and read the destination directory of every volume related to your mailcow compose project. This means we will also transfer volumes you may have added in a override file. Local bind mounts may or may not work.
The use rsync with the --delete flag. The destination will be an exact copy of the source.
mariabackup is used to create a consistent copy of the SQL data directory.
-
After rsync'ing the data we will run docker compose pull and remove old image tags from the destination.
+
After rsync'ing the data we will run docker-compose pull and remove old image tags from the destination.
Your source will not be changed at any time.
You may want to make sure to use the same /etc/docker/daemon.json on the remote target.
You should not run disk snapshots (e.g. via ZFS, LVM etc.) on the target at the very same time as this script is run.
@@ -2513,7 +2513,7 @@ The destination must have Docker and docker compose v1 availabl
Last update:
- 2022-06-02 14:32:36
+ 2022-06-23 15:17:00
diff --git a/de/backup_restore/b_n_r-accidental_deletion/index.html b/de/backup_restore/b_n_r-accidental_deletion/index.html
index 35b3ef4f0..63c783e46 100644
--- a/de/backup_restore/b_n_r-accidental_deletion/index.html
+++ b/de/backup_restore/b_n_r-accidental_deletion/index.html
@@ -2432,10 +2432,10 @@
Stellen Sie sicher, dass der Benutzer, den Sie wiederherstellen wollen, in Ihrem Mailcow-Backend existiert. Legen Sie diesen neu an, falls nicht mehr existent.
Kopieren Sie die Datei mit dem Namen des Benutzers, den Sie wiederherstellen wollen, nach __MAILCOW_DIRECTORY__/data/conf/sogo.
1. Kopieren Sie die Sicherung: cp /var/lib/docker/volumes/mailcowdockerized_sogo-userdata-backup-vol-1/_data/restoreme@example.org __MAILCOW_DIRECTORY__/data/conf/sogo
-
2. Starten Sie docker compose exec -u sogo sogo-mailcow sogo-tool restore -F ALL /etc/sogo restoreme@example.org.
+
2. Starten Sie docker-compose exec -u sogo sogo-mailcow sogo-tool restore -F ALL /etc/sogo restoreme@example.org.
Führen Sie sogo-tool ohne Parameter aus, um nach möglichen Wiederherstellungsoptionen zu suchen.
3. Löschen Sie die kopierte Sicherung, indem Sie rm __MAILCOW_DIRECTORY__/data/conf/sogo ausführen
-
4. Starten Sie SOGo und Memcached neu: docker compose restart sogo-mailcow memcached-mailcow
+
4. Starten Sie SOGo und Memcached neu: docker-compose restart sogo-mailcow memcached-mailcow
Im Falle einer versehentlichen Löschung einer Mailbox, können Sie diese (standardmäßig) 5 Tage lang wiederherstellen. Dies hängt von dem MAILDIR_GC_TIME Parameter in mailcow.conf ab.
Eine gelöschte Mailbox wird in ihrer verschlüsselten Form nach /var/lib/docker/volumes/mailcowdockerized_vmail-vol-1/_data/_garbage kopiert.
@@ -2443,8 +2443,8 @@
Um die Mailbox wiederherzustellen, stellen Sie sicher, dass Sie tatsächlich auf die gleiche Mailcow wiederherstellen, von der sie gelöscht wurde, oder Sie verwenden die gleichen Verschlüsselungsschlüssel in crypt-vol-1.
Stellen Sie sicher, dass der Benutzer, den Sie wiederherstellen wollen, in Ihrer Mailcow existiert. Legen Sie diesen neu an, wenn der Benutzer fehlt.
Kopieren Sie die Ordner von /var/lib/docker/volumes/mailcowdockerized_vmail-vol-1/_data/_garbage/[timestamp]_[domain_sanitized][user_sanitized] zurück nach /var/lib/docker/volumes/mailcowdockerized_vmail-vol-1/_data/[domain]/[user] und synchronisieren Sie die Ordner neu und berechnen Sie die Quota (Speicherplatz) neu:
Am Zielort (in diesem Fall /external_share/backups) möchten Sie vielleicht Snapshot-Fähigkeiten haben (ZFS, Btrfs usw.). Machen Sie täglich einen Snapshot und bewahren Sie ihn für n Tage auf, um ein konsistentes Backup zu erhalten.
Führen Sie kein rsync auf eine Samba-Freigabe durch, Sie müssen die richtigen Berechtigungen einhalten!
-
Zum Wiederherstellen müssen Sie rsync einfach in umgekehrter Richtung ausführen und Docker neu starten, um die Volumes erneut zu lesen. Führen Sie docker compose pull und docker compose up -d aus.
+
Zum Wiederherstellen müssen Sie rsync einfach in umgekehrter Richtung ausführen und Docker neu starten, um die Volumes erneut zu lesen. Führen Sie docker-compose pull und docker-compose up -d aus.
Wenn Sie Glück haben, können Redis und MariaDB die inkonsistenten Datenbanken automatisch reparieren (wenn sie inkonsistent sind).
Im Falle einer beschädigten Datenbank müssen Sie das Hilfsskript verwenden, um die inkonsistenten Elemente wiederherzustellen. Wenn die Wiederherstellung fehlschlägt, versuchen Sie, die Sicherungen zu extrahieren und die Dateien manuell zurück zu kopieren. Behalten Sie die Dateiberechtigungen bei!
@@ -2558,7 +2558,7 @@ Im Falle einer beschädigten Datenbank müssen Sie das Hilfsskript verwenden, um
Letztes Update:
- 2022-06-02 14:32:36
+ 2022-06-23 15:17:00
diff --git a/de/backup_restore/b_n_r-backup_restore-maildir/index.html b/de/backup_restore/b_n_r-backup_restore-maildir/index.html
index 4050387ff..a463396c8 100644
--- a/de/backup_restore/b_n_r-backup_restore-maildir/index.html
+++ b/de/backup_restore/b_n_r-backup_restore-maildir/index.html
@@ -2428,13 +2428,13 @@
Diese Zeile sichert das vmail-Verzeichnis in eine Datei backup_vmail.tar.gz im mailcow-Root-Verzeichnis:
cd /pfad/zu/mailcow-dockerized
-docker run --rm -i -v $(docker inspect --format '{{ range .Mounts }}{{ if eq .Destination "/var/vmail" }}{{ .Name }}{{ end }}{{{ end }}' $(docker compose ps -q dovecot-mailcow)):/vmail -v ${PWD}:/backup debian:stretch-slim tar cvfz /backup/backup_vmail.tar.gz /vmail
+docker run --rm -i -v $(docker inspect --format '{{ range .Mounts }}{{ if eq .Destination "/var/vmail" }}{{ .Name }}{{ end }}{{{ end }}' $(docker-compose ps -q dovecot-mailcow)):/vmail -v ${PWD}:/backup debian:stretch-slim tar cvfz /backup/backup_vmail.tar.gz /vmail
Sie können den Pfad ändern, indem Sie ${PWD} (das dem aktuellen Verzeichnis entspricht) an einen beliebigen Pfad anpassen, auf den Sie Schreibzugriff haben.
Setzen Sie den Dateinamen backup_vmail.tar.gz auf einen beliebigen Namen, aber lassen Sie den Pfad so wie er ist. Beispiel: [...] tar cvfz /backup/mein_eigener_filename_.tar.gz
Um die Pfade Ihrer Quellvolumes zu finden, verwenden wir docker inspect und lesen das Zielverzeichnis jedes Volumes, das mit Ihrem mailcow compose Projekt verbunden ist. Das bedeutet, dass wir auch Volumes übertragen, die Sie in einer Override-Datei hinzugefügt haben. Lokale Bind-Mounts können funktionieren, müssen aber nicht.
Die Verwendung von rsync mit dem --delete Flag. Das Ziel wird eine exakte Kopie der Quelle sein.
mariabackup wird verwendet, um eine konsistente Kopie des SQL-Datenverzeichnisses zu erstellen.
-
Nach dem Rsync der Daten führen wir docker compose pull aus und entfernen alte Image-Tags aus dem Ziel.
+
Nach dem Rsync der Daten führen wir docker-compose pull aus und entfernen alte Image-Tags aus dem Ziel.
Ihre Quelle wird zu keinem Zeitpunkt verändert.
**Sie sollten sicherstellen, dass Sie die gleiche /etc/docker/daemon.json auf dem entfernten Ziel verwenden.
Sie sollten keine Festplatten-Snapshots (z. B. über ZFS, LVM usw.) auf dem Ziel ausführen, während dieses Skript ausgeführt wird.
@@ -2513,7 +2513,7 @@ Das Ziel muss über Docker und docker compose v1 verfügen.
Letztes Update:
- 2022-06-02 14:32:36
+ 2022-06-23 15:17:00
diff --git a/de/i_u_m/i_u_m_deinstall/index.html b/de/i_u_m/i_u_m_deinstall/index.html
index d9b4f21e6..d7f079e36 100644
--- a/de/i_u_m/i_u_m_deinstall/index.html
+++ b/de/i_u_m/i_u_m_deinstall/index.html
@@ -2361,7 +2361,7 @@
Deinstallation
Um mailcow: dockerized mit all seinen Volumes, Images und Containern zu entfernen, tun Sie dies:
-
docker compose down -v --rmi all --remove-orphans
+
docker-compose down -v --rmi all --remove-orphans
Info
@@ -2369,7 +2369,7 @@
-v Entfernt benannte Volumes, die im Abschnitt volumes der Compose-Datei deklariert sind, und anonyme Volumes, die an Container angehängt sind.
--rmi Images entfernen. Der Typ muss einer der folgenden sein: all: Entfernt alle Images, die von einem beliebigen Dienst verwendet werden. local: Entfernt nur Bilder, die kein benutzerdefiniertes Tag haben, das durch das Feld "image" gesetzt wurde.
--remove-orphans Entfernt Container für Dienste, die nicht in der Compose-Datei definiert sind.
-
Standardmäßig entfernt docker compose down nur derzeit aktive Container und Netzwerke, die in der Datei docker-compose.yml definiert sind.
+
Standardmäßig entfernt docker-compose down nur derzeit aktive Container und Netzwerke, die in der Datei docker-compose.yml definiert sind.
Schnelle Installation für die meisten Betriebssysteme:
+
+
+
Docker
curl -sSL https://get.docker.com/ | CHANNEL=stable sh
# Nachdem der Installationsprozess abgeschlossen ist, müssen Sie eventuell den Dienst aktivieren und sicherstellen, dass er gestartet ist (z. B. CentOS 7)
systemctl enable --now docker
+
+
+
+
Docker-Compose
+
+
+
+
Achtung
+
mailcow benötigt die neueste Version von docker-compose v2. Es wird dringend empfohlen, die untenstehenden Befehle zu verwenden, um docker-compose zu installieren. Paket-Manager (z.B. apt, yum) werden wahrscheinlich nicht die richtige Version liefern.
+Hinweis: Dieser Befehl lädt docker-compose aus dem offiziellen Docker-Github-Repository herunter und ist eine sichere Methode. Das Snippet ermittelt die neueste unterstützte Version von mailcow. In fast allen Fällen ist dies die letzte verfügbare Version (Ausnahmen sind kaputte Versionen oder größere Änderungen, die noch nicht von mailcow unterstützt werden).
Starten Sie den Docker-Daemon neu und überprüfen Sie, ob SELinux nun aktiviert ist.
-
Dieser Schritt ist erforderlich, um sicherzustellen, dass die mailcow-Volumes richtig gekennzeichnet werden, wie in der Compose-Datei angegeben.
-Wenn Sie daran interessiert sind, wie dies funktioniert, können Sie sich die Readme-Datei von https://github.com/containers/container-selinux ansehen, die auf viele nützliche Informationen zu diesem Thema verweist.
Version 2 Dateien werden von Compose 1.6.0+ unterstützt und erfordern eine Docker Engine der Version 1.10.0+.
-
-
Achtung
-
Seit Juni 2022 wurde Docker Compose v1 in der mailcow durch Docker Compose v2 abgelöst.
-Docker Compose v1 verliert den offiziellen Support seitens Docker im Oktober 2022.
-mailcow unterstützt bis Dezember 2022 Docker Compose v1. Danach ist die Installation unumgänglich, sollten Sie mailcow weiter betreiben wollen.
-
-
-
Kompatibilität
-
Das Webinterface wird im Zeitraum von Juni - Dezember 2022 standardmäßig nur über v4 erreichbar sein.
-Der Grund dafür ist die Dual-Kompatibilität zwischen Compose v1 und v2.
-Sollten Sie das Webinterface, wie bisher standardmäßig über v6 erreichen wollen, werfen Sie bitte einen Blick auf dieses Kapitel.
-Mit dem 2022-12 Update wird die native IPv6 Erreichbarkeit der Weboberfläche wiederhergestellt.
-
-
Sollten Sie mailcow frisch installieren und Docker auf die oben stehende Weise installiert haben, wird Docker Compose v2 schon mit installiert. Sie müssen also nichts weiter tun.
-
Prüfen lässt sich dies mit docker compose version, wenn die Rückgabe in etwa so aussieht: Docker Compose version v2.5.0, dann ist das neue Docker Compose bereits auf Ihrem System installiert.
-
Falls es nicht installiert ist oder Sie von Docker-Compose v1 auf v2 Upgraden möchten folgen Sie einfach der Anleitung:
Sollten Sie den mailcow Stack bereits mit docker-compose v1 betreiben, stellen Sie sicher, dass Sie den mailcow Stack vor dem Upgrade auf Compose v2 heruntergefahren und das aktuellste Update installiert haben
-
Um Docker Compose v1 zu deinstallieren geben Sie folgenden Befehl ein:
Docker Compose v2 kommt (vorausgesetzt Sie haben die Anleitung bei Punkt Installation von Docker befolgt) mit dem Repository mit.
-
Dann ist die Installation ganz einfach:
-
apt install docker-compose-plugin -y
-
-
Nun noch einmal docker compose version eingeben und die Rückgabe überprüfen. Ist diese ähnlich zu: Docker Compose version v2.5.0? Dann ist alles korrekt installiert worden!
-
-
Hinweis
-
Sollten Sie ein anderes Betriebssystem als Debian/Ubuntu verwenden, werfen Sie bitte einen Blick in das offizielle Installationshandbuch von Docker selbst, um zu erfahren wie Sie Docker Compose v2 auf anderen Linux Systemen installieren können.
1. Klonen Sie den Master-Zweig des Repositorys und stellen Sie sicher, dass Ihre umask gleich 0022 ist.
- Bitte klonen Sie das Repository als root-Benutzer und kontrollieren Sie auch den Stack als root.
- Wir werden die Attribute - wenn nötig - ändern, während wir die Container automatisch bereitstellen und sicherstellen, dass alles gesichert ist.
- Das update.sh-Skript muss daher ebenfalls als root ausgeführt werden.
- Es kann notwendig sein, den Besitzer und andere Attribute von Dateien zu ändern, auf die Sie sonst keinen Zugriff haben.
- Wir geben die Berechtigungen für jede exponierte Anwendung auf und führen einen exponierten Dienst nicht als root aus!
- Wenn Sie den Docker-Daemon als Nicht-Root-Benutzer steuern, erhalten Sie keine zusätzliche Sicherheit.
- Der unprivilegierte Benutzer wird die Container ebenfalls als root spawnen. Das Verhalten des Stacks ist identisch.
+
Dieser Schritt ist erforderlich, um sicherzustellen, dass die mailcows-Volumes richtig gekennzeichnet sind, wie in der Compose-Datei angegeben.
+Wenn Sie daran interessiert sind, wie das funktioniert, können Sie sich die Readme-Datei von https://github.com/containers/container-selinux ansehen, die auf viele nützliche Informationen zu diesem Thema verweist.
+
2. Klonen Sie den Master-Zweig des Repositorys und stellen Sie sicher, dass Ihre umask gleich 0022 ist. Bitte klonen Sie das Repository als root-Benutzer und kontrollieren Sie auch den Stack als root. Wir werden die Attribute - wenn nötig - ändern, während wir die Container automatisch bereitstellen und sicherstellen, dass alles gesichert ist. Das update.sh-Skript muss daher ebenfalls als root ausgeführt werden. Es kann notwendig sein, den Besitzer und andere Attribute von Dateien zu ändern, auf die Sie sonst keinen Zugriff haben. Wir geben die Berechtigungen für jede exponierte Anwendung auf und führen einen exponierten Dienst nicht als root aus! Wenn Sie den Docker-Daemon als Nicht-Root-Benutzer steuern, erhalten Sie keine zusätzliche Sicherheit. Der unprivilegierte Benutzer wird die Container ebenfalls als root spawnen. Das Verhalten des Stacks ist identisch.
$ su
# umask
0022 # <- Überprüfen, dass es 0022 ist
@@ -2558,16 +2412,16 @@ Sollten Sie das Webinterface, wie bisher standardmäßig über v6 erreichen woll
# git clone https://github.com/mailcow/mailcow-dockerized
# cd mailcow-dockerized
-
2. Erzeugen Sie eine Konfigurationsdatei. Verwenden Sie einen FQDN (host.domain.tld) als Hostname, wenn Sie gefragt werden.
+
3. Erzeugen Sie eine Konfigurationsdatei. Verwenden Sie einen FQDN (host.domain.tld) als Hostname, wenn Sie gefragt werden.
./generate_config.sh
-
3. Ändern Sie die Konfiguration, wenn Sie dies möchten:
+
4. Ändern Sie die Konfiguration, wenn Sie das wollen oder müssen.
nano mailcow.conf
-Wenn Sie planen, einen Reverse-Proxy zu verwenden, können Sie zum Beispiel HTTPS an 127.0.0.1 auf Port 8443 und HTTP an 127.0.0.1 auf Port 8080 binden.
+Wenn Sie planen, einen Reverse Proxy zu verwenden, können Sie zum Beispiel HTTPS an 127.0.0.1 auf Port 8443 und HTTP an 127.0.0.1 auf Port 8080 binden.
Möglicherweise müssen Sie einen vorinstallierten MTA stoppen, der Port 25/tcp blockiert. Siehe dieses Kapitel, um zu erfahren, wie man Postfix rekonfiguriert, um nach einer erfolgreichen Installation neben mailcow laufen zu lassen.
Einige Updates modifizieren mailcow.conf und fügen neue Parameter hinzu. Es ist schwer, in der Dokumentation den Überblick zu behalten. Bitte überprüfen Sie deren Beschreibung und fragen Sie, wenn Sie unsicher sind, in den bekannten Kanälen nach Rat.
-
3.1. Benutzer mit einer MTU ungleich 1500 (z.B. OpenStack):
+
4.1. Benutzer mit einer MTU ungleich 1500 (z.B. OpenStack):
Wenn Sie auf Probleme und seltsame Phänomene stoßen, überprüfen Sie bitte Ihre MTU.
Bearbeiten Sie docker-compose.yml und ändern Sie die Netzwerkeinstellungen entsprechend Ihrer MTU.
Fügen Sie den neuen Parameter driver_opts wie folgt hinzu:
@@ -2578,31 +2432,28 @@ Fügen Sie den neuen Parameter driver_opts wie folgt hinzu:
com.docker.network.driver.mtu: 1450
...
-
3.2. Benutzer ohne ein IPv6-aktiviertes Netzwerk auf ihrem Hostsystem:
+
4.2. Benutzer ohne ein IPv6-aktiviertes Netzwerk auf ihrem Hostsystem:
Einschalten von IPv6. Endlich.
Wenn Sie kein IPv6-fähiges Netzwerk auf Ihrem Host haben und Sie sich nicht um ein besseres Internet kümmern (hehe), ist es empfehlenswert, IPv6 für das mailcow-Netzwerk zu deaktivieren, um unvorhergesehene Probleme zu vermeiden.
-
4. Laden Sie die Docker Images herunter und führen Sie die Compose-Datei aus, um die mailcow-Container zu starten. Der Parameter -d sorgt dafür, dass die Container im Hintergrund ausgeführt werden.
-
docker compose pull
-docker compose up -d
-
-
Der Container Status kann mit folgendem Befehl abgefragt werden:
-
docker compose ps
+
5. LAden Sie die Images herunter und führen Sie die Compose-Datei aus. Der Parameter -d wird mailcow: dockerized starten:
+
docker-compose pull
+docker-compose up -d
-
Fertig!
+
Geschafft!
Sie können nun auf https://${MAILCOW_HOSTNAME} mit den Standard-Zugangsdaten admin + Passwort moohoo zugreifen.
Die Datenbank wird sofort initialisiert, nachdem eine Verbindung zur MySQL-Datenbank hergestellt werden kann.
-
Ihre Daten bleiben in mehreren Docker-Volumes erhalten, die nicht gelöscht werden, wenn Sie Container neu erstellen oder löschen. Führen Sie docker volume ls aus, um eine Liste aller Volumes zu sehen. Sie können docker compose down sicher ausführen, ohne persistente Daten zu entfernen.
+
Die Datenbank wird sofort initialisiert, nachdem eine Verbindung zu MySQL hergestellt werden kann.
+
Ihre Daten bleiben in mehreren Docker-Volumes erhalten, die nicht gelöscht werden, wenn Sie Container neu erstellen oder löschen. Führen Sie docker volume ls aus, um eine Liste aller Volumes zu sehen. Sie können docker-compose down sicher ausführen, ohne persistente Daten zu entfernen.
Alternativ können Sie das Skript ./helper-scripts/backup_and_restore.sh verwenden, um ein vollständiges Backup auf der Quellmaschine zu erstellen, dann installieren Sie mailcow auf der Zielmaschine wie gewohnt, kopieren Sie Ihre mailcow.conf und verwenden Sie das gleiche Skript, um Ihr Backup auf der Zielmaschine wiederherzustellen.
Siehe das obige Thema, anstelle eines Diffs führen Sie checkout aus:
-
docker compose down
+
docker-compose down
# Ersetzen Sie die Commit-ID 22cd00b5e28893ef9ddef3c2b5436453cc5223ab durch Ihre ID
git checkout 22cd00b5e28893ef9ddef3c2b5436453cc5223ab
-docker compose pull
-docker compose up -d
+docker-compose pull
+docker-compose up -d
Sie können sich in den Update-Mechanismus einklinken, indem Sie Skripte namens pre_commit_hook.sh und post_commit_hook.sh zu Ihrem mailcows-Root-Verzeichnis hinzufügen. Siehe hier für weitere Details.
Es kann vorkommen, dass legitime (saubere) Mails von ClamAV blockiert werden (Rspamd markiert die Mail mit VIRUS_FOUND). So werden beispielsweise interaktive PDF-Formularanhänge standardmäßig blockiert, da der eingebettete Javascript-Code für schädliche Zwecke verwendet werden könnte. Überprüfen Sie dies anhand der clamd-Protokolle, z.B.:
Diese Zeile bestätigt, dass ein solcher identifiziert wurde:
clamd-mailcow_1 | Sat Sep 28 07:43:24 2019 -> instream(local): PUA.Pdf.Trojan.EmbeddedJavaScript-1(e887d2ac324ce90750768b86b63d0749:363325) FOUND
@@ -2421,11 +2421,11 @@
Um diese spezielle Signatur auf die Whitelist zu setzen (und den Versand dieses Dateityps im Anhang zu ermöglichen), fügen Sie sie der ClamAV-Signatur-Whitelist-Datei hinzu:
docker-compose exec dovecot-mailcow doveadm expunge -A mailbox 'Junk' savedbefore 7d
Löscht alle Mails (aller Benutzer) in allen Ordnern, die älter als 52 Wochen sind (internes Datum der Mail, nicht das Datum, an dem sie auf dem System gespeichert wurde => before statt savedbefore). Nützlich zum Löschen sehr alter Mails in allen Benutzern und Ordnern (daher besonders nützlich für GDPR-Compliance).
-
docker compose exec dovecot-mailcow doveadm expunge -A mailbox % before 52w
+
docker-compose exec dovecot-mailcow doveadm expunge -A mailbox % before 52w
Löschen von Mails in einem benutzerdefinierten Ordner innerhalb des Posteingangs eines Benutzers, die nicht gekennzeichnet und älter als 2 Wochen sind
-
docker compose exec dovecot-mailcow doveadm expunge -u 'mailbox@example.com' mailbox 'INBOX/custom-folder' not FLAGGED not SINCE 2w
+
docker-compose exec dovecot-mailcow doveadm expunge -u 'mailbox@example.com' mailbox 'INBOX/custom-folder' not FLAGGED not SINCE 2w
Info
@@ -2491,8 +2491,8 @@
# Pfad zu mailcow-dockerized, z.B. /opt/mailcow-dockerized
cd /pfad/zu/ihrem/mailcow-dockerized
-/usr/local/bin/docker compose exec -T dovecot-mailcow doveadm expunge -A mailbox 'Junk' savedbefore 2w
-/usr/local/bin/docker compose exec -T dovecot-mailcow doveadm expunge -A mailbox 'Junk' SEEN not SINCE 12h
+/usr/local/bin/docker-compose exec -T dovecot-mailcow doveadm expunge -A mailbox 'Junk' savedbefore 2w
+/usr/local/bin/docker-compose exec -T dovecot-mailcow doveadm expunge -A mailbox 'Junk' SEEN not SINCE 12h
[...]
Um einen Cronjob zu erstellen, können Sie crontab -e ausführen und etwas wie das Folgende einfügen, um ein Skript auszuführen:
Da wir in Docker laufen und unsere Container mit dem "restart: always" Flag erstellen, wird eine oom Situation zumindest nur einen Neustart des Containers auslösen.
Dovecot Wiki: "Scannt, welche Mails im Volltextsuchindex vorhanden sind und vergleicht diese mit den tatsächlich in den Postfächern vorhandenen Mails. Dies entfernt Mails aus dem Index, die bereits gelöscht wurden und stellt sicher, dass der nächste doveadm-Index alle fehlenden Mails (falls vorhanden) indiziert."
Dies indiziert nicht eine Mailbox neu. Es repariert im Grunde einen gegebenen Index.
Wenn Sie die Daten sofort neu indizieren wollen, können Sie den folgenden Befehl ausführen, wobei '*' auch eine Postfachmaske wie 'Sent' sein kann. Sie müssen diese Befehle nicht ausführen, aber es wird die Dinge ein wenig beschleunigen:
# einzelner Benutzer
-docker compose exec dovecot-mailcow doveadm index -u user@domain '*'
+docker-compose exec dovecot-mailcow doveadm index -u user@domain '*'
# alle Benutzer, aber offensichtlich langsamer und gefährlicher
-docker compose exec dovecot-mailcow doveadm index -A '*'
+docker-compose exec dovecot-mailcow doveadm index -A '*'
Dies wird einige Zeit in Anspruch nehmen, abhängig von Ihrer Maschine und Solr kann oom ausführen, überwachen Sie es!
Da die Neuindizierung sehr sinnvoll ist, haben wir sie nicht in die mailcow UI integriert. Sie müssen sich um eventuelle Fehler beim Re-Indizieren einer Mailbox kümmern.
@@ -2481,7 +2481,7 @@ docker compose exec dovecot-mailcow doveadm index -A '*'
Letztes Update:
- 2022-06-02 14:32:36
+ 2022-06-23 15:17:00
diff --git a/de/manual-guides/Dovecot/u_e-dovecot-idle_interval/index.html b/de/manual-guides/Dovecot/u_e-dovecot-idle_interval/index.html
index f1b567ddb..3771f0daf 100644
--- a/de/manual-guides/Dovecot/u_e-dovecot-idle_interval/index.html
+++ b/de/manual-guides/Dovecot/u_e-dovecot-idle_interval/index.html
@@ -2486,12 +2486,12 @@ Fügen Sie die Einstellung ein, gefolgt von dem neuen Wert. Um zum Beispiel das
Sie können den Wert dieser Einstellung überprüfen mit
-
docker compose exec dovecot-mailcow dovecot -a | grep "imap_idle_notify_interval"
+
docker-compose exec dovecot-mailcow dovecot -a | grep "imap_idle_notify_interval"
Wenn Sie den Wert nicht geändert haben, sollte er auf 2m stehen. Wenn Sie ihn geändert haben, sollten Sie den neuen Wert sehen.
@@ -2501,7 +2501,7 @@ Wenn Sie den Wert nicht geändert haben, sollte er auf 2m stehen. Wenn Sie ihn g
Letztes Update:
- 2022-06-02 14:32:36
+ 2022-06-23 15:17:00
diff --git a/de/manual-guides/Dovecot/u_e-dovecot-mail-crypt/index.html b/de/manual-guides/Dovecot/u_e-dovecot-mail-crypt/index.html
index 5732e5e09..e4380a283 100644
--- a/de/manual-guides/Dovecot/u_e-dovecot-mail-crypt/index.html
+++ b/de/manual-guides/Dovecot/u_e-dovecot-mail-crypt/index.html
@@ -2364,7 +2364,7 @@
Die Mails werden komprimiert (lz4) und verschlüsselt gespeichert. Das Schlüsselpaar ist in crypt-vol-1 zu finden.
Wenn Sie vorhandene maildir-Dateien entschlüsseln/verschlüsseln wollen, können Sie das folgende Skript auf eigene Gefahr verwenden:
-
Rufen Sie Dovecot auf, indem Sie docker compose exec dovecot-mailcow /bin/bash im mailcow-dockerisierten Verzeichnis ausführen.
+
Rufen Sie Dovecot auf, indem Sie docker-compose exec dovecot-mailcow /bin/bash im mailcow-dockerisierten Verzeichnis ausführen.
# Entschlüsseln Sie /var/vmail
find /var/vmail/ -type f -regextype egrep -regex '.*S=.*W=.*' | while read -r file; do
if [[ $(head -c7 "$file") == "CRYPTED" ]]; then
@@ -2397,7 +2397,7 @@ done
Letztes Update:
- 2022-06-02 14:32:36
+ 2022-06-23 15:17:00
diff --git a/de/manual-guides/Dovecot/u_e-dovecot-public_folder/index.html b/de/manual-guides/Dovecot/u_e-dovecot-public_folder/index.html
index 72c4974c3..eef096dd5 100644
--- a/de/manual-guides/Dovecot/u_e-dovecot-public_folder/index.html
+++ b/de/manual-guides/Dovecot/u_e-dovecot-public_folder/index.html
@@ -2427,7 +2427,7 @@
:INDEXPVT=~/public kann weggelassen werden, wenn die Flags, die pro Benutzer gesehen werden, nicht gewünscht sind.
Die neue Mailbox im öffentlichen Namensraum wird von den Benutzern automatisch abonniert.
Um allen authentifizierten Benutzern vollen Zugriff auf das neue Postfach (nicht auf den gesamten Namespace) zu gewähren, führen Sie aus:
-
docker compose exec dovecot-mailcow doveadm acl set -A "Public/Develcow" "authenticated" lookup read write write-seen write-deleted insert post delete expunge create
+
docker-compose exec dovecot-mailcow doveadm acl set -A "Public/Develcow" "authenticated" lookup read write write-seen write-deleted insert post delete expunge create
Passen Sie den Befehl an Ihre Bedürfnisse an, wenn Sie detailliertere Rechte pro Benutzer vergeben möchten (verwenden Sie z.B. -u user@domain anstelle von -A).
Erlaube authentifizierten Benutzern den Zugriff auf den gesamten öffentlichen Namespace¶
Führen Sie docker compose up -d aus, um Ihre Änderungen zu übernehmen.
+
Führen Sie docker-compose up -d aus, um Ihre Änderungen zu übernehmen.
Der statische Master-Benutzername wird zu DOVECOT_MASTER_USER@mailcow.local erweitert.
Um sich als test@example.org anzumelden, würde dies test@example.org*mymasteruser@mailcow.local mit dem oben angegebenen Passwort entsprechen.
Eine Anmeldung bei SOGo ist mit diesem Benutzernamen nicht möglich. Für Admins steht eine Click-to-Login-Funktion für SOGo zur Verfügung, wie [hier] beschrieben (https://mailcow.github.io/mailcow-dockerized-docs/debug-admin_login_sogo/)
@@ -2380,7 +2380,7 @@ Es wird kein Hauptbenutzer benötigt.
Neuere Docker-Versionen scheinen sich über bestehende Volumes zu beschweren. Man kann dies vorübergehend beheben, indem man das bestehende Volume entfernt und mailcow mit der Override-Datei startet. Aber es scheint nach einem Neustart problematisch zu sein (muss bestätigt werden).
-
Ein einfacher, schmutziger, aber stabiler Workaround ist es, mailcow zu stoppen (docker compose down), /var/lib/docker/volumes/mailcowdockerized_vmail-vol-1/_data zu entfernen und einen neuen Link zu Ihrem entfernten Dateisystem zu erstellen, zum Beispiel:
+
Ein einfacher, schmutziger, aber stabiler Workaround ist es, mailcow zu stoppen (docker-compose down), /var/lib/docker/volumes/mailcowdockerized_vmail-vol-1/_data zu entfernen und einen neuen Link zu Ihrem entfernten Dateisystem zu erstellen, zum Beispiel:
Kopieren Sie den Inhalt des Mountpoint-Ordners an den neuen Speicherort (z.B. /data/mailcow/vmail) mit cp -a, rsync -a oder einem ähnlichen, nicht strikten Kopierbefehl
-
Stoppen Sie mailcow durch Ausführen von docker compose down aus Ihrem mailcow-Stammverzeichnis (z.B. /opt/mailcow-dockerized)
+
Stoppen Sie mailcow durch Ausführen von docker-compose down aus Ihrem mailcow-Stammverzeichnis (z.B. /opt/mailcow-dockerized)
Erstellen Sie die Datei docker-compose.override.yml, bearbeiten Sie den Gerätepfad entsprechend
Löschen Sie den aktuellen vmail-Ordner: docker volume rm mailcowdockerized_vmail-vol-1
-
Starten Sie mailcow durch Ausführen von docker compose up -d aus Ihrem mailcow-Stammverzeichnis (z.B. /opt/mailcow-dockerized)
+
Starten Sie mailcow durch Ausführen von docker-compose up -d aus Ihrem mailcow-Stammverzeichnis (z.B. /opt/mailcow-dockerized)
Dieser Dateiname muss keine ".conf"-Erweiterung haben, sondern folgt dem Muster site.*.custom, wobei * ein eigener Name ist.
Wenn PHP in eine benutzerdefinierte Site eingebunden werden soll, verwenden Sie bitte den PHP-FPM-Listener auf phpfpm:9002 oder erstellen Sie einen neuen Listener in data/conf/phpfpm/php-fpm.d/pools.conf.
Starten Sie Nginx neu (und PHP-FPM, falls ein neuer Listener erstellt wurde):
Postfix wird sich einmal nach dem Start von postfix-mailcow über doppelte Werte beschweren, dies ist beabsichtigt.
Syslog-ng wurde so konfiguriert, dass es diese Warnungen ausblendet, während Postfix läuft, um die Log-Dateien nicht jedes Mal mit unnötigen Informationen zu spammen, wenn ein Dienst benutzt wird.
Starten Sie postfix-mailcow neu, um Ihre Änderungen zu übernehmen:
Das Hinzufügen von IPv6-Hosts erfolgt auf die gleiche Weise wie bei IPv4, allerdings muss das Subnetz in eckige Klammern [] gesetzt und die Netzmaske angehängt werden.
Um das Subnetz 2001:db8::/32 zu den vertrauenswürdigen Netzwerken hinzuzufügen, können Sie die folgende Konfiguration verwenden, abhängig von Ihren IPV4_NETWORK- und IPV6_NETWORK-Bereichen:
Redis wird als Key-Value-Speicher für die Einstellungen und Daten von rspamd und (einige von) mailcow verwendet. Wenn Sie mit Redis nicht vertraut sind, lesen Sie bitte die Einführung in Redis und besuchen Sie gegebenenfalls diese wunderbare Anleitung, um zu erfahren, wie man Redis benutzt.
Erwägen Sie, einen lokalen Ordner als neues Volume an rspamd-mailcow in docker-compose.yml anzuhängen und die gegebenen Dateien innerhalb des Containers zu lernen. Dies kann als Workaround verwendet werden, um komprimierte Daten mit zcat zu parsen. Beispiel:
``bash
@@ -2562,15 +2562,15 @@ Sie müssen die Schlüssel in Redis löschen, um die gelernten Daten zurückzuse
cp /var/lib/docker/volumes/mailcowdockerized_redis-vol-1/_data/dump.rdb /root/
# Wir müssen zuerst das redis-cli eingeben:
-docker compose exec redis-mailcow redis-cli
+docker-compose exec redis-mailcow redis-cli
# In redis-cli:127.0.0.1:6379> EVAL "for i, name in ipairs(redis.call('KEYS', ARGV[1])) do redis.call('DEL', name); end"0 fuzzy*
## Greylisting deaktivieren
Nur Nachrichten mit einer höheren Punktzahl werden als Greylisting betrachtet (soft rejected). Es ist schlechte Praxis, Greylisting zu deaktivieren.
@@ -2596,26 +2596,26 @@ Fügen Sie die Zeile hinzu:
```cpp
enabled = false;
-
Speichern Sie die Datei und starten Sie "rspamd-mailcow" neu: docker compose restart rspamd-mailcow
+
Speichern Sie die Datei und starten Sie "rspamd-mailcow" neu: docker-compose restart rspamd-mailcow
Jeder Benutzer kann seine Spam-Bewertung individuell ändern. Um eine neue serverweite Grenze zu definieren, editieren Sie data/conf/rspamd/local.d/actions.conf:
reject=15;add_header=8;greylist=7;
-
Speichern Sie die Datei und starten Sie "rspamd-mailcow" neu: docker compose restart rspamd-mailcow
+
Speichern Sie die Datei und starten Sie "rspamd-mailcow" neu: docker-compose restart rspamd-mailcow
Bestehende Einstellungen der Benutzer werden nicht überschrieben!
Um benutzerdefinierte Schwellenwerte zurückzusetzen, führen Sie aus:
source mailcow.conf
-docker compose exec mysql-mailcow mysql -umailcow -p$DBPASS mailcow -e "delete from filterconf where option = 'highspamlevel' or option = 'lowspamlevel';"
+docker-compose exec mysql-mailcow mysql -umailcow -p$DBPASS mailcow -e "delete from filterconf where option = 'highspamlevel' or option = 'lowspamlevel';"
# oder:
-# docker compose exec mysql-mailcow mysql -umailcow -p$DBPASS mailcow -e "delete from filterconf where option = 'highspamlevel' or option = 'lowspamlevel' and object = 'only-this-mailbox@example.org';"
+# docker-compose exec mysql-mailcow mysql -umailcow -p$DBPASS mailcow -e "delete from filterconf where option = 'highspamlevel' or option = 'lowspamlevel' and object = 'only-this-mailbox@example.org';"
Die Standard-Spam-Reject-Meldung kann durch Hinzufügen einer neuen Datei data/conf/rspamd/override.d/worker-proxy.custom.inc mit dem folgenden Inhalt geändert werden:
reject_message = "Meine eigene Ablehnungsnachricht";
-
Speichern Sie die Datei und starten Sie Rspamd neu: docker compose restart rspamd-mailcow.
+
Speichern Sie die Datei und starten Sie Rspamd neu: docker-compose restart rspamd-mailcow.
Waehrend das oben genannte fuer abgelehnte Mails mit einem hohen Spam-Score funktioniert, ignorieren Prefilter-Aktionen diese Einstellung. Für diese Karten muss das Multimap-Modul in Rspamd angepasst werden:
Wenn Sie eine Nachricht stillschweigend verwerfen wollen, erstellen oder bearbeiten Sie die Datei data/conf/rspamd/override.d/worker-proxy.custom.inc und fügen Sie den folgenden Inhalt hinzu:
Wenn Sie das UI nicht verwenden wollen und stattdessen alle Schlüssel in der Redis-Datenbank löschen wollen, können Sie redis-cli für diese Aufgabe verwenden:
-
docker compose exec redis-mailcow sh
+
docker-compose exec redis-mailcow sh
# Unlink (verfügbar in Redis >=4.) löscht im Hintergrund
redis-cli --scan --pattern RL* | xargs redis-cli unlink
Starten Sie Rspamd neu:
-
docker compose exec redis-mailcow sh
+
docker-compose exec redis-mailcow sh
Erneutes Senden von Quarantäne-Benachrichtigungen auslösen¶
Sollte nur zur Fehlersuche verwendet werden!
-
docker compose exec dovecot-mailcow bash
+
docker-compose exec dovecot-mailcow bash
mysql -umailcow -p$DBPASS mailcow -e "update quarantine set notified = 0;"
redis-cli -h redis DEL Q_LAST_NOTIFIED
quarantine_notify.py
@@ -2667,14 +2667,14 @@ quarantine_notify.py
Bearbeiten Sie data/conf/rspamd/local.d/history_redis.conf:
nrows = 1000; # Ändern Sie diesen Wert
-
Starten Sie anschließend Rspamd neu: docker compose restart rspamd-mailcow
+
Starten Sie anschließend Rspamd neu: docker-compose restart rspamd-mailcow
Letztes Update:
- 2022-06-02 15:19:55
+ 2022-06-23 15:17:00
diff --git a/de/manual-guides/SOGo/u_e-sogo/index.html b/de/manual-guides/SOGo/u_e-sogo/index.html
index 7c9c0ae87..b7c379219 100644
--- a/de/manual-guides/SOGo/u_e-sogo/index.html
+++ b/de/manual-guides/SOGo/u_e-sogo/index.html
@@ -2501,7 +2501,7 @@ Bitte schauen Sie sich die AngularJS Material Zurücksetzen auf das SOGo Standardthema¶
@@ -2553,17 +2553,17 @@ und ersetzen Sie es durch:
Entfernen Sie aus docker-compose.override.yml Volume Mount in sogo-mailcow:
mailcow-Builds nach dem 31. Januar 2021 können SOGo's Favicon ändern, indem sie data/conf/sogo/custom-favicon.ico für SOGo und data/web/favicon.png für mailcow UI ersetzen.
Anmerkung: Sie können .png Favicons für SOGo verwenden, indem Sie sie in custom-favicon.ico umbenennen.
Für beide, SOGo und mailcow UI Favicons, müssen Sie eine der Standardgrößen verwenden: 16x16, 32x32, 64x64, 128x128 und 256x256.
-Nachdem Sie diese Datei ersetzt haben, müssen Sie SOGo und Memcached Container neu starten, indem Sie docker compose restart memcached-mailcow sogo-mailcow ausführen.
+Nachdem Sie diese Datei ersetzt haben, müssen Sie SOGo und Memcached Container neu starten, indem Sie docker-compose restart memcached-mailcow sogo-mailcow ausführen.
Mailcow-Builds nach dem 21. Dezember 2018 können das SOGo-Logo ändern, indem sie die Datei data/conf/sogo/sogo-full.svg ersetzen oder erstellen (falls sie fehlt).
-Nachdem Sie diese Datei ersetzt haben, müssen Sie SOGo und Memcached Container neu starten, indem Sie docker compose restart memcached-mailcow sogo-mailcow ausführen.
+Nachdem Sie diese Datei ersetzt haben, müssen Sie SOGo und Memcached Container neu starten, indem Sie docker-compose restart memcached-mailcow sogo-mailcow ausführen.
Führen Sie docker compose exec -u sogo sogo-mailcow sogo-tool user-preferences set defaults user@example.com SOGoTOTPEnabled '{"SOGoTOTPEnabled":0}' aus dem mailcow Verzeichnis aus.
+
Führen Sie docker-compose exec -u sogo sogo-mailcow sogo-tool user-preferences set defaults user@example.com SOGoTOTPEnabled '{"SOGoTOTPEnabled":0}' aus dem mailcow Verzeichnis aus.
Letztes Update:
- 2022-06-02 15:19:55
+ 2022-06-23 15:17:00
diff --git a/de/manual-guides/Unbound/u_e-unbound-fwd/index.html b/de/manual-guides/Unbound/u_e-unbound-fwd/index.html
index bec5ee632..6fa4ae7a1 100644
--- a/de/manual-guides/Unbound/u_e-unbound-fwd/index.html
+++ b/de/manual-guides/Unbound/u_e-unbound-fwd/index.html
@@ -2439,21 +2439,21 @@
forward-addr: 8.8.4.4 # VERWENDET KEINE ÖFFENTLICHEN DNS-SERVER - NUR EIN BEISPIEL
Um sie anzupassen, fügen Sie einfach die notwendigen Threshold Variablen (z.B. MAILQ_THRESHOLD=10) zu mailcow.conf hinzu und führen docker compose up -d aus.
+
Um sie anzupassen, fügen Sie einfach die notwendigen Threshold Variablen (z.B. MAILQ_THRESHOLD=10) zu mailcow.conf hinzu und führen docker-compose up -d aus.
Benachrichtigt Administratoren, wenn Watchdog keine Verbindung zu Nginx auf Port 8081 herstellen kann und startet den Container automatisch neu, wenn Probleme gefunden wurden und der Threshold erreicht wurde.
@@ -2725,7 +2725,7 @@ Beispiel:
Letztes Update:
- 2022-06-02 15:19:55
+ 2022-06-23 15:17:00
diff --git a/de/manual-guides/mailcow-UI/u_e-mailcow_ui-tfa/index.html b/de/manual-guides/mailcow-UI/u_e-mailcow_ui-tfa/index.html
index 61005ed2d..c27c29ebf 100644
--- a/de/manual-guides/mailcow-UI/u_e-mailcow_ui-tfa/index.html
+++ b/de/manual-guides/mailcow-UI/u_e-mailcow_ui-tfa/index.html
@@ -2619,7 +2619,7 @@ Geben Sie schließlich Ihr aktuelles Kontopasswort ein und berühren Sie nach Au
Mit WebAuthn gibt es die Möglichkeit, nur offizielle Fido Security Keys zu verwenden (von den großen Marken wie: Yubico, Apple, Nitro, Google, Huawei, Microsoft, usw.) zu verwenden.
Dies dient in erster Linie der Sicherheit, da es Administratoren ermöglicht, sicherzustellen, dass nur offizielle Hardware in ihrer Umgebung verwendet werden kann.
-
Um diese Funktion zu aktivieren, ändern Sie den Wert WEBAUTHN_ONLY_TRUSTED_VENDORS in mailcow.conf von n auf y und starten Sie die betroffenen Container mit docker compose up -d neu.
+
Um diese Funktion zu aktivieren, ändern Sie den Wert WEBAUTHN_ONLY_TRUSTED_VENDORS in mailcow.conf von n auf y und starten Sie die betroffenen Container mit docker-compose up -d neu.
Die mailcow wird nun die Vendor-Zertifikate verwenden, die sich in Ihrem mailcow-Verzeichnis unter data/web/inc/lib/WebAuthn/rootCertificates befinden.
Wenn Sie die offiziellen Hersteller-Geräte nur auf Apple beschränken wollen, brauchen Sie nur das Apple Hersteller-Zertifikat im data/web/inc/lib/WebAuthn/rootCertificates.
@@ -2652,7 +2652,7 @@ Diese Herstellerzertifikate werden nur zur Überprüfung der Originalhardware ve
Letztes Update:
- 2022-06-02 14:32:36
+ 2022-06-23 15:17:00
diff --git a/de/manual-guides/u_e-80_to_443/index.html b/de/manual-guides/u_e-80_to_443/index.html
index 3ea8b41a1..4240c9ccb 100644
--- a/de/manual-guides/u_e-80_to_443/index.html
+++ b/de/manual-guides/u_e-80_to_443/index.html
@@ -2380,10 +2380,10 @@
}
Falls Sie den Parameter HTTP_BIND geändert haben, erstellen Sie den Container neu:
Damit diese Änderungen wirksam werden, müssen Sie den Stack vollständig stoppen und dann neu starten, damit Container und Netzwerke neu erstellt werden:
-
docker compose down
-docker compose up -d
+
docker-compose down
+docker-compose up -d
3. Deaktivieren Sie IPv6 in unbound-mailcow
Bearbeiten Sie data/conf/unbound/unbound.conf und setzen Sie do-ip6 auf "no":
@@ -2401,7 +2401,7 @@ docker compose up -d
[...]
unbound neu starten:
-
docker compose restart unbound-mailcow
+
docker-compose restart unbound-mailcow
4. Deaktivieren Sie IPv6 in postfix-mailcow
Erstellen Sie data/conf/postfix/extra.cf und setzen Sie smtp_address_preference auf ipv4:
Senden Sie eine Kopie der Berichte an sich selbst¶
Um eine versteckte Kopie der von Rspamd erzeugten Berichte zu erhalten, können Sie eine bcc_addrs Liste im reporting Konfigurationsabschnitt von data/conf/rspamd/local.d/dmarc.conf setzen:
Im obigen Beispiel werden die Berichte einmal alle 24 Stunden gesendet.
@@ -2558,10 +2558,10 @@ services:
Bearbeiten Sie docker-compose.override.yml und stellen Sie ofelia.job-exec.rspamd_dmarc_reporting.schedule: "@every 24h" auf einen gewünschten Wert, zum Beispiel auf "@midnight"
-
Führen Sie docker compose up -d aus.
+
Führen Sie docker-compose up -d aus.
-
Führen Sie docker compose restart ofelia-mailcow aus
+
Führen Sie docker-compose restart ofelia-mailcow aus
Das Ändern von IPv6-Bindings ist anders als bei IPv4. Auch dies hat einen technischen Hintergrund.
Eine docker-compose.override.yml Datei wird verwendet, anstatt die docker-compose.yml Datei direkt zu bearbeiten. Dies geschieht, um die Aktualisierbarkeit zu erhalten, da die Datei docker-compose.yml regelmäßig aktualisiert wird und Ihre Änderungen höchstwahrscheinlich überschrieben werden.
Das Logging in mailcow: dockerized besteht aus mehreren Stufen, ist aber immerhin wesentlich flexibler und einfacher in einen Logging-Daemon zu integrieren als bisher.
In Docker schreibt die containerisierte Anwendung (PID 1) ihre Ausgabe auf stdout. Für echte Ein-Anwendungs-Container funktioniert das sehr gut.
-Führen Sie docker compose logs --help aus, um mehr zu erfahren.
+Führen Sie docker-compose logs --help aus, um mehr zu erfahren.
Einige Container protokollieren oder streamen an mehrere Ziele.
Kein Container wird persistente Logs in sich behalten. Container sind flüchtige Objekte!
Am Ende wird jede Zeile der Logs den Docker-Daemon erreichen - ungefiltert.
@@ -2587,7 +2587,7 @@ erstellen Sie die Datei /etc/rsyslog.d/docker.conf:
...
}
-
Starten Sie den Docker-Daemon neu und führen Sie docker compose down && docker compose up -d aus, um die Container mit dem neuen Protokollierungstreiber neu zu erstellen.
+
Starten Sie den Docker-Daemon neu und führen Sie docker-compose down && docker-compose up -d aus, um die Container mit dem neuen Protokollierungstreiber neu zu erstellen.
Da diese Logs sehr groß werden können, ist es eine gute Idee logrotate zu nutzen, um Logs nach einer gewissen Zeit zu
komprimieren und zu löschen.
@@ -2612,7 +2612,7 @@ komprimieren und zu löschen.
Letztes Update:
- 2022-06-02 15:19:55
+ 2022-06-23 15:17:00
diff --git a/de/post_installation/firststeps-rp/index.html b/de/post_installation/firststeps-rp/index.html
index d1253d3af..376e9dabe 100644
--- a/de/post_installation/firststeps-rp/index.html
+++ b/de/post_installation/firststeps-rp/index.html
@@ -2489,7 +2489,7 @@ mailcow: dockerized vertraut auf das Standard-Gateway IP 172.22.1.1 als Proxy.
Dadurch werden auch die Bindungen innerhalb des Nginx-Containers geändert! Dies ist wichtig, wenn Sie sich entscheiden, einen Proxy innerhalb von Docker zu verwenden.
WICHTIG: Verwenden Sie nicht Port 8081, 9081 oder 65510!
-
Erzeugen Sie die betroffenen Container neu, indem Sie docker compose up -d ausführen.
+
Erzeugen Sie die betroffenen Container neu, indem Sie docker-compose up -d ausführen.
Wichtige Informationen, bitte lesen Sie diese sorgfältig durch!
Info
@@ -2640,7 +2640,7 @@ backend mailcow
Wichtig: Diese Konfiguration deckt nur das "Reverseproxing" des Webpanels (nginx-mailcow) unter Verwendung von Traefik v2 ab. Wenn Sie auch die Mail-Dienste wie dovecot, postfix... reproxen wollen, müssen Sie die folgende Konfiguration an jeden Container anpassen und einen EntryPoint in Ihrer traefik.toml oder traefik.yml (je nachdem, welche Konfiguration Sie verwenden) für jeden Port erstellen.
In diesem Abschnitt gehen wir davon aus, dass Sie Ihren Traefik 2 [certificatesresolvers] in Ihrer Traefik-Konfigurationsdatei richtig konfiguriert haben und auch acme verwenden. Das folgende Beispiel verwendet Lets Encrypt, aber Sie können es gerne auf Ihren eigenen Zertifikatsresolver ändern. Eine grundlegende Traefik 2 toml-Konfigurationsdatei mit allen oben genannten Elementen, die für dieses Beispiel verwendet werden kann, finden Sie hier traefik.toml, falls Sie eine solche Datei benötigen oder einen Hinweis, wie Sie Ihre Konfiguration anpassen können.
Zuallererst werden wir den acme-mailcow-Container deaktivieren, da wir die von traefik bereitgestellten Zertifikate verwenden werden.
-Dazu müssen wir SKIP_LETS_ENCRYPT=y in unserer mailcow.conf setzen und docker compose up -d ausführen, um die Änderungen zu übernehmen.
+Dazu müssen wir SKIP_LETS_ENCRYPT=y in unserer mailcow.conf setzen und docker-compose up -d ausführen, um die Änderungen zu übernehmen.
Dann erstellen wir eine docker-compose.override.yml Datei, um die Hauptdatei docker-compose.yml zu überschreiben, die sich im Mailcow-Stammverzeichnis befindet.
version:'2.1'
@@ -2673,7 +2673,7 @@ Dazu müssen wir SKIP_LETS_ENCRYPT=y in unserer mailcow.conf<
network_mode:nonevolumes:# mounten Sie den Ordner, der Traefiks `acme.json' Datei enthält
-# in diesem Fall wird Traefik von seinem eigenen docker compose in ../traefik gestartet
+# in diesem Fall wird Traefik von seinem eigenen docker-compose in ../traefik gestartet-../traefik/data:/traefik:ro# SSL-Ordner von mailcow einhängen-./data/assets/ssl/:/output:rw
@@ -2686,10 +2686,10 @@ Dazu müssen wir SKIP_LETS_ENCRYPT=y in unserer mailcow.conf<
web:external:true
-
Starten Sie die neuen Container mit docker compose up -d.
+
Starten Sie die neuen Container mit docker-compose up -d.
Da Traefik 2 ein acme v2 Format verwendet, um ALLE Lizenzen von allen Domains zu speichern, müssen wir einen Weg finden, die Zertifikate auszulagern. Zum Glück haben wir [diesen kleinen Container] (https://hub.docker.com/r/humenius/traefik-certs-dumper), der die Datei acme.json über ein Volume und eine Variable DOMAIN=example. org, und damit wird der Container die cert.pem und key.pem Dateien ausgeben, dafür lassen wir einfach den traefik-certs-dumper Container laufen, binden das /traefik Volume an den Ordner, in dem unsere acme.json gespeichert ist, binden das /output Volume an unseren mailcow data/assets/ssl/ Ordner, und setzen die DOMAIN=example.org Variable auf die Domain, von der wir die Zertifikate ausgeben wollen.
Dieser Container überwacht die Datei acme.json auf Änderungen und generiert die Dateien cert.pem und key.pem direkt in data/assets/ssl/, wobei der Pfad mit dem /output-Pfad des Containers verbunden ist.
Nachdem wir die Zertifikate übertragen haben, müssen wir die Konfigurationen aus unseren Postfix- und Dovecot-Containern neu laden und die Zertifikate überprüfen. Wie das geht, sehen Sie hier.
Und das sollte es gewesen sein 😊, Sie können überprüfen, ob der Traefik-Router einwandfrei funktioniert, indem Sie das Dashboard von Traefik / traefik logs / über https auf die eingestellte Domain zugreifen, oder / und HTTPS, SMTP und IMAP mit den Befehlen auf der zuvor verlinkten Seite überprüfen.
Optional: Post-Hook-Skript für nicht-mailcow ACME-Clients¶
Wenn Sie vorhaben, einen Servernamen zu verwenden, der nicht MAILCOW_HOSTNAME in Ihrem Reverse-Proxy ist, stellen Sie sicher, dass Sie diesen Namen zuerst in mailcow.conf über ADDITIONAL_SERVER_NAMES einpflegen. Die Namen müssen durch Kommas getrennt werden und dürfen keine Leerzeichen enthalten. Wenn Sie diesen Schritt überspringen, kann es sein, dass mailcow auf Ihren Reverse-Proxy mit einer falschen Seite antwortet.
Die Werte werden von netfilter-mailcow gelesen. netfilter-mailcow stellt sicher, dass die Post-Routing-Regeln auf Position 1 in der Netfilter-Tabelle stehen. Es löscht sie automatisch und legt sie neu an, wenn sie an einer anderen Position als 1 gefunden werden.
-
Überprüfen Sie die Ausgabe von docker compose logs --tail=200 netfilter-mailcow, um sicherzustellen, dass die SNAT-Einstellungen angewendet wurden.
+
Überprüfen Sie die Ausgabe von docker-compose logs --tail=200 netfilter-mailcow, um sicherzustellen, dass die SNAT-Einstellungen angewendet wurden.
Für jede hinzugefügte Domain wird versucht, autodiscover.ADDED_MAIL_DOMAIN und autoconfig.ADDED_MAIL_DOMAIN in die IPv6-Adresse oder - falls IPv6 in der Domain nicht konfiguriert ist - in die IPv4-Adresse aufzulösen. Wenn dies gelingt, wird ein Name als SAN zur Zertifikatsanforderung hinzugefügt.
Nur Namen, die validiert werden können, werden als SAN hinzugefügt.
Für jede Domain, die Sie entfernen, wird das Zertifikat verschoben und ein neues Zertifikat angefordert. Es ist nicht möglich, Domains in einem Zertifikat zu behalten, wenn wir nicht in der Lage sind, die Challenge für diese zu validieren.
-
Wenn Sie den ACME-Client neu starten wollen, verwenden Sie docker compose restart acme-mailcow und überwachen Sie die Protokolle mit docker compose logs --tail=200 -f acme-mailcow.
+
Wenn Sie den ACME-Client neu starten wollen, verwenden Sie docker-compose restart acme-mailcow und überwachen Sie die Protokolle mit docker-compose logs --tail=200 -f acme-mailcow.
Bearbeiten Sie "mailcow.conf" und fügen Sie einen Parameter ADDITIONAL_SAN wie folgt hinzu:
Verwenden Sie keine Anführungszeichen (") und keine Leerzeichen zwischen den Namen!
@@ -2605,7 +2605,7 @@
Jeder Name wird anhand seiner IPv6-Adresse oder - wenn IPv6 in Ihrer Domäne nicht konfiguriert ist - anhand seiner IPv4-Adresse überprüft.
Ein Wildcard-Name wie smtp.* wird versuchen, ein smtp.DOMAIN_NAME SAN für jede zu mailcow hinzugefügte Domain zu erhalten.
-
Führen Sie docker compose up -d aus, um betroffene Container automatisch neu zu erstellen.
+
Führen Sie docker-compose up -d aus, um betroffene Container automatisch neu zu erstellen.
Info
Die Verwendung anderer Namen als MAILCOW_HOSTNAME für den Zugriff auf das mailcow UI kann weitere Konfiguration erfordern.
@@ -2613,26 +2613,26 @@
Wenn Sie planen, einen anderen Servernamen als MAILCOW_HOSTNAME für den Zugriff auf die mailcow UI zu verwenden (z.B. durch Hinzufügen von mail.* zu ADDITIONAL_SAN), stellen Sie sicher, dass Sie diesen Namen in mailcow.conf über ADDITIONAL_SERVER_NAMES eintragen. Die Namen müssen durch Kommas getrennt sein und dürfen keine Leerzeichen enthalten. Wenn Sie diesen Schritt auslassen, kann mailcow mit einer falschen Seite antworten.
Um eine Erneuerung zu erzwingen, müssen Sie eine Datei namens force_renew erstellen und den acme-mailcow Container neu starten:
cd /opt/mailcow-dockerized
touch data/assets/ssl/force_renew
-docker compose restart acme-mailcow
+docker-compose restart acme-mailcow
# Prüfen Sie nun die Logs auf eine Erneuerung
-docker compose logs --tail=200 -f acme-mailcow
+docker-compose logs --tail=200 -f acme-mailcow
Die Datei wird automatisch gelöscht.
Validierungsfehler und wie man die Validierung überspringt¶
Sie können die IP-Überprüfung überspringen, indem Sie SKIP_IP_CHECK=y in mailcow.conf setzen (keine Anführungszeichen). Seien Sie gewarnt, dass eine Fehlkonfiguration dazu führt, dass Sie von Let's Encrypt eingeschränkt werden! Dies ist vor allem für Multi-IP-Setups nützlich, bei denen der IP-Check die falsche Quell-IP-Adresse zurückgeben würde. Aufgrund der Verwendung von dynamischen IPs für acme-mailcow ist Source-NAT bei Neustarts nicht konsistent.
-
Wenn Sie Probleme mit der "HTTP-Validierung" haben, aber Ihre IP-Adressbestätigung erfolgreich ist, verwenden Sie höchstwahrscheinlich firewalld, ufw oder eine andere Firewall, die Verbindungen von br-mailcow zu Ihrem externen Interface verbietet. Sowohl firewalld als auch ufw lassen dies standardmäßig nicht zu. Es reicht oft nicht aus, diese Firewall-Dienste einfach zu stoppen. Sie müssen mailcow stoppen (docker compose down), den Firewall-Dienst stoppen, die Ketten flushen und Docker neu starten.
+
Wenn Sie Probleme mit der "HTTP-Validierung" haben, aber Ihre IP-Adressbestätigung erfolgreich ist, verwenden Sie höchstwahrscheinlich firewalld, ufw oder eine andere Firewall, die Verbindungen von br-mailcow zu Ihrem externen Interface verbietet. Sowohl firewalld als auch ufw lassen dies standardmäßig nicht zu. Es reicht oft nicht aus, diese Firewall-Dienste einfach zu stoppen. Sie müssen mailcow stoppen (docker-compose down), den Firewall-Dienst stoppen, die Ketten flushen und Docker neu starten.
Sie können diese Validierungsmethode auch überspringen, indem Sie SKIP_HTTP_VERIFICATION=y in "mailcow.conf" setzen. Seien Sie gewarnt, dass dies nicht zu empfehlen ist. In den meisten Fällen wird die HTTP-Überprüfung übersprungen, um unbekannte NAT-Reflection-Probleme zu umgehen, die durch das Ignorieren dieser spezifischen Netzwerk-Fehlkonfiguration nicht gelöst werden. Wenn Sie Probleme haben, TLSA-Einträge in der DNS-Übersicht innerhalb von mailcow zu generieren, haben Sie höchstwahrscheinlich Probleme mit NAT-Reflexion, die Sie beheben sollten.
-
Wenn du einen SKIP_* Parameter geändert hast, führe docker compose up -d aus, um deine Änderungen zu übernehmen.
+
Wenn du einen SKIP_* Parameter geändert hast, führe docker-compose up -d aus, um deine Änderungen zu übernehmen.
Standardmäßig erstellt "acme-mailcow" ein einzelnes SAN-Zertifikat für alle validierten Domains
@@ -2645,7 +2645,7 @@ Dies bietet beste Kompatibilität, bedeutet aber, dass das Let's Encrypt-Limit
Begrenzungen: Ein Zertifikatsname ADDITIONAL_SAN=test.example.com wird als SAN zum Hauptzertifikat hinzugefügt. Ein separates Zertifikat/Schlüsselpaar wird für dieses Format nicht erzeugt.
Postfix, Dovecot und Nginx werden dann diese Zertifikate mit SNI bedienen.
-
Setzen Sie ENABLE_SSL_SNI=y in "mailcow.conf" und erstellen Sie "acme-mailcow" durch Ausführen von docker compose up -d.
+
Setzen Sie ENABLE_SSL_SNI=y in "mailcow.conf" und erstellen Sie "acme-mailcow" durch Ausführen von docker-compose up -d.
Warning
Nicht alle Clients unterstützen SNI, siehe Dovecot Dokumentation oder Wikipedia.
@@ -2675,15 +2675,15 @@ docker restart $(docker ps -qaf name=dovecot-mailcow)
Führen Sie docker compose logs acme-mailcow aus, um herauszufinden, warum eine Validierung fehlschlägt.
+
Führen Sie docker-compose logs acme-mailcow aus, um herauszufinden, warum eine Validierung fehlschlägt.
Um zu überprüfen, ob nginx das richtige Zertifikat verwendet, benutzen Sie einfach einen Browser Ihrer Wahl und überprüfen Sie das angezeigte Zertifikat.
Um das von Postfix, Dovecot und Nginx verwendete Zertifikat zu überprüfen, verwenden wir openssl:
# Verbindung über SMTP (587)
@@ -2703,7 +2703,7 @@ bash helper-scripts/expiry-dates.sh
Letztes Update:
- 2022-06-02 14:32:36
+ 2022-06-23 15:17:00
diff --git a/de/third_party/third_party-borgmatic/index.html b/de/third_party/third_party-borgmatic/index.html
index b0cc19437..81a0d50ee 100644
--- a/de/third_party/third_party-borgmatic/index.html
+++ b/de/third_party/third_party-borgmatic/index.html
@@ -2762,7 +2762,7 @@ nach der vollen Stunde auszuführen und am Ende einige nette Statistiken zu prot
oder OpenSSH wird sich weigern, den SSH-Schlüssel zu benutzen.
Das Wiederherstellen eines Backups setzt voraus, dass Sie mit einer neuen Installation von mailcow beginnen, und dass Sie derzeit keine
@@ -2783,7 +2783,7 @@ dieses Volume zu schreiben.
Bevor Sie eine Wiederherstellung durchführen, müssen Sie das vmail-Volume in docker-compose.override.yml beschreibbar machen, indem Sie das
das ro-Flag aus dem Volume entfernen.
Dann können Sie den folgenden Befehl verwenden, um das Maildir aus einem Backup wiederherzustellen:
@@ -2793,7 +2793,7 @@ Dann können Sie den folgenden Befehl verwenden, um das Maildir aus einem Backup
Die Ausführung dieses Befehls löscht und erstellt die mailcow-Datenbank neu! Führen sie diesen Befehl nicht aus, es sei denn sie beabsichtigen, die mailcow-Datenbank von einem Backup wiederherzustellen.
Um die MySQL-Datenbank aus dem letzten Archiv wiederherzustellen, verwenden Sie diesen Befehl:
@@ -2801,21 +2801,21 @@ Dann können Sie den folgenden Befehl verwenden, um das Maildir aus einem Backup
Nach der Wiederherstellung müssen Sie mailcow neu starten. Wenn Sie den SELinux-Erzwingungsmodus deaktiviert haben, wäre jetzt ein guter Zeitpunkt, um
ihn wieder zu aktivieren.
Um mailcow neu zu starten, verwenden Sie den folgenden Befehl:
-
docker compose down && docker compose up -d
+
docker-compose down && docker-compose up -d
Wenn Sie SELinux verwenden, werden dadurch auch alle Dateien in Ihrem vmail-Volume neu benannt. Seien Sie geduldig, denn dies kann
eine Weile dauern kann, wenn Sie viele Dateien haben.
Wenn borg während eines Archivierungslaufs unterbrochen wird, hinterlässt es eine veraltete Sperre, die gelöscht werden muss, bevor
neue Operationen durchgeführt werden können:
-
docker compose exec borgmatic-mailcow borg break-lock user@rsync.net:mailcow
+
docker-compose exec borgmatic-mailcow borg break-lock user@rsync.net:mailcow
Wobei user@rsync.net:mailcow die URI zu Ihrem Repository ist.
Jetzt wäre ein guter Zeitpunkt, einen manuellen Archivierungslauf durchzuführen, um sicherzustellen, dass er erfolgreich durchgeführt werden kann.
@@ -2825,7 +2825,7 @@ Schlüsseldateien werden erzeugt, wenn Sie das Repository initialisieren. Die
Beachten Sie, dass Sie in beiden Fällen auch die Passphrase haben müssen, um die Archive zu entschlüsseln.
Um die keyfile zu holen, führen Sie aus:
-
docker compose exec borgmatic-mailcow borg key export --paper user@rsync.net:mailcow
+
docker-compose exec borgmatic-mailcow borg key export --paper user@rsync.net:mailcow
Wobei user@rsync.net:mailcow die URI zu Ihrem Repository ist.
@@ -2834,7 +2834,7 @@ Repository, so dass eine manuelle Sicherung nicht so wichtig ist.
Letztes Update:
- 2022-06-02 15:19:55
+ 2022-06-23 15:17:00
diff --git a/de/third_party/third_party-gitea/index.html b/de/third_party/third_party-gitea/index.html
index 67b7f6a05..f63b5025d 100644
--- a/de/third_party/third_party-gitea/index.html
+++ b/de/third_party/third_party-gitea/index.html
@@ -2384,8 +2384,8 @@ services:
3. Öffne mailcow.conf und definiere den Port Bind, den Gitea für SSH verwenden soll. Beispiel:
GITEA_SSH_PORT=127.0.0.1:4000
-
5. Führen Sie docker compose up -d aus, um den Gitea-Container hochzufahren und führen Sie anschließend docker compose restart nginx-mailcow aus.
-
6. Wenn Sie mailcow zu https gezwungen haben, führen Sie Schritt 9 aus und starten Sie gitea mit docker compose restart gitea-mailcow neu. Fahren Sie mit Schritt 7 fort (Denken Sie daran, https anstelle von http zu verwenden, https://mx.example.org/gitea/
+
5. Führen Sie docker-compose up -d aus, um den Gitea-Container hochzufahren und führen Sie anschließend docker-compose restart nginx-mailcow aus.
+
6. Wenn Sie mailcow zu https gezwungen haben, führen Sie Schritt 9 aus und starten Sie gitea mit docker-compose restart gitea-mailcow neu. Fahren Sie mit Schritt 7 fort (Denken Sie daran, https anstelle von http zu verwenden, https://mx.example.org/gitea/
7. Öffnen Sie http://${MAILCOW_HOSTNAME}/gitea/, zum Beispiel http://mx.example.org/gitea/. Für die Datenbankdetails stellen Sie mysql als Datenbankhost ein. Verwenden Sie den in mailcow.conf gefundenen Wert von DBNAME als Datenbankname, DBUSER als Datenbankbenutzer und DBPASS als Datenbankpasswort.
8. Sobald die Installation abgeschlossen ist, loggen Sie sich als Administrator ein und setzen Sie "Einstellungen" -> "Autorisierung" -> "SMTP aktivieren". SMTP-Host sollte postfix mit Port 587 sein, setzen Sie Skip TLS Verify, da wir ein nicht gelistetes SAN verwenden ("postfix" ist höchstwahrscheinlich nicht Teil Ihres Zertifikats).
@@ -2397,14 +2397,14 @@ SSH_PORT = 4000
# Für MAILCOW_HOSTNAME=mx.example.org in mailcow.conf (und Standard-Ports für HTTPS), setzen:
ROOT_URL = https://mx.example.org/gitea/
-
10. Starten Sie gitea neu mit docker compose restart gitea-mailcow. Ihre Nutzer sollten in der Lage sein, sich mit von mailcow verwalteten Konten anzumelden.
+
10. Starten Sie gitea neu mit docker-compose restart gitea-mailcow. Ihre Nutzer sollten in der Lage sein, sich mit von mailcow verwalteten Konten anzumelden.
3. Öffne mailcow.conf und definiere die Bindung, die Gogs für SSH verwenden soll. Beispiel:
GOGS_SSH_PORT=127.0.0.1:4000
-
5. Führen Sie docker compose up -d aus, um den Gogs-Container hochzufahren und führen Sie anschließend docker compose restart nginx-mailcow aus.
+
5. Führen Sie docker-compose up -d aus, um den Gogs-Container hochzufahren und führen Sie anschließend docker-compose restart nginx-mailcow aus.
6. Öffnen Sie http://${MAILCOW_HOSTNAME}/gogs/, zum Beispiel http://mx.example.org/gogs/. Für Datenbank-Details setzen Sie mysql als Datenbank-Host. Verwenden Sie den in mailcow.conf gefundenen Wert von DBNAME als Datenbankname, DBUSER als Datenbankbenutzer und DBPASS als Datenbankpasswort.
7. Sobald die Installation abgeschlossen ist, loggen Sie sich als Administrator ein und setzen Sie "Einstellungen" -> "Autorisierung" -> "SMTP aktivieren". SMTP-Host sollte postfix mit Port 587 sein, setzen Sie Skip TLS Verify, da wir ein nicht gelistetes SAN verwenden ("postfix" ist höchstwahrscheinlich nicht Teil Ihres Zertifikats).
8. Erstellen Sie data/gogs/gogs/conf/app.ini und setzen Sie die folgenden Werte. Sie können Gogs cheat sheet für ihre Bedeutung und andere mögliche Werte konsultieren.
@@ -2396,14 +2396,14 @@ SSH_PORT = 4000
# Für MAILCOW_HOSTNAME=mx.example.org in mailcow.conf (und Standard-Ports für HTTPS), setzen:
ROOT_URL = https://mx.example.org/gogs/
-
9. Starten Sie Gogs neu mit docker compose restart gogs-mailcow. Ihre Benutzer sollten in der Lage sein, sich mit von mailcow verwalteten Konten einzuloggen.
+
9. Starten Sie Gogs neu mit docker-compose restart gogs-mailcow. Ihre Benutzer sollten in der Lage sein, sich mit von mailcow verwalteten Konten einzuloggen.
Dies ist auch Schritt 4 in der offiziellen mailcow-Installation (nano mailcow.conf). Passen Sie also Ihre Bedürfnisse an und ändern Sie die folgenden Variablen:
HTTP_PORT=18080 # verwenden Sie nicht 8080, da mailman es braucht
@@ -2913,7 +2913,7 @@ cd docker-mailman
Erstellen Sie einen langen Schlüssel für Hyperkitty, z.B. mit dem Linux-Befehl cat /dev/urandom | tr -dc a-zA-Z0-9 | head -c30; echo. Speichern Sie diesen Schlüssel vorerst als HYPERKITTY_KEY.
Erstellen Sie ein langes Passwort für die Datenbank, z. B. mit dem Linux-Befehl cat /dev/urandom | tr -dc a-zA-Z0-9 | head -c30; echo. Speichern Sie dieses Passwort zunächst als DBPASS.
Erstellen Sie einen langen Schlüssel für Django, z. B. mit dem Linux-Befehl cat /dev/urandom | tr -dc a-zA-Z0-9 | head -c30; echo. Speichern Sie diesen Schlüssel für einen Moment als DJANGO_KEY.
-
Erstellen Sie die Datei /opt/docker-mailman/docker compose.override.yaml und ersetzen Sie HYPERKITTY_KEY, DBPASS und DJANGO_KEY durch die generierten Werte:
+
Erstellen Sie die Datei /opt/docker-mailman/docker-compose.override.yaml und ersetzen Sie HYPERKITTY_KEY, DBPASS und DJANGO_KEY durch die generierten Werte:
version: '2'
services:
@@ -2972,11 +2972,11 @@ a2ensite mailman.conf
systemctl restart apache2
cd /opt/docker-mailman
-docker compose pull
-docker compose up -d
+docker-compose pull
+docker-compose up -d
cd /opt/mailcow-dockerized/
-docker compose pull
+docker-compose pull
./renew-ssl.sh
Warten Sie ein paar Minuten! Die Container müssen ihre Datenbanken und Konfigurationsdateien erstellen. Dies kann bis zu 1 Minute und mehr dauern.
@@ -2984,7 +2984,7 @@ docker compose pull
Neue Listen werden von Postfix nicht sofort erkannt¶
Wenn man eine neue Liste anlegt und versucht, sofort eine E-Mail zu versenden, antwortet postfix mit Benutzer existiert nicht, weil postfix die Liste noch nicht an Mailman übergeben hat. Die Konfiguration unter /opt/mailman/core/var/data/postfix_lmtp wird nicht sofort aktualisiert. Wenn Sie die Liste sofort benötigen, starten Sie postifx manuell neu:
cd /opt/mailcow-dockerized
-docker compose restart postfix-mailcow
+docker-compose restart postfix-mailcow
Nextcloud kann mit dem helper script, das in mailcow enthalten ist, eingerichtet (Parameter -i) und entfernt (Parameter -p) werden. Um Nextcloud zu installieren, navigieren Sie einfach zu Ihrem mailcow-dockerized Root-Ordner und führen Sie das Helper-Skript wie folgt aus:
./helper-scripts/nextcloud.sh -i
Für den Fall, dass Sie das Passwort (z.B. für admin) vergessen haben und kein neues anfordern können [über den Passwort-Reset-Link auf dem Login-Bildschirm] (https://docs.nextcloud.com/server/20/admin_manual/configuration_user/reset_admin_password.html?highlight=reset), können Sie durch den Aufruf des Helper-Skripts mit -r als Parameter ein neues Passwort setzen. Verwenden Sie diese Option nur, wenn Ihre Nextcloud nicht so konfiguriert ist, dass Sie mailcow zur Authentifizierung verwendet, wie im nächsten Abschnitt beschrieben.
-
Damit mailcow ein Zertifikat für die Nextcloud Domain generieren kann, muss die Domain unter welcher die Nextcloud später erreichbar sein soll als ADDITIONAL_SAN in die mailcow.conf hinzufügt werden und docker compose up -d zur Übernahme ausgeführt werden. Für weitere Informationen siehe: Erweitertes SSL.
+
Damit mailcow ein Zertifikat für die Nextcloud Domain generieren kann, muss die Domain unter welcher die Nextcloud später erreichbar sein soll als ADDITIONAL_SAN in die mailcow.conf hinzufügt werden und docker-compose up -d zur Übernahme ausgeführt werden. Für weitere Informationen siehe: Erweitertes SSL.
Zur Verwendung der empfohlenen Einstellung (Cron) zur Verarbeitung der Hintergrund-Aufgaben müssen in der docker-compose.override.yml folgende Zeilen
hinzugefügt werden:
Nachdem diese Zeilen hinzugefügt wurden muss docker compose up -d ausgeführt werden, um das Docker Image mit den entsprechenden Labels zu versehen. Danach muss
- zudem der docker scheduler neu gestartet werden, um den neuen Job zu registrieren. Dazu wird docker compose restart ofelia-mailcow ausgeführt. Zur
- Überprüfung, ob die ofelia Konfiguration korrekt ist geladen wurde, kann mittels docker compose logs ofelia-mailcow nach einer Zeile mit dem Inhalt
+
Nachdem diese Zeilen hinzugefügt wurden muss docker-compose up -d ausgeführt werden, um das Docker Image mit den entsprechenden Labels zu versehen. Danach muss
+ zudem der docker scheduler neu gestartet werden, um den neuen Job zu registrieren. Dazu wird docker-compose restart ofelia-mailcow ausgeführt. Zur
+ Überprüfung, ob die ofelia Konfiguration korrekt ist geladen wurde, kann mittels docker-compose logs ofelia-mailcow nach einer Zeile mit dem Inhalt
New job registered "nextcloud-cron" - ... gesucht werden.
Hierdurch wird alle 5 Minuten die Hintergrundverarbeitung gestartet. Da die Ausführung selbst keine Ausgabe liefert, kann die korrekte Funktionsweise in den
Grundeinstellungen von Nextcloud überprüft werden. Hier wird automatisch mit der ersten Ausführung die Hintergrund-Aufgaben Verarbeitung auf (X) Cron gesetzt
@@ -2532,13 +2532,13 @@ services:
Wenn Sie bisher Nextcloud mit mailcow-Authentifizierung über user_external/IMAP verwendet haben, müssen Sie einige zusätzliche Schritte durchführen, um Ihre bestehenden Benutzerkonten mit OAuth2 zu verknüpfen.
1. Klicken Sie auf die Schaltfläche in der oberen rechten Ecke und wählen Sie Apps. Scrollen Sie nach unten zur App Externe Benutzerauthentifizierung und klicken Sie daneben auf Entfernen.
-2. Führen Sie die folgenden Abfragen in Ihrer Nextcloud-Datenbank aus (wenn Sie Nextcloud mit dem Skript von mailcow einrichten, können Sie source mailcow.conf && docker compose exec mysql-mailcow mysql -u$DBUSER -p$DBPASS $DBNAME ausführen):
+2. Führen Sie die folgenden Abfragen in Ihrer Nextcloud-Datenbank aus (wenn Sie Nextcloud mit dem Skript von mailcow einrichten, können Sie source mailcow.conf && docker-compose exec mysql-mailcow mysql -u$DBUSER -p$DBPASS $DBNAME ausführen):
INSERT INTO nc_users (uid, uid_lower) SELECT DISTINCT uid, LOWER(uid) FROM nc_users_external;
INSERT INTO nc_sociallogin_connect (uid, identifier) SELECT DISTINCT uid, CONCAT("Mailcow-", uid) FROM nc_users_external;
Wenn Sie Nextcloud bisher ohne mailcow-Authentifizierung, aber mit den gleichen Benutzernamen wie mailcow genutzt haben, können Sie Ihre bestehenden Benutzerkonten auch mit OAuth2 verknüpfen.
-
1. Führen Sie die folgenden Abfragen in Ihrer Nextcloud-Datenbank aus (wenn Sie Nextcloud mit dem Skript von mailcow einrichten, können Sie source mailcow.conf && docker compose exec mysql-mailcow mysql -u$DBUSER -p$DBPASS $DBNAME ausführen):
+
1. Führen Sie die folgenden Abfragen in Ihrer Nextcloud-Datenbank aus (wenn Sie Nextcloud mit dem Skript von mailcow einrichten, können Sie source mailcow.conf && docker-compose exec mysql-mailcow mysql -u$DBUSER -p$DBPASS $DBNAME ausführen):
INSERT INTO nc_sociallogin_connect (uid, identifier) SELECT DISTINCT uid, CONCAT("Mailcow-", uid) FROM nc_users;
@@ -2558,14 +2558,14 @@ Es wird angezeigt, welche Befehle ausgeführt werden müssen, diese müssen im p
),
Nachdem die Änderungen vorgenommen wurden, muss der nginx-Container neu gestartet werden.
-docker compose restart nginx-mailcow
docker compose up -d && docker compose restart nginx-mailcow
+
docker-compose up -d && docker-compose restart nginx-mailcow
Nun können Sie einfach zu https://${MAILCOW_HOSTNAME}/portainer/ navigieren, um Ihre Portainer-Container-Überwachungsseite anzuzeigen. Sie werden dann aufgefordert, ein neues Passwort für den admin Account anzugeben. Nachdem Sie Ihr Passwort eingegeben haben, können Sie sich mit der Portainer UI verbinden.
@@ -2677,7 +2677,7 @@ docker compose up -d
Letztes Update:
- 2022-06-02 15:19:55
+ 2022-06-23 15:17:00
diff --git a/de/troubleshooting/debug-admin_login_sogo/index.html b/de/troubleshooting/debug-admin_login_sogo/index.html
index fd5bf77b6..ef6a5277f 100644
--- a/de/troubleshooting/debug-admin_login_sogo/index.html
+++ b/de/troubleshooting/debug-admin_login_sogo/index.html
@@ -2445,7 +2445,7 @@ Dazu wird ein zusätzlicher Link zu SOGo in der Mailbox-Liste (mailcow UI) angez
@@ -2479,7 +2479,7 @@ In den meisten Fällen sollte dies nicht spürbar sein, aber Sie sollten es im H
Letztes Update:
- 2022-06-02 14:32:36
+ 2022-06-23 15:17:00
diff --git a/de/troubleshooting/debug-attach_service/index.html b/de/troubleshooting/debug-attach_service/index.html
index 349a0805c..70795d258 100644
--- a/de/troubleshooting/debug-attach_service/index.html
+++ b/de/troubleshooting/debug-attach_service/index.html
@@ -2491,16 +2491,16 @@
Wenn Sie sich direkt mit einem Dienst / einer Anwendung verbinden wollen, ist es immer eine gute Idee, source mailcow.conf zu benutzen, um alle relevanten Variablen in Ihre Umgebung zu bekommen.
AttributeError: 'NoneType' Objekt hat kein Attribut 'keys'.
ERROR: In der Datei './docker-compose.yml' hat der Dienst 'version' keine Konfigurationsoptionen.
-
Wenn Sie eine oder ähnliche Meldungen erhalten, während Sie versuchen, mailcow: dockerized auszuführen, überprüfen Sie bitte, ob Sie die aktuellste Version von Docker und docker compose haben.
+
Wenn Sie eine oder ähnliche Meldungen erhalten, während Sie versuchen, mailcow: dockerized auszuführen, überprüfen Sie bitte, ob Sie die aktuellste Version von Docker und docker-compose haben.
Dieser Fehler versucht Ihnen mitzuteilen, dass eine der (Gesundheits-)Bedingungen für einen bestimmten Container nicht erfüllt ist. Daher kann er nicht gestartet werden. Dies kann verschiedene Gründe haben, der häufigste ist ein aktualisierter Git-Klon, aber ein altes Docker-Image oder umgekehrt.
Auch eine falsch konfigurierte Firewall kann einen solchen Fehler verursachen. Die Container müssen in der Lage sein, über das Netzwerk 172.22.1.1/24 miteinander zu kommunizieren.
Dieser Abschnitt gilt nur für Docker's Standard-Logging-Treiber (JSON).
-
Um die Logs aller mailcow: dockerized bezogenen Container zu sehen, können Sie docker compose logs innerhalb Ihres mailcow-dockerized Ordners verwenden, der Ihre mailcow.conf enthält. Dies ist normalerweise ein bisschen viel, aber Sie können die Ausgabe mit --tail=100 auf die letzten 100 Zeilen pro Container kürzen, oder ein -f hinzufügen, um die Live-Ausgabe aller Ihrer Dienste zu verfolgen.
-
Um die Logs eines bestimmten Dienstes zu sehen, kann man docker compose logs [options] $service_name verwenden
+
Um die Logs aller mailcow: dockerized bezogenen Container zu sehen, können Sie docker-compose logs innerhalb Ihres mailcow-dockerized Ordners verwenden, der Ihre mailcow.conf enthält. Dies ist normalerweise ein bisschen viel, aber Sie können die Ausgabe mit --tail=100 auf die letzten 100 Zeilen pro Container kürzen, oder ein -f hinzufügen, um die Live-Ausgabe aller Ihrer Dienste zu verfolgen.
+
Um die Logs eines bestimmten Dienstes zu sehen, kann man docker-compose logs [options] $service_name verwenden
Info
-
Die verfügbaren Optionen für den Befehl docker compose logs sind:
+
Die verfügbaren Optionen für den Befehl docker-compose logs sind:
Wenn Ihr Server abgestürzt ist und MariaDB eine Fehlermeldung ähnlich [ERROR] mysqld: Aria recovery failed. Please run aria_chk -r on all Aria tables (*.MAI) and delete all aria_log.######## files, können Sie Folgendes versuchen, um die Datenbank in einen gesunden Zustand zu bringen:
-
Starten Sie den Stack und warten Sie, bis mysql-mailcow beginnt, einen Neustart zu melden. Überprüfen Sie dies, indem Sie docker compose ps ausführen.
+
Starten Sie den Stack und warten Sie, bis mysql-mailcow beginnt, einen Neustart zu melden. Überprüfen Sie dies, indem Sie docker-compose ps ausführen.
Führen Sie nun die folgenden Befehle aus:
# Stoppe den Stack, führe nicht "down" aus
-docker compose stop
+docker-compose stop
# Führen Sie eine Bash in dem gestoppten Container als Benutzer mysql aus
-docker compose run --rm --entrypoint '/bin/sh -c "gosu mysql bash"' mysql-mailcow
+docker-compose run --rm --entrypoint '/bin/sh -c "gosu mysql bash"' mysql-mailcow
# cd in das SQL-Datenverzeichnis
cd /var/lib/mysql
# aria_chk ausführen
@@ -2424,14 +2424,14 @@ aria_chk --check --force */*.MAI
# Löschen der aria-Logdateien
rm aria_log.*
-
Führen Sie nun docker compose down gefolgt von docker compose up -d aus.
+
Führen Sie nun docker-compose down gefolgt von docker-compose up -d aus.
Dies funktioniert ähnlich wie das Zurücksetzen eines MySQL-Passworts, jetzt machen wir es vom Host aus, ohne uns mit dem MySQL CLI zu verbinden:
Quelle mailcow.conf
-docker compose exec mysql-mailcow mysql -u${DBUSER} -p${DBPASS} ${DBNAME} -e "DELETE FROM tfa WHERE username='YOUR_USERNAME';"
+docker-compose exec mysql-mailcow mysql -u${DBUSER} -p${DBPASS} ${DBNAME} -e "DELETE FROM tfa WHERE username='YOUR_USERNAME';"
Sollten Sie Probleme mit Ihrem Zertifikat, Schlüssel oder Let's Encrypt-Konto haben, versuchen Sie bitte, die TLS-Assets zurückzusetzen:
source mailcow.conf
-docker compose down
+docker-compose down
rm -rf data/assets/ssl
mkdir data/assets/ssl
openssl req -x509 -newkey rsa:4096 -keyout data/assets/ssl-example/key.pem -out data/assets/ssl-example/cert.pem -days 365 -subj "/C=DE/ST=NRW/L=Willich/O=mailcow/OU=mailcow/CN=${MAILCOW_HOSTNAME}" -sha256 -nodes
cp -n -d data/assets/ssl-example/*.pem data/assets/ssl/
-docker compose up -d
+docker-compose up -d
Dies wird mailcow stoppen, die benötigten Variablen beschaffen, ein selbstsigniertes Zertifikat erstellen und mailcow starten.
Wenn Sie Let's Encrypt verwenden, sollten Sie vorsichtig sein, da Sie ein neues Konto und einen neuen Satz von Zertifikaten erstellen werden. Sie werden früher oder später auf ein Ratelimit stoßen.
Entfernen Sie das Volume rspamd-vol-1, um alle Rspamd-Daten zu entfernen.
Entfernen Sie Volume crypt-vol-1, um alle Crypto-Daten zu entfernen. Dies wird alle Mails unlesbar machen.
-
Alternativ dazu wird die Ausführung von docker compose down -valle mailcow: dockerized volumes zerstören und alle zugehörigen Container und Netzwerke löschen.
+
Alternativ dazu wird die Ausführung von docker-compose down -valle mailcow: dockerized volumes zerstören und alle zugehörigen Container und Netzwerke löschen.
Eine kurze Anleitung, um einen schlecht funktionierenden Rspamd tiefgehend zu analysieren.
-
docker compose exec rspamd-mailcow bash
+
docker-compose exec rspamd-mailcow bash
if ! grep -qi 'apt-stable-asan' /etc/apt/sources.list.d/rspamd.list; then
sed -i 's/apt-stabil/apt-stabil-asan/i' /etc/apt/sources.list.d/rspamd.list
@@ -2376,17 +2376,17 @@ nano /docker-entrypoint.sh
export G_SLICE=always-malloc
export ASAN_OPTIONS=new_delete_type_mismatch=0:detect_leaks=1:detect_odr_violation=0:log_path=/tmp/rspamd-asan:quarantine_size_mb=2048:malloc_context_size=8:fast_unwind_on_malloc=0
-
Starten Sie Rspamd neu: docker compose restart rspamd-mailcow
+
Starten Sie Rspamd neu: docker-compose restart rspamd-mailcow
Ihr Speicherverbrauch wird stark ansteigen, er wird auch stetig wachsen, was nicht mit einem möglichen Memory Leak zusammenhängt, nach dem Sie suchen.
-
Lassen Sie den Container für ein paar Minuten, Stunden oder Tage laufen (es sollte die Zeit sein, die Sie normalerweise warten, bis der Memory Leak "passiert") und starten Sie ihn neu: docker compose restart rspamd-mailcow.
-
Betreten Sie nun den Container, indem Sie docker compose exec rspamd-mailcow bash ausführen, wechseln Sie das Verzeichnis zu /tmp und kopieren Sie die asan-Dateien an den gewünschten Ort oder laden Sie sie über termbin.com hoch (cat /tmp/rspamd-asan.* | nc termbin.com 9999).
+
Lassen Sie den Container für ein paar Minuten, Stunden oder Tage laufen (es sollte die Zeit sein, die Sie normalerweise warten, bis der Memory Leak "passiert") und starten Sie ihn neu: docker-compose restart rspamd-mailcow.
+
Betreten Sie nun den Container, indem Sie docker-compose exec rspamd-mailcow bash ausführen, wechseln Sie das Verzeichnis zu /tmp und kopieren Sie die asan-Dateien an den gewünschten Ort oder laden Sie sie über termbin.com hoch (cat /tmp/rspamd-asan.* | nc termbin.com 9999).
In case of an accidental deletion of a mailbox, you will be able to recover for (by default) 5 days. This depends on the MAILDIR_GC_TIME parameter in mailcow.conf.
A deleted mailbox is copied in its encrypted form to /var/lib/docker/volumes/mailcowdockerized_vmail-vol-1/_data/_garbage.
@@ -2443,8 +2443,8 @@
To restore make sure you are actually restoring to the same mailcow it was deleted from or you use the same encryption keys in crypt-vol-1.
Make sure the user you want to restore exists in your mailcow. Re-create them if they are missing.
Copy the folders from /var/lib/docker/volumes/mailcowdockerized_vmail-vol-1/_data/_garbage/[timestamp]_[domain_sanitized][user_sanitized] back to /var/lib/docker/volumes/mailcowdockerized_vmail-vol-1/_data/[domain]/[user] and resync the folder and recalc the quota:
On the destination (in this case /external_share/backups) you may want to have snapshot capabilities (ZFS, Btrfs etc.). Snapshot daily and keep for n days for a consistent backup.
Do not rsync to a Samba share, you need to keep the correct permissions!
-
To restore you'd simply need to run rsync the other way round and restart Docker to re-read the volumes. Run docker compose pull and docker compose up -d.
+
To restore you'd simply need to run rsync the other way round and restart Docker to re-read the volumes. Run docker-compose pull and docker-compose up -d.
If you are lucky Redis and MariaDB can automatically fix the inconsistent databases (if they are inconsistent).
In case of a corrupted database you'd need to use the helper script to restore the inconsistent elements. If a restore fails, try to extract the backups and copy the files back manually. Keep the file permissions!
@@ -2539,7 +2539,7 @@ In case of a corrupted database you'd need to use the helper script to restore t
Last update:
- 2022-06-02 14:32:36
+ 2022-06-23 15:17:00
diff --git a/en/backup_restore/b_n_r-backup_restore-maildir/index.html b/en/backup_restore/b_n_r-backup_restore-maildir/index.html
index 3b2ef22a4..2574bb841 100644
--- a/en/backup_restore/b_n_r-backup_restore-maildir/index.html
+++ b/en/backup_restore/b_n_r-backup_restore-maildir/index.html
@@ -2428,13 +2428,13 @@
This line backups the vmail directory to a file backup_vmail.tar.gz in the mailcow root directory:
cd /path/to/mailcow-dockerized
-docker run --rm -i -v $(docker inspect --format '{{ range .Mounts }}{{ if eq .Destination "/var/vmail" }}{{ .Name }}{{ end }}{{ end }}' $(docker compose ps -q dovecot-mailcow)):/vmail -v ${PWD}:/backup debian:stretch-slim tar cvfz /backup/backup_vmail.tar.gz /vmail
+docker run --rm -i -v $(docker inspect --format '{{ range .Mounts }}{{ if eq .Destination "/var/vmail" }}{{ .Name }}{{ end }}{{ end }}' $(docker-compose ps -q dovecot-mailcow)):/vmail -v ${PWD}:/backup debian:stretch-slim tar cvfz /backup/backup_vmail.tar.gz /vmail
You can change the path by adjusting ${PWD} (which equals to the current directory) to any path you have write-access to.
Set the filename backup_vmail.tar.gz to any custom name, but leave the path as it is. Example: [...] tar cvfz /backup/my_own_filename_.tar.gz
To find the pathes of your source volumes we use docker inspect and read the destination directory of every volume related to your mailcow compose project. This means we will also transfer volumes you may have added in a override file. Local bind mounts may or may not work.
The use rsync with the --delete flag. The destination will be an exact copy of the source.
mariabackup is used to create a consistent copy of the SQL data directory.
-
After rsync'ing the data we will run docker compose pull and remove old image tags from the destination.
+
After rsync'ing the data we will run docker-compose pull and remove old image tags from the destination.
Your source will not be changed at any time.
You may want to make sure to use the same /etc/docker/daemon.json on the remote target.
You should not run disk snapshots (e.g. via ZFS, LVM etc.) on the target at the very same time as this script is run.
@@ -2513,7 +2513,7 @@ The destination must have Docker and docker compose v1 availabl
Last update:
- 2022-06-02 14:32:36
+ 2022-06-23 15:17:00
diff --git a/en/i_u_m/i_u_m_deinstall/index.html b/en/i_u_m/i_u_m_deinstall/index.html
index f6861ef14..ad3d58e23 100644
--- a/en/i_u_m/i_u_m_deinstall/index.html
+++ b/en/i_u_m/i_u_m_deinstall/index.html
@@ -2361,7 +2361,7 @@
Deinstallation
To remove mailcow: dockerized with all it's volumes, images and containers do:
-
docker compose down -v --rmi all --remove-orphans
+
docker-compose down -v --rmi all --remove-orphans
Info
@@ -2369,7 +2369,7 @@
-v Remove named volumes declared in the volumes section of the Compose file and anonymous volumes attached to containers.
--rmi Remove images. Type must be one of: all: Remove all images used by any service. local: Remove only images that don't have a custom tag set by the image field.
--remove-orphans Remove containers for services not defined in the compose file.
-
By default docker compose down only removes currently active containers and networks defined in the docker-compose.yml.
+
By default docker-compose down only removes currently active containers and networks defined in the docker-compose.yml.
curl -sSL https://get.docker.com/ | CHANNEL=stable sh
# After the installation process is finished, you may need to enable the service and make sure it is started (e.g. CentOS 7)
systemctl enable --now docker
-
+
+
+
+
Docker-Compose
+
-
Please use the latest available Docker engine and not the engine that ships with your distro repository.
-
On SELinux-enabled systems, e.g. CentOS 7:
+
+
Danger
+
mailcow requires the latest version of docker-compose v2. It is highly recommended to use the commands below to install docker-compose. Package managers (e.g. apt, yum) likely won't give you the correct version.
+Note: This command downloads docker-compose from the official Docker Github repository and is a safe method. The snippet will determine the latest supported version by mailcow. In almost all cases this is the latest version available (exceptions are broken releases or major changes not yet supported by mailcow).
Restart the docker daemon and verify SELinux is now enabled.
This step is required to make sure mailcows volumes are properly labeled as declared in the compose file.
If you are interested in how this works, you can check out the readme of https://github.com/containers/container-selinux which links to a lot of useful information on that topic.
As of June 2022, Docker Compose v1 has been replaced in mailcow by Docker Compose v2.
-Docker Compose v1 will lose official support from Docker in October 2022.
-mailcow supports Docker Compose v1 until December 2022, after which installation is imperative should you wish to continue running mailcow.
-
-
-
Compatibility
-
The web interface will only be accessible via v4 by default in the period from June - December 2022.
-The reason for this is the dual compatibility between Compose v1 and v2.
-Should you wish to access the web interface, as before by default via v6, please take a look at this chapter.
-The 2022-12 update will restore the native IPv6 reachability from the UI.
-
-
If you are freshly installing mailcow and have installed Docker in the above way, Docker Compose v2 will already be installed with it. So you don't need to do anything else.
-
You can check this with docker compose version, if the return looks something like Docker Compose version v2.5.0, then the new Docker Compose is already installed on your system.
-
If it is not installed or you want to upgrade from Docker Compose v1 to v2 just follow the instructions:
If you are already running the mailcow stack with docker-compose v1, make sure you have shut down the mailcow stack and installed the latest update before upgrading to Compose v2.
-
To uninstall Docker Compose v1 enter the following command:
Docker Compose v2 comes with the repository (assuming you followed the instructions at point installing Docker).
-
Then the installation is quite simple:
-
apt install docker-compose-plugin -y
-
-
Now type docker compose version again and check the return. Is it similar to: Docker Compose version v2.5.0? Then everything has been installed correctly!
-
-
Warning
-
If you are using an operating system other than Debian/Ubuntu, please take a look at the official installation manual of Docker itself to learn how to install Docker Compose v2 on other Linux systems.
1. Clone the master branch of the repository, make sure your umask equals 0022. Please clone the repository as root user and also control the stack as root. We will modify attributes - if necessary - while bootstrapping the containers automatically and make sure everything is secured. The update.sh script must therefore also be run as root. It might be necessary to change ownership and other attributes of files you will otherwise not have access to. We drop permissions for every exposed application and will not run an exposed service as root! Controlling the Docker daemon as non-root user does not give you additional security. The unprivileged user will spawn the containers as root likewise. The behaviour of the stack is identical.
+
2. Clone the master branch of the repository, make sure your umask equals 0022. Please clone the repository as root user and also control the stack as root. We will modify attributes - if necessary - while bootstrapping the containers automatically and make sure everything is secured. The update.sh script must therefore also be run as root. It might be necessary to change ownership and other attributes of files you will otherwise not have access to. We drop permissions for every exposed application and will not run an exposed service as root! Controlling the Docker daemon as non-root user does not give you additional security. The unprivileged user will spawn the containers as root likewise. The behaviour of the stack is identical.
$ su
# umask
0022 # <- Verify it is 0022
@@ -2550,16 +2412,16 @@ Should you wish to access the web interface, as before by default via v6, please
# git clone https://github.com/mailcow/mailcow-dockerized
# cd mailcow-dockerized
-
2. Generate a configuration file. Use a FQDN (host.domain.tld) as hostname when asked.
+
3. Generate a configuration file. Use a FQDN (host.domain.tld) as hostname when asked.
./generate_config.sh
-
3. Change configuration if you want or need to.
+
4. Change configuration if you want or need to.
nano mailcow.conf
If you plan to use a reverse proxy, you can, for example, bind HTTPS to 127.0.0.1 on port 8443 and HTTP to 127.0.0.1 on port 8080.
You may need to stop an existing pre-installed MTA which blocks port 25/tcp. See this chapter to learn how to reconfigure Postfix to run besides mailcow after a successful installation.
Some updates modify mailcow.conf and add new parameters. It is hard to keep track of them in the documentation. Please check their description and, if unsure, ask at the known channels for advise.
-
3.1. Users with a MTU not equal to 1500 (e.g. OpenStack):
+
4.1. Users with a MTU not equal to 1500 (e.g. OpenStack):
Whenever you run into trouble and strange phenomena, please check your MTU.
Edit docker-compose.yml and change the network settings according to your MTU.
Add the new driver_opts parameter like this:
@@ -2570,12 +2432,12 @@ Add the new driver_opts parameter like this:
com.docker.network.driver.mtu: 1450
...
-
3.2. Users without an IPv6 enabled network on their host system:
+
4.2. Users without an IPv6 enabled network on their host system:
Enable IPv6. Finally.
If you do not have an IPv6 enabled network on your host and you don't care for a better internet (thehe), it is recommended to disable IPv6 for the mailcow network to prevent unforeseen issues.
-
4. Pull the images and run the compose file. The parameter -d will start mailcow: dockerized detached:
-
docker compose pull
-docker compose up -d
+
5. Pull the images and run the compose file. The parameter -d will start mailcow: dockerized detached:
+
docker-compose pull
+docker-compose up -d
Done!
You can now access https://${MAILCOW_HOSTNAME} with the default credentials admin + password moohoo.
The database will be initialized right after a connection to MySQL can be established.
-
Your data will persist in multiple Docker volumes, that are not deleted when you recreate or delete containers. Run docker volume ls to see a list of all volumes. You can safely run docker compose down without removing persistent data.
+
Your data will persist in multiple Docker volumes, that are not deleted when you recreate or delete containers. Run docker volume ls to see a list of all volumes. You can safely run docker-compose down without removing persistent data.
Alternatively, you can use the ./helper-scripts/backup_and_restore.sh script to create a full backup on the source machine, then install mailcow on the target machine as usual, copy over your mailcow.conf and use the same script to restore your backup to the target machine.
See the topic above, instead of a diff, you run checkout:
-
docker compose down
+
docker-compose down
# Replace commit ID 22cd00b5e28893ef9ddef3c2b5436453cc5223ab by your ID
git checkout 22cd00b5e28893ef9ddef3c2b5436453cc5223ab
-docker compose pull
-docker compose up -d
+docker-compose pull
+docker-compose up -d
You can hook into the update mechanism by adding scripts called pre_commit_hook.sh and post_commit_hook.sh to your mailcows root directory. See this for more details.
You may find that legitimate (clean) mail is being blocked by ClamAV (Rspamd will flag the mail with VIRUS_FOUND). For instance, interactive PDF form attachments are blocked by default because the embedded Javascript code may be used for nefarious purposes. Confirm by looking at the clamd logs, e.g.:
docker-compose exec dovecot-mailcow doveadm expunge -A mailbox 'Junk' savedbefore 7d
Delete all mails (of all users) in all folders that are older than 52 weeks (internal date of the mail, not the date it was saved on the system => before instead of savedbefore). Useful for deleting very old mails on all users and folders (thus especially useful for GDPR-compliance).
-
docker compose exec dovecot-mailcow doveadm expunge -A mailbox % before 52w
+
docker-compose exec dovecot-mailcow doveadm expunge -A mailbox % before 52w
Delete mails inside a custom folder inside a user's inbox that are not flagged and older than 2 weeks
-
docker compose exec dovecot-mailcow doveadm expunge -u 'mailbox@example.com' mailbox 'INBOX/custom-folder' not FLAGGED not SINCE 2w
+
docker-compose exec dovecot-mailcow doveadm expunge -u 'mailbox@example.com' mailbox 'INBOX/custom-folder' not FLAGGED not SINCE 2w
Info
@@ -2491,8 +2491,8 @@
# Path to mailcow-dockerized, e.g. /opt/mailcow-dockerized
cd /path/to/your/mailcow-dockerized
-/usr/local/bin/docker compose exec -T dovecot-mailcow doveadm expunge -A mailbox 'Junk' savedbefore 2w
-/usr/local/bin/docker compose exec -T dovecot-mailcow doveadm expunge -A mailbox 'Junk' SEEN not SINCE 12h
+/usr/local/bin/docker-compose exec -T dovecot-mailcow doveadm expunge -A mailbox 'Junk' savedbefore 2w
+/usr/local/bin/docker-compose exec -T dovecot-mailcow doveadm expunge -A mailbox 'Junk' SEEN not SINCE 12h
[...]
To create a cron job you may execute crontab -e and insert something like the following to execute a script:
Since we run in Docker and create our containers with the "restart: always" flag, a oom situation will at least only trigger a restart of the container.
# single user
-docker compose exec dovecot-mailcow doveadm fts rescan -u user@domain
+docker-compose exec dovecot-mailcow doveadm fts rescan -u user@domain
# all users
-docker compose exec dovecot-mailcow doveadm fts rescan -A
+docker-compose exec dovecot-mailcow doveadm fts rescan -A
Dovecot Wiki: "Scan what mails exist in the full text search index and compare those to what actually exist in mailboxes. This removes mails from the index that have already been expunged and makes sure that the next doveadm index will index all the missing mails (if any)."
This does not re-index a mailbox. It basically repairs a given index.
If you want to re-index data immediately, you can run the followig command, where '*' can also be a mailbox mask like 'Sent'. You do not need to run these commands, but it will speed things up a bit:
# single user
-docker compose exec dovecot-mailcow doveadm index -u user@domain '*'
+docker-compose exec dovecot-mailcow doveadm index -u user@domain '*'
# all users, but obviously slower and more dangerous
-docker compose exec dovecot-mailcow doveadm index -A '*'
+docker-compose exec dovecot-mailcow doveadm index -A '*'
This will take some time depending on your machine and Solr can run oom, monitor it!
Because re-indexing is very sensible, we did not include it to mailcow UI. You will need to take care of any errors while re-indexing a mailbox.
@@ -2481,7 +2481,7 @@ docker compose exec dovecot-mailcow doveadm index -A '*'
Last update:
- 2022-06-02 14:32:36
+ 2022-06-23 15:17:00
diff --git a/en/manual-guides/Dovecot/u_e-dovecot-idle_interval/index.html b/en/manual-guides/Dovecot/u_e-dovecot-idle_interval/index.html
index c2dca40f3..55fe4802c 100644
--- a/en/manual-guides/Dovecot/u_e-dovecot-idle_interval/index.html
+++ b/en/manual-guides/Dovecot/u_e-dovecot-idle_interval/index.html
@@ -2486,12 +2486,12 @@ Insert the setting followed by the new value. For example, to set the interval t
docker compose exec dovecot-mailcow dovecot -a | grep "imap_idle_notify_interval"
+
docker-compose exec dovecot-mailcow dovecot -a | grep "imap_idle_notify_interval"
If you didn't change it, it should be at 2m. If you did change it, you should see your new value.
@@ -2501,7 +2501,7 @@ If you didn't change it, it should be at 2m. If you did change it, you should se
Last update:
- 2022-06-02 14:32:36
+ 2022-06-23 15:17:00
diff --git a/en/manual-guides/Dovecot/u_e-dovecot-mail-crypt/index.html b/en/manual-guides/Dovecot/u_e-dovecot-mail-crypt/index.html
index 0d2e86707..6048ae4d4 100644
--- a/en/manual-guides/Dovecot/u_e-dovecot-mail-crypt/index.html
+++ b/en/manual-guides/Dovecot/u_e-dovecot-mail-crypt/index.html
@@ -2364,7 +2364,7 @@
Mails are stored compressed (lz4) and encrypted. The key pair can be found in crypt-vol-1.
If you want to decode/encode existing maildir files, you can use the following script at your own risk:
-
Enter Dovecot by running docker compose exec dovecot-mailcow /bin/bash in the mailcow-dockerized location.
+
Enter Dovecot by running docker-compose exec dovecot-mailcow /bin/bash in the mailcow-dockerized location.
# Decrypt /var/vmail
find /var/vmail/ -type f -regextype egrep -regex '.*S=.*W=.*' | while read -r file; do
if [[ $(head -c7 "$file") == "CRYPTED" ]]; then
@@ -2396,7 +2396,7 @@ done
Last update:
- 2022-06-02 14:32:36
+ 2022-06-23 15:17:00
diff --git a/en/manual-guides/Dovecot/u_e-dovecot-public_folder/index.html b/en/manual-guides/Dovecot/u_e-dovecot-public_folder/index.html
index 0183e69a7..b6f547905 100644
--- a/en/manual-guides/Dovecot/u_e-dovecot-public_folder/index.html
+++ b/en/manual-guides/Dovecot/u_e-dovecot-public_folder/index.html
@@ -2427,7 +2427,7 @@
:INDEXPVT=~/public can be omitted if per-user seen flags are not wanted.
The new mailbox in the public namespace will be auto-subscribed by users.
To allow all authenticated users access full to that new mailbox (not the whole namespace), run:
-
docker compose exec dovecot-mailcow doveadm acl set -A "Public/Develcow" "authenticated" lookup read write write-seen write-deleted insert post delete expunge create
+
docker-compose exec dovecot-mailcow doveadm acl set -A "Public/Develcow" "authenticated" lookup read write write-seen write-deleted insert post delete expunge create
Adjust the command to your needs if you like to assign more granular rights per user (use -u user@domain instead of -A for example).
Allow authenticated users access to the whole public namespace¶
The static master username will be expanded to DOVECOT_MASTER_USER@mailcow.local.
To login as test@example.org this would equal to test@example.org*mymasteruser@mailcow.local with the specified password above.
A login to SOGo is not possible with this username. A click-to-login function for SOGo is available for admins as described here
@@ -2380,7 +2380,7 @@ No master user is required.
Newer Docker versions seem to complain about existing volumes. You can fix this temporarily by removing the existing volume and start mailcow with the override file. But it seems to be problematic after a reboot (needs to be confirmed).
-
An easy, dirty, yet stable workaround is to stop mailcow (docker compose down), remove /var/lib/docker/volumes/mailcowdockerized_vmail-vol-1/_data and create a new link to your remote filesystem location, for example:
+
An easy, dirty, yet stable workaround is to stop mailcow (docker-compose down), remove /var/lib/docker/volumes/mailcowdockerized_vmail-vol-1/_data and create a new link to your remote filesystem location, for example:
Copy the content of the Mountpoint folder to the new location (e.g. /data/mailcow/vmail) using cp -a, rsync -a or a similar non strcuture breaking copy command
-
Stop mailcow by executing docker compose down from within your mailcow root folder (e.g. /opt/mailcow-dockerized)
+
Stop mailcow by executing docker-compose down from within your mailcow root folder (e.g. /opt/mailcow-dockerized)
Create the file docker-compose.override.yml, edit the device path accordingly
Delete the current vmail folder: docker volume rm mailcowdockerized_vmail-vol-1
-
Start mailcow by executing docker compose up -d from within your mailcow root folder (e.g. /opt/mailcow-dockerized)
+
Start mailcow by executing docker-compose up -d from within your mailcow root folder (e.g. /opt/mailcow-dockerized)
This filename does not need to have a ".conf" extension but follows the pattern site.*.custom, where * is a custom name.
If PHP is to be included in a custom site, please use the PHP-FPM listener on phpfpm:9002 or create a new listener in data/conf/phpfpm/php-fpm.d/pools.conf.
Restart Nginx (and PHP-FPM, if a new listener was created):
Postfix will complain about duplicate values once after starting postfix-mailcow, this is intended.
Syslog-ng was configured to hide those warnings while Postfix is running, to not spam the log files with unnecessary information every time a service is used.
Adding IPv6 hosts is done the same as IPv4, however the subnet needs to be placed in brackets [] with the netmask appended.
To add the subnet 2001:db8::/32 to the trusted networks you may use the following configuration, depending on your IPV4_NETWORK and IPV6_NETWORK scopes:
Redis is used as a key-value store for rspamd's and (some of) mailcow's settings and data. If you are unfamiliar with redis please read the introduction to redis and maybe visit this wonderful guide on how to use it.
Consider attaching a local folder as new volume to rspamd-mailcow in docker-compose.yml and learn given files inside the container. This can be used as workaround to parse compressed data with zcat. Example:
for file in /data/old_mail/.Junk/cur/*;do rspamc learn_spam < zcat $file;done
@@ -2586,15 +2586,15 @@ This is achieved by using the Sieve plugin "sieve_imapsieve" and parser scripts.
cp /var/lib/docker/volumes/mailcowdockerized_redis-vol-1/_data/dump.rdb /root/
# We need to enter the redis-cli first:
-docker compose exec redis-mailcow redis-cli
+docker-compose exec redis-mailcow redis-cli
# In redis-cli:127.0.0.1:6379> EVAL "for i, name in ipairs(redis.call('KEYS', ARGV[1])) do redis.call('DEL', name); end"0 fuzzy*
The default spam reject message can be changed by adding a new file data/conf/rspamd/override.d/worker-proxy.custom.inc with the following content:
reject_message = "My custom reject message";
-
Save the file and restart Rspamd: docker compose restart rspamd-mailcow.
+
Save the file and restart Rspamd: docker-compose restart rspamd-mailcow.
While the above works for rejected mails with a high spam score, prefilter reject actions will ignore this setting. For these maps, the multimap module in Rspamd needs to be adjusted:
If you don't want to use the UI and instead wipe all keys in the Redis database, you can use redis-cli for that task:
-
docker compose exec redis-mailcow sh
+
docker-compose exec redis-mailcow sh
# Unlink (available in Redis >=4.) will delete in the backgronud
redis-cli --scan --pattern RL* | xargs redis-cli unlink
mailcow builds after 31 January 2021 can change SOGo's favicon by replacing data/conf/sogo/custom-favicon.ico for SOGo and data/web/favicon.png for mailcow UI.
Note: You can use .png favicons for SOGo by renaming them to custom-favicon.ico.
For both SOGo and mailcow UI favicons you need use one of the standard dimensions: 16x16, 32x32, 64x64, 128x128 and 256x256.
-After you replaced said file you need to restart SOGo and Memcached containers by executing docker compose restart memcached-mailcow sogo-mailcow.
+After you replaced said file you need to restart SOGo and Memcached containers by executing docker-compose restart memcached-mailcow sogo-mailcow.
mailcow builds after 21 December 2018 can change SOGo's logo by replacing or creating (if missing) data/conf/sogo/sogo-full.svg.
-After you replaced said file you need to restart SOGo and Memcached containers by executing docker compose restart memcached-mailcow sogo-mailcow.
+After you replaced said file you need to restart SOGo and Memcached containers by executing docker-compose restart memcached-mailcow sogo-mailcow.
Run docker compose exec -u sogo sogo-mailcow sogo-tool user-preferences set defaults user@example.com SOGoTOTPEnabled '{"SOGoTOTPEnabled":0}' from within the mailcow directory.
+
Run docker-compose exec -u sogo sogo-mailcow sogo-tool user-preferences set defaults user@example.com SOGoTOTPEnabled '{"SOGoTOTPEnabled":0}' from within the mailcow directory.
Last update:
- 2022-06-02 15:19:55
+ 2022-06-23 15:17:00
diff --git a/en/manual-guides/Unbound/u_e-unbound-fwd/index.html b/en/manual-guides/Unbound/u_e-unbound-fwd/index.html
index 5e60803b9..506a0431b 100644
--- a/en/manual-guides/Unbound/u_e-unbound-fwd/index.html
+++ b/en/manual-guides/Unbound/u_e-unbound-fwd/index.html
@@ -2439,21 +2439,21 @@
forward-addr: 8.8.4.4 # DO NOT USE PUBLIC DNS SERVERS - JUST AN EXAMPLE
Notifies administrators if watchdog can not establish a connection to Nginx on port 8081 and it will restart the container automatically when issues were found and the threshold has been reached.
@@ -2725,7 +2725,7 @@ Example:
Last update:
- 2022-06-02 15:19:55
+ 2022-06-23 15:17:00
diff --git a/en/manual-guides/mailcow-UI/u_e-mailcow_ui-tfa/index.html b/en/manual-guides/mailcow-UI/u_e-mailcow_ui-tfa/index.html
index bdb3729fe..1088baf03 100644
--- a/en/manual-guides/mailcow-UI/u_e-mailcow_ui-tfa/index.html
+++ b/en/manual-guides/mailcow-UI/u_e-mailcow_ui-tfa/index.html
@@ -2620,7 +2620,7 @@ Finally, enter your current account password and, after selecting the Touc
With WebAuthn there is the possibility to use only official Fido Security Keys (from the big brands like: Yubico, Apple, Nitro, Google, Huawei, Microsoft, etc.).
This is primarily for security purposes, as it allows administrators to ensure that only official hardware can be used in their environment.
-
To enable this feature, change the value WEBAUTHN_ONLY_TRUSTED_VENDORS in mailcow.conf from n to y and restart the affected containers with docker compose up -d.
+
To enable this feature, change the value WEBAUTHN_ONLY_TRUSTED_VENDORS in mailcow.conf from n to y and restart the affected containers with docker-compose up -d.
The mailcow will now use the Vendor Certificates located in your mailcow directory under data/web/inc/lib/WebAuthn/rootCertificates.
If you want to limit the official Vendor devices to Apple only you only need the Apple Vendor Certificate inside the data/web/inc/lib/WebAuthn/rootCertificates.
@@ -2653,7 +2653,7 @@ These vendor certificates are only used to verify original hardware, not to secu
Last update:
- 2022-06-02 14:32:36
+ 2022-06-23 15:17:00
diff --git a/en/manual-guides/u_e-80_to_443/index.html b/en/manual-guides/u_e-80_to_443/index.html
index a9d8ea10b..58de9226c 100644
--- a/en/manual-guides/u_e-80_to_443/index.html
+++ b/en/manual-guides/u_e-80_to_443/index.html
@@ -2380,10 +2380,10 @@
}
In case you changed the HTTP_BIND parameter, recreate the container:
@@ -2380,7 +2380,7 @@ smtps_smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
Last update:
- 2022-06-02 14:32:36
+ 2022-06-23 15:17:00
diff --git a/en/models/model-passwd/index.html b/en/models/model-passwd/index.html
index ee16c32d5..dfb2cd2e7 100644
--- a/en/models/model-passwd/index.html
+++ b/en/models/model-passwd/index.html
@@ -2466,14 +2466,14 @@ With SOGo disabled, all hashing methods below will be able to be read by mailcow
I changed the password hashes in the "mailbox" SQL table and cannot login.
-
A "view" needs to be updated. You can trigger this by restarting sogo-mailcow: docker compose restart sogo-mailcow
+
A "view" needs to be updated. You can trigger this by restarting sogo-mailcow: docker-compose restart sogo-mailcow
Last update:
- 2022-06-02 14:32:36
+ 2022-06-23 15:17:00
diff --git a/en/post_installation/firststeps-disable_ipv6/index.html b/en/post_installation/firststeps-disable_ipv6/index.html
index ee9fa26e4..31e5fdbbb 100644
--- a/en/post_installation/firststeps-disable_ipv6/index.html
+++ b/en/post_installation/firststeps-disable_ipv6/index.html
@@ -2390,8 +2390,8 @@ services:
entrypoint: ["echo", "ipv6nat disabled in compose.override.yml"]
For these changes to be effective, you need to fully stop and then restart the stack, so containers and networks are recreated:
-
docker compose down
-docker compose up -d
+
docker-compose down
+docker-compose up -d
3. Disable IPv6 in unbound-mailcow
Edit data/conf/unbound/unbound.conf and set do-ip6 to "no":
@@ -2401,7 +2401,7 @@ docker compose up -d
[...]
Restart Unbound:
-
docker compose restart unbound-mailcow
+
docker-compose restart unbound-mailcow
4. Disable IPv6 in postfix-mailcow
Create data/conf/postfix/extra.cf and set smtp_address_preference to ipv4:
To receive a hidden copy of reports generated by Rspamd you can set a bcc_addrs list in the reporting config section of data/conf/rspamd/local.d/dmarc.conf:
In the example above reports are sent once every 24 hours.
@@ -2558,10 +2558,10 @@ Take one of the lines from output you interested in and request it, f.e.:
Edit docker-compose.override.yml and a djust ofelia.job-exec.rspamd_dmarc_reporting.schedule: "@every 24h" to a desired value, for example to "@midnight"
@@ -2574,7 +2574,7 @@ Take one of the lines from output you interested in and request it, f.e.:
Revert changes done in docker-compose.override.yml to rspamd-mailcow and ofelia-mailcow
-
Run docker compose up -d
+
Run docker-compose up -d
@@ -2583,7 +2583,7 @@ Take one of the lines from output you interested in and request it, f.e.:
Last update:
- 2022-06-02 15:19:55
+ 2022-06-23 15:17:00
diff --git a/en/post_installation/firststeps-ip_bindings/index.html b/en/post_installation/firststeps-ip_bindings/index.html
index 211ab1578..02e587636 100644
--- a/en/post_installation/firststeps-ip_bindings/index.html
+++ b/en/post_installation/firststeps-ip_bindings/index.html
@@ -2455,7 +2455,7 @@ DOVEADM_PORT=127.0.0.1:19991
SQL_PORT=127.0.0.1:13306
SOLR_PORT=127.0.0.1:18983
-
To apply your changes, run docker compose down followed by docker compose up -d.
+
To apply your changes, run docker-compose down followed by docker-compose up -d.
Changing IPv6 bindings is different from IPv4. Again, this has a technical background.
A docker-compose.override.yml file will be used instead of editing the docker-compose.yml file directly. This is to maintain updatability, as the docker-compose.yml file gets updated regularly and your changes will most likely be overwritten.
Logging in mailcow: dockerized consists of multiple stages, but is, after all, much more flexible and easier to integrate into a logging daemon than before.
In Docker the containerized application (PID 1) writes its output to stdout. For real one-application containers this works just fine.
-Run docker compose logs --help to learn more.
+Run docker-compose logs --help to learn more.
Some containers log or stream to multiple destinations.
No container will keep persistent logs in it. Containers are transient items!
In the end, every line of logs will reach the Docker daemon - unfiltered.
As those logs can get quite big, it is a good idea to use logrotate to compress and delete them after a certain time period.
Create /etc/logrotate.d/mailcow with the following content:
@@ -2610,7 +2610,7 @@ input(type="imudp" port="514")
Last update:
- 2022-06-02 15:19:55
+ 2022-06-23 15:17:00
diff --git a/en/post_installation/firststeps-rp/index.html b/en/post_installation/firststeps-rp/index.html
index 0c67eba34..b3ebf9226 100644
--- a/en/post_installation/firststeps-rp/index.html
+++ b/en/post_installation/firststeps-rp/index.html
@@ -2489,7 +2489,7 @@ mailcow: dockerized trusts the default gateway IP 172.22.1.1 as proxy.
This will also change the bindings inside the Nginx container! This is important, if you decide to use a proxy within Docker.
IMPORTANT: Do not use port 8081, 9081 or 65510!
-
Recreate affected containers by running docker compose up -d.
+
Recreate affected containers by running docker-compose up -d.
Important information, please read them carefully!
Info
@@ -2640,7 +2640,7 @@ backend mailcow
Important: This config only covers the "reverseproxing" of the webpannel (nginx-mailcow) using Traefik v2, if you also want to reverseproxy the mail services such as dovecot, postfix... you'll just need to adapt the following config to each container and create an EntryPoint on your traefik.toml or traefik.yml (depending which config you use) for each port.
For this section we'll assume you have your Traefik 2 [certificatesresolvers] properly configured on your traefik configuration file, and also using acme, also, the following example uses Lets Encrypt, but feel free to change it to your own cert resolver. You can find a basic Traefik 2 toml config file with all the above implemented which can be used for this example here traefik.toml if you need one, or a hint on how to adapt your config.
So, first of all, we are going to disable the acme-mailcow container since we'll use the certs that traefik will provide us.
-For this we'll have to set SKIP_LETS_ENCRYPT=y on our mailcow.conf, and run docker compose up -d to apply the changes.
+For this we'll have to set SKIP_LETS_ENCRYPT=y on our mailcow.conf, and run docker-compose up -d to apply the changes.
Then we'll create a docker-compose.override.yml file in order to override the main docker-compose.yml found in your mailcow root folder.
version:'2.1'
@@ -2673,7 +2673,7 @@ For this we'll have to set SKIP_LETS_ENCRYPT=y on our mailcow
network_mode:nonevolumes:# mount the folder which contains Traefik's `acme.json' file
-# in this case Traefik is started from its own docker compose in ../traefik
+# in this case Traefik is started from its own docker-compose in ../traefik-../traefik/data:/traefik:ro# mount mailcow's SSL folder-./data/assets/ssl/:/output:rw
@@ -2686,10 +2686,10 @@ For this we'll have to set SKIP_LETS_ENCRYPT=y on our mailcow
web:external:true
-
Start the new containers with docker compose up -d.
+
Start the new containers with docker-compose up -d.
Now, there's only one thing left to do, which is setup the certs so that the mail services can use them as well, since Traefik 2 uses an acme v2 format to save ALL the license from all the domains we have, we'll need to find a way to dump the certs, lucky we have this tiny container which grabs the acme.json file trough a volume, and a variable DOMAIN=example.org, and with these, the container will output the cert.pem and key.pem files, for this we'll simply run the traefik-certs-dumper container binding the /traefik volume to the folder where our acme.json is saved, bind the /output volume to our mailcow data/assets/ssl/ folder, and set up the DOMAIN=example.org variable to the domain we want the certs dumped from.
This container will watch over the acme.json file for any changes, and regenerate the cert.pem and key.pem files directly into data/assets/ssl/ being the path binded to the container's /output path.
-
You can use the command line to run it, or use the docker compose shown here.
+
You can use the command line to run it, or use the docker-compose shown here.
After we have the certs dumped, we'll have to reload the configs from our postfix and dovecot containers, and check the certs, you can see how here.
Aaand that should be it 😊, you can check if the Traefik router works fine trough Traefik's dashboard / traefik logs / accessing the setted domain trough https, or / and check HTTPS, SMTP and IMAP trough the commands shown on the page linked before.
Optional: Post-hook script for non-mailcow ACME clients¶
If you plan to use a server name that is not MAILCOW_HOSTNAME in your reverse proxy, make sure to populate that name in mailcow.conf via ADDITIONAL_SERVER_NAMES first. Names must be separated by commas and must not contain spaces. If you skip this step, mailcow may respond to your reverse proxy with an incorrect site.
Last update:
- 2022-06-02 15:19:55
+ 2022-06-23 15:17:00
diff --git a/en/post_installation/firststeps-snat/index.html b/en/post_installation/firststeps-snat/index.html
index 46d1fda71..6a955caaa 100644
--- a/en/post_installation/firststeps-snat/index.html
+++ b/en/post_installation/firststeps-snat/index.html
@@ -2369,16 +2369,16 @@ SNAT_TO_SOURCE=1.2.3.4
# Use this IPv6 for outgoing connections (SNAT)
SNAT6_TO_SOURCE=dead:beef
-
Run docker compose up -d.
+
Run docker-compose up -d.
The values are read by netfilter-mailcow. netfilter-mailcow will make sure, the post-routing rules are on position 1 in the netfilter table. It does automatically delete and re-create them if they are found on another position than 1.
-
Check the output of docker compose logs --tail=200 netfilter-mailcow to ensure the SNAT settings have been applied.
+
Check the output of docker-compose logs --tail=200 netfilter-mailcow to ensure the SNAT settings have been applied.
For each domain you add, it will try to resolve autodiscover.ADDED_MAIL_DOMAIN and autoconfig.ADDED_MAIL_DOMAIN to its IPv6 address or - if IPv6 is not configured in your domain - IPv4 address. If it succeeds, a name will be added as SAN to the certificate request.
Only names that can be validated, will be added as SAN.
For every domain you remove, the certificate will be moved and a new certificate will be requested. It is not possible to keep domains in a certificate, when we are not able validate the challenge for those.
-
If you want to re-run the ACME client, use docker compose restart acme-mailcow and monitor its logs with docker compose logs --tail=200 -f acme-mailcow.
+
If you want to re-run the ACME client, use docker-compose restart acme-mailcow and monitor its logs with docker-compose logs --tail=200 -f acme-mailcow.
Edit "mailcow.conf" and add a parameter ADDITIONAL_SAN like this:
Do not use quotes (") and do not use spaces between the names!
@@ -2605,7 +2605,7 @@
Each name will be validated against its IPv6 address or - if IPv6 is not configured in your domain - IPv4 address.
A wildcard name like smtp.* will try to obtain a smtp.DOMAIN_NAME SAN for each domain added to mailcow.
-
Run docker compose up -d to recreate affected containers automatically.
+
Run docker-compose up -d to recreate affected containers automatically.
Info
Using names other name MAILCOW_HOSTNAME to access the mailcow UI may need further configuration.
@@ -2613,26 +2613,26 @@
If you plan to use a server name that is not MAILCOW_HOSTNAME to access the mailcow UI (for example by adding mail.* to ADDITIONAL_SAN make sure to populate that name in mailcow.conf via ADDITIONAL_SERVER_NAMES. Names must be separated by commas and must not contain spaces. If you skip this step, mailcow may respond with an incorrect site.
You can skip the IP verification by setting SKIP_IP_CHECK=y in mailcow.conf (no quotes). Be warned that a misconfiguration will get you ratelimited by Let's Encrypt! This is primarily useful for multi-IP setups where the IP check would return the incorrect source IP address. Due to using dynamic IPs for acme-mailcow, source NAT is not consistent over restarts.
-
If you encounter problems with "HTTP validation", but your IP address confirmation succeeds, you are most likely using firewalld, ufw or any other firewall, that disallows connections from br-mailcow to your external interface. Both firewalld and ufw disallow this by default. It is often not enough to just stop these firewall services. You'd need to stop mailcow (docker compose down), stop the firewall service, flush the chains and restart Docker.
+
If you encounter problems with "HTTP validation", but your IP address confirmation succeeds, you are most likely using firewalld, ufw or any other firewall, that disallows connections from br-mailcow to your external interface. Both firewalld and ufw disallow this by default. It is often not enough to just stop these firewall services. You'd need to stop mailcow (docker-compose down), stop the firewall service, flush the chains and restart Docker.
You can also skip this validation method by setting SKIP_HTTP_VERIFICATION=y in "mailcow.conf". Be warned that this is discouraged. In most cases, the HTTP verification is skipped to workaround unknown NAT reflection issues, which are not resolved by ignoring this specific network misconfiguration. If you encounter problems generating TLSA records in the DNS overview within mailcow, you are most likely having issues with NAT reflection you should fix.
-
If you changed a SKIP_* parameter, run docker compose up -d to apply your changes.
+
If you changed a SKIP_* parameter, run docker-compose up -d to apply your changes.
By default, "acme-mailcow" will create a single SAN certificate for all validated domains
@@ -2645,7 +2645,7 @@ This provides best compatibility but means the Let's Encrypt limit exceeds if yo
Limitations: A certificate name ADDITIONAL_SAN=test.example.com will be added as SAN to the main certificate. A separate certificate/key pair will not be generated for this format.
Postfix, Dovecot and Nginx will then serve these certificates with SNI.
-
Set ENABLE_SSL_SNI=y in "mailcow.conf" and recreate "acme-mailcow" by running docker compose up -d.
+
Set ENABLE_SSL_SNI=y in "mailcow.conf" and recreate "acme-mailcow" by running docker-compose up -d.
Warning
Not all clients support SNI, see Dovecot documentation or Wikipedia.
@@ -2675,15 +2675,15 @@ docker restart $(docker ps -qaf name=dovecot-mailcow)
Run docker compose logs acme-mailcow to find out why a validation fails.
+
Run docker-compose logs acme-mailcow to find out why a validation fails.
To check if nginx serves the correct certificate, simply use a browser of your choice and check the displayed certificate.
To check the certificate served by Postfix, Dovecot and Nginx we will use openssl:
# Connect via SMTP (587)
@@ -2703,7 +2703,7 @@ bash helper-scripts/expiry-dates.sh
Last update:
- 2022-06-02 14:32:36
+ 2022-06-23 15:17:00
diff --git a/en/third_party/third_party-borgmatic/index.html b/en/third_party/third_party-borgmatic/index.html
index c659baa1e..5affa2513 100644
--- a/en/third_party/third_party-borgmatic/index.html
+++ b/en/third_party/third_party-borgmatic/index.html
@@ -2790,13 +2790,13 @@ usual id_rsa, id_ed25519 or similar to be in this dire
or OpenSSH will refuse to use the SSH key.
You will be asked you to authenticate the SSH host key of your remote repository server. See if it matches and confirm
the prompt by entering yes. The repository will be initialized with the passphrase you set in the BORG_PASSPHRASE
@@ -2808,7 +2808,7 @@ for how to retrieve the key.
Restoring a backup assumes you are starting off with a fresh installation of mailcow, and you currently do not have
@@ -2829,7 +2829,7 @@ this volume.
Before running a restore you must make the vmail volume writeable in docker-compose.override.yml by removing
the ro flag from the volume.
Then you can use the following command to restore the maildir from a backup:
@@ -2840,7 +2840,7 @@ Then you can use the following command to restore the maildir from a backup:
intend to recover the mailcow database from a backup.
To restore the MySQL database from the latest archive use this command:
@@ -2848,21 +2848,21 @@ intend to recover the mailcow database from a backup.
After restoring you need to restart mailcow. If you disabled SELinux enforcing mode now would be a good time to
re-enable it.
To restart mailcow use the follwing command:
-
docker compose down && docker compose up -d
+
docker-compose down && docker-compose up -d
If you use SELinux this will also trigger the re-labeling of all files in your vmail volume. Be patient, as this may
take a while if you have lots of files.