Shell Scripting Dateiliste verarbeiten



fragger1991

New Member
Hallo,

ich wollte für mein GameServer Webinterface ein Addon Installer machen, damit ich mir nicht die Dateien in eine Liste schreiben muss, dachte ich, lass ich es mir von tar ausgeben.

Meine Frage ist nun, wie kann ich diese Liste im Shell Script verarbeiten? Bei PHP würde ich es einfach in ein Array packen und im foreach verarbeiten und mit dem Befehl unlink zum entfernen dieser Dateien.

Ich kann zwar bis zu einem gewissen Punkt mit Shell arbeiten, aber Schleifen etc. hab ich bisher nicht genutzt in meinen Scripten, max. ein if :D

Danke!
 
Ich habe mir da ne besser Lösung gebastelt, welche auch ziemlich universell ist :D

Code:
tar tf TAR-ARCHIVE.tar | tr -d "\r" |while read list; do rm -Rf $list; done

Damit habe ich also die Möglichkeit eine Liste direkt aus dem TAR Archiv raus zu erstellen, womit auch direkt ALLE Dateien die mit dem Archiv in Verbindung standen gelöscht werden.

Dabei sollte man allerdings auf gewisse Dinge achten, wie z.B. wird bei HL1 Engine MetaMod direkt in die liblist.gam eingetragen, wäre nun natürlich fatal diese zu Löschen.
 
Gamepanels und Installscripte wie zB Teklab arbeiten auch mit Listen, jedoch mit teilweise unterschiedlichem Muster.
Hier ein Beispiel wie ich es verwende.

Liste:
Code:
orangebox/cstrike/addons/metamod
orangebox/cstrike/addons/sourcemod
orangebox/cstrike/addons/metamod.vdf
orangebox/cstrike/cfg/sourcemod
./smversion.txt
./sourcemod_css.list

Aussschnitt des Codes:
Code:
cat $DIR/$2.list |tr -d "\r" |while read list; do rm -Rf $list; done

Zum reinen auflisten gibt es viele Möglichkeiten, zB Find.
Eine relativ blöde wäre die Methode mit 'du' :D


MfG
Impact
 
Last edited by a moderator:
Wie gehst du bei dem Panel vor?
Hast du die Vorgehensweise von teklab/my-wi übernommen und installierst bei jedem Server und Addon alle Dateien?

Wenn man etwas effizienter Denkt, setzt man Symlinks ein. Wenn man das macht, hat man einen zentralen Ordner, auf dessen Inhalt die Kundendateien dann verlinkt sind.
Um den Ordner samt Unterordner rekursiv zu kopieren und nur die Dateien zu verlinken, kann man mit "cp -rS" arbeiten.
Das spart viel Festplattenspeicher und Wartungsaufwand.

Wenn man nach dem Installieren ein Addon entfernen möchte, hat man den Masterordner, den man als Dateiliste nutzen kann. So brauch man dann nicht für jedes Addon eine Liste anzulegen.
Code:
cd masterordner
find -type f | while read data
 do
  rm -f $gamefolder/$data
done
 
Ich merke schon hier gibt es viele Ideen dazu =)

Ich habe mich dazu entschieden mit einer Liste zu Arbeiten, diese in den Kunden Ordner zu legen.

Den Vorteil den ich darin sehe ist das wenn sich etwas am Archiv verändert hat, dennoch alle Dateien entfernt werden da die Dateiliste aus dem Kunden Ordner genommen wird. Somit kann man gewährleisten das alles Rückstandlos entfernt wird.

Und seien wir mal ehrlich, in der Heutigen Zeit noch auf Festplatten Speicher zu achten, ist Schwachsinn :D

Die meisten Dedicated haben eine 500GB (abzüglich des OS und MFT etc.) Platte drin, auf so einer Maschine werden auch wenn dann nur allerhöchsten 20 Server Installiert macht also (450 / 20) 22,5GB für jeden.

Dann könnte man je nach Prinzip noch hingehen und den Speicher für die Game Images abziehen, sagen wir mal macht nochmal 50GB wären wir dann bei 400GB bleiben immer noch je Kunde 20GB Speicher.

Dazu auch gleich nochmal die Frage, wir macht ihr das mit dem Game Images? Ich wollte diese auf jedem Dedicated Anlegen, den Vorteil darin sehe ich vorallem in der Installationsgeschwindigkeit, da diese nicht geladen werden müssen sondern einfach nur entpackt werden müssen. Ich gehe von dem Fall aus das man kein Cage oder Rack besitzt und entsprechend auch nicht unbedingt ein VLAN oder sogar direkt per LAN an den Image Server kommt.
 
