Pterodacty Egg erstellen – Bau dir dein eigenes Ei!

Mit dieser Anleitung möchte ich dir den Weg einfacher gestalten, ein eigenes Ei für das Pterodactyl Webinterface zu erstellen.
Ich will dir hier einmal Schritt für Schritt klar machen, was du zu tun hast.
Es ist keine „Alles ab kopieren und es geht schon“-Anleitung, sondern du brauchst etwas Hirnschmalz, damit es funktioniert.
Sieh diesen ewig langen Text ehr als Leitfaden, anstatt eine Anleitung.

Daher vorab schon einmal die Warnung:
Für das erstellen eines Eggs, sind mittlere Linux-Kentnisse notwendig!

Hier ist kein Docker-Experte am Start, sei daher gewarnt!
Docker und ich werden wohl auch keine Freunde mehr …

Was benötigst du, um ein Egg erstellen zu können?
– Eine Installation von Pterodactyl inkl. Wings
– Einen Editor, welcher Quellcode versteht (z.B. Notepad++ / Notepadqq), damit es übersichtlicher bleibt
– Einen Docker-HUB Account (optional!)
– Einen GitHub-Account (optional!)
– Fortgeschrittenere Linux-Kentnisse zur Bedienung eines Servers und Installation von Software

Im Groben und Ganzen benötigen wir zwei große Schritte für die Erstellung eines Eggs,
zum einen brauchen wir ein Docker Contaner, welcher das Grundsystem mit bringt und zum anderen ein Installationsscript, was die gewünschte Software einspielt.
Schon ist ein Egg Einsatzbereit!
Optional können noch diverse Parameter eingebaut werden.

Wir werden hier in diesem Beispiel ein Egg für TeaSpeak erstellen.
Weil dies kurz und einfach umgesetzt werden kann und damit die Grundfunktionen gut erklärt werden können.

1. Den Container einbinden / erstellen

Damit das Egg lauffähig ist, brauchen wir ein Docker Container und diesen erhalten wir mit einem Docker Image.
Wir haben hierzu zwei Möglichkeiten.
1. Wir bauen uns ein eigenes
2. Wir nehmen einen bereits existierendes Image
Was du hier nimmst, hängt von deinen Docker-Kentnissen ab und wie viel Zeit du in das Ei investieren willst.
Wenn du es selbst baust und darauf achtest, was du nimmst, kann dein Ei am Ende wunderbar Performant sein und wenig Ressourcen benötigen.

1.1 – Docker Image erstellen

Um ein Docker Image selbst zu erstellen, brauchen wir eine Dockerfile und eine entrypoint.sh-Datei.
Die Dockerfile beinhaltet die Grundeinstellungen des Systems.
Hier ein Beispiel für Alpine Linux:

# ----------------------------------
# Pterodactyl Dockerfile for TrackMania Nations Forever - United Forever
# By Hoerli - GameMania.org
# Minimum Panel Version: 0.6.0
# ----------------------------------
FROM frolvlad/alpine-glibc

LABEL maintainer='Hoerli'

RUN apk add --update --no-cache wget ca-certificates libstdc++ musl libuuid curl tar bash \
  && adduser -D -h /home/container container

USER container
ENV  USER=container HOME=/home/container
WORKDIR /home/container

COPY ./entrypoint.sh /entrypoint.sh
CMD ["/bin/ash", "/entrypoint.sh"]

Das FROM gibt das originale Docker Image an. Hier brauchen wir kein Rad neu erfinden. Wir nehmen das was da ist.
Bei LABEL geben wir den Betreuer des Containers an. Im besten Fall wir.
Anschließend können wir mit RUN und den üblichen Installationsbefehlen des Systems, benötigte Pakete installieren lassen.
Diese werden dann direkt beim erstellen des Containers installiert.
Hier können wir nun Pakete angeben, müssen wir aber nicht! Ich empfehle aber hier Minimum Systemrelevante Pakete direkt zu installieren.
Also pack hier z.B. diverse Bibliotheken hinein, die eventuell deine Anwendung braucht.
(SteamCMD benötigt z.B. libstdc++.so.6)
Des weiteren lassen sich noch User und deren Home-Ordner angeben.
Für Pterodactyl MUSS der Nutzer „container“ heißen und sein Home-Verzeichniss MUSS /home/container sein!
Zum Schluss geben wir noch an, das die entrypoint.sh-Datei hineinkopiert werden soll und anschließend per bash gestartet wird.
Das wars.
Klein und fein.
Naja … oder so grob.

