ubuntuusers.de

Nginx Config nach Apache2 Config "übersetzen"

Status: Ungelöst | Ubuntu-Version: Server 22.04 (Jammy Jellyfish)
Antworten |

crazy-to-bike

Avatar von crazy-to-bike

Anmeldungsdatum:
11. Oktober 2009

Beiträge: 291

Hallo,

ich nutze auf dem Server schon immer Apache2 und betreibe damit auch erfolgreich Docker-Anwendungen mit Reverse Proxy.

Nun will ich Firefish in Docker nutzen. Die Container laufen, ich bekomme aber über Apache2 mit all meinen üblichen Reverse Proxy Configs für Collabora, Mastodon usw. keine Verbindung, sondern einen 502 Error.

[proxy_http:error] [pid 167113] (104)Connection reset by peer: [client <ip>:45598] AH01102: error reading status line from remote server 127.0.0.1:3020
[proxy:error] [pid 167113] [client <ip>:45598] AH00898: Error reading from remote server returned by /inbox

Firefish stellt imho keine komplette Apache Config zur Verfügung - zumindest klappt es damit auch nicht.

Nun würde ich gerne wissen, wie deren Nginx Config übersetzt in Apache2 aussehen müsste. Von Nginx habe ich absolut keinen Plan und einfach parallel betreiben geht imho eh nicht.

# Replace example.tld with your domain

# For WebSocket
map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

proxy_cache_path /tmp/nginx_cache levels=1:2 keys_zone=cache1:16m max_size=1g inactive=720m use_temp_path=off;

server {
    listen 80;
    listen [::]:80;
    server_name example.tld;

    # For SSL domain validation
    root /var/www/html;
    location /.well-known/acme-challenge/ { allow all; }
    location /.well-known/pki-validation/ { allow all; }
    location / { return 301 https://$server_name$request_uri; }
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.tld;

    ssl_session_timeout 1d;
    ssl_session_cache shared:ssl_session_cache:10m;
    ssl_session_tickets off;

    # To use Let's Encrypt certificate
    ssl_certificate     /etc/letsencrypt/live/example.tld/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.tld/privkey.pem;

    # To use Debian/Ubuntu's self-signed certificate (For testing or before issuing a certificate)
    #ssl_certificate     /etc/ssl/certs/ssl-cert-snakeoil.pem;
    #ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key;

    # SSL protocol settings
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;
    ssl_stapling on;
    ssl_stapling_verify on;

    # Change to your upload limit
    client_max_body_size 80m;

    # Proxy to Node
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_http_version 1.1;
        proxy_redirect off;

        # If it's behind another reverse proxy or CDN, remove the following.
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;

        # For WebSocket
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

        # Cache settings
        proxy_cache cache1;
        proxy_cache_lock on;
        proxy_cache_use_stale updating;
        add_header X-Cache $upstream_cache_status;
    }
}

encbladexp Team-Icon

Ehemaliger
Avatar von encbladexp

Anmeldungsdatum:
16. Februar 2007

Beiträge: 17524

Kannst du uns erst den output von docker container ls geben?

Weil wir wollen ja erstmal verstehen was wo läuft. Ein HTTP 502 ist ein Bad Gateway, d.h. es ist sehr wahrscheinlich das du Traffic auf ein ungültiges Ziel schickst.

crazy-to-bike

(Themenstarter)
Avatar von crazy-to-bike

Anmeldungsdatum:
11. Oktober 2009

Beiträge: 291

Hi,

sorry für die späte Antwort. Habe die Mailbenachrichtigung entweder nicht bekommen oder übersehen.

Hier die Ausgabe für die betreffenden Container:

7b17429a76f5   registry.joinfirefish.org/firefish/firefish:beta-amd64   "/usr/bin/tini -- pn…"   2 days ago   Up 2 days (healthy)   127.0.0.1:3020->3000/tcp                    firefish_web_test
ef5d7784abab   redis:7.0-alpine                                         "docker-entrypoint.s…"   2 days ago   Up 2 days (healthy)   6379/tcp                                    firefish_redis_test
8ac991275ef2   postgres:12.2-alpine                                     "docker-entrypoint.s…"   2 days ago   Up 2 days (healthy)   5432/tcp                                    firefish_db_test
b361ba8881af   docker.io/kittysh/sonic:v1.4.0                           "/docker_init"           2 days ago   Up 2 days             1491/tcp                                    firefish_sonic_test

