php startet über exec() EXE und waaaaaaaartet endlos

Hey Leute,

ich kann mittels php einen Windows-Arma-Server starten (Konsolen-Version). Das klappt folgendermaßen:
[src=php]exec("analyse\SteamCmd\arma3\arma3server.exe -config=server.cfg -port=YYYY",$err);[/src]

Allerdings lädt das Script dann endlos weiter. Auch die max_execution_time(30) ändert daran nichts. Witzig ist, dass, wenn ich die Server-Konsole dann manuel beende, ein FATAL ERROR erscheint, der mich auf die 30 Sekunden aufmerksam macht. Aber egal, ob ich nach 5 Sekunden oder 5 Minuten beende.

Der Server gibt in seiner eigenen Konsole zurück:

22:19:25 Dedicated host created.
22:19:29 BattlEye Server: Initialized (v1.208)
22:19:29 Host identity created.
22:19:29 Game Port: XXXX, Steam Query Port: YYYY

Zum Vergrößern anklicken....

1. Ich verstehe nicht, warum sich PHP nicht damit zufrieden gibt, dass der Server läuft. Das Programm ist doch gestartet. Warum läuft das PHP-Skript nicht weiter?
2. Warum ignoriert er die 30 Sekunden? Ein Ändern auf 5 Sekunden ändert nichts an dem Problem, sondern nur die Fatal-Error-Meldung... Also total sinnlos.

Ehrlich du solltest den Server deaktivieren und das Hosting Leuten überlassen die zumindest eine grobe Idee von ihrem Job haben.

Allein dieser Post sagt mir schon wieder viel zu viele Sachen die bei dir schief laufen.

na ja, das Programm läuft ja noch. PHP wartet eben auf die Beendigung des Servers.

http://stackoverflow.com/questions/45953/php-execute-a-background-process#45966
http://php.net/manual/en/function.exec.php#86329

alter_Bekannter schrieb:

Ehrlich du solltest den Server deaktivieren und das Hosting Leuten überlassen die zumindest eine grobe Idee von ihrem Job haben.

Zum Vergrößern anklicken....

Ich verstehe solche Posts immer nicht. Ich habe alles auf einer Entwicklungsumgebung laufen, die von außen nicht erreichbar ist. Also kann ich doch gefahrlos üben. Diese Arroganz gegenüber Lernenden verdirbt einem jedes Mal die Lust, sich mit Neuem zu beschäftigen. Da dein Post wirklich keinerlei weiterführenden Inhalt hat, frage ich mich, warum du dir überhaupt die Mühe machst, zu schreiben.


@phre4k: danke für deine Antwort. Ich konnte mir schon denken, dass der Elternprozesse auf den Kindprozess wartet. Der Vorschlag in den Links läuft auf etwas hinaus, das ich schon probiert und umgesetzt habe: das Auslagern des laufenden Prozesses in den Hintergrund.

[src=javascript]<script type="text/javascript">

function start_server(){
var xmlHttp = null;
try {
xmlHttp = new XMLHttpRequest();
} catch(e) {
try {
xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
} catch(e) {
try {
xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
} catch(e) {
xmlHttp = null;
}
}
}
if (xmlHttp) {
xmlHttp.open('GET', 'test2.php', true);
xmlHttp.onreadystatechange = function () {
if (xmlHttp.readyState == 4) {
alert(xmlHttp.responseText);
}
};
xmlHttp.send(null);
}}
</script>

<input type="Submit" name="action" value="Server starten" onclick="start_server()";> [/src]

Die test2.php ruft dann den Code aus meinem ersten Beitrag auf. Das funktioniert tatsächlich. Die test2.php läuft dann allerdings trotzdem so lange wie der Server, nur dass man sie nicht mehr sieht. Wird dann der Server beendet, stirbt die test2.php wieder mit FatalError im Hintergrund, zeigt aber dennoch den Fehler an, wenn des test.php-Browserfenster noch offen ist.

