Beiträge von TBT

Zitat von KB19

Was TBT meine ist die oberste Ebene: /

Er meinte weder /root, noch den root-User. Wobei es ohne Rootrechte tatsächlich nicht klappen wird…

Du solltest Dir dringend die Grundlagen bezüglich absoluter und relativer Pfadangaben aneignen.

Genau das. Ohne Linux und ohne Docker Grundkenntnisse wirds halt nix.

Nebenbei kann man die Ordner hinlegen wo man will - wenn man sich auskennt - aber mein oben genanntes Howto war halt ein Versuch die Sache EINFACH zu machen.

Nö, hast Du eben nicht so angelegt. Ich habe Dich angewiesen die Ordner /docker und /docker_data anzulegen. Und damit meine ich im ROOT Verzeichnis des Servers, nicht in irgendwelchen Unterordnern. Darauf ist alles in meiner Anleitung ausgelegt. Pfeif auf den Ordner /opt/Steam.

Wenn wir jetzt hier auch noch mit Linux Verzeichnisangaben anfangen müssen, dann ist ja noch weniger Vorwissen da wie befürchtet.

Die Domain und DNS Problematik ist ja nun nicht neu. Wieso zieht man dann nicht einfach Konsequenzen und alle Domains von Netcup ab bzw. stellt den DNS Server um? Und evtl auch noch Mailserver ab?

Es gibt genug reine Domainprovider oder auch zuverlässige DNS Serveranbieter, dass man sich solche Dauerthemen echt nicht geben muss. Auch SMTP Relays gibts zur Genüge.

Was an „der Container zieht sich alle Game Files von Steam selbst“ war nicht verständlich?

Ist keine Inkompetenz, sondern nur der Wunsch, Shortcuts bei einem komplexen System zu machen, ohne das System vorher verstanden zu haben.

Ergänzung: mit diesem Docker Container MUSST Du alle Environment Variablen im Docker compose setzen, denn

Zitat

Note: ServerHostSettings.json is overwritten on startup using information from server variables. If you do not define the environment variables they will be filled with the defaults from the table below

Dude, mach’s einfach so wie oben beschrieben. Ich habe selbst einen lauffähigen und funktionierenden VRising Server auf meinem Server, die Container ziehen sich über steamcmd die nötigen Spieldateien selbst, da muss man keine Dateien vorgeben. Insofern ist es komplett egal was Du wo liegen hast, der Container braucht nichts vorgegebenes.

Da schreibt man Dir ein Privat-Hoto und das ist alles was zurück kommt…

Nebenbei: könntest Du bitte mal die Formatierung des Forums so verwenden wie es vorgesehen ist? Bei Deinem wilden Antworten in Zitaten und Fett und Kursiv Schreiben bekommt man ja Augenkrebs.

Ein docker run ist, wie gesagt, nicht wirklich die einfachere Variante, da da unstrukturiert einfach alles in einem Bandwurm drin steht. Wenn das docker-compose.yml korrekt geschrieben ist (und das ist viel leichter zu lesen), dann ist DAS die einfachere Variante.

Man baut kein Auto, indem man schnell schnell vier Räder an einen Schuhkarton klebt, sondern man lernt erst mal wie es gehen muss. Übertragen auf diesen Fall heißt das zu lernen, wie die Syntax von Docker aussieht und welche Prinzipien dahinter stecken.

Wenn wir Dir jetzt eine docker-compose hinschreiben, hast Du absolut nichts gelernt und stehst bei dem nächsten Problem wieder ohne Ahnung da. Ich versuche es trotzdem, obwohl es für Deine eigene Erkenntnis definitiv der falsche Weg ist.

Saubere Datenhaltung in einem deutlich weniger verschachtelten Ordner (statt /opt/steam/VRising/mnt/vrising/server ) ist angebracht, daher läufts in der Folge anders:

Mit der folgenden Anleitung hast Du die herausgelegten Daten des Containers in /docker und die yml Files in /docker_data . Beides sollte nicht im gleichen Ordner liegen, da Du sonst das yml File mit in den Container legst, darin hat es aber nichts zu suchen.

mkdir /docker
mkdir /docker/vrising
mkdir /docker/vrising/server
mkdir /docker/vrising/persistentdata

mkdir /docker_data
cd /docker_data

# Im Ordner /docker_data
nano vrising-compose.yml
( "apt install nano", falls nicht vorhanden)

von solareon/vrising-svr - Docker Image | Docker Hub