Statt Port 3000 wird, wie man sieht, für den Proxy Port 3020 verwendet und dann in der Dockerumgebung auf Port 3000 weitergeleitet.

Ich habe es aber auch mit 127.0.0.1:3000->3000/tcp probiert. Macht keinen Unterschied.

Die Apache-Config auf Git von Firefish:

<VirtualHost *:80>
    ServerName example.tld
    # For WebSocket
    ProxyPass "/streaming" "ws://127.0.0.1:3000/streaming/"
    # Proxy to Node
    ProxyPass        "/" "http://127.0.0.1:3000/"
    ProxyPassReverse "/" "http://127.0.0.1:3000/"
    ProxyPreserveHost On
    # For files proxy
    AllowEncodedSlashes On
</VirtualHost>

Da ist gar kein VirtualHost für 443 definiert und damit geht es auch nicht.

Meine eigene Apache-Config sieht so aus:

<VirtualHost *:80>
   ServerName firefish.crazy-to-bike.de
   Redirect Permanent / https://firefish.crazy-to-bike.de/
</VirtualHost>

<VirtualHost *:443>
   ServerName firefish.crazy-to-bike.de
   Protocols h2 h2c http/1.1
   DocumentRoot /var/www/public_html
   Header always set Referrer-Policy "same-origin"
   SSLEngine on
   SSLProtocol -all +TLSv1.2
   SSLHonorCipherOrder on
   SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM>
   ProxyPreserveHost On
   AllowEncodedSlashes On
   RequestHeader set X-Forwarded-Proto "https"
   ProxyPass /streaming/ ws://127.0.0.1:3020/
   ProxyPass / http://127.0.0.1:3020/
   ProxyPassReverse / http://127.0.0.1:3020/
   SSLCertificateFile /etc/letsencrypt/live/firefish.crazy-to-bike.de/fullchain.pem
   SSLCertificateKeyFile /etc/letsencrypt/live/firefish.crazy-to-bike.de/privkey.pem
   Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>

Ach ja, falls es verwundern sollte, dass firefish.crazy-to-bike.de erreichbar ist: Das ist eine andere Docker-Umgebung, die jemand für Firefish gebaut hat. Davon würde ich aber gerne weg, weil... hängt an einer Einzelperson.

encbladexp Team-Icon

Ehemaliger
Avatar von encbladexp

Anmeldungsdatum:
16. Februar 2007

Beiträge: 17524

   ProxyPass /streaming/ ws://127.0.0.1:3020/
   ProxyPass / http://127.0.0.1:3020/
   ProxyPassReverse / http://127.0.0.1:3020/

Ist korrekt, den du stellst den Dienst per Docker nur auf 3020 an localhost/127.0.0.1 bereit. Kannst du per curl/telnet testen ob da was erreichbar ist?

Was mir noch aufgefallen ist: Lass erstmal das Websocket Zeugs weg, das kannst du später hinzufügen, wichtiger wären das die X-Irgendwas Header gesetzt sind, dazu findest du Dokumentation in den Modulen mod_cache und mod_remoteip sowie mod_proxy. Prüfe auch ob der Container so etwas wie eine "Allowed Hosts" konfiguration hat, aber das siehst du auch mit curl/wget.

crazy-to-bike

(Themenstarter)
Avatar von crazy-to-bike

Anmeldungsdatum:
11. Oktober 2009

Beiträge: 291

Ich weiß jetzt nicht, ob du auf eine bestimmte Syntax von Curl / Telnet aus warst, aber