Und seien wir mal ehrlich, in der Heutigen Zeit noch auf Festplatten Speicher zu achten, ist Schwachsinn :D

Wenn man schon einmal das Wort SSD gehört und sich die Preise dazu angeschaut hat, würde man eine solche Aussage nicht treffen.

Effizientes Arbeiten zeigt sich auch darin, dass man Recourcen spart, obwohl man nicht muss.
Ein gutes Beispiel dafür:
Code:
cat datei.txt | grep 'Phrase' | wc -l
grep 'Phrase' datei.txt | wc -l
grep -c 'Phrase' datei.txt

;)

Mal abgesehen vom Platz gibt es die Faktoren Wartung und Zeit.
Vergleich einmal die Zeit bei:
tar -xf css.tar
cp -rS /pfad/masterorder/css /pfad/kunde/gameserver

Wenn ein Update für den Server veröffentlicht wird, updatet man dann den Master und man hat seine Ruhe.
Auch hier einmal vergleichen:
- jeden Server einzeln updaten
- einen zentralen Server je Spiel und dedizierten Rootserver
 
Wenn man schon einmal das Wort SSD gehört und sich die Preise dazu angeschaut hat, würde man eine solche Aussage nicht treffen.

Ist ja für GameServer ziemlich uninteressant, schneller oder besser Laufen tun die damit ja trotzdem nicht. Und mehr Verbaut werden tun diese ebenfalls nicht, daher sprechen wir hier nach wie vor von Mechanischen Platten.

Mal abgesehen vom Platz gibt es die Faktoren Wartung und Zeit.
Vergleich einmal die Zeit bei:
tar -xf css.tar
cp -rS /pfad/masterorder/css /pfad/kunde/gameserver

Das mag wohl sein dass das eine Theoretisch weniger Zeit braucht als das andere. Mir als Hoster ist das aber relativ egal, ich drücke auf Reinstallieren und fertig. Der Rest wird vom SH Script abgearbeitet.

Aber mit einem Tar Archiv spare ich ja auch wieder Ressourcen, denn ein Archiv ist kleiner als ein Entpackter Ordner. CoD4 z.B. hat nunmal gut 7GB. Damit widersprichst du dir auch selbst :P

Wenn ein Update für den Server veröffentlicht wird, updatet man dann den Master und man hat seine Ruhe.
Auch hier einmal vergleichen:
- jeden Server einzeln updaten
- einen zentralen Server je Spiel und dedizierten Rootserver

Damit ist man auch gleich wieder unflexible, was ist denn wenn der Kunde seinen Server nicht updaten möchte? Oder es kommt raus dass das Update nicht läuft und den Server dadurch unbrauchbar macht, so könnte der Kunde autoupdate ausschalten und hätte das Problem nicht.

Zumindest bei den Steam Server würde ich mir meine Finger nicht krumm machen, dafür liegt in jedem Server Ordner die steam bin durch ein quit in die Console Updatet sich der Server selbst. Ansonsten macht man halt ein neues Image was der Kunde einfach auch als Update einspielen kann, so kann der Kunde ebenfalls entscheiden ob er das Update möchte oder nicht.
 
Ist ja für GameServer ziemlich uninteressant, schneller oder besser Laufen tun die damit ja trotzdem nicht. Und mehr Verbaut werden tun diese ebenfalls nicht, daher sprechen wir hier nach wie vor von Mechanischen Platten.
SSDs werden mittlerweile immer öfter verbaut. Gerade Gameserver dürften bei Ladezeiten wie Map-Changes von der SSD profitieren. Insbesondere wenn da (wie du schreibst) 20 Gameserver auf "einer" Platte laufen.

Das mag wohl sein dass das eine Theoretisch weniger Zeit braucht als das andere. Mir als Hoster ist das aber relativ egal, ich drücke auf Reinstallieren und fertig.
Den Kunden ist das aber gewiss nicht egal. Die wollen alles und zwar sofort. Die interessiert es nicht ob du etwas entpacken musst oder nicht.
Und spätestens wenn der Kunde dir die Ohren volljammert, weil er keine X Minuten warten will, wird es auch dich als Hoster interessieren.