>> in die vrising-compose.yml

version: "3"
services: 
  vrising:
    container_name: vrising-server
    image: solareon/vrising-svr:latest
    volumes: 
      - /docker/vrising/server:/mnt/vrising/server
      - /docker/vrising/persistentdata:/mnt/vrising/persistentdata
    environment:
      - "TZ=Europe/Berlin"
    ports: 
      - "27015:27015/udp"
      - "27016:27016/udp"
      - "25575:25575/tcp"
    restart: unless-stopped

YAML ist sehr sehr picky was die Einrückungen betrifft, man kann hier nicht einfach irgendwas hinschreiben, die korrekten Einrückungen sind essentiell. Man kann mit YAMLlint - The YAML Validator kontrollieren, ob das YAML korrekt ist.

Du fragtest wo das docker-compose liegen soll. Im Prinzip ist das bei meinem compose File erst mal egal, denn wie man sieht ist das unabhängig von jeglichem Bezugsordner (anders als die Verwendung der Tilde). Ich habe Dir oben angegeben, dass es in einen Ordner /docker_data liegen soll. In diesem solltest Du Dich befinden, wenn Du die folgenden Befehle ausführst (alternativ kann man die Befehle auch mit Pfad versehen, dann ist es egal wo man ist).

#in den Ordner /docker_data
cd /docker_data

# Aus Compose File Starten
docker-compose -f vrising-compose.yml up -d
# ODER unabhängig davon in welchem Ordner Du bist
docker-compose -f /docker_data/vrising-compose.yml up -d

# Mit docker-compose stoppen
docker-compose -f vrising-compose.yml down
# ODER unabhängig davon in welchem Ordner Du bist
docker-compose -f /docker_data/vrising-compose.yml down

# Neuen Build erzwingen
docker-compose -f vrising-compose.yml build --no-cache --pull
# ODER unabhängig davon in welchem Ordner Du bist
docker-compose -f /docker_data/vrising-compose.yml build --no-cache --pull

Du kannst Docker Container mit beidem starten, mit docker run Befehl oder mit docker-compose. Bei einfacheren Containern reicht ggfalls ersteres, bei komplexeren (wie Gameservern) und insbesondere wenn man sehr viele Environmentvariablen und/oder Volumes sowie zusammengestellte Systeme (z.B. aus Webserver und Datenbank) hat, wird ein run Befehl extrem schnell unübersichtlich und das Docker Compose File deutlich angenehmer.

Ein weiterer wichtiger Aspekt ist, dass zusammengestellte Anwendungen (wenn für eine Anwendung mehrere Container benötigt werden) automatisch im gleichen Docker Subnetz laufen und sich darin ohne weiteres sehen, sogar ohne das jeglicher Port nach außen gelegt wird.

Daher würde ich vorschlagen, Du entscheidest Dich für eines, ich favorisiere aus genannten Gründen docker-compose und ja, das File kann man dann zügig editieren, es ist übersichtlich und der Befehl zum starten und stoppen bleibt immer gleich:

# Aus Compose File Starten
docker-compose -f meinserver-compose.yml up -d

# Mit docker-compose stoppen
docker-compose -f meinserver-compose.yml down

# Neuen Build erzwingen
docker-compose -f meinserver-compose.yml build --no-cache --pull

Mit Composerize kannst Du einen Run Befehl auch in ein Docker-compose umwandeln. Besser wäre es jedoch im vorliegenden Fall, das vorhandene File docker-vrising/docker-compose.yml at main · TrueOsiris/docker-vrising (github.com) zu verwenden und an die eigenen Bedürfnisse anzupassen.

Ein Container, der sehr zur Übersichtlichkeit beiträgt und bei der Verwaltung hilft wäre übrigens https://www.portainer.io/ . Das ist Teil meines Standardstacks.

P.S: Ich kann mich da nur aRaphael anschließen: wenn man Docker mal durchdrungen hat, kann man quasi jede Umgebung einrichten, das ist sehr mächtig und wird Dir weit über Dein Gameserverprojekt weiterhelfen. Natürlich nur wenn Du das willst. Einen Container ohne tieferes Verständnis können wir vielleicht gemeinsam hinstricken, aber deutlich hilfreicher für Dich selbst wäre es, sich mehr damit zu beschäftigen und dann erst das Gameserverprojekt umzusetzen.