curl -v http://127.0.0.1:3020
*   Trying 127.0.0.1:3020...
* Connected to 127.0.0.1 (127.0.0.1) port 3020 (#0)
> GET / HTTP/1.1
> Host: 127.0.0.1:3020
> User-Agent: curl/7.81.0
> Accept: */*
> 
* Recv failure: Die Verbindung wurde vom Kommunikationspartner zurückgesetzt
* Closing connection 0
curl: (56) Recv failure: Die Verbindung wurde vom Kommunikationspartner zurückgesetzt

Websocket ist dabei auskommentiert und Apache neu gestartet.

Sind die X-Header nicht hierdurch gesetzt:

RequestHeader set X-Forwarded-Proto "https"

Das Ganze funktioniert zumindest bei den anderen Containern.

encbladexp Team-Icon

Ehemaliger
Avatar von encbladexp

Anmeldungsdatum:
16. Februar 2007

Beiträge: 17524

Das zeigt aber schon sein Problem: Auf Port 3020 läuft nichts, es ist ab jetzt vollkommen egal was du machst, aber so lange da nichts läuft wird der Apache auch nichts machen.

crazy-to-bike

(Themenstarter)
Avatar von crazy-to-bike

Anmeldungsdatum:
11. Oktober 2009

Beiträge: 291

Ich habe jetzt mal den Docker Container, der gemäß docker-compose.yml auf Port 3000 lauscht heruntergefahren und für die Firefish-Umgebung den Port in der docker-compose.yml auf 127.0.0.1:3000:3000 geändert, wie es beim Firefish-Git in der docker-compose.yml der Fall ist.

Firefish Docker neu gestartet. Selbes Ergebnis.

Das kann doch am Ende nur heißen, dass in deren Docker-Image / Umgebung aus den 4 Containern ganz grundsätzlich was falsch gebaut ist, oder?

encbladexp Team-Icon

Ehemaliger
Avatar von encbladexp

Anmeldungsdatum:
16. Februar 2007

Beiträge: 17524

Es bedeutet erstmal nur das auf Port 3000 nichts läuft. Welchen Port nutzt den das Docker Image intern, also der Dienst in dem Image?

crazy-to-bike

(Themenstarter)
Avatar von crazy-to-bike

Anmeldungsdatum:
11. Oktober 2009

Beiträge: 291

Laut docker-compose.yml, die von Firefish auf git veröffentlicht ist, Port 3000:

version: "3"

services:
  web:
    # Choose one of these tags:
    # stable-amd64, stable-arm64, beta-amd64, beta-arm64
    image: registry.joinfirefish.org/firefish/firefish:stable-amd64
    container_name: firefish_web
    restart: unless-stopped
    depends_on:
      - db
      - redis
### Uncomment one of the following to use a search engine
#     - meilisearch
#     - sonic
    ports:
      - "3000:3000"
    networks:
      - calcnet
#     - web
    environment:
      NODE_ENV: production
    volumes:
      - ./files:/firefish/files
      - ./.config:/firefish/.config:ro

  redis:
    restart: unless-stopped
    image: docker.io/redis:7.0-alpine
    container_name: firefish_redis
    networks:
      - calcnet
    volumes:
      - ./redis:/data

  db:
    restart: unless-stopped
    image: docker.io/postgres:12.2-alpine
    container_name: firefish_db
    networks:
      - calcnet
    env_file:
      - .config/docker.env
    volumes:
      - ./db:/var/lib/postgresql/data

### Only one of the below should be used.
### Meilisearch is better overall, but resource-intensive. Sonic is a very light full text search engine.

#  meilisearch:
#    container_name: meilisearch
#    image: getmeili/meilisearch:v1.1.1
#    environment:
#      - MEILI_ENV=${MEILI_ENV:-development}
#    ports:
#      - "7700:7700"
#    networks:
#      - calcnet
#    volumes:
#      - ./meili_data:/meili_data
#    restart: unless-stopped

  sonic:
    restart: unless-stopped
    image: docker.io/valeriansaliou/sonic:v1.4.0
    logging:
     driver: none
    networks:
      - calcnet
    volumes:
      - ./sonic:/var/lib/sonic/store
      - ./sonic/config.cfg:/etc/sonic.cfg

networks:
  calcnet:
  #  web:
  #    external:
  #      name: web

encbladexp Team-Icon

Ehemaliger
Avatar von encbladexp

Anmeldungsdatum:
16. Februar 2007

Beiträge: 17524

Das Image ist echt groß:

REPOSITORY                                    TAG            IMAGE ID       CREATED       SIZE
registry.joinfirefish.org/firefish/firefish   stable-amd64   5898dc16ff39   12 days ago   2.37GB

Leider hat der Entwickler wohl keine Lust gehabt im Dockerfile zu hinterlegen welche Ports gebraucht werden, so muss man raten ob das Compose file passt (tut es vermutlich). Du solltest dir mal die Logfiles vom Container anschauen, eventuell siehst du da was. Generell: So lange dir curl nicht brauchbar antwortet, kannst du dir Arbeit am Apache sparen.

Antworten |