Aber mit einem Tar Archiv spare ich ja auch wieder Ressourcen, denn ein Archiv ist kleiner als ein Entpackter Ordner. CoD4 z.B. hat nunmal gut 7GB. Damit widersprichst du dir auch selbst :P
Mathe?
Ein entpackter Ordner von 7GB + 20 Instanzen via Symlink entsprechen immernoch 7GB + paar Bytes für die Symlinks. Seien wir also mal sehr großzügig und sagen 7,01GB.
Dein Tar-Archiv hat vielleicht eine Größe von 4GB, die entpackten Instanzen 7GB. (20*7)+4=144GB.
Merkst du was?

Oder es kommt raus dass das Update nicht läuft und den Server dadurch unbrauchbar macht
Updates testet man, bevor sie eingespielt werden. Insbesondere bei zahlender Kundschaft. Das betrifft auch Gameserver.
 
Mein Eindruck durch diesen und andere Threads ist es, dass du versuchst teklab nachzubauen.

Wie wäre es, wenn du versuchst die Schwächen dieses Systems zu erkennen und nicht zu wiederholen?

Ein .tar Archiv komprimiert nicht, sondern fasst nur zusammen.
Wenn man Archive benutzen will, um Platz zu sparen, dann benutze man gleich tar.bz2, tar.gz, usw. Nur .tar zu nutzen ist da relativ sinnfrei.

Wenn man konsequent ist, dann baut man auch den Protection Modus ein, den die ESL fordert. Nur so kann man alle potentiellen Kunden erreichen.

Bei den allermeisten Hostern wird beim Start ein Server komplett neu aufgesetzt. 7GB zu entpacken kostet seine Zeit. Diese will der Kunde nicht warten.
cp -rS dauert nur wenige Sekunden.

Zu SSDs:
Das wird die Zukunft sein. Mittelfristig mag man noch mechanische Platten verwenden. Der Trend geht aber jetzt schon Richtung SSD.

Zu Symlinks kann man noch anfügen:
Die großen Gameserverhoster wie ngz, 4netplayer, g-portal etc. setzen alle Symlinks ein.
Der Großteil der Kinderzimmerhoster volle Installationen je Kunde.
 
Nur mal so ein Tipp am Rande: Fast nach jedem Steam-Update ist es notwendig den Server zu aktualisieren. Da ist es ******egal ob der Kunde das will oder nicht. Die Kunden werden dir viel eher die Ohren volljammern, wenn sie nicht mehr auf den Serve rkommen, weil der Server nicht mehr aktuell ist und das Update nicht funktioniert, weil mal wieder die Steam-Server überlastet sind.

Da ist ein Konzept mit Master und Slave viel perfomanter und platzsparender. Um nur mal auf das Thema SSD zu kommen. Mittlerweile sind die 160GB SSDs fast bezahlbar. Wäre es da nicht toll, z.B. alle Masterdateien der Server auf die SSD auszulagern? Dank mount kann das Verzeichnis des Masterservers dort eingegangen werden, wo das Webinterface/Shellscript sie erwartet. Ein System mit vielen eigenen Installationen würde das z.B. nicht zulassen. Dort müsstest du erstmal eine SSD finden, die groß genug wäre.

Um das ganze mal weiter zu spinnen, könntest du die Masterdateien sogar im RAM auslagern. Heutige Server haben oftmals 12 GB RAM. Da ist es kein Problem eine 3 GB große CS:S-Installation per Script in den Speicher auszulagern und danach zu Mounten. Das ganze könnte nach dem Serverrestart on-the-fly passieren und hätte keinerlei Auswirkung auf bereits gestartete Server.

Ist nur mal so eine Idee meinerseits.
 
SSDs werden mittlerweile immer öfter verbaut. Gerade Gameserver dürften bei Ladezeiten wie Map-Changes von der SSD profitieren. Insbesondere wenn da (wie du schreibst) 20 Gameserver auf "einer" Platte laufen.
Maximal 20 GameServer, das wäre aber auch schon ziemlich krass, kommt halt letztlich immer auf die Maschine drauf an.

Nunja, was die Map Changes angeht, da haben sich die Zocker wohl dran gewöhnt und so langsam ist das ja auch nicht. Ich hab aber nun auch keine Tests da ;)

Den Kunden ist das aber gewiss nicht egal. Die wollen alles und zwar sofort. Die interessiert es nicht ob du etwas entpacken musst oder nicht.
Und spätestens wenn der Kunde dir die Ohren volljammert, weil er keine X Minuten warten will, wird es auch dich als Hoster interessieren.
Das mag wohl sein, aber solange dauert es ja auch nicht, auch hier habe ich keine Versuche gemacht zwischen cp und tar xfv, werde es allerdings mal berücksichtigen und Testen.