Die entrypoint.sh-Datei wird nun gestartet, sobald der Container gestartet wird.
Schauen wir uns also kurz an, was die so können muss.
Hierzu haben ich folgendes Beispiel, was eigentlich so gerne für neue Projekte verwendet werden kann.

#!/bin/bash
cd /home/container

# Make internal Docker IP address available to processes.
export INTERNAL_IP=`ip route get 1 | awk '{print $NF;exit}'`

#STARTUP = MODIFIED_STARTUP
MODIFIED_STARTUP=`eval echo $(echo ${STARTUP} | sed -e 's/{{/${/g' -e 's/}}/}/g')`
echo ":/home/container$ ${MODIFIED_STARTUP}"

# Run the Server
eval ${MODIFIED_STARTUP}

Wir gehen in das Home-Verzeichnis von dem Nutzer container,
Wir machen die interne IP-Adresse für den Prozess verfügbar, Modifizieren den Startprozess auf die Vorgaben für Pterodactyl und führen diesen in der letzten Zeile aus.
Dieses Beispiels stammt auch so aus der Dokumentation von Pterodactyl.
Es hilft einfach dem Panel, den Container richtig zu interpretieren und die Steuerung zu ermöglichen.

Damit haben wir die Vorbereitungen für Docker abgeschlossen.
Für die bequeme Verwaltung deines neuen Containers, empfiehlt es sich nun, die beiden Daten auf GitHub hochzuladen und deinen GitHub-Account mit deinem Docker-HUB-Account zu verknüpfen.
DockerHUB baut dir anschließend aus deinen zwei Daten alles zusammen und du kannst dein Container in Pterodactyl einbinden.
Du erhälst bei DockerHUB am Ende auch eine Adresse (DeinBenutzername/DeinContainer:Version), welche wir in Pterodactyl hinterlegen müssen.

Ich habe hier in diese Anleitung absichtlich keine ausführliche Erklärung gepackt, was man alles mit den beiden Daten noch anstellen kann. Das wäre enorm viel Aufwand und du willst ja schnell ein Ei erstellen, daher machen wir nur das nötigste.

1.2 – Nehmen was da ist

Zu kompliziert das ganze oder zu viel Arbeit?
Dann nehmen wir was schon da ist.
Wir können auch schon auf fertige Werke zurückgreifen und diese nutzen.
Merke dir daher diese Docker Images für Schritt 2!
Ich habe hier ein paar fertige Images aufgelistet, welche von Pterodactyl selbst gewartet werden.
Sie sollten also stets recht aktuell sein und vor allem funktionieren.
quay.io/pterodactyl/core:source → Alpine Linux, von Pterodactyl gewartet
quay.io/pterodactyl/core:java → Alpine Linux mit Java, von Pterodactyl gewartet
quay.io/parkervcp/pterodactyl-images:base_debian→ Basis Debian-System, von Pterodacyl gewartet
quay.io/parkervcp/pterodactyl-images:debian_source → Basis Debian-System, von Pterodacyl gewartet
quay.io/parkervcp/pterodactyl-images:debian_openjdk-13→ Basis Debian-System mit OpenJDK (JAVA) in Version 13, von Pterodacyl gewartet
quay.io/parkervcp/pterodactyl-images:debian_dotnet-5→ Aktuelles Debian System mit .NET-Framework

Was soll ich davon nehmen?
Es kommt darauf an, was du machen willst und womit es gut läuft.
Alpine Linux Systeme sind sehr „schlank“. Verbrauchen daher erst einmal sehr wenig Ressourcen (RAM + Festplatte).
Du muss aber eventuell sehr viele Pakete installieren, damit deine Anwendungen laufen.
Ein Debian-System braucht mehr Speicherplatz, hat aber diverse Bibliotheken schon mit dabei.
Nimm am besten das, was dir bisher am besten liegt und wo du mit Sicherheit sagen kannst, das deine Anwendung damit läuft.

Für TeaSpeak nutze ich hier das base_debian Image.
TeaSpeak ist noch in Entwicklung, läuft aber gut mit Debian. Daher ist die Entscheidung für mich hier recht einfach.