Mein letzter Versuch ging über eine Batch-Datei, die mit dem Präfix "start" die Anwendung ins Rollen bringt und dann weiterarbeitet (nur "exit"). Das funktioniert aber nur, wenn ich sie händlisch ausführe. Aufgerufen durch das Php-Skript verhält es sich wie vorher - es wartet, bis ich den Serve selbst beende. Wie kann das sein?

batch:

@echo OFF
start C:\........\arma3server.exe -config=server.cfg -port=YYYY
exit

Zum Vergrößern anklicken....

Wenn ich nach dem Startbefehl noch den Befehl eintrage, eine Textdatei zu erstellen, wird das auch erledigt. Also arbeitet er tatsächlich weiter. Das PHP-Skript hängt aber trotzdem auf Ewigkeiten.

@nietaL: kenne mich mit Windows nicht so 100% aus, würde das eher mit Wine machen und müsste jetzt selbst googlen.

Aber könnte mir vorstellen, dass bei cmd auch nur bei direktem Aufruf geforkt wird und das bei nem Aufruf durch PHP nicht mehr geht. Vielleiht kannst du den Interpreter vornedran stellen, wie bei bash unter Linux? Also C:\Windows\cmd.exe script.bat oder so ähnlich...?

Bist du dir sicher, dass es notwendig ist, den Server via PHP zu starten? Das ganze über ein JavaScript zu realisieren halte ich für wenig sinnvoll, weil es halt auch ohne geht, z. B. wenn man die Note im PHP Manual zum exec-Befehl liest.

Worauf alter_bekannter wohl hinweisen wollte sind die Nachteile von exec. Wenn viele Leute auf deinen Server starten Button hauen, erzeugst du unnötig Last auf deinem Server, im Falle eines Angriffs ist es über einen Button, der sofort exec aufruft ziemlich leicht den Server abzuschießen. Warum soll das ganze über den Button realisiert werden?

Wenn es dir nur um die Fehlerneldung geht: setz Display_errors in deiner php.ini auf false.

Edit: @phre4k: unter Windows wird aus exec("foo -bar -baz"); ein cmd /c foo -bar -baz

Als ich 2003 mit PHP rumgespielt habe, hab ich mir immer die Seite zu einer Funktion durchgelesen. Bei exec steht zufälligerweise

Hinweis:

Falls Sie diese Funktion benutzen, um ein Programm zu starten und im Hintergrund weiterlaufen lassen möchten, müssen Sie sicherstellen, dass die Ausgabe des Programms in eine Datei oder einen anderen Ausgabestream umgeleitet wird. Anderenfalls wird PHP solange hängen, bis das Programm zu Ende ausgeführt wurde.

Zum Vergrößern anklicken....

Unten in den Kommentaren stehen Lösungen für dein "Problem".

@nietaL:

Dann solltest du vielleicht ein paar zusätzliche Angaben machen gepaart mit deinem letzten Thread sieht das hier fürchterlich aus, denn es beschreibt ein leider absolut gängiges worst-case Scenario.

Anfänger denkt: Ich nehm Windowsserver weil das total einfach ist und nicht so kompliziert. Ich hab gehört mit Plesk kann man alles super toll in einer einfachen GUI machen. Ich hab zwar keine Ahnung was überhaupt installiert ist oder gar Verbindungen von außen annimmt, aber es läuft doch alles prima! Was ich nicht sehe interessiert mich nicht.

Und gerade dieses Problem hier hätte man sofort mit Google gefunden weils wie erwähnt sogar bei exec() steht.

Das ist keine Arroganz gegenüber lernenden sondern gegenüber Ignoranten. Richtig, man kann nicht alles wissen, aber wenn man Meldungen zu bekannten Lücken ignoriert weil man nicht mal wusste das Dienst X überhaupt läuft dann ist das in der heutigen Zeit einfach Ignoranz. Denn gerade weil man nicht mit dem Wissen auf die Welt kommt sollte einem genau das klar sein. "Oh, ich weiss das nicht, ich sollte vorsichtig sein." Seine erste Erfahrung mit eine Tischkreissägen macht man schließlich auch nicht indem man mit 3 Stück mit verbundenen Augen jongliert. Oder hast du die Markierung des Ninjas und siehst jeden Elektron in deinem Server?

