ngix 500 error

[schealex]

Hi

i'm trying to use your docker image but i'm always getting a 500 from ngix when i try to access the url of the installation. Any steps i'm missing?

Regards

[tiredofit]

Have a peek at the logs in /www/logs/nginx/error.log and it should give a reason as to why its failing..

[schealex]

not really. the log folder does contain logs but they are all empty.

when i check my ngix reverse proxy i see this:

7.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36" xxx.xxx.de x.x.121.111 - - [04/Sep/2020:14:17:24 +0000] "GET / HTTP/2.0" 500 595 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36"

[tiredofit]

Unfortunately the reverse proxy won't tell what script or file is failing yet only pass the 500 value. 50x errors typically relate to something related to the PHP-FPM implementation - either it's misconfigured, or is failing on a specific file. Perhaps access.log might give some tips as well.

Otherwise, are you able to share the way you are starting the image? Strip of course any domain names/credentials..

[schealex]

acceess.log is also empty

I'm also using jrcs/letsencrypt-nginx-proxy-companion for my ngix and proxy setup. for me it seems like the container is not accepting any connections \o/

this is my compose file:

version: '3.3'
services:

  osticket-app:
    image: tiredofit/osticket
    container_name: osticket-app
    volumes:
      - /data/osticket/data/:/www/osticket
      - /data/osticket/logs/:/www/logs
    environment:
      - ZABBIX_HOSTNAME=osticket-app

      - CRON_PERIOD=10

      - DB_HOST=osticket-db
      - DB_NAME=osticket
      - DB_USER=osticket
      - DB_PASS=xxx

      - SMTP_HOST=mail.xxx.de
      - SMTP_PORT=25
      - SMTP_FROM=tickets@xxx.de
      - SMTP_TLS=0
      - SMTP_USER=tickets@xxx.de
      - SMTP_PASS=xxx

      - INSTALL_SECRET=xxx
      - INSTALL_EMAIL=tickets@xxx.de
      - INSTALL_NAME=Helpdesk

      - ADMIN_FIRSTNAME=x
      - ADMIN_LASTNAME=x
      - ADMIN_EMAIL=x@xxx.de
      - ADMIN_USER=x
      - ADMIN_PASS=xxx

      - VIRTUAL_HOST=tickets.xxx.de
      - LETSENCRYPT_HOST=tickets.xxx.de
      - LETSENCRYPT_EMAIL=hostmaster@xxx.de
    networks:
      - nginx-proxy
      - services
    restart: always

  osticket-db:
    image: tiredofit/mariadb
    container_name: osticket-db
    volumes:
      - /data/osticket/db/osticket:/var/lib/mysql
    environment:
      - ROOT_PASS=xxx
      - DB_NAME=osticket
      - DB_USER=osticket
      - DB_PASS=xxx

      - ZABBIX_HOSTNAME=osticket-db
    networks:
      - services
    restart: always

  osticket-db-backup:
    container_name: osticket-db-backup
    image: tiredofit/mariadb-backup
    links:
      - osticket-db
    volumes:
      - /data/osticket/dbbackup:/backup
    environment:
      - DB_HOST=osticket-db
      - DB_TYPE=mariadb
      - DB_NAME=osticket
      - DB_USER=osticket
      - DB_PASSWORD=xxx
      - DB_DUMP_FREQ=1440
      - DB_DUMP_BEGIN=0000
      - DB_CLEANUP_TIME=8640
      - COMPRESSION=BZ
    networks:
      - services
    restart: always

networks:
  nginx-proxy:
    external: true
  services:
    external: true

[tiredofit]

OK, I'm familiar with the proxy - used it for many years before Traefik.

Let's verify a few things:

docker exec -it osticket-app - enter curl http://localhost and see what response you get. We are making sure the web server is responding. Also echo "<?php phpinfo();?> >> /www/osticket/phpinfo.php and echo "Working" >> /www/osticket/test.html .

You should be able to do the following:

• curl http://localhost/phpinfo.php
• curl http://localhost/test.html

Both with responses from inside the container.

Then lets switch over to your nginx proxy container.. docker exec -it ... sh

First try to ping osticket-app you should get valid responses. Then lets try again curl http://osticket-app/test.html curl http://osticket-app/phpinfo.php to verify that we can access from the proxy the container and its content.

If all else fails - I think we could try adding VIRTUAL_PORT=80 to your environment variables in osticket-app. I may have written things in shorthand where my own systems were hardcoded by default to accept that sort of mapping without the need to explicitly declare it across a couple hundred containers...

[schealex]

curl is giving me a the login site. so there is defenetly something wrong with the connection from proxy to osticket-app. Thats good news.

sadly the proxy does not have curl or ping commands :/

I tried adding the virtual port but no change. I also tried and expose of ports 80 and 443 without success

[schealex]

It does seem like there is a problem generating the certificate for that domain:

Creating/renewal tickets.xxx.de certificates... (tickets.xxx.de) ACME server returned an error: urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Error creating new authz :: Validations for new domains are disabled in the V1 API (https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430)

but that should not stop it from making a connection :/

[tiredofit]

Not sure if its under alpine or debian that image, I see two Dockerfiles in the nginx-proxy repo.

Alpine:

apk update
apk add curl iputils

Debian:

apt-get update
apt-get install -y curl iputils-ping

[schealex]

that worked perfektly and from the proxy both is working. I'm getting a ping back and curl is receiving the login page

very strange

[schealex]

this is the generated part in the default.conf for the subdomain

# tickets.xxx.de
upstream tickets.xxx.de {
                ## Can be connected with "nginx-proxy" network
            # osticket-app
            server x.x.0.10:80;
                # Cannot connect to network of this container
                server 127.0.0.1 down;
}
server {
    server_name tickets.xxx.de;
    listen 80 ;
    access_log /var/log/nginx/access.log vhost;
    include /etc/nginx/vhost.d/tickets.xxx.de;
    location / {
        proxy_pass http://tickets.xxx.de;
    }
}
server {
    server_name tickets.xxx.de;
    listen 443 ssl http2 ;
    access_log /var/log/nginx/access.log vhost;
    return 500;
    ssl_certificate /etc/nginx/certs/default.crt;
    ssl_certificate_key /etc/nginx/certs/default.key;
}

this seems not to be right imho

[tiredofit]

Right, that's interesting with the return 500 value in there. Something a bit screwy on the proxy front. Are you able to run other virtual domains against this proxy with success?

[schealex]

yes all other domains are running fine. and they are all subdomains of the same top level domain. I would try to update the proxies image do i just need to remove and recreate the container for that?

[tiredofit]

Should just be able to do a docker pull jwilder/nginx-proxy and whatever else you have or docker-compose pull in the directory where the proxy stack is and restart the containers... The Letsencrypt issue is troubling however. I think they have switched to using ACME v2 which may be causing that strange 500 error.

[schealex]

yep. that did the trick. just updating the image resolved it! Thanks for your time and for the images ;)

[tiredofit]

Nice! Enjoy.