Hast du ein Image für den Container erstellt oder ein Images ausgewählt?
Dann gehts weiter mit dem Schritt 2!

2. Das Egg erstellen

2.1 – Das Ei anlegen

Logge dich in Pterodactyl ein, klick auf „Nests“ und erstelle dir ein neues Nest.
In ein Nest legen wir dann unsere Eier.
Klick also auf „Create New“, gebe einen Namen für das Nest an und eine kurze Beschreibung.
Was du eingibst, ist vollkommen egal. Das sehen nur die Admins des Panels.
Geh nun in dein Nest und erstelle ein neues Ei. Klick also auf „New egg“.

Ein Nest ist quasi auf deutsch ein einfacher Ordner und das Ei schlussendlich die Anwendung im Ordner.
Ist zwar nett, das man sich hierfür andere Namen ausgedacht hat, für einen Admin ist das aber meiner Meinung nach etwas übertriebener Mist.

Nun müssen wir ein paar Grundinformationen angeben.

Die Configuration

Associated Nest
Hier können wir das Nest noch einmal anpassen, falls wir uns verklickt haben.
Wähle hier dein Nest aus, wo das Ei drin landen soll.
Ich sage hier, mein TeaSpeak-Ei soll in „Voice Servers“ landen.

Name
Gebe deinen Namen für dein Ei an.
Sei präzise, denn ein guter Name hilft nachher bei der Zuweisung des Eis für eine Nutzer.
Hast du ein speziellen Gameserver mit eventuell ein paar Mods dabei, gib das im Namen an.
Das Hilft am Ende ungemein.

Description
Gebe eine Beschreibung von deinem Ei an.
Schreibt hier am besten rein, was das Ei tut. So kannst du einen besseren Überblick behalten.
Hast du Mods oder ähnliches eingebunden, schreib es dazu!

Docker Images
Gebe hier nun dein Docker Image an.
Entweder aus den vorgefertigten Sachen, die ich oben angegebenen habe oder dein eigenes.
Wichtig hierbei: Sind die Images bei quay.io gehostet, gebe die URL wie oben die Beispiele an. Sind deine Images bei DockerHUB, gebe die HUB-Adresse an (Beispiel: Nickmane/Containername:Version). Andere URLS funktionieren (scheinbar) nicht!

Ich gebe hier für mein TeaSpeak-Ei nun quay.io/parkervcp/pterodactyl-images:base_debian an.

Startup Command
Trage hier den Startbefehl ein, der bei jedem Start des normalen Servers dann ausgeführt werden soll.
In meinem TeaSpeak-Beispiel wäre es folgender:

./teastart_minimal.sh --property:voice.default_port={{SERVER_PORT}} --property:binding.query.port={{QUERY_PORT}} --property:binding.file.port={{FILE_PORT}}

Wir rufen die Anwendung auf, die sich direkt im Home-Verzeichnis des Nutzers „container“ befindet und fügen die vom Server unterstützen Parameter für die Portzuweisung an.
Die variieren je nach Server immer! Mach dich im Internet schlau, was deine Anwendung kann und was nicht!
Der Startup-Command legt IMMER im Home-Verzeichnis des Nutzers Contanier los!

Wie du siehst, können wir hier mit Variablen arbeiten, welche von Pterodactyl dann automatisch ausgefüllt werden.
Folgendes steht zur Auswahl:
{{SERVER_PORT}} = Port der in Pterodactyl als frei nutzbarer Port ausgewählt werden kann

Alle weiteren von Hand angelegten Variablen, müssen wir später noch dazu bauen.

Wichtig: Pterodactyl will gerne das die Anwendung im Vordergrund läuft. Dadurch sehen wir auch im Panel die Shell mit allen Loginfos von einem Server.
Eine zweite Anwendung lässt sich somit NICHT starten. Brauchst du also noch weitere Dienste, musst du dir am besten ein Start-Script in deinem Container zusammenbauen, welches dann über den Start Command aufgerufen wird, oder du arbeitest mit z.B. CronJobs, Services,….
Sei hier kreativ und teste, was alles mit deinem Vorhaben möglich ist.

Das Process Management

Copy Settings From
Wenn du ein Egg bereits hast, was alle notwendigen Befehle besitzt, kannst du hier das Ei auswählen. Da wir hier von vorne Beginnen, lassen wir es auf „None“.

