Umleitung in Datei bei Sudo?

[Andreas Mandalka]

Hi.

Habe hier ein Problem, wenn ich sudo benutze.

Wenn ich folgende Zeile als entsprechender Benutzer, dem die Datei gehört)
ausführe:
./etded.x86 +set fs_homepath ${GS_HOME} [...] 2>server.log
dann funktioniert alles wie es soll; etded.x86 wird ausgeführt und in der
Serverlog steht, was drin stehen soll.

Wenn ich obere Zeile in eine Datei hineinpacke und die mittels sudo
ausführe:
sudo -u ${GS_USER} screen -dmS gameserver-${GS_USER} DATEI_MIT_BEFEHL.bash
dann funktioniert es auch.

Wenn ich allerdings den ganzen Aufruf in eine Zeile schreibe (also oberste
Zeile inklusive sudo):
sudo -u ${GS_USER} screen -dmS gameserver-${GS_USER} ./etded.x86 +set
fs_homepath [...] 2>server.log
dann wird die Datei server.log nicht angelegt. Wenn ich vorher die Datei
selbst anlege und dem Benutzer die Schreibrechte geben, funktioniert es auch
nicht; die Datei bleibt einfach leer. Das Programm an sich läuft jedoch.

Woran könnte das liegen? Ist für mich wichtig, dass es alles in einer Zeilt
funktioniert, bzw. in einem Skript.

Mfg

Andreas.

[Christian Schneider]