Mathe?
Ein entpackter Ordner von 7GB + 20 Instanzen via Symlink entsprechen immernoch 7GB + paar Bytes für die Symlinks. Seien wir also mal sehr großzügig und sagen 7,01GB.
Dein Tar-Archiv hat vielleicht eine Größe von 4GB, die entpackten Instanzen 7GB. (20*7)+4=144GB.
Merkst du was?
Mein Beispiel bezog sich auf lediglich 1 Ordner bzw. 1 Archiv, nicht auf eine Mehrzahl, ein Denkfehler :D

Bzgl. Symlinks, mir erschließt sich jedoch gerade nicht so ganz wie dann der Kunde nach belieben Daten ändern darf? Ihm gehört ja dann nichtmal der Maps Ordner, entweder hab ich was nicht bedacht oder ihr nicht.

Updates testet man, bevor sie eingespielt werden. Insbesondere bei zahlender Kundschaft. Das betrifft auch Gameserver.
Da frage ich mich wie viele Hoster das tun xD
Ich kann nicht, wenn ich 40 - 50 Games anbiete und für 5 - 8 Updates kommen diese ausgiebig testen. Soviel Games hätte ich ja nichtmal. Solche Spiele wie Minecraft oder sowas würde ich auch gar nicht Spielen wollen :D

Mein Eindruck durch diesen und andere Threads ist es, dass du versuchst teklab nachzubauen.
Der Eindruck täuscht nicht so ganz :D
Aber nachbauen will ich das nicht unbedingt. Das Interface läuft bei mir in einem CMS nicht als Standalone. Die meisten Features sind halt Basics, klar das ich das auch so übernehme.

Wie wäre es, wenn du versuchst die Schwächen dieses Systems zu erkennen und nicht zu wiederholen?
Das Versuche ich natürlich an gewissen punkten.
Wie z.B. das ein Kunde soviel FTP Accounts anlegen kann wie er will, das bietet soweit mir bekannt Teklab nicht.

Ein .tar Archiv komprimiert nicht, sondern fasst nur zusammen.
Wenn man Archive benutzen will, um Platz zu sparen, dann benutze man gleich tar.bz2, tar.gz, usw. Nur .tar zu nutzen ist da relativ sinnfrei.
Selbstverständlich nutze ich tar.gz => gzip --best archiv.tar :P

Wenn man konsequent ist, dann baut man auch den Protection Modus ein, den die ESL fordert. Nur so kann man alle potentiellen Kunden erreichen.
Mit diesem Mode habe ich mich um ehrlich zu sein bisher nicht befasst. Ich hätte auch nicht wirklich eine Idee diesen zu Realisieren. Und die ESL fuckt eh ziemlich ab, natürlich man muss mit dem Trend gehen, dem Kunden das geben was er will. 10000FPS Server werden ja immer noch gemietet obwohl es absolut GAR nichts mehr bringt.

Bei den allermeisten Hostern wird beim Start ein Server komplett neu aufgesetzt. 7GB zu entpacken kostet seine Zeit. Diese will der Kunde nicht warten.
cp -rS dauert nur wenige Sekunden.
Wie gesagt, mache ich auch nicht anderst. Werde es mal Testen und schauen. Ich war aber immer der Meinung ein tar xfv geht schneller als ein cp, keine Ahnung wieso :D

Zu Symlinks kann man noch anfügen:
Die großen Gameserverhoster wie ngz, 4netplayer, g-portal etc. setzen alle Symlinks ein.
Der Großteil der Kinderzimmerhoster volle Installationen je Kunde.
Na dann möchte ich mich doch lieber abheben :P
Natürlich bin ich immer bestrebt alles so effektiv wie möglich zu gestalten und bisher war ich der Meinung das ich das tue. Jedoch bekommt man durch dieses Forum auch andere Perspektiven da sich mehr Leute darum Gedanken machen. Aber wie oben schon angemerkt, wie realisiert man soetwas? Der Kunde soll ja schliesslich eine "Vollwerige" Installation haben.

Da ist ein Konzept mit Master und Slave viel perfomanter und platzsparender. Um nur mal auf das Thema SSD zu kommen. Mittlerweile sind die 160GB SSDs fast bezahlbar. Wäre es da nicht toll, z.B. alle Masterdateien der Server auf die SSD auszulagern? Dank mount kann das Verzeichnis des Masterservers dort eingegangen werden, wo das Webinterface/Shellscript sie erwartet. Ein System mit vielen eigenen Installationen würde das z.B. nicht zulassen. Dort müsstest du erstmal eine SSD finden, die groß genug wäre.
Das ist korrekt, die großen Vorzüge habe ich jedoch im Bereich GameServer noch nicht gefunden. Denn so Plattenlastig sind GameServer insgesamt nicht, nur bei gewissen Aktionen. Bei Datenbanken und WebServer mag das natürlich wieder sinn machen.

