[offtopic] Docker Ports werden doppelt frei gegeben

[bugster_de]

Hi,

da sich hier im Forum ja Leute mit viel Know-How sind frage ich mal hier nach, da ich keine taugliche Antwort auf meine Frage finden konnte.

Ich möchte auf meinem Ubuntu Server einen Assetto Corsa Competizione (ACC) Server in einem Docker Image laufen lassen. Leider kann er sich nicht mit dem Backend bei ACC, verbinden. Mittels docker ps bekomme ich das hier:

Code: [Auswählen]

CONTAINER ID   IMAGE         COMMAND                CREATED         STATUS         PORTS                                                                                  NAMES
1c9f8f4427ce   acc_acc-gt3   "wine accServer.exe"   5 seconds ago   Up 2 seconds   0.0.0.0:9320->9320/tcp, :::9320->9320/tcp, 0.0.0.0:9330->9330/udp, :::9330->9330/udp   acc-GT3

Da der Server es nicht schafft zum Backend sich zu connecten vermute ich mal, dass irgendwas bei der Port-Öffnung am Container nicht passt, denn was mich stört ist das hier:

Code: [Auswählen]

0.0.0.0:9320->9320/tcp, :::9320->9320/tcpHier wird der Port zweimal genutzt. Bei all meinen anderen Containern ist das nicht der Fall, da würde dann z.B. nur

Code: [Auswählen]

0.0.0.0:9320->9320/tcp stehen
Wenn ich den ACC Server auf einer Windows Maschine starte geht alles, was mir zeigt, dass meine Port Weiterleitung am Router schon richtig ist.

Mein docker-compose.yml sieht wie folgt aus:

Code: [Auswählen]

version: '3.4'
services:
# ======================================================================
#  Nuerburgring GT3
# ======================================================================
  acc-gt3:
    build: .
    restart: unless-stopped
    network_mode: "bridge"
    ports:
       - "9320:9320"
       - "9330:9330/udp"
    volumes:
       - "/mount/int/docker/0_Appconfig/acc/server1/:/opt/server/cfg"
       - "/mount/int/docker/1_Appdata/acc/server1/results/:/opt/server/results"
       - "/mount/int/docker/1_Appdata/acc/server1/log/:/opt/server/log"
    container_name: acc-GT3

Das zugehörige Dockerfile wie folgt

Code: [Auswählen]

FROM ubuntu:20.04