Stop Command
Trage hier den Befehl ein, wie dein Server angehalten werden soll.
In der Regel reichen hier die zwei Beispiele in Pterodactyl. SIGINT oder ^C.
Andere Spiele hören z.B. auf „EXIT“ oder „STOP“.
Hier musst du schauen, was dein Spiel / Anwendung erlaubt.

Für TeaSpeak reicht ^C.

Log Configuration
Hier kannst du angeben, wo die Logs liegen, die ggf. ausgegeben werden.
Die Config muss im JSON-Format angegeben werden.
Keine Logs da oder irrelevant?
Gebe einfach folgendes ein:

{
    "custom": true,
    "location": "logs/latest.log"
}

Leider muss etwas drin stehen. Daher kannst du auch einfach Stumpfsinn angeben.

Configuration Files
Du kannst deine Config-Files hier direkt vor dem Startup editieren lassen.
Somit wäre es möglich, Serverbrandings oder Portkonfigurationen jedes mal beim Start in die Einstellungen zu setzen.
Die Werte müssen in JSON angegeben werden.
Brauch ich das Feld nicht, gebe ich einfach {} ein.

Start Configuration
Dieser Wert ist wichtig.
Hier definieren wir in JSON, ab welchem Punkt der Server als „online“ gelistet werden soll.
Der Status wird aus dem Server-Output (also die offene Shell) gelesen.
Sobald also eine bestimmte Zeile im Log auftaucht, wir der Server als Online eingestuft. Andernfalls wird der Container neu gestartet. Klappt das nicht, wird der Container wieder offline gesetzt.
Für mein TeaSpeak-Server wäre das hier folgendes

{
    "done": "Starting server",
    "userInteraction": []
}

Sobald der Server korrekt gestartet wurde, taucht nämlich der Eintrag „Starting server“ im Output auf.

Alles eingegeben?
Dann klick auf „Create“!

2.2 – Angabe von Image-Infos

Super, wir sind einen Schritt weiter!
Nun haben wir oben ein Menüband erhalten, wo wir nun „Configuration“, „Variables“ und „Install Script“ finden.
Rufe nun „Install Script“ auf.
Nun gehts an die lustige Arbeit, ein Installationsscript zu erstellen, was beim erstellen eines neuen Servers automatisch gestartet wird.

Hierüber installieren wir nicht nur benötigte Pakete, wir laden auch die Serverdaten herunter und legen Konfigurationen an.
Zusätzlich können wir hier mit den Variablen arbeiten, die wir anlegen. Diese müssen dann z.B. bei der Erstellung eines Servers ausgefüllt werden und die Werte landen z.B. an den richtigen Stellen in einer Konfigurationsdatei.

Fangen wir aber von unten an.
Copy Script From
Soweit wir schon ein Ei mit einem perfekten Script haben, können wir das kopieren.
Haben wir aber nicht 😉

Script Container
Hier müssen wir ein Docker Image angeben, der verwendet werden soll.
Dieser sollte gleich sein, wie der, den wir bei Docker Images angegeben haben.
Ich habe hier folgende Beispiele:
alpine:3.10 → Alpine Linux in Version 3.10. Sehr sehr kleines System!
alpine:3.11 → Alpine Linux in Version 3.11. Sehr sehr kleines System!
debian:buster-slim → Sehr schlankes Debian
debian:stable-slim → Sehr schlankes Debian, aber immer das aktuellste stable-Release
node:12-buster-slim → Debian Buster Slim mit NodeJS12 im Gepäck
node:14-buster-slim → Debian Buster Slim mit NodeJS14 im Gepäck
openjdk:8-jdk-slim → Debian Buster Slim mit OpenJDV (Java)
ubuntu:16.04 → Ubuntu 16.04
ubuntu:18.04 → Ubuntu 18.04
ubuntu:18.10 → Ubuntu 18.10

Ich verwende hier für TeaSpeak, den Debian-Slim Container also gebe ich debian:buster-slim an.
Es gibt noch weitere Images. Die hier aufgeführten, sind mir nur durch diverse Eggs unter die Finger gekommen.

Script Entrypoint Command
Wir geben an, wie wir das Script ausführen wollen.
Debian → bash
Alpine Linux → ash

