PHP-Script von der Shell?

[HELLinG3R]

Hallo Leute, ich muss ein aufwändiges script schreiben, das stündlich aufgerufen wird.

Das script überprüft bestimmte werte einer MySQL-Datenbank und reagiert entsprechend (bzw. das soll es mal können)

da sich ja zu MySQL PHP direkt anbietet, habe ich mir überlegt, das ganze per PHP zu lösen.

jetzt habe ich nur ein problem: wie kille ich den Lynx, der Stündlich aufgerufen wird? (ich weiss ja nicht wie die jeweilige PID ist...)

daher habe ich mir gedacht, dass es doch sicher möglich ist, PHP auf der shell auszuführen, also wie ein shellscript.

Ausserdem wäre es notwendig auf PHP-Funktionen des zugehörigen Programmes zurückzugreifen... ich habe keine große lust, das alles neu zu coden (wenn es sich nicht vermeiden lässt..... dann muss ich halt)

habt ihr eine Idee, wie das funktionieren könnte? (ich habe wo gehört, dass ich dazu die CGI-Version brauche)

oder habt ihr sogar noch bessere lösungen für mein Problem?

[robotto7831a]

Hallo,

um ein PHP Skript in der Shell zu starten einfach

php skript.php

eingeben.

Frank

[HELLinG3R]

geht das auch mit der apache-modul version von php??? dafür brauche ich doch dann die CGI-Version, oder?

[robotto7831a]

Probieren geht über studieren.

Frank

[HELLinG3R]

man braucht die cgi-version.

wenn man ein shell-php script ausführen möchte, macht man am besten ein

#!/usr/bin/php4 (<- natürlich muss der pfad stimmen)

in die erste zeile und setzt ausführrechte auf das script; dann klappt das wunderbar!

jetzt muss ich nur noch die mysql-funktionen zum laufen bringen...

[alligator]

Hallo,

Original geschrieben von HELLinG3R

oder habt ihr sogar noch bessere lösungen für mein Problem?

ja -> nimm Perl anstatt php. Genau dafür ist es gedacht !

Gruß

alligator

[HELLinG3R]

hmm...

das problem ist nur, dass ich perl nicht kenne (okay, kann man lernen) aber ich müsste wie oben schon erwähnt, bereits vorhandene php-funktionen benutzen...

und php von der shell ist eigentlich okay, die frage ist nur noch, wie ich mysql-funktionen zum laufen bekommen, aber da bin ich grade dabei...

(wenns jemand schon weis, wäre ich erfreut, wenn er es mir trotzdem verrät )

[HELLinG3R]

okay, ich habe es jetzt gelöst.

installiert ist das Package "php4-cgi", Linux ist Debian Sarge

#!/usr/bin/php4

<?php

echo "DB open... ";

$db = @MYSQL_CONNECT('localhost','test','test') or die ("FAIL");


mysql_close($db);

echo "done.\n"

?>[/PHP]

:bimei

[MadCro]

Hi zusammen, ich habe so ein ähnliches problem,

ich muss mein php script immer zur einer bestimmten uhrzeit und bestimmten datum unter linux aufrufen, ich mein unter windows wäre das ja kein größeres problem aber von linux habe ich null ahnung, googlen hat mir auch nicht besonder weiter geholfen

jemand einen kleinen Tipp für mich ?

danke

gruß

MadCro

[HELLinG3R]

Was du brtauchst ist ein Cronjob.

in Linux gibt es einen Daemon (dienst) der dafür zuständig ist:

Cron.d

das kannst du dir so vorstellen wie den taskplaner -

man trägt die zeit ein, die man haben will und was da passieren soll.

genauer kenne ich mich auch noch nicht aus, aber google mal nach "cronjob howto"

oder suche hier im forum danach.

[MadCro]

hej HELLinG3R,

cronjobs also heisst das zauberwort

danke jetzt habe ich was womit ich gezielt googeln kann.

danke

Gruß

MadCro :marine

[HELLinG3R]

nur mal so ne frage:

ist es sinnvoll, wenn ich php NUR als CGI benutze? sprich das apachemodul einfach weglasse? man kann doch dem apachen sicherlich auch sagen, er soll das CGI benutzen, oder (wie denn genau?)

[Hopser]

Original geschrieben von HELLinG3R

ist es sinnvoll, wenn ich php NUR als CGI benutze? sprich das apachemodul einfach weglasse? man kann doch dem apachen sicherlich auch sagen, er soll das CGI benutzen, oder (wie denn genau?)

Nein, das ist in 99% der Anwendungsfälle vollkommen unsinnig. Ein Interpreter, was das PHP als Kommanozeilenversion ist, muß bei jedem Skript-Aufruf neu geladen werden, führt das Skript aus und beendet sich wieder. Das Apache-Modul kann nahezu direkt mit der Ausführung der Skripte anfangen. Schätz mal, wieviel schneller die 2. Variante sein kann.

Das ist übrigens auch einer der Vorteile, den PHP gegenüber Perl bei der dynamischen Webseitengestaltung hat. Aber auf der Kommandozeile würde ich dropsdem immer noch zu Perl raten. So unterschiedlich sind die Sprachen nicht, die kleinen Eigenheiten kriegt man schnell gebacken.

Tschau,

Andreas

[HELLinG3R]

wie gesagt, das problem ist, dass ich auf umfangreiche php-funktionen eines anderen programmierers verwenden muss, die nur einmal vorhanden sein sollen (sonst muss ich jede änderung, die er macht nachpflegen)

die cgi-version kann also, solange ich sie nicht im apachen einbinde NICHT von ausserhalb benutzt werden, oder?

und auf der shell nur mit den rechten des benutzers, dem das script gehört?

(also FALLS siche in hacker shell-zugriff verschafft hat, kann er ja eins cript schreiben und ausführen - mit welchen rechten?)

[Hopser]

Original geschrieben von HELLinG3R

die cgi-version kann also, solange ich sie nicht im apachen einbinde NICHT von ausserhalb benutzt werden, oder?

Falsch. Jeder, der die Rechte hat, bei dir ein CGI abzulegen, und der weiß, wo der PHP-Interpreter liegt, kann den auch benutzen. Das Risiko ist aber meines Erachtens auch nicht höher, als bei Perl.

und auf der shell nur mit den rechten des benutzers, dem das script gehört? (also FALLS siche in hacker shell-zugriff verschafft hat, kann er ja eins cript schreiben und ausführen - mit welchen rechten?)

Skripte, die man ausführt, laufen immer erstmal unter dem Nutzer, der das macht. Augenscheinlich nicht sonderlich kritisch, weil der Apache meist als nobody oder wwwrun rennt, der eh nix weiter darf. Allerdings sollte man drauf achten, daß auch wwwrun schon ein lokaler Nutzer ist. Und eine Shell, die ein Angreifer unter dem Nutzer bekommt, kann er als "Sprungbrett" nutzen, um bespielsweise einen Local Root Exploit zu plazieren. Daher sollte man auch diese Sicherheitslücken IMMER schließen, auch wenn sie augenscheinlich nicht so dringend sind.

Aber ich glaub, langsam gehört das nicht mehr in die Skriptsprachen, sondern schon eher in Richtung Sicherheit

Tschau,

Andreas