Falls nicht musst du dich wohl auf den wissenschaftlichen Ansatz verlassen:
Beobachten
Hypothese aufstellen
die Hypothese testen

Alles unter den geeigneten Vorsichtsmaßnahmen versteht sich, das hat gleich 2 Nutzen:
1. Man eliminiert ein paar Variablen vorab
2. Schadensbegrenzung

Beides wird dank des Dunning-Krueger Effekts vernachlässigt.

Aber wenn es sich um eine Testumgebung handelt dann ist das wohl trotz der vielen Alarmglocken:
-Plesk
-mangelhaft eingerichteter Windowsserver
-willkürliche "Anonymisierung von Daten" (Warum die Ports wenns lokal ist? Selbst öffentlich würden die keine Rolle spielen. Name des Logs aber nicht. Auch die ganze PHP-Info wurde einfach veröffentlicht...)
-Info direkt aus der Doku ignoriert(die einen hohen Pagerank hat)

...wohl alles in Ordnung.

Wem das nicht das erwähnte Bullshit Bingo ziemlich gefüllt hat, der werfe den ersten Stein.

Naja das war die ausführliche Version falls sie dich wirklich interessiert ich bin skeptisch.

Das mit dem Button ist natürlich nur zum Testen gewesen. Später wird er nach Erstellung der Serverparameter selbstständig und natürlich nur einmal im HG starten.Wenn alter_bekannter mich darauf hinweisen wollte, hätte er es getan. Wie auch immer: ich danke euch. Abul, deinen Link habe ich natürlich gleich anfangs, als ich auf mein Problem (ohne Anführungsstriche) stieß, konsultiert. Ich hatte zu dem Zeitpunkt folgendes probiert:

start.bat

@echo ON
echo test
start "" "SteamCmd\arma3\arma3server.exe"
echo test2
pause

Zum Vergrößern anklicken....

[src=php]
if($server['server']==0)
{
mysqli_query($db, "UPDATE status SET server = '1' WHERE runde = '1'");
echo "<br>SERVER STARTET ...<br>";

function execInBackground($cmd)
{
if (substr(php_uname(), 0, 7) == "Windows")
{
pclose(popen("start /B ". $cmd, "r"));
} else {
exec($cmd . " > /dev/null &");
}
}

execInBackground("SteamCmd\arma3\start.bat");

echo "<br>SERVER GESTARTET";
}
[/src]

Zumindest hätte ich meine Hand dafür ins Feuer gelegt, dass ich genau das schon ausprobiert habe. Jedenfalls funktioniert es nun so.
Danke schön.

Nur zum Verständnis: da ich ja weiß, dass es auf einem Windows-Server laufen wird, kann ich das Skript ja sorglos einkürzen, oder?

[src=php]
if($server['server']==0)
{
mysqli_query($db, "UPDATE status SET server = '1' WHERE runde = '1'");
echo "<br>SERVER STARTET ...<br>";

pclose(popen("start /B ". "SteamCmd\arma3\start.bat", "r"));

echo "<br>SERVER GESTARTET";
}
[/src]

oder?



@ alter_bekannter: Hochinteressiert habe ich deine Ausführungen studiert. Einiges war nachvollziehbar, vieles nicht. Ich habe die php.info getilgt. Danke. Das mit den Ports ist natürlich Quatsch gewesen, aber lieber zu viel als zu wenig anonymisieren. Der Dunning-Kruger-Effekt trifft nicht zu.
1. Ich schätze meine Kompetenzen als nicht sonderlich hoch ein, sonst wäre ich nicht hier und entwickelte nicht offline. (auch wenn ich noch ein Elektron trotz Ninja-Fähigkeiten übersehen habe)
2. Ich schätze deine Kompetenzen und derer, die mir hier versuchen zu helfen, als sehr hoch ein.