Da ich Debian auserwählt habe, trage ich hier bash ein.

2.3 – Das Installationsscript

So! Nun gehts ans Scripten!
Wir müssen nun ein Installationsscript erstellen, was notwendige Pakete installiert, TeaSpeak herunterlädt und dann entpackt.
Eigentlich einfach, doch wir machen es etwas dynamischer.

Wichtig jetzt hier: Unser Verzeichnis ist jetzt nicht /home/container, sondern wir arbeiten im Script in /mnt/server! Nur so wird später alles in Pterodactyl sichtbar!
Warum die Entwickler sich so ein Mist einfallen lassen haben, ist mir bisher nicht ganz klar, aber seis drum.
Wir haben auch nun die Möglichkeit, mit Variablen zu Arbeiten.
Wir können auch beliebig viele anlegen.

Es empfielt sich aktuell einen Code-Editor zu verwenden, da die Eingabebox nicht größer gemacht werden kann.
Ich empfehle z.B. Notepad++ oder Notepadqq dafür.

Hier mein Code:

#!/bin/bash
 
## install required packages and update the system
apt update
apt upgrade -y
apt install curl ffmpeg tar wget bzip2 -y

## make and change to directory
mkdir /mnt/server
cd /mnt/server/

## get download link
if [ "${VERSION}" == "" ] || [ "${VERSION}" == "latest" ]; then
    DOWNLOAD_URL=$(echo "https://repo.teaspeak.de/server/linux/amd64/TeaSpeak-$(curl -sSLk https://repo.teaspeak.de/server/linux/amd64/latest).tar.gz")
elif [ "${VERSION}" == "" ] || [ "${VERSION}" == "nightly" ]; then
    DOWNLOAD_URL=$(echo "https://repo.teaspeak.de/server/linux/amd64_nightly/TeaSpeak-$(curl -sSLk https://repo.teaspeak.de/server/linux/amd64_nightly/latest).tar.gz")
else
    DOWNLOAD_URL=$(echo "https://repo.teaspeak.de/server/linux/amd64/TeaSpeak-${VERSION}.tar.gz")
fi

if [ ! -z "${DOWNLOAD_URL}" ]; then 
    if curl --output /dev/null --silent --head --fail ${DOWNLOAD_URL}; then
        echo -e "link is valid. setting download link to ${DOWNLOAD_URL}"
        DOWNLOAD_LINK=${DOWNLOAD_URL}
    else        
        echo -e "link is invalid closing out"
        exit 2
    fi
fi

## download files
echo -e "running: curl -sSL -o teaspeak.tar.gz ${DOWNLOAD_LINK}"
curl -sSL -o teaspeak.tar.gz ${DOWNLOAD_LINK}

## unpack files
echo -e "unpacking files"
tar xzvf teaspeak.tar.gz
rm teaspeak.tar.gz

echo -e "Install complete! Have fun!"

In Zeile 4-6 updaten wir das System und installieren noch notwendige Pakete.
Wir erstellen in Zeile 9 den Ordner server im Ordner mnt und wechseln in Zeile 10 direkt da hinein.
In Zeile 13-29 prüfen wir, was die neuste Version von TeaSpeak ist und laden ein gewünschtes Paket via Variable herunter. Ich kann so z.B. auch die Nighly-Builds als Installationswunsch angeben.
$VERSION → Es wird entweder die neuste (latest) Version geladen oder von dir eine vorbestimmte.
Der eigentliche Download findet dann in Zeile 32 und 33 statt, in der dann auch die Datei gleich teaspeak.tar.gz genannt wird.
In Zeile 37 entpacken wir nun das Archiv in unserem Ordner, in dem wir uns aktuell befinden (/mnt/server).
Dann entfernen wir das Archiv in Zeile 38, weil das brauchen wir nicht mehr.
Fertig!

Das Setup ist soweit durch. Mehr braucht es für TeaSpeak soweit erst einmal nicht.
Ich muss keine Konfigurationen editieren oder Daten anlegen.
Ist das für dein Server wichtig, wünsche ich dir viel Spaß beim Editieren dieser Daten oder neu anlegen. 🙂