Um das ganze mal weiter zu spinnen, könntest du die Masterdateien sogar im RAM auslagern. Heutige Server haben oftmals 12 GB RAM. Da ist es kein Problem eine 3 GB große CS:S-Installation per Script in den Speicher auszulagern und danach zu Mounten. Das ganze könnte nach dem Serverrestart on-the-fly passieren und hätte keinerlei Auswirkung auf bereits gestartete Server.

Ist nur mal so eine Idee meinerseits.
Hört sich natürlich ziemlich genial an. Aber erstmal verfolge ich andere Ideen, bevor ich anfange und Daten in den RAM auslagere :P
 
Du solltest dir einmal die Manpage von cp durchlesen, dann würdest du nicht fragen, warum cp schneller sein soll.
-R, --recursive copy directories recursively
-s, --symbolic-link make symbolic links instead of copying

Wenn man also den Befehl "cp -sR master ziel", hat der Kunde alle Ordner und an Stelle der Dateien Symlinks.

Lässt man vor cp -sR Dateien, die der Kunde editieren muss/soll, kopieren und erst danach den -sR Befehl, hat man eine Vollwertige Installation und der Kunde hat alle notwendigen Freiheiten.

Wenn du dir im Anschluss die Dateigröße von Symlinks anschaust, dann wirst du staunen und begreifen, warum der Befehl so schnell läuft.
 
@Terrorkarotte

Bei cp denke ich an Kopieren, die Option s hat für mich erst Sinn gemacht als ich den Befehl mal ausführte :D

Klar das es dadurch enorm Schnell ist, wird ja quasi nix erstellt.

Nunja, dann müsste ich nun nur noch jede Datei irgendwie finden und in eine Liste eintragen welche der Kunde editieren darf. Irgendwo macht ja alles wieder Arbeit =)
 
Das ist eigentlich ziemlich einfach.

Eins vorweg, der Befehl cp -sR kopiert Dateien als symbolische Verknüpfungen. Verzeichnisse werden als echte Verzeichnisse erstellt. -r/-R erwirkt, dass der Befehl alle Verzeichnisse rekursiv durchläuft (also alle Unterverzeichnisse usw..)

Um zu dem Ziel zu kommen, welches du erreichen willst, kannst du erst damit anfangen ein Template aus echten Dateien in das Kundenverzeichnis zu kopieren (gleiche Struktur wie der Server). Diese Dateien kann/soll der Kunde zukünftig bearbeiten können. Dazu zählen z.B. die motd.txt, maplist.txt, server.cfg, autoexec.cfg.

Danach kommen die eigentlichen Masterdateien, die der Kunde nicht ändern soll. Diese kopierst du dann nachträglich mit cp -sr in das Kundenverzeichnis. Es werden keine bestehenden Dateien überschrieben.

Dann kannst du noch Optional einen Mappool mit cp-sR kopieren. Würde auch Sinn machen, da der Kunde dann z.B. schon den Mappool hätte, den man in der ESL so braucht.

Nach jedem Serverupdate einmal ein cp -sR auf jedes Kundenverzeichnis, damit auch neu hinzugekommene Dateien verfügbar sind.

Ich habe angefangen seit 2005 diese Technik zu verwenden. Insiriert wurde ich durch meinen Provider. Nachdem ich mich gefragt habe, was das für komische Dateien, die FTP-Programm wie eine Verknüpfung aussehen, fing ich an mich damit zu beschäftigen. Mein erstes kleines Script hatte ich schnell geschrieben und siehe da, das Updaten machte dann bei 5 Servern richtig Spaß. Script ausführen und 5 Minuten warten. Die meiste Zeit ging eigentlich nur durch das Steam-Update drauf. Letztes Jahr hab ich damit angefangen mich mit dem Tool srcdsupdatecheck auseinander zu setzen. Ich habe mein Script dann so verändert, dass es alle 7 Minuten ausgeführt wird und nur wenn ein Serverupdate verfügbar gewesen ist, dieses auch mit den anderen Operationen zusammen durchgeführt worden ist. Das hat mir zu einem System verholfen, welches völlig unabhängig vom Admin arbeitet. Einzig um die Plugins musste man sich kümmern, wenn diese mal durch ein Update wieder nicht gingen.



