exec()-Ausführung unter Linux funzt net!
Kerstin
- php
Hallo liebe Leute,
ich habe hier ein wenig was in PHP unter WIN programmiert. Da läufts auch ganz gut. Nun versuche ich es unter Linux zum laufen zu bringen. Der PHP-Code selbst läuft recht gut, bis auf eine Sache: Weder exec noch shell_exec oder ein anderes Kommando zur Programmausführung funktioniert. Es passiert einfach nichts! Keine Ausgabe, keine Fehlermeldung! Das per exec ausgeführte Programm soll zwei Dateien einlesen und eine erzeugen. Unter Win wie gesagt funzt das. Die Frage ist nun, warum das unter Linux GAR NICHT geht!?
Ich nutze Apache 2.2 und PHP 5.1.4, habe in der php.ini safe_mode auf Off gesetzt, so dass exec etc. eigentlich funktionieren sollten.
Der auszuführende Befehl funktioniert in der Konsole eingegeben übrigens prima! Nur eben nicht per exec aus PHP heraus. Gibts da noch nen Trick? Dieser sollte natürlich sowohl in Win und Linux funktionieren.
Hat jemand eine Idee? Ich steh da im Moment total aufn Schlauch.
Gruß,
Kerstin
hallo,
Weder exec noch shell_exec oder ein anderes Kommando zur Programmausführung funktioniert. Es passiert einfach nichts!
Du müßtest bitte das Stückchen relevanten Quellcode angeben. Und am besten auch, was du mit exec ausführen lassen willst.
Die Frage ist nun, warum das unter Linux GAR NICHT geht!?
Das tut es durchaus.
Ich nutze Apache 2.2 und PHP 5.1.4
Das ist die übliche ungenaue Angabe. Einen Apache 2.2 gibt es nicht. Gib bitte an, ab du einen Apache 2.2.0 oder einen Apache 2.2.2 benutzt, und es ist auch nicht ganz uninteressant, welche Linux-Distribution du einsetzt.
Grüße aus Berlin
Christoph S.
hallo,
Weder exec noch shell_exec oder ein anderes Kommando zur Programmausführung funktioniert. Es passiert einfach nichts!
Du müßtest bitte das Stückchen relevanten Quellcode angeben. Und am besten auch, was du mit exec ausführen lassen willst.
$command = escapeshellarg($xfcpath.$docbookpara.$docbook.$docbookxmlfile.$docbookxsl);
exec($command);
Die Variable $command hat dann diese Form:
'../xfc/xslutil -v ../docbookhtml/manual-1-1.html ../docbook/manual-1-1.xml ../docbookxslt/mydocbookhtml.xsl'
Die Frage ist nun, warum das unter Linux GAR NICHT geht!?
Das tut es durchaus.
Wär mal interessant zu erfahren was, denn Ausgaben gibt es nicht, obwohl system, shell_exec oder auch passthru ja Ausgaben produzieren sollten. Wenn ich die dann aber per echo ausgeben möchte, bleibt die Ausgabe ganz einfach leer!
Ich nutze Apache 2.2 und PHP 5.1.4
Das ist die übliche ungenaue Angabe. Einen Apache 2.2 gibt es nicht. Gib bitte an, ab du einen Apache 2.2.0 oder einen Apache 2.2.2 benutzt, und es ist auch nicht ganz uninteressant, welche Linux-Distribution du einsetzt.
Na gut, aber wenigstens habe ich überhaupt eine gemacht ;)
Etwas genauer: Apache 2.2.2 mit PHP 5.1.4. -> eigentlich XAMPP 1.5.3a, da sind die vorher aufgelisteten Komponenten mit drin. Das ganze läuft auf einem Debian-System.
Gruß,
Kerstin
hallo Kerstin,
$command = escapeshellarg($xfcpath.$docbookpara.$docbook.$docbookxmlfile.$docbookxsl);
exec($command);
Wow.
Die Variable $command hat dann diese Form:
'../xfc/xslutil -v ../docbookhtml/manual-1-1.html ../docbook/manual-1-1.xml ../docbookxslt/mydocbookhtml.xsl'
Nö, hat sie nicht (scheint mir so, es sei denn, $docbookpara hätte den Wert "-v"). Du klebst sie aus fünf Bestandteilen (Variablen) zusammen, gibst hier aber nur vier an ;-p
Und ich habe erstmal Mühe, herauszufinden, ob der resultierende String überhaupt in dieser Form an exec() übergeben werden darf.
Die Frage ist nun, warum das unter Linux GAR NICHT geht!?
Das tut es durchaus.
Wär mal interessant zu erfahren was
Vielleicht hilft es dir, im PHP-Handbuch nachzulesen, was exec() tut.
Apache 2.2.2 mit PHP 5.1.4. -> eigentlich XAMPP 1.5.3a, da sind die vorher aufgelisteten Komponenten mit drin.
Äks. Warum man XAMPP unter Windows installieren möchte, kann ich zur Not noch verstehen. Aber Apache 2.2.2 kann mit dem bisher letzten offiziellen PHP 5.1.4 unter Windows nichts anfangen. Wenn die Apache-Friends sowas in ihr Paket integriert haben, so müssen sie irgendeinen Patch für PHP verwendet haben, oder sie haben eben gleich das noch nicht freigegebene PHP 5.2 eingesetzt - siehe übrigens dieser Thread.
Das ganze läuft auf einem Debian-System.
Debian ist die konservativste aller Linux-Distributionen. Wenn du dort "apt-get install apache" eingibst, wird dir Apache 1.3.34 eingerichtet, und wenn du "apt-get install apache2" fährst, bekommst du einen Apache 2.0.54. Nix da mit Apache 2.2.x, den mußt du dir dann schon selber kompilieren.
Ich weiß zwar, daß die Apache-Friends ihr XAMPP auch für Linux anbieten, aber ich werde mich hüten, das zu nutzen, weil ich immer erst nachsehen müßte, was sie wie kompiliert haben. _Alle_ Bestandteile gibt es für _jede_ Linux-Distribution auch so zu freien Download. Wenn man sie sich selber zusammenbaut, weiß man wenigstens, was sie tun.
Grüße aus Berlin
Christoph S.
Hallo Christoph,
danke für deine Antworten.
Wow.
Ja, nicht.
Die Variable $command hat dann diese Form:
'../xfc/xslutil -v ../docbookhtml/manual-1-1.html ../docbook/manual-1-1.xml ../docbookxslt/mydocbookhtml.xsl'Nö, hat sie nicht (scheint mir so, es sei denn, $docbookpara hätte den Wert "-v"). Du klebst sie aus fünf Bestandteilen (Variablen) zusammen, gibst hier aber nur vier an ;-p
Und ich habe erstmal Mühe, herauszufinden, ob der resultierende String überhaupt in dieser Form an exec() übergeben werden darf.
Genau das steht im String $command, den man durch Angabe von echo $command erhält und den exec() zum ausführen erhält. Dabei ist es doch eigentlich wurscht, ob 5 Variablen, auch 5 Parameter ergeben. Wie gesagt, unter Windows funzt es so. In diesem Fall ist es so, dass $docbookpara = "-v" ist. Kann man ja auch weg lassen. Dann siehts halt so aus:
'../xfc/xslutil ../docbookhtml/manual-1-1.html ../docbook/manual-1-1.xml ../docbookxslt/mydocbookhtml.xsl'
$docbookpara ist in diesem Fall leer. Es gibt aber weitere Fälle, in dem er gesetzt ist.
Vielleicht hilft es dir, im PHP-Handbuch nachzulesen, was exec() tut.
Nee, nicht wirklich. Ich kenne das PHP-Manual und konsultiere es, um u.a. nach geeigneten Funktionen zu suchen. exec ist eine Möglichkeit. Es gibt auch andere Funktionen zur Programmausgabe, die ebenfalls nichts ausgeben.
Äks. Warum man XAMPP unter Windows installieren möchte, kann ich zur Not noch verstehen. Aber Apache 2.2.2 kann mit dem bisher letzten offiziellen PHP 5.1.4 unter Windows nichts anfangen. Wenn die Apache-Friends sowas in ihr Paket integriert haben, so müssen sie irgendeinen Patch für PHP verwendet haben, oder sie haben eben gleich das noch nicht freigegebene PHP 5.2 eingesetzt - siehe übrigens dieser Thread.
Unter Windows hätte ich weniger Probleme einen Apachen 2.2.2 mit einem PHP 5 per Hand zu installieren als XAMPP zu nutzen. Unter Linux ist diese Kombination nur mit Hilfe von XAMPP möglich.
Debian ist die konservativste aller Linux-Distributionen. Wenn du dort "apt-get install apache" eingibst, wird dir Apache 1.3.34 eingerichtet, und wenn du "apt-get install apache2" fährst, bekommst du einen Apache 2.0.54. Nix da mit Apache 2.2.x, den mußt du dir dann schon selber kompilieren.
Um nicht auf Apache 1.3.34 zurückgreifen zu müssen, oder eben den Apache 2.0.54 mit einer veralteten PHP 4 Version, habe ich mich eben für XAMPP entschieden.
Ich weiß zwar, daß die Apache-Friends ihr XAMPP auch für Linux anbieten, aber ich werde mich hüten, das zu nutzen, weil ich immer erst nachsehen müßte, was sie wie kompiliert haben. _Alle_ Bestandteile gibt es für _jede_ Linux-Distribution auch so zu freien Download. Wenn man sie sich selber zusammenbaut, weiß man wenigstens, was sie tun.
Ich will doch programmieren, nicht kompilieren. Für meine Zwecke reicht XAMPP völlig. Einstellungen kann man dort ebenso vornehmen. Es gibt sogar die normale httpd.conf. Bei der Installation von Apache 2 darf man erstmal nach den Einstellungsdateien suchen. Eine httpd.conf gibts da nicht. Die heißt apache2.conf. Aber das nur mal so am Rande.
Tja, mit meinem Problem bin ich damit auch nicht weiter und ob der Einsatz eines selbst kompilierten Apache 2 und PHP 5 die Lösung ist, bezweifle ich.
Ich tippe mittlerweile stark auf Zugriffsrechte, die fehlen. Die Frage ist halt, wie man das einstellt, dass eine Programmausführung möglich ist. Im PHP-Manual steht soweit ich das sehe nichts dazu.
Gruß und Gute Nacht,
Kerstin
hallo Kerstin,
Ich tippe mittlerweile stark auf Zugriffsrechte, die fehlen
Das ist immerhin eine Idee, die du verfolgen solltest.
Grüße aus Berlin
Christoph S.
Hallo Kerstin.
Um nicht auf Apache 1.3.34 zurückgreifen zu müssen, oder eben den Apache 2.0.54 mit einer veralteten PHP 4 Version, habe ich mich eben für XAMPP entschieden.
Diese Schlussfolgerung verstehe ich nicht. Was hat die Apache-Version mit der PHP-Version zu tun?
Ich nutze hier PHP 5.1.4 mit Apache 2.0.55 auf Debian Sid.
Bei der Installation von Apache 2 darf man erstmal nach den Einstellungsdateien suchen.
Hm? Wo als unter /etc/apache2 würdest du sie denn suchen wollen?
Eine httpd.conf gibts da nicht.
Doch, die gibt es, auch wenn sie nur als Platzhalter dient.
Die heißt apache2.conf. Aber das nur mal so am Rande.
Und wo ist das Problem? Ob die Konfigurationsdatei nun httpd.conf, apache2.conf oder husseldiguggeldu.foobar heißt, ist doch gänzlich irrelevant. Die Handhabung ist immer die selbe.
Einen schönen Donnerstag noch.
Gruß, Ashura
hallo Ashura,
Ob die Konfigurationsdatei nun httpd.conf, apache2.conf oder husseldiguggeldu.foobar heißt, ist doch gänzlich irrelevant
Nein, nicht ganz. Du mußt den gewünschten Namen während des Kompilierens angeben. Dann kannst du, wenns beliebt, auch husseldiguggeldu.foobar verwenden. Aber wenn du ein distributionsspezifisches Sourcenpaket oder eine Installationsroutine nimmst (apt-get install), kriegst du die Konfigurationsdatei mit dem Namen, den sich der Distributor ausgedacht hat.
Grüße aus Berlin
Christoph S.
hi,
Nun versuche ich es unter Linux zum laufen zu bringen. Der PHP-Code selbst läuft recht gut, bis auf eine Sache: Weder exec noch shell_exec oder ein anderes Kommando zur Programmausführung funktioniert.
Hast du dich informiert, ob diese Funktionen nicht vielleicht aus Sicherheitsgründen deaktiviert worden sind?
gruß,
wahsaga
Hallo wahasaga,
soweit ich weiß, würde safe_mode=On das Ausführen dieser Funktionen unterbinden. Hab dieses auf Off gesetzt. Gibt es noch an einer anderen Stelle die Möglichkeit, die Unterbindung aufzulösen? Z.B. beim Webserver selbst? Wenn ja, ist die Frage wo?
Gruß,
Kerstin
hi,
soweit ich weiß, würde safe_mode=On das Ausführen dieser Funktionen unterbinden. Hab dieses auf Off gesetzt. Gibt es noch an einer anderen Stelle die Möglichkeit, die Unterbindung aufzulösen?
disable_functions wäre eine weitere Möglichkeit (aber per Default sollte das leer sein).
gruß,
wahsaga
Hallo wahsaga,
disable_functions wäre eine weitere Möglichkeit (aber per Default sollte das leer sein).
Wie du schon meintest ist disable_functions leer.
Gruß,
Kerstin
Hi,
was sagt das error.log des Indianers?
Die meisten Fehler in dem Zusammenhand sind fehlende Ausführrechte oder falsche Pfade.
Was passiert, wenn du im Ordner, in dem das Script liegt, ds Shellkommando direkt ausführst, ohne PHP? Wenn das auch nicht funktioniert, liegts nicht am Script.
Hallihallo,
was sagt das error.log des Indianers?
Die meisten Fehler in dem Zusammenhand sind fehlende Ausführrechte oder falsche Pfade.
Da gugg ich gleich mal rein, wenn ich wieder unter Linux bin.
Was passiert, wenn du im Ordner, in dem das Script liegt, ds Shellkommando direkt ausführst, ohne PHP? Wenn das auch nicht funktioniert, liegts nicht am Script.
Per Konsole wird der Befehl einwandfrei ausgeführt, im selben Verzeichnis. Spielt es eigentlich eine Rolle, wenn ich meine PHP-Dateien über den Browser aus meinem eigenen home-Verzeichnis heraus ausführe? Also meine PHP-Dateien liegen in public_html und ich rufe sie dann so auf: http://localhost/~kerstin/index.php.
Ich habs mal ins htdocs-Verzeichnis vom Indianer gepackt. Der hat dann wegen fehlenden Zugriffsrechten gemeckert, als er scheinbar eine Ausgabedatei beim Ausführen des exec()-Befehls schreiben wollte. Allerdings kam diese Meldung viel zu schnell. Der Prozess bis eine Ausgabedatei raus kommt, dauert merklich ein paar Sekunden.
Gruß,
Kerstin
Hi Kerstin,
Per Konsole wird der Befehl einwandfrei ausgeführt, im selben Verzeichnis. Spielt es eigentlich eine Rolle, wenn ich meine PHP-Dateien über den Browser aus meinem eigenen home-Verzeichnis heraus ausführe? Also meine PHP-Dateien liegen in public_html und ich rufe sie dann so auf: http://localhost/~kerstin/index.php.
Das dürfte bei einem korrekt konfigurierten Apache eigentlich keine Rolle spielen.
Aber hier mal noch ein paar Vorschläge, was du noch ausprobieren kannst:
Ich gehe jetzt nämlich mal davon aus, dass du kein suExec oder suPHP verwendest, dann läuft das PHP-Script nämlich unter dem User, unter dem der Apache auch läuft - und der hat möglicherweise keine Zugriffsrechte auf das was du machen willst.
MfG, Dennis.
Hi Dennis,
Per Konsole wird der Befehl einwandfrei ausgeführt, im selben Verzeichnis. Spielt es eigentlich eine Rolle, wenn ich meine PHP-Dateien über den Browser aus meinem eigenen home-Verzeichnis heraus ausführe? Also meine PHP-Dateien liegen in public_html und ich rufe sie dann so auf: http://localhost/~kerstin/index.php.
Das dürfte bei einem korrekt konfigurierten Apache eigentlich keine Rolle spielen.
Aber hier mal noch ein paar Vorschläge, was du noch ausprobieren kannst:
- echo $command; in deinem PHP-Script, nimm die Ausgabe dort dann in den Zwischenspeicher...
- da du offensichtlich root-Rechte auf dem Server hast, wechsle zu dem Benutzer unter dem Apache läuft (unter Debian ist das www-run, da du aber XAMPP verwendest kann das alles und nichts sein)
- und führe dort den oben kopierten Befehl in dem Verzeichnis des PHP-Scriptes aus
Ich hab den Befehl in $command genommen und ihn in meinem Verzeichnis, dort wo auch die PHP-Skripte liegen als normaler User, wie ich es bin ausgeführt. Kein Problem. Is ja auch kein Wunder, is ja mein Verzeichnis. Dann hab ich mal alles in die htdocs vom xampp kopiert. Als normaler User ist da nix mit Datei schreiben. Klar eigentlich.
Ich gehe jetzt nämlich mal davon aus, dass du kein suExec oder suPHP verwendest, dann läuft das PHP-Script nämlich unter dem User, unter dem der Apache auch läuft - und der hat möglicherweise keine Zugriffsrechte auf das was du machen willst.
ja, ich verwende soweit mir bekannt kein suExec oder suPHP. Hab schon was gelesen hier im Forum, aber wozu das genau gut ist, stand da nicht wirklich.
Ich vermute auch schon langsam, dass es was mit Zugriffsrechten zu tun hat. Das Problem ist nur: Wie kriege ich das hin, dass der Apache das Programm per PHP-exec() ausführt und dann auch noch zulässt, Dateien von diesem Programm in das jeweilige Verzeichnis zu schreiben?
Gruß,
Kerstin
Hi Kerstin,
Ich hab den Befehl in $command genommen und ihn in meinem Verzeichnis, dort wo auch die PHP-Skripte liegen als normaler User, wie ich es bin ausgeführt.
Du solltest ihn aber nicht als normalen User, sondern als _genau der_ User, unter dem der Apache läuft ausführen! Alles andere ist nichts-aussagend.
Unter welchem User der Apache läuft steht in der Konfigurationsdatei des Apaches (welchen du ja als root startest), bei "User ..." - per su
kannst du dann zu dem User werden. (Solange der als Shell nicht /bin/false oder so hat, aber probiers einfach mal.)
ja, ich verwende soweit mir bekannt kein suExec oder suPHP. Hab schon was gelesen hier im Forum, aber wozu das genau gut ist, stand da nicht wirklich.
Hast du schon mal per PHP eine Datei angelegt? Die gehört dann nicht dem Benutzer kerstin, sondern dem Benutzer, unter dem Apache läuft, das kann sein www-run, apache oder auch nobody (oder ganz was anderes). Mit suExec läuft PHP nicht unter dem Apache-User, sondern unter einem anderen User (z.B. kerstin) - aber das ist jetzt erst mal nicht so wichtig. Solange du nur alleine an dem PC arbeitest brauchst du so etwas nicht wirklich.
Ich vermute auch schon langsam, dass es was mit Zugriffsrechten zu tun hat. Das Problem ist nur: Wie kriege ich das hin, dass der Apache das Programm per PHP-exec() ausführt und dann auch noch zulässt, Dateien von diesem Programm in das jeweilige Verzeichnis zu schreiben?
Gehe in dein Verzeichnis (/home/kerstin/public_html oder was auch immer), lege folgende PHP-Datei an:
~~~php
<?php
error_reporting(E_ALL);
ini_set("display_errors", true);
file_put_contents("test.txt", "hallo");
echo shell_exec("whoami");
?>
Dann rufe das Script über den Browser auf und poste uns die Ausgabe. Poste uns weiterhin die Ausgabe von `ls -la` deines Verzeichnises (also /home/kerstin/public\_html).
MfG, Dennis.
--
Mein [SelfCode](http://community.de.selfhtml.org/fanprojekte/selfcode.htm): [ie:{ fl:( br:> va:) ls:\[ fo:) rl:( n4:# ss:) de:\] js:| ch:{ sh:| mo:} zu:|](http://www.peter.in-berlin.de/projekte/selfcode/?code=ie%3A%7B+fl%3A%28+br%3A%3E+va%3A%29+ls%3A%5B+fo%3A%29+rl%3A%28+n4%3A%23+ss%3A%29+de%3A%5D+js%3A%7C+ch%3A%7B+sh%3A%7C+mo%3A%7D+zu%3A%7C)
[Patch zur Verwendung von PATHINFO in JLog](http://www.gymnasium-odenthal.de/~dennis/jlog/PATHINFO-Fix-1.0.1/)
Mit Gesetzen ist es wie mit Würstchen - es ist besser, wenn man nicht weiß, wie sie gemacht werden. (Otto v. Bismarck)
Hi Dennis,
Gehe in dein Verzeichnis (/home/kerstin/public_html oder was auch immer), lege folgende PHP-Datei an:
~~~php
<?php
error_reporting(E_ALL);
ini_set("display_errors", true);
file_put_contents("test.txt", "hallo");
echo shell_exec("whoami");
?>
Das gibt mir folgende Meldung:
Warning: file\_put\_contents(test.txt) [function.file-put-contents]: failed to open stream: Keine Berechtigung in /home/kerstin/public\_html/test.php on line 8
nobody
Da is nix mit reinschreiben in test.txt. Die gibts ja auch gar nicht in dem Verzeichnis. Ansonsten wär der user wohl nobody. Nur wie führe ich auf der Konsole den Befehl als nobody aus. Wie ich zu root werde, weeß ich ja. Mehr brauchte ich ja bisher nicht wissen.
> Dann rufe das Script über den Browser auf und poste uns die Ausgabe. Poste uns weiterhin die Ausgabe von `ls -la` deines Verzeichnises (also /home/kerstin/public\_html).
Das sieht so aus:
drwxr-xr-x 5 kerstin kerstin 4096 2006-06-28 15:53 .
drwxr-xr-x 21 kerstin kerstin 4096 2006-06-29 12:06 ..
drwxr-xr-x 16 kerstin kerstin 4096 2006-06-29 12:29 project
-rwxr-xr-x 1 kerstin kerstin 21 2005-10-25 10:58 phpinfo.php
Meine PHP-Skripte liegen im Verzeichnis project unter php, da gibts dann noch mehr Verzeichnisse.
Scheinbar war doch irgendwas falsch am Pfad, den ich sonst angegeben hab. Statt exec("whoami"); Hab ich einfach mal den Befehl so ganz da reinkopiert, und er ging. Davon mal abgesehen, dass es jetzt andere Probleme gibt, kam jetzt jedenfalls nicht mehr der Fehler von wegen "Datei oder Verzeichnis nicht gefunden". Dafür wird jetzt ins error\_log folgendes geschrieben:
Exception in thread "main" java.lang.NullPointerException
at java.io.File.<init>(File.java:180)
at com.xmlmind.xslutility.a.if(Unknown Source)
at com.xmlmind.xslutility.CommandLine.main(Unknown Source)
Ob dann am Ende aber dann wirklich die AusgabeDatei wird, steht noch offen. Denn durchgelaufen ist der Befehl, wie gesehen ja noch nicht. Naja, ich bastele mal noch ein wenig weiter. Muss ja irgendwie hinzukriegen sein. Mal schaun, ob ich noch mehr im Netz dazu finde.
THX für eure Hilfe.
Gruß,
Kerstin
Hi Kerstin,
Da is nix mit reinschreiben in test.txt. Die gibts ja auch gar nicht in dem Verzeichnis. Ansonsten wär der user wohl nobody. Nur wie führe ich auf der Konsole den Befehl als nobody aus. Wie ich zu root werde, weeß ich ja. Mehr brauchte ich ja bisher nicht wissen.
Ok, das zeigt also erst mal, dass PHP (wie der Apache) als User nobody läuft - da deine Dateien kerstin:kerstin gehören, wirken die Zugriffsrechte für Welt für PHP, da du dort keinen Schreibzugriff (sinnvollerweise) gestattet hast, hast du defakto mit PHP keinen Schreibzugriff. Ok so weit.
Zu der Sache mit den Usern, das geht so:
su # Zu root werden, dieser Schritt kann weggelassen werden, wenn du das PW des
# nachfolgenden Users kennst
su Username # zu Username werden, sofern als root ausgefürht, ist kein PW nötig
Ein su nobody
wird allerdings scheitern, da nobody unter Debian /bin/false als Shell zugewiesen hat und du dich somit nicht also nobody einloggen kannst (Sicherheitsgründe!).
-rwxr-xr-x 1 kerstin kerstin 21 2005-10-25 10:58 phpinfo.php
Der Vollständigkeit halber: Hier wären die x-Rechte nicht notwendig, da die Datei nicht ausgeführt, sondern nur von PHP geparst wird - Leserechte wären also ausreichend.
Scheinbar war doch irgendwas falsch am Pfad, den ich sonst angegeben hab. Statt exec("whoami"); Hab ich einfach mal den Befehl so ganz da reinkopiert, und er ging.
Dann hast du definitiv in deinem anderen Script etwas falsch.
Davon mal abgesehen, dass es jetzt andere Probleme gibt, [...]
Das ist dann ein Problem der Software die du da aufrust, das hat (wie dir aber auch bewusst zu sein scheint) dann nichts mehr mit PHP tun - und weil ich die Software die du da aufrust nicht kenne, kann ich dir da dann auch nicht mehr helfen ;-)
Ob dann am Ende aber dann wirklich die AusgabeDatei wird, steht noch offen. Denn durchgelaufen ist der Befehl, wie gesehen ja noch nicht. Naja, ich bastele mal noch ein wenig weiter. Muss ja irgendwie hinzukriegen sein. Mal schaun, ob ich noch mehr im Netz dazu finde.
Diese Software wird ja aus PHP herraus aufgerufen, und wird also wohl auch als nobody ausgeführt - wenn diese Software irgendwo eine Datei erstellen/abspeichern soll, braucht nobody die Rechte dafür irgendwo eine Datei anzulegen.
MfG, Dennis.
Zu der Sache mit den Usern, das geht so:
su # Zu root werden, dieser Schritt kann weggelassen werden, wenn du das PW des
# nachfolgenden Users kennst
su Username # zu Username werden, sofern als root ausgefürht, ist kein PW nötigEin
su nobody
wird allerdings scheitern, da nobody unter Debian /bin/false als Shell zugewiesen hat und du dich somit nicht also nobody einloggen kannst (Sicherheitsgründe!).
Danke dir für diesen kleinen Crash-Kurs ;) Jetzt weiß ich dahingehend wenigstens bescheid.
Davon mal abgesehen, dass es jetzt andere Probleme gibt, [...]
Das ist dann ein Problem der Software die du da aufrust, das hat (wie dir aber auch bewusst zu sein scheint) dann nichts mehr mit PHP tun - und weil ich die Software die du da aufrust nicht kenne, kann ich dir da dann auch nicht mehr helfen ;-)
Jupp, das hängt dann mit der Software zusammen, die ich da aufrufe und nicht mehr mit PHP. Oder halt mit dem Apachen, der ja diese Fehlermeldung auffängt. Auf der Konsole läufts ja. Jetz könnte halt der Apache da nicht wollen. Na man schaun.
Ich danke dir ganz doll.
Liebe Grüße,
Kerstin
Hi Manuel,
was sagt das error.log des Indianers?
Die meisten Fehler in dem Zusammenhand sind fehlende Ausführrechte oder falsche Pfade.
In der error.log steht folgendes:
sh: line 1: ../xfc/xslutil ../docbookhtml/manual-1-1.html ../docbook/manual-1-1.xml ../docbookxslt/mydocbookhtml.xsl: Dat$
[Thu Jun 29 11:55:42 2006] [error] [client 127.0.0.1] File does not exist: /opt/lampp/htdocs/favicon.ico
Das deutet auf falschen Pfad hin. Allerdings funktioniert der Pfad ja, wenn ich ihn auf Konsole ausführe ... Genau der selbe!
Gruß,
Kerstin
Mist da hat noch was gefehlt:
sh: line 1: ../xfc/xslutil ../docbookhtml/manual-1-1.html ../docbook/manual-1-1.xml ../docbookxslt/mydocbookhtml.xsl: Datei oder Verzeichnis nicht gefunden!
!
Gruß,
Kerstin
Hi Kerstin,
sh: line 1: ../xfc/xslutil ../docbookhtml/manual-1-1.html ../docbook/manual-1-1.xml ../docbookxslt/mydocbookhtml.xsl: Datei oder Verzeichnis nicht gefunden!
!
Ah, das ist doch schon mal was - probier mal den absoluten Pfad anzugeben, nach deinen bisherigen Angaben würde ich vermuten, dass das /home/kerstin/xfc/sxlutil ist.
MfG, Dennis.