[Toni Kenzig]

Hi,

meine Migration von OTRS6 zu OTOBO ist ja erfolgreich verlaufen. Jetzt läuft das System ein paar Tage und nun wollte ich gern HTTPS aktivieren.

Ich habe dafür:
https://doc.otobo.org/manual/installation/10.1/de/content/installation-docker.html

– .env-Datei überschrieben (Punkt 2)
– SSL-Konfiguration NGINX (Punkt 4)
– CERTBOT installiert nach Anleitung (https://www.veuhoff.net/ssl-zertifikat-installieren-mit-certbot-und-lets-encrypt/)

Im Anschluss habe ich „sudo reboot“ gemacht und nach dem Neustart erhalte ich im Browser (egal ob http oder https):

„404 not found – NGINX“

Kann mir dazu jemand vielleicht helfen?

[bes]

Hallo Toni,

der erste Check wäre ob die Container laufen:

docker-compose ps

Sind die Services otobo_db_1, otobo_elastic_1, otobe_nginx_1, otobo_redis_1 und otobo_web_1  aktiv und haben sie den Status healthy?

Viele Grüße,

Bernhard

 

[Toni Kenzig]

Hi, hier die Antwort:
otobo@ticket:/opt/otobo-docker$ sudo docker-compose ps
Name Command State Ports
————————————————————————————
otobo_daemon_1 /opt/otobo_install/entrypo … Up (healthy)
otobo_db_1 docker-entrypoint.sh –max … Up (healthy) 3306/tcp
otobo_elastic_1 /bin/tini — /usr/local/bi … Up (healthy) 9200/tcp, 9300/tcp
otobo_redis_1 docker-entrypoint.sh redis … Up (healthy) 6379/tcp
otobo_web_1 /opt/otobo_install/entrypo … Exit 128

[bes]

Hallo Toni,

otobo_web_1 ist der Container der tatsächlich das HTML ausliefert. otobo_nginx_1 kümmert sich nur um HTTPS. Dass der Webserver nicht läuft erklärt jedenfalls den Fehler 404.

Der nächste Schritt ist es otobo_web_1 zum Laufen zu bringen.  Zur analyse kann man einfach neu starten mit docker-compose up 2>&1 | tee compose_up.log . In der Logdatei sollte dann eine Logeintrag zu finden sein, der erklärt warum der Webserver nicht läuft.

Viele Grüße,

Bernhard

 

[Toni Kenzig]

Das sieht jetzt noch so gut aus:

otobo@ticket:/opt/otobo-docker$ sudo docker-compose up 2>&1 | tee compose_up.log
tee: compose_up.log: Permission denied
The NGINX_ENVSUBST_TEMPLATE_DIR variable is not set. Defaulting to a blank string.
Pulling nginx (rotheross/otobo-nginx-webproxy:latest-10_0)…
latest-10_0: Pulling from rotheross/otobo-nginx-webproxy
Digest: sha256:cec438c8c8a52a18affb91119019196e37b983ef972f2b493bf5e6a94a4fae0f
Status: Downloaded newer image for rotheross/otobo-nginx-webproxy:latest-10_0
otobo_elastic_1 is up-to-date
otobo_redis_1 is up-to-date
otobo_db_1 is up-to-date
Recreating otobo_web_1 … done
otobo_daemon_1 is up-to-date
Creating otobo_nginx_1 …
Creating otobo_nginx_1 … error

ERROR: for otobo_nginx_1 Cannot start service nginx: driver failed programming external connectivity on endpoint otobo_nginx_1 (a65f0aba6ad94753c370115dbd9bfb0d4decbf9aa8907bb4bf112e26f98db797): Error starting userland proxy: listen tcp4 0.0.0.0:80: bind: address already in use

ERROR: for nginx Cannot start service nginx: driver failed programming external connectivity on endpoint otobo_nginx_1 (a65f0aba6ad94753c370115dbd9bfb0d4decbf9aa8907bb4bf112e26f98db797): Error starting userland proxy: listen tcp4 0.0.0.0:80: bind: address already in use
Encountered errors while bringing up the project.

[Toni Kenzig]

Ich habe mal ein sudo docker-compose ps abgesetzt:

otobo@ticket:/opt/otobo-docker$ sudo docker-compose ps
Name Command State Ports
———————————————————————————————
otobo_daemon_1 /opt/otobo_install/entrypo … Up (health: starting)
otobo_db_1 docker-entrypoint.sh –max … Up (health: starting) 3306/tcp
otobo_elastic_1 /bin/tini — /usr/local/bi … Up (health: starting) 9200/tcp, 9300/tcp
otobo_nginx_1 /docker-entrypoint.sh ngin … Exit 128
otobo_redis_1 docker-entrypoint.sh redis … Up (health: starting) 6379/tcp
otobo_web_1 /opt/otobo_install/entrypo … Up (health: starting)

[bes]

Hallo,

dass otobo_nginx:1 sich über den Port 80 beschwert ist etwas ungewöhnlich. Ist eventuell in .env die Variable OTOBO_WEB_HTTPS_PORT gesetzt? Wenn ja, dann muss diese Variable auskommentiert werden, damit der Default-Port 443 verwenndet wird.

Viele Grüße,

Bernhard

[Stefan Rother]

Hi,

irgendwas läuft schon auf Port 80 bei Dir. Hast Du auf dem Server noch einen anderen Webserver?
0.0.0.0:80: bind: address already in use

Schöne Grüße,

Stefan
Team OTOBO

[Toni Kenzig]

Hi,

auf der virtuelle Maschine läuft nichts weiter. Die habe ich vor kurzem erst installiert für Otobo. Wie können wir herausfinden, was es ist?

[Stefan Rother]

Hi,

führe mal

root> netstat -tulpen

aus, dann siehst Du was da läuft. Entweder es läuft noch ein anderer Container (vielleicht gestartet mit einem anderen User?) oder ein anderer Webserver.

@Bernhard: Ich glaube Du verwechselst das mit dem anderen Foreneintrag, kann das sein? Der NGINX braucht doch immer 80 und 443?

Schöne Grüße,

Stefan

[bes]

@Bernhard: Ich glaube Du verwechselst das mit dem anderen Foreneintrag, kann das sein? Der NGINX braucht doch immer 80 und 443?

Ah, das hatte ich ja selbst eingebaut. Nginx macht ja für Anfragen auf Port 80 den Redirect auf Port 443.

Wenn der Port 80 auf dem Docker Host belegt ist, dann kann man auch ausweichen. Das geht dann wieder über die .env Datei.

# HTTP options
# In the HTTPS case http:// redirects to https://
# Set OTOBO_WEB_HTTP_PORT when the HTTP port is not 80
OTOBO_WEB_HTTP_PORT=81

 

 

[Toni Kenzig]

otobo@ticket:/etc/nginx/sites-enabled$ sudo netstat -tulpen
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 0 26552 812/nginx: master p
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 26588 774/sshd: /usr/sbin
tcp 0 0 127.0.0.1:46121 0.0.0.0:* LISTEN 0 28062 737/containerd
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 101 22584 638/systemd-resolve
tcp6 0 0 :::80 :::* LISTEN 0 26553 812/nginx: master p
tcp6 0 0 :::22 :::* LISTEN 0 26590 774/sshd: /usr/sbin
udp 0 0 127.0.0.53:53 0.0.0.0:* 101 22583 638/systemd-resolve
udp 0 0 10.10.250.5:68 0.0.0.0:* 100 22587 635/systemd-network
udp 0 0 127.0.0.1:323 0.0.0.0:* 0 23257 696/chronyd
udp6 0 0 ::1:323 :::* 0 23258 696/chronyd

[Stefan Rother]

Hallo Toni,

Da hast Du die Lösung;
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 0 26552 812/nginx: master p

Es läuft ein NGINX auf Port 80 auf dem Server. Stoppen und OTOBO wird starten.

Schöne Grüße,

Stefan

[Toni Kenzig]

Hi, sorry das die Antwort so lang gedauert hat.

Vielen Dank im Übrigen für Eure Hilfe schon mal!

Ich habe NGINX mit sudo systemctl nginx stop beendet, richtig? Otobo gestartet habe ich im Verzeichnis /opt/otobo-docker mit sudo docker-compose up?

Wieso muss ich den NGINX eigentlich stoppen? Benötige ich den nicht für den HTTPS-Aufruf von Otobo?

[Toni Kenzig]

Ich korrigiere:

sudo docker-compose up –detach (zum Starten):

otobo@ticket:/opt/otobo-docker$ sudo docker-compose up –detach
WARNING: The NGINX_ENVSUBST_TEMPLATE_DIR variable is not set. Defaulting to a blank string.
Starting otobo_redis_1 … done
Starting otobo_db_1 … done
Starting otobo_elastic_1 … done
Starting otobo_web_1 … done
Starting otobo_daemon_1 … done
Starting otobo_nginx_1 … done

otobo@ticket:/opt/otobo-docker$ sudo docker-compose ps
Name Command State Ports
————————————————————————————
otobo_daemon_1 /opt/otobo_install/entrypo … Up (healthy)
otobo_db_1 docker-entrypoint.sh –max … Up (healthy) 3306/tcp
otobo_elastic_1 /bin/tini — /usr/local/bi … Up (healthy) 9200/tcp, 9300/tcp
otobo_nginx_1 /docker-entrypoint.sh ngin … Restarting
otobo_redis_1 docker-entrypoint.sh redis … Up (healthy) 6379/tcp
otobo_web_1 /opt/otobo_install/entrypo … Up (healthy)

otobo@ticket:/opt/otobo-docker$ sudo netstat -tulpen
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 101 22352 640/systemd-resolve
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 25235 819/sshd: /usr/sbin
tcp 0 0 127.0.0.1:45383 0.0.0.0:* LISTEN 0 27494 739/containerd
tcp6 0 0 :::22 :::* LISTEN 0 25237 819/sshd: /usr/sbin
udp 0 0 127.0.0.53:53 0.0.0.0:* 101 22351 640/systemd-resolve
udp 0 0 10.10.250.5:68 0.0.0.0:* 100 22539 637/systemd-network
udp 0 0 127.0.0.1:323 0.0.0.0:* 0 24322 715/chronyd
udp6 0 0 ::1:323 :::* 0 24323 715/chronyd

Ich habe in etc/nginx/sites-enabled/default die Datei „default“ bearbeitet. Den Port 80 habe ich auskommentiert. Die Kommentierung von Port 443 aktiviert:

server {
#listen 80 default_server;
#listen [::]:80 default_server;

# SSL configuration
#
listen 443 ssl default_server;
listen [::]:443 ssl default_server;

[Toni Kenzig]

Aktueller Stand:

• docker-compose ps: otobo_nginx_1 steht im Status: Restarting
• sudo docker-compose logs nginx zeigt: (in etwa): failed(SSL:error:02001002:system library:fopen:
  No such file or directory:fopen(‚/etc/nginx/cert.pem‘,’r‘)
  error:2006D080:BIO routines:BIO_new_file:no such file)

Ich habe NGINX erstmal de- und re-installiert; die .env (https) gegen eine .http getauscht und kann das System erstmal benutzen. Allerdings noch HTTPS.

[Toni Kenzig]

OK – geschafft!

Da ich in einigen Foren immer Beiträge ohne Lösung sehe (obwohl der TE meist zum Schluss schreibt: „ich habs hin bekommen“ aber nicht verrät wie), hier meine Lösung:

Der Zertifikatsfehler „…no such file…“ bedeutet: dein Docker-Volume beinhaltet nichts.
Ich habe das Docker-Volume mittels ’sudo docker volume otobo_nginx_ssl‘ gelöscht. Danach habe ich die folgenden Befehle lt. Anleitung abgearbeitet:
sudo docker volume create otobo_nginx_ssl
otobo_nginx_ssl_mp=$(docker volume inspect –format ‚{{ .Mountpoint }}‘ otobo_nginx_ssl)
sudo cp /PathToYourSSLCert/ssl-cert.crt /PathToYourSSLCert/ssl-key.key $otobo_nginx_ssl_mp

Wichtig: der zweite Befehl muss ohne sudo ausgeführt werden, ansonsten funktioniert er nicht.

Im Anschluss habe ich mit ’sudo docker-compose up –detach‘ den Container gestartet und siehe – es läuft!

Auch wenn das ich den Fehler letztlich allein lösen konnte: vielen Dank an die Unterstützer – macht weiter so!

[Toni Kenzig]

Befehslkorrektur: otobo_nginx_ssl_mp=$(docker volume inspect –format ‚{{ .Mountpoint }}‘ otobo_nginx_ssl)

Die ‚ sind immer oben.

[Autor]

Beiträge