Nächster Schritt wäre die Installation von Pluginpaketen, wobei dort die Dateien auch größtenteils aus Symlinks bestehen würden. Auch da müsstest du wieder nachdenken und üüberprüfen, welche Dateien der Kunde ändern kann/soll. Wenn es dabei dann z.B. möglich sein soll symlinks durch den Kunden löschen zu lassen, welches aber global verboten ist, könntest du mit einer .ftpaccess im jeweiligen addonverzeichnis des Plugins ansetzen. Dazu brauchst du aber proftpd. Das ist mir der einzig bekannte FTP-Server der so flexibel ist.


Der Protection-Mode steht auf einem ganz anderem Blatt. Die Server sollten möglichst gekapselt von den anderen laufen (Zugriffsberechtigungen des Servers auf andere Kundenserver unterbinden). Erlaubst du den FTP-Zugriff, bist du gezwungen mit den FTP-Regeln zu arbeiten. Der Kunde darf z.B. keine Dateien von Plugins hochladen (alles mit .so am Ende). Der Kunde sollte auch nicht irgendwelche Dateien vom eigentlichen Server austauschen dürfen. Der ServerSideHack ist eher ein fast nicht existentes Problem. Hierbei wurde es von der ESL nur gepuscht, damit die ihr Zertifikat verkaufen können. Letztendlich spielt das aber auch keine Rolle. Die Kunden wollen einen sicheren "Protection-Mode" und dafür hat zur Zeit nur der Provider zu sorgen.

Du mit deinem WI legst dann von vorne herein, ob ein Provider dein WI für den "Protection-Mode" überhaupt verwenden kann. Sollte dein WI das nicht können, schließt du einen Großteil potenzieller Kunden aus. Du solltest bei der Konzeption deines WI immer daran denken.


http://downloads.sourceserver.info/docs/de/serververlinkung/
http://downloads.sourceserver.info/docs/de/serververlinkung/serververlinkung.pdf

Irgendwo hatte ich das auch mal in einem Forum geschrieben. Hab jetzt aber keine Lust danach zu suchen.
 
Hallo,

ja super, genau danach hatte ich gesucht :D
Hatte das im Forum schon gefunden, war aber nicht mehr verfügbar.

Die Plugins lade ich derzeit komplett als tar Archiv in den Ordner des Kunden. Der Kunde soll ja dort eh alles ändern können. Wichtig ist vorallem das der Kunde die Binär Dateien nicht mehr ändern kann.

Bzgl. des Protection Mode, da würde ich dann einfach einen Ordner anlegen like /home/user/server_protected wobei der Kunden nur FTP Accounts auf /home/user/server anlegen kann. Die Sachen wie RCON, Hostname etc. kann man ja über Startparameter machen. Ich denke damit das man komplett den FTP Zugriff verweigert wirkt auch der Mode am besten.

Also mein WI soll keine Kaufversion werden, ich möchte mit dem WI 1. Geld Sparen 2. Vor allem KEIN Teklab nutzen und 3. Das ganze auf meine Bedürfnisse bzw. des Kunden anpassen können.

Letztlich ist es meine Persönliche Einstellung so etwas selbst schaffen zu können, klar ich kann mir alles zusammenkaufen, aber ein Webinterface für GameServer ist wie ich finde keine große Sache, bei Webhosting würde ich lieber auf ispCP oder Kostenpflichtig auf Plesk zurückgreifen.
 
Der Kunde soll ja dort eh alles ändern können. Wichtig ist vorallem das der Kunde die Binär Dateien nicht mehr ändern kann.

Was denn nun? Die Sätze widersprechen sich.

Bzgl. des Protection Mode, da würde ich dann einfach einen Ordner anlegen like /home/user/server_protected wobei der Kunden nur FTP Accounts auf /home/user/server anlegen kann. Die Sachen wie RCON, Hostname etc. kann man ja über Startparameter machen. Ich denke damit das man komplett den FTP Zugriff verweigert wirkt auch der Mode am besten.

Nicht nur der Ordner, aus dem ausgeführt wird entscheidet. Es ist auch sehr relevant, wie der ausführende User auf Ordner und Dateien zugreifen kann, die nicht im protected Ordner liegen.

ein Webinterface für GameServer ist wie ich finde keine große Sache

Es kommt auf die Ansprüche an, ob es eine große Sache ist, oder nicht.
 
Back
Top