Post by Andreas Mandalka
Habe hier ein Problem, wenn ich sudo benutze.
Wenn ich folgende Zeile als entsprechender Benutzer, dem die Datei gehört)
./etded.x86 +set fs_homepath ${GS_HOME} [...] 2>server.log
dann funktioniert alles wie es soll; etded.x86 wird ausgeführt und in der
Serverlog steht, was drin stehen soll.
Wenn ich obere Zeile in eine Datei hineinpacke und die mittels sudo
sudo -u ${GS_USER} screen -dmS gameserver-${GS_USER} DATEI_MIT_BEFEHL.bash
dann funktioniert es auch.
Wenn ich allerdings den ganzen Aufruf in eine Zeile schreibe (also oberste
sudo -u ${GS_USER} screen -dmS gameserver-${GS_USER} ./etded.x86 +set
fs_homepath [...] 2>server.log
dann wird die Datei server.log nicht angelegt. Wenn ich vorher die Datei
selbst anlege und dem Benutzer die Schreibrechte geben, funktioniert es auch
nicht; die Datei bleibt einfach leer. Das Programm an sich läuft jedoch.

Verstaendlich, da nur screen, aber nicht die Umleitung "2>server.log"
von sudo(8) ausgefuehrt wird.

[Andreas Mandalka]

Christian Schneider wrote:

[...]

Post by Christian Schneider
Verstaendlich, da nur screen, aber nicht die Umleitung "2>server.log"
von sudo(8) ausgefuehrt wird.

Jupp, das klingt logisch, hätte ich drauf kommen müssen.

Und wie kriege ich es hin, dass das ganze funktionsfähig in einem Script
stehen kann?

Mfg

Andreas.

[Christian Schneider]

Post by Andreas Mandalka
[...]

Post by Christian Schneider
Verstaendlich, da nur screen, aber nicht die Umleitung "2>server.log"
von sudo(8) ausgefuehrt wird.

Jupp, das klingt logisch, hätte ich drauf kommen müssen.
Und wie kriege ich es hin, dass das ganze funktionsfähig in einem Script
stehen kann?

Steht in der Manpage unter /EXAMPLES

sudo sh -c "... 2>server.log"

[Helmut Waitzmann]

Christian Schneider <***@gmx.net> writes:

[Sudo-Manual-Page]

Post by Christian Schneider
Steht in der Manpage unter /EXAMPLES
sudo sh -c "... 2>server.log"

Dabei schüttelt es mich: Der OP wird für die »...« eine Kommandozeile
einsetzen wollen, die zwei Shell-Variablen-Aufrufe »${GS_USER}« enthält.
Das wird dabei -- je nach Inhalt der Shell-Variablen -- gehörig auf die
Schnauze fallen...

Die Methode der Wahl ist

sudo sh -c 'exec ${1+"$@"} 2>server.log' sh ...

Und weil niemand das Manual-Page sh(1) richtig liest, war auch irgend
jemand auf die hirnrissige Idee gekommen, das bei Debian bisher
verwendete Programm »su« so abzuändern, dass es für die Nichtleser
scheinbar einfacher wird. Dass es damit sowohl das Single Unix
Specification als auch das Linux Standard Base bricht, war jenem Jemand
egal. (Inzwischen ist dieser Fehler endlich behoben. Irgendwann wird
die Korrektur dann auch in Debian Stable auftauchen.)

[Helmut Waitzmann]

Post by Helmut Waitzmann
Und weil niemand das Manual-Page sh(1) richtig liest, war auch irgend
jemand auf die hirnrissige Idee gekommen, das bei Debian bisher
verwendete Programm »su« so abzuändern, dass es für die Nichtleser
scheinbar einfacher wird.

Hier muss ich präzisieren, um Missverständnisse zu vermeiden:

Ich weiß nicht, wer das verhunzte »su« entwickelt hatte, und ich weiß
auch nicht, ob in Debian jemals ein unverhunztes »su« war oder ob »su«
gleich in verhunzter Form nach Debian kam.

[Helmut Waitzmann]

Post by Andreas Mandalka
Wenn ich folgende Zeile als entsprechender Benutzer, dem die Datei gehört)
./etded.x86 +set fs_homepath ${GS_HOME} [...] 2>server.log
dann funktioniert alles wie es soll; etded.x86 wird ausgeführt und in der
Serverlog steht, was drin stehen soll.
Wenn ich obere Zeile in eine Datei hineinpacke und die mittels sudo
sudo -u ${GS_USER} screen -dmS gameserver-${GS_USER} DATEI_MIT_BEFEHL.bash
dann funktioniert es auch.
Wenn ich allerdings den ganzen Aufruf in eine Zeile schreibe (also oberste
sudo -u ${GS_USER} screen -dmS gameserver-${GS_USER} ./etded.x86 +set
fs_homepath [...] 2>server.log
dann wird die Datei server.log nicht angelegt. Wenn ich vorher die Datei
selbst anlege und dem Benutzer die Schreibrechte geben, funktioniert es auch
nicht; die Datei bleibt einfach leer. Das Programm an sich läuft jedoch.
Woran könnte das liegen?

Die Umlenkung des Fehlerkanals, »2>server.log«, wird vom das Kommando
interpretierenden Shell, nicht vom »sudo«-Programm bewerkstelligt.

Was musst Du also tun? Starte mittels »sudo« ein Shell, das die
Umlenkung vornimmt und die Aufgabe übergeben bekommt, den Programmaufruf
»./etded.x86 ...« vorzunehmen.

Das geht so:

sudo -u ${GS_USER} screen -dmS gameserver-${GS_USER} \
sh -c 'exec ${1+"$@"} 2>server.log' sh \
./etded.x86 +set fs_homepath ${GS_HOME} [...]

Hinweis: Die »\« an den Zeilenenden bedeuten, dass die nächste Zeile
eigentlich hintendran gehört. Du musst sie also genau dann weglassen,
wenn Du alles in eine sehr lange Zeile schreiben willst.

Um zu verstehen, was bei diesem Kommando (soll heißen, bei »sh -c ...«
passiert, lies im Manual-Page des Shells im Abschnitt »OPTIONS« bei
Option »-c«, im Abschnitt »PARAMETERS« beim Unterabschnitt »Special
Parameters«, »@«, und im Abschnitt »EXPANSION«, »Parameter Expansion«
nach.

Ohne, dass Du das verstanden hast, solltest Du die Kommandozeile
eigentlich dem Shell nicht überantworten, mindestens nichts daran ändern.

Post by Andreas Mandalka
Ist für mich wichtig, dass es alles in einer Zeilt funktioniert, bzw. in
einem Skript.

Sollte es tun.

Du solltest Dich dringend schlau machen, was es heißt, einem Shell eine
Kommandozeile zur Ausführung zu übergeben und folgende Aussagen und
Fragen bedenken:

In Unix/Linux gibt es beim Start eines Programms keine Kommandozeilen
sondern nur Programmaufrufe, denen Parameter mitgegeben werden.

Nun scheint aber

$ Programm mit Parametern und 2>Umlenkung

eine Kommandozeile zu sein.

Doch wie entsteht nun aus der Zeile ein Programmaufruf mit
Parameterliste?

Was hat das Shell dabei zu tun?

Wie unterscheidet sich in der Kommandozeile die Kanalumlenkung
»2>Umlenkung« von einem an das Programm übergebenen Parameter, der aus
der Zeichenfolge »2>Umlenkung« besteht?

Wie wird dem Shell mitgeteilt, welche Wörter der Kommandozeile
Kanalumlenkungen und welche Parameter sind?

Wer nimmt die Kanalumlenkung vor?

Wenn Du die Fragen beantworten kannst, dann ist auch das von Dir
geschilderte Verhalten zu erklären.