Bevor wir da mehr einsteigen, der Servername sollte unbedingt geändert werden, das wird der Name sein, wie er im Steam Browser angezeigt wird. Die Timezone ist eh gleich, kannst auch "Europe/Berlin" nehmen, sollte genauso gehen.

Deutlich übersichtlicher als docker run Befehle ist die Arbeit mit docker-compose Files. Du solltest Dir ansehen wie man Docker Compose installiert, wie man damit arbeitet (Befehle) und dann auf https://github.com/TrueOsiris/docker-vrising gehen und die dortige docker-compose.yml nehmen und an Deine Verhältnisse anpassen, also im Wesentlichen den Teil Environment und Volumes.

Ohhh, so ein kleiner Pocket Admin wäre nice.

Zitat von aRaphael

Na, dann übersetze ich das mal für dich.

=

Auf einem Webhostingpaket ist bei weitem nicht alles das möglich, was auf einem Server geht.

z.B. docker.

Jep. Genau das war die Aussage, die vielleicht etwas klarer hätte sein sollen. Nebenbei kommen die Labels einfach nach Postmenge und spiegeln nicht unbedingt den Kenntnisstand wider.

Zitat von ASS

https://anexia.onlyfy.jobs/job/azlhtu5ppg…ab33u3tltk6i39w

SENIOR SOFTWARE ENGINEER CLOUD SERVICES - MANAGED DNS

Ob das mal nicht ganz gefährliches Terrain ist... Auf der anderen Seite: so jemand brauchen sie definitiv.

Zitat von engine

Deshalb hab ich vor der neuen Jobherausforderung nicht mehr so viel Angst

Let's gooo! Viel Erfolg!

Ich wusste jetzt nicht ob ich den oder den Smiley als Reaktion auswählen sollte. Ist irgendwie beides. Aber eigentlich wäre der richtige Smiley:

This is customer forum. No customer will be able to answer this. Look into https://www.netcup.eu/bestellen/agb.php and / or ask Netcup.

Ein Webhostingpaket ist kein Server...

Zitat von Bud

Interessant finde ich bei solchen Stellenangeboten immer die Skala (in dem Fall "Gehaltsspanne") mit nur einem Pin. Wo hört der Grüne Bereich auf? 60.001 €?

pasted-from-clipboard.png

Naja, wenn man die Skala links von dem "mindestens" als von 0-60.000 gehend sieht, könnte die Range auch bis 150.000 gehen...

Zitat von Ente-Unser

Das RaPi mit den Ampere Instanzen zu vergleichen kommt sich in etwa gleich mit Intel Celeron vs Xeon. (nur dass das rapi immer noch effizienter ist als der celeron *duck ung weg*)

Ich glaube sogar, dass der Leistungsunterschied noch viel extremer ist. Im Prinzip muss man halt - wie immer bei CPUs - Benchmarks fahren um unterschiedliche CPUs oder sogar Architekturen vergleichen zu können.

Wenn man auf https://www.cpubenchmark.net/cpu_list.php nach ARM sucht, findet man Einträge von 93 bis 46.000 Punkten.

Zitat von netsch1967

Wenn ich das richtig interpretiere sollte es möglich sein das Netzwerk mehrere Docker Instanzen auf unterschiedlichen Hosts ins gleiche Subnet zu stecken. Die Kommunikation wäre dann sicherlich einfacher, verschlüsselt und Vserver übergreifend.

Jep. Davon gehe ich aus, habs aber wie gesagt noch nicht verwendet.

Arm Core ist nicht gleich Arm Core. Da gibt es viele verschiedene Varianten, denn ARM designed eigentlich nur die Architektur, die dann von OEMs als Vorlage genommen wird, um eigene Hardware zu stricken. Je nach Anwendungsgebiet kann das in alle möglichen Richtungen optimiert und mit zusätzlichen Bereichen auf dem System on a Chip (SoC) erweitert werden.

Der M1/M2 von Apple packt CPU Kerne, GPU Kerne sowie das RAM in ein SoC und bindet die SSD proprietär und sehr breitbandig an. Zudem werden da noch einige Hardware Video Codecs drauf gepackt, die die CPU/GPU davon entlasten, Videos en- und decodieren zu müssen.

Daraus wird etwas sehr performantes bei gleichzeitig niedrigem Energieverbrauch. Andere ARM SoCs können eine ganz andere Zusammenstellung mitbringen und günstiger oder energiesparender oder besser auf Spezialaufgaben zugeschnitten sein.