Problem beim ausführen eines scripts mit shell_execute
Re: Problem beim ausführen eines scripts mit shell_execute
hat da jemand noch ne idee?
Re: Problem beim ausführen eines scripts mit shell_execute
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).
kannst du zum Testen verwenden, um den Befehl mit www-data auszuführen.
Code: Alles auswählen
su -c "sudo -u arkserver...." www-data
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Re: Problem beim ausführen eines scripts mit shell_execute
su -c "sudo -u arkserver /home/arkserver/arkserver start" www-dataTRex hat geschrieben: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).
kannst du zum Testen verwenden, um den Befehl mit www-data auszuführen.Code: Alles auswählen
su -c "sudo -u arkserver...." www-data
=
This account is currently not available.
Re: Problem beim ausführen eines scripts mit shell_execute
Na Mist. Dachte ich mir schon fast... du kannst ihn wie folgt aktivieren:
Danach wieder deaktivieren:
und das su als root (oder mit sudo) ausführen - sonst musst du das Passwort für www-data kennen.
Code: Alles auswählen
usermod -s /bin/sh www-data
Code: Alles auswählen
usermod -s /usr/sbin/nologin www-data
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Re: Problem beim ausführen eines scripts mit shell_execute
hm also habs aktiviert dann den befehl ausgeführt und dann wider deaktiviert.TRex hat geschrieben:Na Mist. Dachte ich mir schon fast... du kannst ihn wie folgt aktivieren:
Danach wieder deaktivieren:Code: Alles auswählen
usermod -s /bin/sh www-data
und das su als root (oder mit sudo) ausführen - sonst musst du das Passwort für www-data kennen.Code: Alles auswählen
usermod -s /usr/sbin/nologin www-data
Aber warum führt er das nicht per php script aus? Also das start, denn stop nimmt er ja
Re: Problem beim ausführen eines scripts mit shell_execute
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)
Insbesondere steht da auch nochmal der COMMAND.
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
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Re: Problem beim ausführen eines scripts mit shell_execute
TRex hat geschrieben: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)Insbesondere steht da auch nochmal der COMMAND.Code: Alles auswählen
grep sudo /var/log/auth.log
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
Re: Problem beim ausführen eines scripts mit shell_execute
Ich hoffe, dass du den Rest auch gelesen hast. Das war kein tl;dr
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Re: Problem beim ausführen eines scripts mit shell_execute
Was evtl. noch von Bedeutung sein könnte, das script was den arkserver startet startet den server dann wiederrrum mit tmuxTRex hat geschrieben:Ich hoffe, dass du den Rest auch gelesen hast. Das war kein tl;dr
evtl. liegt es daran, das da irgendwie was blockt
hab das script jetzt umgeschrieben dass es mit screen geht