Aber warte 'mal: Vielleicht trifft er doch zu, weil ich inkompetent bin, zu erkennen, dass ich dem Dunning-Kruger-Effekt doch unterworfen bin. Oder so ...

Wenn du das ganze nur einmal pro Runde/was auch immer (kenne das Spiel nicht) machen möchtest warum nutzt du keine Cron Jobs? Ich find das total Banane da PHP noch mit reinzuziehen um ein bat Script auszuführen

@nietaL:
Das Bezog sich nicht explizit auf dich, ich habe ja schon, vielleicht zu subtil zugegeben das ich die Situation vielleicht falsch eingeschätzt habe. Weil ich aus erwähnten Gründen ziemlich skeptisch war und immer noch bin. Es gibt halt ne Menge Affen die es exakt so machen. Abe einer gewissen Menge an Indikatoren geht man dann vom schlimmsten aus.

Aber wie Teufelskreis schon sagte PHP eignet sich dafür überhaut nicht. Aber unter Windows kannst du doch prima die .Net Sachen benutzen, die können das.

Musst du allerdings mit OOP anfangen für, kann aber eh nicht schaden. Wenns unbedingt Web sein muss sieh dir ASP(.Net) an. Ich kenns zwar nur in der ekligen VB Variante aber vielleicht geht auch C Syntax.

Naja, es werden über das Web Daten eingegeben, die für den Game-Server von Wichtigkeit sind. Und ich schätze meine Kompetenzen (und berufsbedingt Zeit) als nicht ausreichend, um OOP, ASP und VB parallel zu lernen. :-D Bei PHP fühle ich mich wenigstens ETWAS sicherer :-p

Ich hoffe, dass du die Nutzereingaben vernünftig abfängst und nicht irgendwie in deinen exec-Befehl reinlaufen lässt. Weil dann brennt es wirklich :-(

Ich führe gerne nochmal was länger aus, was das Problem an PHP und exec ist: Man wird dazu verleitet, die gesamte Software und alle Konfigurationsdateien ins DocumentRoot oder darunter zu speichern. Da gehört sowas aber nicht hin, weil's dann für alle Welt lesbar ist. Das ist eine ziemlich unangenehme Sache, weil da teils sicherheitsrelevante Sachen drinstehen und du es Angreifern so sehr leicht machst, Sicherheitslücken zu finden und auszunutzen. Dazu noch eine bat-Datei, die ständig aufgerufen wird -- das kann sehr schnell in die Hose gehen und dein Server verteilt Malware ohne Ende. Und deshalb reagieren hier teilweise Menschen etwas ungehalten: Malware werden so gut wie immer von gekaperten Servern nachgeladen, die Software die das tut ist meistens unverdächtig. Wenn jeder seine Server gescheit administrieren würde, wäre das Malwareproblem heute nicht so groß wie es ist.

Bitte tu' dir selbst einen Gefallen und überlege dir etwas, wie man das ganze ohne Webserver administrieren und verwalten kann. Reicht ja schon, wenn die Login-Maske zum Konfigurator nicht SSL/TLS verschlüsselt ist und einer deiner Verwalter sich in einem öffentlichen WLAN einloggt -- dann kann jeder an deiner Konfiguration rumspielen.

Also WENN das irgendwann einmal soweite sein sollte, dass das funktioniert, wie ich mir das dachte, wäre ich durchaus auch bereit, etwas zum Aufstöbern von Sicherheitslücken zu investieren. Versierte Menschen gibt es ja genug. ;-) Wahrscheinlich wäre es weniger Aufwand auf so etwas von Anfang an zu achten, aber was solls. Es ist nur ein beiläufiges Hobby - ein Hobby, bei dem ich aber dank eurer Eingebung nun noch mehr auf Sicherheit achten werden - versprochen