Wie du im Code siehst, können wir hier auch mit Kommentarfelder und echo arbeiten.
So sehen wir z.B. auch während die Installaion läuft, was aktuell so vor sich geht.
Am Ende gibt ich ein “Fertig” aus, das der Nutzer im Terminalfenster in Pterodactyl sieht, dass das Script durchgelaufen ist und er nun sein Server nutzen kann.

Denk auch daran, falls du Dateioperationen durchführst (Daten erstellen, ersetzen,..), das du die Berechtigungen auch passend setzt.
Der Besitzer muss immer “container” sein (chown container:container) und falls eine Datei ausgeführt werden soll, mach diese ausführbar (z.B. chmod +x).

Erst einmal auf Speichern (Save) klicken.

Du kannst nun dein Script jederzeit erweitern und testen.
Erstelle dir einen neuen Server und weise dein Egg nun zu.
Dann siehst du was passiert.
Falls du einen Log zur Fehleranalyse brauchst, den findest du auf deinem Server, auf dem du dein Ei gerade zugewiesen hast unter /var/log/pterodactyl/wings!

Falls du ein paar Denkanstöße brauchst, ich habe meine Eggs z.B. auf GitHub veröffentlicht.
Schau sie dir gerne an.

2.4 – Variablen anlegen und definieren

Hast du Variablen in deinem Installationsscript genutzt?
Dann müssen wir diese nun noch anlegen und deren Wert bestimmen, sofern du das nicht schon im Installationsscript gemacht hast.
Geh dazu in den Reiter „Variables“ und klicke auf „Create New Variable“.
Für meinen TeaSpeak Server möchte ich z.B., das ich die Version und die Serverports bestimmen kann, ohne jedes mal in das Script gehen zu müssen oder von Hand eine Konfiguration anpassen muss.
Zudem soll der Nutzer entscheiden dürfen, welche Serverversion er gerne hätte.

Ich erstelle hier also 3 Variablen.
1. Die Versionsangabe

Name
Hier kann ich ein freien Namen angeben. Am besten einfach angeben, was damit geändert wird.
Ich nenn es einfach „TeaSpeak Version“.

Description
Hier kann ich angeben, wie ich die Variable verändern kann oder darf.

Environment Variable
Hier muss ich nun die Variable aus dem Script angeben.
Ich habe sie VERSION getauft, daher trage ich hier ins Feld VERSION ein.
Pterodactyl wird sie finden, und durch den Inhalt ersetzen.

Default Value

Trage hier die Standardangabe ein, sofern es eine geben soll.
Ich möchte z.B. für meinen Download, das er Standardgemäß die aktuellste stabile Version herunterlädt. Also gebe ich latest an.

Permissions
Hier können wir auswählen, ob der Nutzer die Variable sehen darf und ob er sie editieren darf.
Je nach dem was du hier für Variablen anlegst, ist es schlau, wenn der Nutzer zumindest die Variable sehen darf.
Wenn du z.B. ein Fernwartungsport (RCON, RPC,..) angibst, das er den Port sehen kann, um ggf. passende Verwaltungssoftware korrekt einzurichten, um seinen Server steuern zu können.
Du willst aber nicht, das der Nutzer den Port ändern darf, um doppelt belegte Ports zu vermeiden.
Du kannst auch Passwort-Variablen erstellen, wo der Nutzer sehr einfach ein Admin-Kennwort z.B. definieren kann. Dies sollte er auch editieren dürfen.
Ich lass dem Nutzer die Freiheit, die Version selbst zu bestimmen. Daher lass ich es zu, das der Nutzer die Variable sieht und editieren kann.

Input Rules
Hier können wir die Eingabemöglichkeit für „Default Value“ beschränken, um so Fehleingaben zu verhindern.
Zusätzlich können wir hier Pflichtvariablen erstellen.
Wir können Werte am Stück angeben und trennen sie mit einem |.
In meinem Fall gebe ich folgendes an: required|string|max:20

Ich mach es mit required zu einem Pflichtfeld, definiere mit string, das Text eingegeben werden darf und erlaube maximal 20 Zeichen.

Das wars für die erste Variable!

2. Query Port
Nun will ich einen QueryPort für den Start-Command bestimmen, damit ich z.B. mehrere Server auf einer Hostmaschine laufen lassen kann, ohne das die Ports doppelt belegt werden.
Also im Schnelldurchlauf:

Name: Query-Port
Description: Was nettes eintragen
Environment Variable: QUERY_PORT
Default Value: 10101
Permission: User Can View
Input Rules: required|numeric|max:65535

