Zammad ist eine leistungsstarke Open-Source-Helpdesk-Software, die eine vereinheitlichte Plattform für die Verwaltung von Kundenanfragen bietet, die aus verschiedenen Kommunikationskanälen wie E-Mail, sozialen Medien und Telefonanrufen stammen. Sie bietet eine klare und intuitive Benutzeroberfläche, die den Support-Teams die Möglichkeit gibt, Tickets zu erstellen, zuzuweisen und zu verfolgen.
Zusätzlich zur Ticketverwaltung verfügt Zammad über eine Reihe von Features, die das Kundenbeziehungsmanagement (CRM) unterstützen, eine Wissensdatenbank zur Organisation und Speicherung relevanter Informationen bereitstellen und verschiedene Automatisierungsoptionen ermöglichen. Zammad kann entweder auf einem privaten Server installiert oder als gehosteter Service genutzt werden.
0. Versionierung
| Datum | Änderung |
|---|---|
| 26.07.2023 | Update der .env auf die aktuellste Version. Bitte in eurem Setup übernehmen und dann ein docker compose pull && docker compose up -d durchführen |
| 16.07.2023 | Initialer Release |
1. Zielsetzung
Unser Ziel in dieser Anleitung ist es, den Installationsprozess von Zammad in einem Docker-Container auf einem Server zu erleichtern und zu erklären, wie man Traefik als Reverse Proxy konfiguriert.
2. Voraussetzung
Bevor wir mit der Installation und Konfiguration von Zammad beginnen, müssen wir einige Voraussetzungen erfüllen. Die wichtigste davon ist, dass wir Traefik als unseren Reverse Proxy eingerichtet haben und mit CrowdSec konfiguriert haben.
Für Zammad ist mindestens empfohlen:
- 2 CPU-Kerne
- 4 GB RAM (+4 GB, wenn wir Elasticsearch auf demselben Server ausführen möchten)
Natürlich hängt dies letztendlich von der tatsächlichen Last durch gleichzeitige Agenten und Datenverkehr ab.
3. Verzeichnisse / Dateien anlegen
Um mit der Installation und Konfiguration von Zammad zu beginnen, müssen wir zuerst die notwendigen Verzeichnisse und Dateien erstellen. Dazu erstellen wir ein Hauptverzeichnis für Zammad und verschiedene Dateien, die wir im Verlauf dieser Anleitung benötigen.
Führen Sie die folgenden Befehle in Ihrer Linux-Shell aus, um das Verzeichnis und die Dateien zu erstellen:
# Hier erstellen wir das Hauptverzeichnis und ein Unterverzeichnis für Zammad
mkdir -p /opt/containers/zammad/scripts
# Als nächstes erstellen wir verschiedene Dateien, die wir im weiteren Verlauf der Anleitung verwenden werden
touch /opt/containers/zammad/{docker-compose.yml,docker-compose.override.yml,scripts/backup.sh}
# Schließlich wechseln wir in das neu erstellte Verzeichnis
cd /opt/containers/zammad/
Die obigen Befehle erstellen ein neues Verzeichnis und mehrere leere Dateien im Pfad /opt/containers/zammad/. Sie dienen als Grundlage für die Installation und Konfiguration von Zammad in den nachfolgenden Schritten.
4. Erstellung der docker-compose.yml
4.1. Original Datei von Github
Die docker-compose.yml Datei ist das Herzstück unserer Docker Konfiguration. Sie definiert, welche Dienste gestartet werden und wie sie miteinander interagieren. Um diese Datei zu erstellen, nehmen wir uns die Vorlage aus der offiziellen Zammad-Dokumentation als Basis, welche unter folgendem Link zu finden ist: https://docs.zammad.org/en/latest/install/docker-compose.html.
Die docker-compose.yml Vorlage befindet sich im Zammad Github-Repository: https://github.com/zammad/zammad-docker-compose. Wir kopieren den Inhalt dieser Datei in unsere neu erstellte docker-compose.yml:
nano /opt/containers/zammad/docker-compose.yml
In die geöffnete Datei kopieren wir folgenden Inhalt:
---
version: '3.8'
services:
zammad-backup:
command: ["zammad-backup"]
depends_on:
- zammad-railsserver
- zammad-postgresql
entrypoint: /usr/local/bin/backup.sh
environment:
- BACKUP_TIME=03:00
- HOLD_DAYS=10
- POSTGRESQL_DB=${POSTGRES_DB}
- POSTGRESQL_USER=${POSTGRES_USER}
- POSTGRESQL_PASSWORD=${POSTGRES_PASS}
- TZ=Europe/Berlin
image: postgres:${POSTGRES_VERSION}
restart: ${RESTART}
volumes:
- zammad-backup:/var/tmp/zammad
- zammad-var:/opt/zammad/var:ro
- ./scripts/backup.sh:/usr/local/bin/backup.sh:ro
zammad-elasticsearch:
image: bitnami/elasticsearch:${ELASTICSEARCH_VERSION}
restart: ${RESTART}
volumes:
- elasticsearch-data:/bitnami/elasticsearch/data
zammad-init:
command: ["zammad-init"]
depends_on:
- zammad-postgresql
environment:
- MEMCACHE_SERVERS=${MEMCACHE_SERVERS}
- REDIS_URL=${REDIS_URL}
image: ${IMAGE_REPO}:${VERSION}
restart: on-failure
user: 0:0
volumes:
- zammad-config-nginx:/etc/nginx/sites-enabled
- zammad-var:/opt/zammad/var
zammad-memcached:
command: memcached -m 256M
image: memcached:${MEMCACHE_VERSION}
restart: ${RESTART}
zammad-nginx:
command: ["zammad-nginx"]
expose:
- "8080"
depends_on:
- zammad-railsserver
image: ${IMAGE_REPO}:${VERSION}
restart: ${RESTART}
volumes:
- zammad-config-nginx:/etc/nginx/sites-enabled:ro
- zammad-var:/opt/zammad/var:ro
zammad-postgresql:
environment:
- POSTGRES_DB=${POSTGRES_DB}
- POSTGRES_USER=${POSTGRES_USER}
- POSTGRES_PASSWORD=${POSTGRES_PASS}
image: postgres:${POSTGRES_VERSION}
restart: ${RESTART}
volumes:
- postgresql-data:/var/lib/postgresql/data
zammad-railsserver:
command: ["zammad-railsserver"]
depends_on:
- zammad-memcached
- zammad-postgresql
- zammad-redis
environment:
- MEMCACHE_SERVERS=${MEMCACHE_SERVERS}
- REDIS_URL=${REDIS_URL}
image: ${IMAGE_REPO}:${VERSION}
restart: ${RESTART}
volumes:
- zammad-var:/opt/zammad/var
zammad-redis:
image: redis:${REDIS_VERSION}
restart: ${RESTART}
volumes:
- redis-data:/data
zammad-scheduler:
command: ["zammad-scheduler"]
depends_on:
- zammad-memcached
- zammad-railsserver
- zammad-redis
environment:
- MEMCACHE_SERVERS=${MEMCACHE_SERVERS}
- REDIS_URL=${REDIS_URL}
image: ${IMAGE_REPO}:${VERSION}
restart: ${RESTART}
volumes:
- zammad-var:/opt/zammad/var
zammad-websocket:
command: ["zammad-websocket"]
depends_on:
- zammad-memcached
- zammad-railsserver
- zammad-redis
environment:
- MEMCACHE_SERVERS=${MEMCACHE_SERVERS}
- REDIS_URL=${REDIS_URL}
image: ${IMAGE_REPO}:${VERSION}
restart: ${RESTART}
volumes:
- zammad-var:/opt/zammad/var
volumes:
elasticsearch-data:
driver: local
postgresql-data:
driver: local
redis-data:
driver: local
zammad-backup:
driver: local
zammad-config-nginx:
driver: local
zammad-var:
driver: local
4.2. Anpassen der docker-compose.yml
Jetzt nehmen wir einige Änderungen an der docker-compose.yml vor, um sie an unsere spezifischen Bedürfnisse anzupassen. Unsere modifizierte Version sieht so aus:
version: '3.9'
services:
zammad-backup:
command: ["zammad-backup"]
depends_on:
- zammad-railsserver
- zammad-postgresql
entrypoint: /usr/local/bin/backup.sh
environment:
- BACKUP_TIME=03:00
- HOLD_DAYS=10
- POSTGRESQL_DB=${POSTGRES_DB}
- POSTGRESQL_USER=${POSTGRES_USER}
- POSTGRESQL_PASSWORD=${POSTGRES_PASS}
- TZ=Europe/Berlin
image: postgres:${POSTGRES_VERSION}
restart: ${RESTART}
volumes:
- ./zammad/backup:/var/tmp/zammad
- zammad-var:/opt/zammad/var:ro
- ./scripts/backup.sh:/usr/local/bin/backup.sh:ro
zammad-elasticsearch:
image: bitnami/elasticsearch:${ELASTICSEARCH_VERSION}
restart: ${RESTART}
volumes:
- elasticsearch-data:/bitnami/elasticsearch/data
zammad-init:
command: ["zammad-init"]
depends_on:
- zammad-postgresql
environment:
- MEMCACHE_SERVERS=${MEMCACHE_SERVERS}
- REDIS_URL=${REDIS_URL}
image: ${IMAGE_REPO}:${VERSION}
restart: on-failure
user: 0:0
volumes:
- zammad-config-nginx:/etc/nginx/sites-enabled
- zammad-var:/opt/zammad/var
zammad-memcached:
command: memcached -m 256M
image: memcached:${MEMCACHE_VERSION}
restart: ${RESTART}
zammad-nginx:
command: ["zammad-nginx"]
expose:
- "8080"
depends_on:
- zammad-railsserver
image: ${IMAGE_REPO}:${VERSION}
restart: ${RESTART}
volumes:
- zammad-config-nginx:/etc/nginx/sites-enabled:ro
- zammad-var:/opt/zammad/var:ro
zammad-postgresql:
environment:
- POSTGRES_DB=${POSTGRES_DB}
- POSTGRES_USER=${POSTGRES_USER}
- POSTGRES_PASSWORD=${POSTGRES_PASS}
image: postgres:${POSTGRES_VERSION}
restart: ${RESTART}
volumes:
- postgresql-data:/var/lib/postgresql/data
zammad-railsserver:
command: ["zammad-railsserver"]
depends_on:
- zammad-memcached
- zammad-postgresql
- zammad-redis
environment:
- MEMCACHE_SERVERS=${MEMCACHE_SERVERS}
- REDIS_URL=${REDIS_URL}
image: ${IMAGE_REPO}:${VERSION}
restart: ${RESTART}
volumes:
- zammad-var:/opt/zammad/var
zammad-redis:
image: redis:${REDIS_VERSION}
restart: ${RESTART}
volumes:
- redis-data:/data
zammad-scheduler:
command: ["zammad-scheduler"]
depends_on:
- zammad-memcached
- zammad-railsserver
- zammad-redis
environment:
- MEMCACHE_SERVERS=${MEMCACHE_SERVERS}
- REDIS_URL=${REDIS_URL}
image: ${IMAGE_REPO}:${VERSION}
restart: ${RESTART}
volumes:
- zammad-var:/opt/zammad/var
zammad-websocket:
command: ["zammad-websocket"]
depends_on:
- zammad-memcached
- zammad-railsserver
- zammad-redis
environment:
- MEMCACHE_SERVERS=${MEMCACHE_SERVERS}
- REDIS_URL=${REDIS_URL}
image: ${IMAGE_REPO}:${VERSION}
restart: ${RESTART}
volumes:
- zammad-var:/opt/zammad/var
volumes:
elasticsearch-data:
driver: local
postgresql-data:
driver: local
redis-data:
driver: local
zammad-config-nginx:
driver: local
zammad-var:
driver: local
Die vorgenommenen Änderungen in der docker-compose.yml sind:
- Aktualisierung der Docker Compose-Version auf
3.9. Dies ist die aktuellste Version von Docker Compose und bietet Unterstützung für alle neuesten Funktionen. - Anpassung des Volumen-Pfades für den Zammad-Backup-Service. Statt eines Docker-managed Volumens (
zammad-backup) verwenden wir nun einen Pfad im Dateisystem des Hosts (./zammad/backup). Dadurch werden die Backups in einem spezifischen Verzeichnis auf dem Host-System gespeichert, was die Datensicherung und -wiederherstellung vereinfacht. - Das
zammad-backup-Volume am Ende der Datei wurde entfernt
4.3. Erstellen der docker-compose.override.yml
Um Änderungen an den Servicekonfigurationen vorzunehmen, ohne die ursprüngliche docker-compose.yml-Datei zu ändern, erstellen wir eine docker-compose.override.yml. Diese Methode behält die Integrität der Hauptkonfigurationsdatei bei und erleichtert die Wartung, sollten an der Originaldatei signifikante Änderungen vorgenommen werden.
Erstellen Sie die docker-compose.override.yml Datei:
nano /opt/containers/zammad/docker-compose.override.yml
Fügen Sie den folgenden Inhalt ein:
version: '3.9'
services:
zammad-backup:
networks:
default:
zammad-elasticsearch:
networks:
default:
zammad-init:
networks:
default:
zammad-memcached:
networks:
default:
zammad-nginx:
environment:
- VIRTUAL_HOST=deinzammad.de
- NGINX_SERVER_SCHEME=https
labels:
traefik.docker.network: proxy
traefik.enable: "true"
traefik.http.routers.zammad-secure.entrypoints: websecure
traefik.http.routers.zammad-secure.middlewares: default@file
traefik.http.routers.zammad-secure.rule: Host(`deinzammad.de`)
traefik.http.routers.zammad-secure.service: zammad
traefik.http.routers.zammad-secure.tls: "true"
traefik.http.routers.zammad-secure.tls.certresolver: http_resolver
traefik.http.routers.zammad.entrypoints: web
traefik.http.routers.zammad.rule: Host(`deinzammad.de`)
traefik.http.services.zammad.loadbalancer.server.port: "8080"
networks:
proxy:
default:
zammad-postgresql:
networks:
default:
zammad-railsserver:
networks:
default:
zammad-redis:
networks:
default:
zammad-scheduler:
networks:
default:
zammad-websocket:
networks:
default:
networks:
proxy:
name: proxy
external: true
default:
name: zammad
In dieser Datei definieren wir spezifische Netzwerk- und Umgebungsparameter für unsere Zammad-Dienste und passen die Nginx Konfiguration an Traefik an. Wichtig ist hier, dass wir deinzammad.de durch die tatsächliche Domain ersetzen. Das Netzwerk “proxy” ist extern und von Traefik verwaltet, während “default” das Standardnetzwerk für unsere Anwendung ist.
Diese docker-compose.override.yml Datei ermöglicht uns eine flexible und wartungsfreundliche Konfiguration unserer Zammad-Installation. Durch die Verwendung dieser Datei können wir Änderungen an unserer Konfiguration vornehmen, ohne die ursprüngliche docker-compose.yml-Datei zu beeinträchtigen, was insbesondere bei zukünftigen Updates und Upgrades nützlich ist.
5. Erstellung der .env-Datei
Jetzt benötigen wir einige spezifische Umgebungsvariablen für unsere Zammad-Installation. Diese Variablen sind in einer .env Datei definiert, die wir aus dem Github-Repository von Zammad kopieren und in unsere eigene .env Datei einfügen müssen.
Wir öffnen unsere neue Datei namens .env im Verzeichnis /opt/containers/zammad/
nano /opt/containers/zammad/.env
und kopieren die folgenden Zeilen in die .env Datei:
ELASTICSEARCH_VERSION=8.8.0 IMAGE_REPO=ghcr.io/zammad/zammad MEMCACHE_SERVERS=zammad-memcached:11211 MEMCACHE_VERSION=1.6.20-alpine POSTGRES_DB=zammad_production POSTGRES_PASS=zammad POSTGRES_USER=zammad POSTGRES_HOST=zammad-postgresql POSTGRES_PORT=5432 POSTGRES_VERSION=15.3-alpine REDIS_URL=redis://zammad-redis:6379 REDIS_VERSION=7.0.5-alpine RESTART=always VERSION=6.0.0-66
Die .env Datei enthält eine Reihe von Umgebungsvariablen, die von der Zammad-Installation verwendet werden. Hier eine kurze Erklärung, was einige dieser Variablen bedeuten:
ELASTICSEARCH_VERSION: Definiert die Version von Elasticsearch, die verwendet werden soll.IMAGE_REPO: Gibt das Repository an, aus dem die Zammad-Docker-Images bezogen werden.MEMCACHE_SERVERS: Stellt die Adresse des Memcached-Servers zur Verfügung.POSTGRES_*: Diese Variablen konfigurieren die PostgreSQL-Datenbank, die Zammad verwendet. Dazu gehören der Datenbankname, der Benutzername und das Passwort, der Hostname und der Port.REDIS_URL: Gibt die URL des Redis-Servers an.RESTART: Legt die Neustartpolitik für die Container fest.VERSION: Definiert die Version von Zammad, die installiert werden soll.
Diese Datei wird nun von Docker beim Start der Zammad-Container verwendet, um die richtigen Umgebungsvariablen zu setzen.
6. Erstellen der backup.sh
Nun benötigen wir noch die backup.sh für unsere Zammad-Installation. Auch diese Datei holen wir uns aus dem Github-Repository von Zammad.
Wir öffnen unsere neue Datei:
nano /opt/containers/zammad/scripts/backup.sh
und kopieren den Inhalt der originalen Datei hinein:
#!/bin/bash
set -e
: "${ZAMMAD_DIR:=/opt/zammad/var}"
: "${BACKUP_DIR:=/var/tmp/zammad}"
: "${ZAMMAD_RAILSSERVER_HOST:=zammad-railsserver}"
: "${ZAMMAD_RAILSSERVER_PORT:=3000}"
: "${POSTGRESQL_HOST:=zammad-postgresql}"
: "${POSTGRESQL_PORT:=5432}"
: "${POSTGRESQL_DB:=zammad_production}"
function check_railsserver_available {
until (echo > "/dev/tcp/$ZAMMAD_RAILSSERVER_HOST/$ZAMMAD_RAILSSERVER_PORT") &> /dev/null; do
echo "waiting for railsserver to be ready..."
sleep 60
done
}
function zammad_backup {
TIMESTAMP="$(date +'%Y%m%d%H%M%S')"
echo "${TIMESTAMP} - backuping zammad..."
# delete old backups
if [ -d "${BACKUP_DIR}" ] && [ -n "$(ls "${BACKUP_DIR}")" ]; then
find "${BACKUP_DIR}"/*_zammad_*.gz -type f -mtime +"${HOLD_DAYS}" -delete
fi
if [ "${NO_FILE_BACKUP}" != "yes" ]; then
# tar files
tar -czf "${BACKUP_DIR}"/"${TIMESTAMP}"_zammad_files.tar.gz "${ZAMMAD_DIR}"
fi
#db backup
pg_dump --dbname=postgresql://"${POSTGRESQL_USER}:${POSTGRESQL_PASSWORD}@${POSTGRESQL_HOST}:${POSTGRESQL_PORT}/${POSTGRESQL_DB}" | gzip > "${BACKUP_DIR}"/"${TIMESTAMP}"_zammad_db.psql.gz
echo "backup finished :)"
}
if [ "$1" = 'zammad-backup' ]; then
check_railsserver_available
while true; do
NOW_TIMESTAMP=$(date +%s)
TOMORROW_DATE=$(date -d@"$((NOW_TIMESTAMP + 24*60*60))" +%Y-%m-%d)
zammad_backup
NEXT_TIMESTAMP=$(date -d "$TOMORROW_DATE $BACKUP_TIME" +%s)
NOW_TIMESTAMP=$(date +%s)
sleep $((NEXT_TIMESTAMP - NOW_TIMESTAMP))
done
fi
if [ "$1" = 'zammad-backup-once' ]; then
check_railsserver_available
zammad_backup
fi
if [ "$1" = 'zammad-backup-db' ]; then
NO_FILE_BACKUP="yes"
zammad_backup
fi
6.1. Ausführbarkeit
Damit unsere Backup-Skriptdatei korrekt vom Docker-Container ausgeführt werden kann, müssen wir die entsprechenden Ausführungsrechte einstellen. Dies erreichen wir mit dem Befehl chmod, der zur Änderung von Datei- und Verzeichnisrechten in einem Unix- oder Linux-ähnlichen Betriebssystem dient.
Der Befehl chmod +x fügt der Datei die Ausführungsberechtigung (execute permission) hinzu, was bedeutet, dass die Datei als ein Programm oder ein Skript ausgeführt werden kann.
Führen Sie den folgenden Befehl aus, um die Ausführungsrechte für unser Backup-Skript einzurichten:
chmod +x /opt/containers/zammad/scripts/backup.sh
Mit diesem Schritt ist sichergestellt, dass unser Backup-Skript ohne Probleme ausgeführt werden kann, wenn es vom Zammad-Docker-Container aufgerufen wird.
7. Zammad starten
Nachdem alle Vorbereitungen abgeschlossen sind, können wir nun Zammad starten. Wir wechseln zuerst in das Verzeichnis, in dem sich die Docker-Compose- und .env-Dateien befinden:
cd /opt/containers/zammad/
Jetzt können wir Zammad mit dem Befehl docker compose up -d starten:
docker compose up -d
Dieser Befehl startet alle Dienste, die in der docker-compose.yml– und docker-compose.override.yml-Datei definiert sind, im Hintergrund und lässt sie laufen, selbst wenn wir die Terminal-Sitzung beenden.
Die Option -d steht für “detached” und bedeutet, dass die Container im Hintergrund laufen und die Shell nach dem Start der Container zur Verfügung steht.
8. Elasticsearch optimieren
Um sicherzustellen, dass Elasticsearch effizient funktioniert, ist es möglicherweise notwendig, den vm.max_map_count-Wert auf dem Host-System selbst anzupassen.
Der Wert für vm.max_map_count bestimmt die maximale Anzahl von Speicherzuordnungen (Memory Mappings), die ein Prozess erstellen kann. Elasticsearch benötigt oft einen höheren Wert als den standardmäßigen, um optimal zu funktionieren.
Dafür öffnen wir die Datei /etc/sysctl.conf auf dem Host-System:
nano /etc/sysctl.conf
Wur fügen die folgende Zeile am Ende der Datei hinzu und speichern die Änderungen:
vm.max_map_count=262144
Wenn du dir nicht sicher bist, welchen Wert du einstellen sollen, beginne mit dem doppelten des aktuellen Werts und erhöhe diesen schrittweise, bis Elasticsearch erfolgreich startet. Die offizielle Dokumentation empfiehlt einen Wert von mindestens 262144.
Wir starten unser System neu oder laden Sie die Konfiguration mit dem folgenden Befehl neu, um die Änderungen wirksam zu machen:
sysctl -p
Mit diesem Schritt stellen wir sicher, dass Elasticsearch die erforderlichen Ressourcen zur Verfügung hat, um optimal zu funktionieren.
FAQ
1. Warum wählen wir in diesem Setup Docker Volumes statt lokaler Mounts, und warum ist das Backup die Ausnahme zu dieser Regel?
Die Wahl, Docker Volumes anstelle von lokalen Mounts zu verwenden, hängt in erster Linie mit den besonderen Eigenschaften von Zammad und dessen Verwendung von verschiedenen Containern, insbesondere solchen, die auf Java basieren, zusammen. Java-basierte Anwendungen können bei unsachgemäßer Konfiguration zu Benutzerrechtsproblemen auf dem Server führen. Die Benutzung von Docker Volumes erleichtert das Management von Benutzerrechten, da Docker Volumes standardmäßig die korrekten Berechtigungen und Besitzer haben.
Zudem ist der Prozess der Anpassung der Docker-Compose-Datei, um lokale Mounts zu verwenden, tendenziell komplizierter und zeitaufwendiger. Er kann auch die Wartungsfreundlichkeit beeinträchtigen, da jede zusätzliche Anpassung der ursprünglichen Docker-Compose-Datei die Wahrscheinlichkeit erhöht, dass zukünftige Updates Probleme verursachen.
Aus all diesen Gründen habe ich mich dazu entschieden, in dieser Anleitung die Verwendung von Docker Volumes zu empfehlen und mich auf die bereitgestellte .env-Datei zu verlassen, anstatt eine eigene zu erstellen. Das Ziel ist es, einen klaren, einfach zu folgenden und wartungsfreundlichen Prozess zu gewährleisten.
Eine wichtige Ausnahme hierbei sind die Backups. Für diese nutzen wir lokale Mounts, um eine einfache Integration in bestehende Backup-Lösungen wie Borg Backup zu ermöglichen. Lokale Backups ermöglichen uns auch einen schnelleren Zugriff auf Backup-Dateien und eine flexiblere Handhabung der Backup-Datensicherung.
2. Was mache ich, wenn ich beim Starten der Container den folgenden Fehler erhalte: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "/usr/local/bin/backup.sh": permission denied: unknown?
Dieser Fehler kann auftreten, wenn Sie Schritt 6.1. in der Anleitung ausgelassen haben. Dieser Schritt ist unerlässlich, da er die Ausführungsrechte für das Backup-Skript setzt.
Wenn Sie diesen Fehler erhalten, beenden Sie zuerst alle laufenden Container mit dem Befehl:
docker compose down
Anschließend beginnen Sie ab Schritt 6.1 erneut mit der Anleitung. Dieser beinhaltet die korrekte Einstellung der Ausführungsrechte für das Backup-Skript. Das Auslassen dieses Schrittes führt dazu, dass das Skript nicht ausgeführt werden kann und resultiert in dem oben genannten Fehler.
Hinweis
Hinweis zu Kommentaren
Wenn etwas nicht funktioniert, gehe noch einmal alle einzelnen Punkte in der Anleitung durch. Ich habe die Anleitung mehrfach getestet. Wenn du sicher bist, dass du alles richtig konfiguriert hast und das noch einmal überprüft hast, dann hinterlasse gerne einen Kommentar. Der Blog wird von Christian betrieben und er, sowie alle Co-Autoren, bemühen uns, alle Fragen und Probleme zu lösen – allerdings ist dies auch immer von unserer verfügbaren Zeit abhängig!
Bitte abonniert GoNeuland, damit dieser Blog uns auch weiterhin viele Jahre Freude bereiten kann 😉
Ich habe die .env ein wenig geändert, um die neusten Versionen zu nutzen:
Dadurch wird die stable version installiert und die Version ist nicht gelocked.
ELASTICSEARCH_VERSION=latest IMAGE_REPO=ghcr.io/zammad/zammad MEMCACHE_SERVERS=zammad-memcached:11211 MEMCACHE_VERSION=1.6-alpine POSTGRES_DB=zammad_production POSTGRES_PASS=zammad POSTGRES_USER=zammad POSTGRES_HOST=zammad-postgresql POSTGRES_PORT=5432 POSTGRES_VERSION=15-alpine REDIS_URL=redis://zammad-redis:6379 REDIS_VERSION=7.2-alpine RESTART=always VERSION=stableHat noch jemand das Problem, dass ein Logo nicht gespeichert wird?
Es wird hochgeladen, angezeigt, dann speichere ich die Änderung ab und es wird als broken Link zur Datei angezeigt.
Dateien in den Ticket können gespeichert werden. Dort bleiben sie auch verfügbar.
Vielen Dank für diese Anleitung! Auch im generellen ein großes Lob für die tolle Arbeit!
Ich habe aber leider ein Problem, das ich nicht lösen kann.
Für Elasticsearch erhalte ich immer folgenden Fehler. Eine Idee, wie ich das lösen kann?
Vielen Dank im Voraus!