Um zu Vermeiden Änderungen am laufendem System durchzuführen, ist es sinnvoll ein weiteres System zu erstellen. Auf dem sogenannten Staging System, läuft dann eine weitere OTOBO Instanz. Es ist sinvoll einen Testserver zu erstellen. Wie kann man ein Staging Systemerstellen ? Das Entwickeln auf dem live system ist sehr gefährlich, weil dies dazu führen kann, dass das System abstürzt. Erst wenn man einige Änderungen durchgefürt hat und diese funktionieren, am Besten testet man diese noch gründlich, kann man den Stand des Staging Systems auf das live System übertragen.
Zusätzlich kann man auch noch eine weitere OTOBO Instanz erstellen, welche man zum Testen unterschiedlicher Funktionen nutzen kann.
Um eine Test-Instanz mit dem Ticketsystem zu haben, muss man sich zuerst eine neuen Server hosten. Dabei sollte der Server möglichst Ähnliche Eigenschaften wie das Produktiv System haben. Also möglich gleich viel CPU, Speicherplatz und RAM. Damit es auch ein realistischer Test ist.
Alternativ können Sie je nachdem was für einen Hosting Anbieter haben, den Server per Kopf Druck klonen.
Achtung! Falls Sie EMails aus einem Postfach abholen müssen Sie beim Erstellen des Servers aufpassen, dass der Staging Server nicht die Mails abholt. Sonst versuchen beide Server die Emails abzuholen. Dies wird dazu führen, dass die Emails im schnelleren Server landen. Im worst-case landen manche Emails im Produktiv System und andere auf dem staging Server. Generell empfiehlt sich es daher bei IMAP das Postfach so zu konfigurieren, dass man ein weiteres Postfach hat in dem Kopien der Emails gespeichert werden.
Um den Fehler zu vermeiden können Sie vor dem Übertragen der Daten alle OTOBO Container löschen, danach alle Container aus den otobo_daemon Cntainer starten und daraufhin in den Systemkonfigurationen deen FetchMail CronJob dektivieren, danach otobo daemon starten. Dazu im folgenden mehr ...
Danach muss auf dem neuen Staging Server OTOBO Installiert werden, am Besten die Docker Variante. Diese sollte die selbe OTOBO Version nutzen wie das live System. Die Installations-Schritte werden ganz normal durchgeführt werden. Gerne können Sie unser OTOBO Installationsskript ausprobieren.
Es ist empfehlenswert ein Testsystem zu erstellen.
Für die OTOBO Installation benötigen wir einen Server. Haben Wir Bereits im vorherigem Schritt gehostet. Das heißt wir können jetzt mit der OTOBO Installation starten.
root> apt-get install git docker docker-compose
root> systemctl enable docker
Man braucht die Pakete um die OTOBO Docker Installation durchführen zu können.
Mit rel-10_1 wird die OTOBO Version 10.1 installiert.
docker_admin> cd /opt
docker_admin> git clone https://github.com/RotherOSS/otobo-docker.git --branch rel-10_1 --single-branch
docker_admin> ls otobo-docker # README.md sollte existieren
Es bietet sich an beim Erstellen eines Staging Servers die .env Datei System vom produktiv System zu kopieren. In ubuntu kann man die Datei mit dem "scp" Befehl kopieren. In der Konfigurationsdatei .env werden die Einstellungen gespeichert. Je nachdem, ob eine SSL Verschlüsselung benötigt wird oder nicht, muss zwischen der Datei .docker_compose_env_http und .docker_compose_env_https entschieden werden. Eine SSL Verschlüsselung führt dazu ,dass sie das https Protokoll verwenden können. Im Gegensatz zum HTTP Protokoll wird bei HTTPS die gesamte Kommunikation verschlüsselt, sodass keine Nachrichten von dritten mitgelesen können. Das ist vor allem bei sensiblen Daten wichtig, wie Passwörter, Zahlungsinformationen, persönliche Daten.
docker_admin> cd /opt/otobo-docker
docker_admin> cp -p .docker_compose_env_https .env # für HTTP .docker_compose_env_http
Danach müssen Sie ein SSL Zertifikat angeben, welches signiert werden muss um gültig zu sein. Dabei gibt es unterschiedliche Anbieter bei welchen man sein Zertifikat verschlüsseln lassen kann. Zum Beispiel bei Lets Encrypt https://letsencrypt.org/.
Danach müssen Sie Die Datei mit Ihrem signierten Zertifikat auf den Server hochladen, dazu bspw. putty oder WinScp verwende(oder irgendein anderes Programm mit welchem Sie Zugriff auf die Dateien Ihres Servers haben). Nun müssen Sie in der .env Datei den Pfad zu Ihrem Zertifikat angeben.
Falls die .env Datei vom Produktiv System kopiert wurde muss das root Passwort nicht mehr geändert werden, es ist das selbe.
Ansonsten ändere das Datenbank root Passwort in der .env Datei.
OTOBO_DB_ROOT_PASSWORD=<Dein_Passwort>
Das Passwort kann frei gewählt werden. Um die .env Datei zu bearbeiten kannst du folgenden Befehl verwenden:
nano .env
Mit nano kannst du ganz simpel Dateien bearbeiten, du kannst aber natürlich ein beliebiges Tool nutzen um das Datenbank Passwort zu ändern. Das festgelegte Passwort, kann im nachhinein noch verändert werden, sollte aber logischerweise ein gutes Passwort sein. Mit diesem Datenbank Zugang kann man alle Daten des Ticketsystems löschen! Gerne können Sie sich das Passwort aufschreiben, Sie können es aber auch immer wieder anschauen in dem Sie die .env Datei öffnen.
nginx erfordert für die SSL-Verschlüsselung ein Zertifikat sowie einen privaten Schlüssel.
Für Testzwecke und beim Entwickeln kann ein selbst signiertes Zertifikat verwendet werden. Grundsätzlich sind jedoch offizielle Zertifikate erforderlich. Mehr dazu, wie Sie ein selbst signiertes Zertifikat erstellen, erfahren Sie z. B. unter https://www.digitalocean.com/community/tutorials/how-to-create-a-self-signed-ssl-certificate-for-nginx-in-ubuntu-18-04.
Um in nginx eine CA-Chain zusammen mit einem Zertifikat anzugeben, muss das CA-Chain-File mit dem eigentlichen Zertifikat in eine Datei kopiert werden. Das Zertifikat und der private Schlüssel werden in einem Volume hinterlegt, um später von nginx verwendet werden zu können. Legen Sie zunächst das Volume an und kopieren Sie anschließend Zertifikat und Schlüssel hinein:
docker_admin> docker volume create otobo_nginx_ssl
docker_admin> otobo_nginx_ssl_mp=$(docker volume inspect --format '{{ .Mountpoint }}' otobo_nginx_ssl)
docker_admin> echo $otobo_nginx_ssl_mp # just a sanity check
docker_admin> cp /PathToYourSSLCert/ssl-cert.crt /PathToYourSSLCert/ssl-key.key $otobo_nginx_ssl_mp
Die Namen der kopierten Dateien müssen in die eben angelegte .env-Datei eingegeben werden. Beispiel:
OTOBO_NGINX_SSL_CERTIFICATE=/etc/nginx/ssl/ssl-cert.crt und OTOBO_NGINX_SSL_CERTIFICATE_KEY=/etc/nginx/ssl/ssl-key.key
Bitte passen Sie nur die Dateinamen an. Der Pfad /etc/nginx/ssl/ ist im Docker Image festgeschrieben.
Jetzt starten wir die Docker Container mit docker-compose. An der Stelle aufpassen, wegen der Email abholung. Nachdem Sie den Befehl ausführen wird der Staging Server die Emails aus em Postfach holen.
docker_admin> docker-compose up --detach
Danch können Sie mit dem Befehl:
docker ps
alle laufenden Docker Container anschauen, es sollten Ihnen die 5(bzw. 6 bei SSL Verschlüsselung) Container angezeigt werden. Diese sind:
Um einzelne Container zu starten, können Sie den Befehl:
docker start <container_name>
Genauso um einzelne container zu stoppen:
docker stop <container_name>
Wenn Sie alle Container stoppen möchten können Sie aus dem Ordner /opt/otobo-docker(ist der Standard Installations Ordner, kann je nach Konfiguration auch ein anderer sein) den Befehl
docker-compose down
Um das System neu zu starten und damit auch alle docker container neu zu starten, ist der Befehl
reboot
sinnvoll.
Führe den OTOBO Installer aus, indem du http://{yourIPorFQDN}/otobo/installer.pl aufrufst.
Folge den Schritten im Installer. Dort kannst du einige wichtige Einstellungen setzen, wie die Email Konfiguration und Ähnliches. All diese Konfigurationen kannst du auch überspringen und dann noch danach ändern.
Wenn nachdem Datenbank Passwort gefragt wird, gebe das in der .env Datei angegebene root Passwort an. Es ist das selbe Passwort wie im Produktiv-System. Jetzt ist die OTOBO Docker Installation abgeschlossen.
OTOBO Docker Installationsskript
Wenn Sie nun OTOBO erfolgreich installiert haben, müssen Sie jetzt noch den aktuellen Stand des live Systems übertragen. Dafür ist der einfachste Trick alle Daten der Docker Volumes zu übertragen. Mit folgendem Befehlen ist das möglich. Um mit dem scp Befehl Daten von einem anderen System zu kopieren, wird ein Zugang benötigt. Also zum Beispiel über ssh. Falls man noch kein Key-Pair hat muss man auf dem neuem System einen SSH Key generieren. Auf dem alten System muss der public key des neuen Systems in die Datei .ssh/authorized_keys hinzugefügt werden.
Welche wichtigen docker Befehle gibt es ?
Aufpassen falls die Email Abholung eingerichtet ist, nicht den Docker Container des Daemons starten. Nachdem alle Container außer dem Daemon gestartet sind, ist die Web-Oberfläsche trotzdem erreichbar.
Folgende Systemkonfigurationen Deaktivieren:
Daemon::SchedulerCronTaskManager::Task###FetchMail
Daemon::SchedulerCronTaskManager::Task###FetchMailSSL
Daemon::SchedulerCronTaskManager::Task###MailAccountFetch
falls auch keine Mals gesendet werden sollen:
Daemon::SchedulerCronTaskManager::Task###MailQueueSend
Über scp kann man alle volumes aus dem live Server auf den Staging Server übertragen. Dies sollte bereits ausreichen um den kompletten Stand zu übertragen. Man kann auch per Cronjob einstellen, dass dieses Skript in regelmäßigen Abständen ausgeführt wird. Somit man immer eine aktuelle Version zum Testen hat.
Nachdem die Volumes übertragen sind, kann es helfen das System neu zu starten, mit dem Befehl reboot .
Damit die neusten Änderungen in Kraft treten kann es sinnvoll sein den Cache zu löschen. Dafür muss man einen Befehl im Terminal des Servers eingeben.
Cronjob erstellen
Wenn man den Server täglich auf den aktuellen Stand bringen will, dann kann man dafür Cronjobs verwenden. Um einen neuen Cronjob zu erstellen muss man den Befehl:
> crontab -e
In diese Datei kann man eine neue Zeile einfügen. Die Syntax funktioniert folgendermaßen:
min hour day month weekday BEFEHL
Wenn man einen * angibt wird es jedes mal ausgeführt. Beispielsweise würde * * * * * jede Minute ausgeführt werden, * /2 * * * alle 2 Stunden, 20 10 /3 * * alle 3 Tage um 10:20.
Nachdem man einige Dinge getestet hat, dann häufen sich möglicherweise Tickets an. Über den Generic Agent kann man diese alle auf einmal entfernen. Im Admin Bereich -> Generic Agent : kann man einen neuen Auftrag erstellen. Dabei muss man Selektions kriterien angeben, zum Beispiel alle neuen Tickets, oder alle die "Test" im Betreff stehen haben.
Der Generic Agent kann über das Admin Portal ausgewählt werden.
Danach auf "Auftrag hinzufügen" klicken:
Nun muss man einen Namen für den Auftrag einfügen, zum Beispiel "Löschen aller Tickets". Jetzt müssen wir bei Tickets selektieren eine Bedingung angeben, Ticket erstellt innerhalb des letzten Jahres
Bei Tickets-Befehle ausführen Ticket-Löschen auf Ja stellen. Danach Speichern, nun sollte in der Übersicht der neue Auftrag angezeigt werden. Um alle Tickets zu löschen auf "Diesen Auftrag ausführen" klicken.
Falls Sie aus der Kommandozeile alle Tickets löschen wollen, können Sie dies auch per SQL Anfragen erledigen.
Ein sehr einfacher Weg viele Einstellungen von einem OTOBO-System zu einem anderen zu übertragen ist das übertragen der Systemkonfigurationen.
Sehr viele Anpassungen des OTOBO Ticketsystems werden durch die Systemkonfiguration umgesetzt. Für die Systemkonfigurationen gibt es eine Import, Export Funktion. Somit ist es also sehr einfach Konfigurationen von der einen Instanz zur anderen zu übertragen.
Wenn man nun einige Änderungen auf dem Staging System getätigt hat und man diese dann auf das live System übertragen will. Könnte man die docker volumes übertragen, damit würde man aber alle Ticket Daten auf dem Produktivsystem überschreiben. In dem Fall das man nur Systemkonfigurationen geändert hat, kann man ganz einfach die Import / Exportfunktion nutzen.
Eine weitere Möglichkeit Daten von dem live System zum Staging System zu bringen, besteht darin die Daten über die Datenbank zu übertragen. Dies funktioniert beispielsweise mit den mysqldump Befehlen. Der mysqldump ist ein Backup der mysql Datenbank. Die Datei enthält alle Daten aus der Datenbank.
Beim Übertragen von Tabellen oder sogar von allen Datenbank Tabellen wird nicht alles übertragen. Sehr viele Einstellungen des Ticketsystems befindet sich in Dateien.
Um ein Backup zu erstellen oder die OTOBO Daten auf den Staging Server zu übertragen bietet es sich an mysqldump Dateien zu erstellen.
Die Tickets werden in der Datei /home/tickets.sql gespeichert. Host user und Password aus dem Befehl müssen natürlich noch angepasst werden.
Falls man die Daten aus der MySQLDump Datei importieren will, kann man dies mit folgendem Befehl.
Daraufhin ist das Backup wieder hergestellt.
Auf System 1 mit Mysql Dump alle Tickets herunterladen in tickets.sql.Die Datei tickets.sql auf das System 2 hochladen. Auf System 2 Tickets aus tickets.sql laden
Wir helfen Ihnen gerne bei Fragen und Problemen. Als Berater bieten wir Dienstleistungen für OTOBO an.
Wir beraten dich zum Thema OTOBO!