Ich hab also wieder ein Pflichtfeld erstellt, nur dieses mal dürfen bei Default Value nur Zahlen von 0 – 65535 angegeben werden.

3. File Transfer Port
Name: File Transfer Port
Description: Was nettes eintragen
Environment Variable: FILE_PORT
Default Value: 30303
Permission: User Can View
Input Rules: required|numeric|max:65535

Und hier das selbe Spiel wie bei Query-Port.
Variablen sind also schnell angelegt und die Standardwerte festgelegt.

Drücke nach dem Editieren bei jeder Variable auf „Save“. Sicher ist sicher!

Damit sind wir nun Startklar!
Du kannst nun bei Servers dir ein neuen Server mit deinem Egg anlegen und sehen, ob alles durchläuft.
Davor musst du nun die Variablen-Felder selbstverständlich ausfüllen.

Einfach oder?
Nein, nicht wirklich 😉
Wir können nur hoffen, dass das erstellen von Eggs eventuell etwas einfacher wird.
Ganz trivial finde ich es nicht und man stößt an das ein oder andere Limit.

Ich hoffe, das diese kleine Anleitung hier, dir den Einstieg in die Eier-Welt etwas erleichter hat und du nun deine eigenen Eier ausbrüten kannst.
Es ist keine Top-Anleitung, aber sollte dem kompletten Neueinsteiger einige Infos geben, die bei der Dokumentation von Pterodactyl fehlen oder nicht ganz so gut rüber kommen.
Bis dahin wünsche ich dir frohe Ostern … ääääh … viel Spaß beim Eier legen!
…. ich werde hier wohl bald zum Landwirt.

Achja, falls du schon tolle Eier erstellt hast, lass es mich wissen.
Ich würde die gerne hier verlinken!


Hoerli’s Eggs: [GitHub]
ParkerVCP’s Eggs: [GitHub]

6 Kommentare

  1. hallo,

    ich habe dein trackmania egg instaliert und bekomme bei starten immer diesen fehler

    [PHP Warning] unpack(): Type V: not enough input, need 4, have 0 on line 553 in file /home/container/xaseco/includes/GbxRemote.inc.php
    [PHP Warning] fread(): Length parameter must be greater than 0 on line 559 in file /home/container/xaseco/includes/GbxRemote.inc.php
    [XASECO Warning] [-32300] InitWithIp – transport error – wrong lowlevel protocol version
    [XASECO Fatal Error] Connection could not be established ! on line 717 in file /home/container/xaseco/aseco.php

    • Hi!
      Das Egg mit XASECO ist gerade noch im Aufbau / Umbau.
      Achte darauf, dass alle Felder korrekt ausgefüllt sind und der TM-Server mit XASECO und die Datenbank auf einem Server laufen.
      Falls du noch mehr Informationen liefern kannst, würde ich mich über ein Issue über GitHub freuen, da ich das Egg nicht alleine gerade baue.

  2. Alles genau befolgt , daten sind alle richtig aber es bringt keine datenbank verbindung zustande. vlt kannst du mal schauen?

    • Ich habe das Egg gerade mal bei mir getestet.
      Soweit eine Datenbank auf dem Host existiert und für XASECO die Tabellen importiert wurden, startet der Server ohne Probleme.
      Da muss ggf. was bei der Installation auf deinem System schief gelaufen sein.
      Lösche am besten noch einmal alles von dem Gameserver und achte bei der Installation darauf, dass keine Fehler beim Download von Dateien auftreten.

  3. Habe den Fehler gefunden und zwar muss man in der localdatabase.xml bei localhost ip + port eingeben.

    Hast du eine idee wie man Adminserv zusätzlich laufen lassen kann? irgnedwie geht das nicht

    • Die IP sollte automatisch korrekt ausgefüllt werden.
      Soweit die DB auf dem gleichen Hostsystem läuft wie der TM-Server, sollte “localhost” oder 127.0.0.1 ausreichen.
      Bei mir funktioniert das.
      Der Port muss nicht angepasst werden, es sei, du hast ihn selbst in MySQL/MariaDB geändert.
      Sollte letzteres der Fall sein, musst du selbst an solche Dinge denken, das kann ich dir nicht abnehmen 😉

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.