Problem beim ausführen eines scripts mit shell_execute

[C0kkie]

hat da jemand noch ne idee?

[TRex]

Ich würd nochmal beide Zeilen in die sudoers aufnehmen (einmal start, einmal mit stop) und dann nochmal als user www-data prüfen, obs wirklich nicht funktioniert. Und keine Bildschirmfotos mehr, bitte. In Putty den Text markieren, dann ist er in der Zwischenablage von Windows (ich unterstelle dir an der Stelle, dass du putty verwendest).

Code: Alles auswählen

su -c "sudo -u arkserver...." www-data

kannst du zum Testen verwenden, um den Befehl mit www-data auszuführen.

[C0kkie]

Ich würd nochmal beide Zeilen in die sudoers aufnehmen (einmal start, einmal mit stop) und dann nochmal als user www-data prüfen, obs wirklich nicht funktioniert. Und keine Bildschirmfotos mehr, bitte. In Putty den Text markieren, dann ist er in der Zwischenablage von Windows (ich unterstelle dir an der Stelle, dass du putty verwendest).

Code: Alles auswählen

su -c "sudo -u arkserver...." www-data

kannst du zum Testen verwenden, um den Befehl mit www-data auszuführen.

su -c "sudo -u arkserver /home/arkserver/arkserver start" www-data

=

This account is currently not available.

[TRex]

Na Mist. Dachte ich mir schon fast... du kannst ihn wie folgt aktivieren:

Code: Alles auswählen

usermod -s /bin/sh www-data

Danach wieder deaktivieren:

Code: Alles auswählen

usermod -s /usr/sbin/nologin www-data

und das su als root (oder mit sudo) ausführen - sonst musst du das Passwort für www-data kennen.

[C0kkie]

Na Mist. Dachte ich mir schon fast... du kannst ihn wie folgt aktivieren:

Code: Alles auswählen

usermod -s /bin/sh www-data

Danach wieder deaktivieren:

Code: Alles auswählen

usermod -s /usr/sbin/nologin www-data

und das su als root (oder mit sudo) ausführen - sonst musst du das Passwort für www-data kennen.

hm also habs aktiviert dann den befehl ausgeführt und dann wider deaktiviert.
Aber warum führt er das nicht per php script aus? Also das start, denn stop nimmt er ja

[TRex]

Du musst dafür sorgen, dass du kontrollierst und dir bewusst bist,

1. wie der Befehl aufgerufen wird
2. in welchem Environment der Befehl aufgerufen wird (ob es zB spezielle Umgebungsvariablen gibt, PATH gefüllt ist usw...)
3. welche Seiteneffekte der Befehl hat und wie du rausbekommst, welche
4. wie du an die Ausgabe des Befehls kommst.

2 mag für dich noch etwas kryptisch klingen, aber möglich wärs, dass du nach Sicherstellung von 3. (dass du evt ein Logfile von ark selbst findest) und 4. (dass du auch ein Logfile schreibst) rausfindest, dass der PHP-Prozess irgendwas braucht, was es in dem schmalen Environment nicht gibt. Momentan fliegst du blind, und ich schrubb die Glaskugel. Das ganze muss reproduzierbar werden... wenn du morgen aufstehst, dich auf dem Server einloggst und was anderes als heute passiert, ist das nicht der Fall.

In deinem Beitrag steht etwas, was ich so deuten könnte, als obs nun insgesamt funktioniert hätte. In den Systemlogs sollte der Authentifierungsversuch mit sudo auftauchen... du solltest zusätzlich zu dem obigen schauen, ob dein manueller Aufruf die gleichen Logzeilen erzeugt wie der Aufruf über PHP.

(als root)

Code: Alles auswählen

grep sudo /var/log/auth.log

Insbesondere steht da auch nochmal der COMMAND.

[C0kkie]

Du musst dafür sorgen, dass du kontrollierst und dir bewusst bist,

1. wie der Befehl aufgerufen wird
2. in welchem Environment der Befehl aufgerufen wird (ob es zB spezielle Umgebungsvariablen gibt, PATH gefüllt ist usw...)
3. welche Seiteneffekte der Befehl hat und wie du rausbekommst, welche
4. wie du an die Ausgabe des Befehls kommst.

2 mag für dich noch etwas kryptisch klingen, aber möglich wärs, dass du nach Sicherstellung von 3. (dass du evt ein Logfile von ark selbst findest) und 4. (dass du auch ein Logfile schreibst) rausfindest, dass der PHP-Prozess irgendwas braucht, was es in dem schmalen Environment nicht gibt. Momentan fliegst du blind, und ich schrubb die Glaskugel. Das ganze muss reproduzierbar werden... wenn du morgen aufstehst, dich auf dem Server einloggst und was anderes als heute passiert, ist das nicht der Fall.

In deinem Beitrag steht etwas, was ich so deuten könnte, als obs nun insgesamt funktioniert hätte. In den Systemlogs sollte der Authentifierungsversuch mit sudo auftauchen... du solltest zusätzlich zu dem obigen schauen, ob dein manueller Aufruf die gleichen Logzeilen erzeugt wie der Aufruf über PHP.

(als root)

Code: Alles auswählen

grep sudo /var/log/auth.log

Insbesondere steht da auch nochmal der COMMAND.

Nov 9 17:31:16 ns3019232 sudo: www-data : TTY=unknown ; PWD=/var/www/ark-webinterface/include/functions ; USER=arkserver ; COMMAND=/home/arkserver/arkserver start
Nov 9 17:31:16 ns3019232 sudo: pam_unix(sudo:session): session opened for user arkserver by (uid=0)
Nov 9 17:31:19 ns3019232 sudo: pam_unix(sudo:session): session closed for user arkserver

mehr steht da nicht, es wundert mich halt warum stop geht, und warum bei start im error.log steht:

failed to connect to server: Connection refused

[TRex]

Ich hoffe, dass du den Rest auch gelesen hast. Das war kein tl;dr

[C0kkie]

Ich hoffe, dass du den Rest auch gelesen hast. Das war kein tl;dr

Was evtl. noch von Bedeutung sein könnte, das script was den arkserver startet startet den server dann wiederrrum mit tmux
evtl. liegt es daran, das da irgendwie was blockt

hab das script jetzt umgeschrieben dass es mit screen geht