RUN dpkg --add-architecture i386 && \
    apt-get update && \
    DEBIAN_FRONTEND=noninteractive apt-get install -y wine-development && \
    apt-get clean  && \
    rm -rf /var/lib/apt/lists/* && \
    mkdir -p /opt/server/cfg && \
    mkdir -p /opt/server/log && \
    mkdir -p /opt/server/data

ENV WINEARCH=win64 \
    WINEDEBUG=-all

RUN wineboot --init

COPY files/accServer.exe /opt/server/

VOLUME /opt/server/cfg
VOLUME /opt/server/log
VOLUME /opt/server/data
WORKDIR /opt/server/

CMD ["wine", "accServer.exe"]

Kann mir bitte jemand einen Schubser geben, denn ich stehe auf dem Schlauch?

P.S.: bevor jemand frägt: ja ich habe das Spiel gekauft und besitze die Lizenz.

[Otto123]

Hi,

das mit den Ports sieht eigentlich gut aus, der zweite Eintrag ist die Bindung an ipv6 der erste an ipv4.

Zum Rest kann ich nichts sagen 

Gruß Otto

[bugster_de]

...der zweite Eintrag ist die Bindung an ipv6 der erste an ipv4.

Servus,

Danke. IPV6 wusste ich nicht. Komisch dass meine anderen Container das nicht machen und dort habe ich nichts anders konfiguriert.

[Otto123]

Deine Aussage verstehe ich so: der Server kommt nicht raus. Die Ports sind doch für "es kommt einer rein"
Macht Windows hier per upnp irgendwelche Dinge um sich mit dem Server außerhalb zu verbinden (oder wurde dort die Firewall anders konfiguriert) und Dein Linux Server verhindert genau dies?

Ich habe wegen meiner schlampigen ipv6 Konfiguration immer mal den Fall das mein vpn Client ipv6 nimmt um sich nach draußen zu verbinden, es funktioniert aber nur wenn er ipv4 nimmt. Kann sowas sein?

[Wernieman]

- Man kann  Docker IPv6 "verbieten".
- Docker und udp .... eventuell könnte es nötig sein, an den Rechten des Netzwerkes/Containers zu basteln. Gibt zu viele Möglichkeiten um hier Tipps zu geben.

[bugster_de]

Hi,

ja, das erscheint mir schon der Grund zu sein: der Container kommt nicht "raus". Wenn ich den Server auf Windows starte läuft er in den Logs sehr weit und hat z.B. einen Eintrag "Trying to register to Lobby ... succeeded". Das bedeutet, er meldet sich bei den zentralen Servern an. Wenn ich den Server in meinem Docker auf Linux starte ist der letzte Logeintrag genau eine Zeile vor dem "Lobby register". Sprich er fährt hoch aber sobald er was mit dem Netzwerk machen will geht es nicht mehr.

Am Router habe ich die entsprechenden Ports freigegeben und "biege" versuchsweise nur die interne IP zwischen dem Linux-Server und meiner Windowsmaschine hin- und her.

Der Server selbst ist ein komplett frisches UBUNTU 20.04 LTS System (am Dienstag neu aufgesetzt). Ich habe wissentlich keine Firewall drauf installiert geschweige denn irgendwas daran konfiguriert. Auf der gleichen Maschine laufen auch Server im Docker für Assetto Corsa (also die ältere Version) und Project Cars. Bei denen geht es ohne Probleme. Dies sind aber auch native Linux Applikationen und nicht wie hier eine Windows-Applikation die mittels Wine gestartet wird.


Update:
ich habe gerade Wine direkt auf dem Host System installiert und die ganze Sache mal nativ ohne Docker auf der Maschine laufen lassen. Dort geht es. Jetzt weiß ich nicht ob ich mich freuen oder ärgern soll.
Freuen: es geht also auf Ubuntu 20.04 mit WINE und die Infrastruktur wie Router etc. passt.
Ärgern: keinen Plan was ich jetzt machen soll. Wenn ich es im Docker laufen lassen geht es nicht also ist irgendwas am Übergang von Docker nach Wine

[Otto123]

den Container im network host modus laufen lassen?

[bugster_de]

Update: ich weiß jetzt woran es liegt aber leider weiß ich nicht wie ich es lösen soll.

Ich nutze für die Dockerimages das User-Remap Feature von Docker; sprich der Root im Container wird auf einen anderen User auf dem Host System gemappt. Und genau hier schlägt wine zu: wenn der Docker-Remap User auf dem Wirt Wine nicht ausführen kann, dann kann es root im Container auch nicht. Wenn ich es richtig sehe, braucht wine im Home Verzeichnis des Users, unter dem es ausgeführt wird die entsprechenden Konfig Dateien. Vermutlich wird auch an anderer Stelle auf dem System User-spezifische Dateien durch Wine angelegt.
Wenn ich das User-Remap Feature ausschalte geht es, aber dann ist root im Container halt auch root auf dem Wirt.

Wenn z.B. mein Remap User horst heisst und dieser weder Home-Share noch login noch Shell hat, dann geht  auf dem Wirt

Code: [Auswählen]

sudo -u horst wine accServer.exe nicht. Und wenn ich das richtig verstehe ist dieser Befehal auf dem Host equivalent zu

Code: [Auswählen]

wine accServer.exe im Container.

Genialerweise kommt hierzu halt auch keinerlei Fehlermeldung auch im Container Log.

Blöderweise hat mein Remap-User weder ein Home-Verzeichnis, noch Login noch ein Shell und das mag ich auch nicht ändern weshalb ich nun keinen Plan habe, wie die Lösung aussehen soll. Wenn ihr Ideen habt, dann bitte gerne her damit.

[Wernieman]

Warum brauchst Du den User innnerhalb des Containers auch außerhalb? Und Du kannst doch dem User innerhalb des Containers ein Home/Login etc. geben, ohne das der Gemappte ein hat .... oder?
Ach und root innerhalb des Containers <> root außerhalb ....

[bugster_de]

Vorab sorry für die Verzögerung in meiner Antwort. Beruf und Familie waren die letzten Tage wieder vorrangig :-)

Ach und root innerhalb des Containers <> root außerhalb ....

ja genau, deshalb mache ich das remapping.

root im Container ist gleich horst ausserhalb des Containers

Warum brauchst Du den User innnerhalb des Containers auch außerhalb?

den brauche ich nicht ausserhalb, aber es fiel mir halt auf, als ich mich in den Container eingeloggt habe, dass ich als root (im Container) keine Wine Programme ausführen kann und so habe ich es versucht ob ich es auf dem gemappten User (horst) ausserhalb kann. Wenn ich das User Remapping ausschalte geht alles.

Und Du kannst doch dem User innerhalb des Containers ein Home/Login etc. geben, ohne das der Gemappte ein hat .... oder?

im Container ist der User ja root und der sollte das alles ja automatisch haben, oder?
Ich kann natürlich noch im Container einen dedizierten user anlegen und dem dann die Wine Installation geben. Aber dann wird es kompliziert.



Generell scheint eine Wine Installation User abhängig zu sein. Wenn ich auf dem Server zwei User habe und ich wine mit User1 installiere, kann ich wine ausführen. Wenn ich mich als User2 einlogge, kann ich keine wine Programme ausführen. Wenn ich dann aber das Unterverzeichnis .wine aus dem Home Ordner von User1 in den Homer Ordner von User2 kopiere geht es. Ich glaube, das macht sogar Sinn, da jeder User sein eigenes, emuliertes Windows (mit C. etc.) erhält und viele Windows Programme ja gar nicht auf Multi-Suer ausgelegt sind.