Ist eigentlich in solchen Fällen relativ einfach, einfach keine Userinputs weiterreichen. Die nötigen Presets mit switch/case regeln.

Also es gibt zumindest keine textfelder. Nur dropdown, radiobuttons usw. Oder ist das irrelevant für die Sicherheit?

Ist es, denn es ist die Clientside und die ist unter Clientkontrolle.

In diesem Konkreten Fall reichen die Debugging features eines Browsers zum aushebeln. Von schwer ist das so weit entfernt wie irgendwie möglich.

Aber es bestätigt das du es Regeln kannst wie ich es gesagt habe.

Alles was auf dem System (egal ob windows oder linux) etwas ausführen könnte hat auf einer Webseite nichts verloren außer es ist zwingend notwendig und die Webschnittstelle gesondert abgesichert - das trifft aber nur in sehr wenigen Fällen zu.

Global sollten exec genauso wie system, passthru(), shell_exec() und evtl. ein paar mehr deaktiviert werden.
Dein vorhaben lässt sich anders viel schöner Managed (und sicherer).

Warum speicherst du deine Einstellungen, eingaben what ever nicht in eine Datenbank -dort gehören Daten hin.
alle 1-5min lässt du einen cronjob laufen der alle *neuen* / *geänderten* noch nicht verarbeiteten DB-Einträge ausliest und startest deine Anwendung > update auf die DB.
Damit lassen sich die Rechte der Anwendung, die Rechte auf die Daten, auf die Prozesse usw. detailiert regeln und auf ein Minimum reduzieren.

Das Starten lässt sich Global Monitoren, Das Starten des Dienstes ist unabhängig vom Benutzer der auf der Seite irgendwie *warten* muss.
Bei einem Neustart des Servers lässt sich der gleiche Prozess verwenden um die Umgebung wieder komplett zu starten.

Den Cronjob kannst du dann von mir aus sogar in php schreiben und über php -c ausführen. Oder aber in jeder anderen Scriptsprache die unter Windows zur Verfügung steht... powershell, vb-script - dafür ist noch nicht mal .net nötig. (außer bei Powershell für den DB-Connect insofern man nicht auf ext. programme zugreifen möchte - die mysql commandline anwendung ginge auch)


@Eingabefelder auf der Webseite - ein *Angreifer* muss / wird nicht deine Webseite besuchen oder verwenden - es ist kein Problem die Anfragen die der Webbrowser erzeugt und an den Webserver sendet von *Hand* zu erzeugen und selber dort hin zu schicken mit beliebigen Inhalten.
Es ist die Aufgabe des Empfängers die Daten zu prüfen - nicht des Absenders (der Absender in diesem Szenario der Webbrowser kann dies zusätzlich tun um dem Besucher ein schöneres Benutzer-Erlebnis zu geben)

Hältst du in diesem Kontext deine Vorschlag nicht für fatal missverständlich?

Denn der reine Umweg über die Datenbank macht die Userinputs nicht sicher! Das fügt hier eher noch eine weite Schicht die man angreifen kann hinzu. Schließlich muss man dann je nach Konstrukt noch aufpassen das sich die Sachen dann nicht kombinieren lassen. Oder Eingaben von SQL anders verarbeitet werden als vom nachfolgenden Programm.

Den Userinput nicht - daher ja auch der letzte Satz der evtl. im Verhältnis zu kurz gekommen ist das sich die Anwendung um Validierung der Eingabe kümmern muss.
Da eine Rechtetrennung stattfindet finde ich die Anggriffsfläche so schon kleiner, im Zweifel wird der *schmarn* an Usereingaben als Parameter an die .exe übergeben die den Dienst startet - aber zumindest lassen sich keine beliebigen .exe starten die auf dem System sind - oder zumindest im Webverzeichnis (k.a eine Spieleuser-passwort-rücksetz-exe) usw.