Executer un script en dehors du site

WRInaute accro
Bonjour,

Voila, je souhaite exécuter un script en-dehors des dossiers de mon site.
C'est un cron qui lance une tâche (un php) pour exécuter certaines opérations.

Faut-il qu'il soit obligatoirement dans mon dossier du site ? :?

ah oui...
j'ai un dédié donc accès ssh.

Ce que je voudrais c'est créer un dossier spécifique pour les tâche php à exécuter en cron, qui n'a rien a voir avec le reste. Est-ce que le php sera exécuté ? ou faut-il paramètrer apache ou php de tel sorte qu'il reconnaisse le dossier ?

J'espère que vous m'aurez compris. :? :?
 
WRInaute discret
Bein pas sur que le php s'execute hors de l'arbo du site (quoiqu'en dédié, tu fais bien ce que tu veux non? Mais question sécurité, ça me semble un peu limite). Sinon, pourquoi pas tout simplement un sous dossier du site avec .htaccess qui empeche tout accès via le web?
 
WRInaute accro
nuxvomica a dit:
Bein pas sur que le php s'execute hors de l'arbo du site (quoiqu'en dédié, tu fais bien ce que tu veux non? Mais question sécurité, ça me semble un peu limite). Sinon, pourquoi pas tout simplement un sous dossier du site avec .htaccess qui empeche tout accès via le web?
Pourquoi limite niveau sécurité ?
Je suis preneur pour le .htaccess qui empêche tout accès venant du web. :wink:
 
WRInaute discret
thierry8 a dit:
Pourquoi limite niveau sécurité ?
Autoriser l'execution de scripts dans l'arbo de ton serveur, hors répertoires web, me semble douteux. On regroupe en général les cgi dans un seul rep autorisé par exemple. Enfin bon, je suis loin d'être pointu sur le sujet, c'est juste une hypothèse.
 
WRInaute passionné
euuuh pour ma part, je ne vois pas en quoi cela peut poserait problème.
Au contraire, tous mes crons sont dans un répertoire différent de l'arborescence du site ! Ainsi pas besoin de placer un .htaccess, ceux là ne sont pas accessibles.

Exemple :
/var/www/site1 => répertoire du site www.domaine.com
/var/www/cronsite1 => répertoire des crons
 
WRInaute accro
Merci Robinson.

Une question, lorsque tu créé manuellement le dossier cronsite1, rajoute tu quelque chose dans le httpd.conf, au dans un autre fichier de config. pour que les scripts se trouvant à l'intérieure soit exécuté ?
 
WRInaute impliqué
Il est fortement déconseillé de mettre un script destiné à être un cron dans l'arborescence de ton site...

Tout d'abord, il faut bien comprendre une chose: dans ton script cron, apache n'intervient nulle part !

Ton script cron risque d'avoir besoin de droit d'accès à certains fichiers (suivant ce que fait exactement le cron) et le mettre sous l'arborescence apache présente le risque que :
1- quelqu'un le sollicite alors que tu ne le veux pas
2- quelqu'un trouve une faille dans ton script qui risque alors de devenir un vrai danger publique sur ton serveur.
3- si tu le fais passer par apache, lorsque tu as un plantage de Apache, ton cron ne marche plus.

Pour exécuter un cron en PHP, tu n'as même pas besoin de Apache. J'en avais parlé dans un post préccédent, mais je le retrouve plus, alors je vais me la refaire ;)

PHP c'est un programme qui va interprêter du code que tu lui fournis, soit par le biais d'un fichier, soit même à la volée.
On l'utilise surtout avec Apache car il permet de créer des pages dynamiques, et qu'il dispose d'une floppée de fonctions bien utiles pouir une application en mode cgi.

Dans ta configuration Apache, pour un serveur qui supporte les pages Web en PHP, la seule chose que tu lui dis, c'est :

"lorsqu'il y a une page qui porte l'extension '.php', je la donne à l'interprêteur, qui fait son taff, et me renvoie le résultat, que je ferai suivre à l'internaute".

Bref. PHP peut être utilisé indépendamment de Apache. Comment ?

Puisque Apache n'est pas là pour dire à PHP d'interprêter un fichier, tu dois utiliser la syntaxe prévue sous Linux pour ce genre de cas: dans le fichier, donner le chemin vers l'interprêteur du script.

Par exemple si tu faisais un script en SH, ça donnerait :
Code:
#!/bin/sh

en première ligne, car, le programme qui interprête le SH se trouve dans /bin et est SH.

Pour PHP, c'est génériquement :
Code:
#!/usr/local/bin/php

Le "#!" ça veut dire "Attention, voici le chemin vers l'interprêteur.

Par contre, sur ton serveur tu dois avoir installé un PHP qui est compilé pour optimiser les échanges avec Apache. Donc si tu lances ton script sous SSH, la sortie de ton script sera formaté avec des headers html

Toi tu n'en as pas besoin, car tu le lance en mode console. Donc tu vas lui dire gentillement de se la fermer :) Comment ? En lui précisant l'option "-q" qui permet de le lancer en "quiet mode".

Ta première ligne dans ton php devient :
Code:
#!/usr/local/bin/php -q

Ensuite, dans ton code, tu précise bien les balises "<?php" et "?>" là où il y a du code à interprêter. En dehors, le reste sera affiché en tant que texte.

Ensuite, pour le passage de variables au script, tu as deux globales à connaitres :

$argc : qui contient le nombre d'argument passé au script.
$argv : un tableau qui te donne le nom du script puis les différents arguments.

Le premier argument est $argv[1] .

Ensuite, il te reste une seule manip à faire: donner les bons droits à ton script. Je te laisse gérer ça, sauf que tu dois absolument lui donner le droit d'exécution :

Code:
chmod +x script.php

Et vala c'est tout bon ;)
 
WRInaute accro
..
Merci pour cette explication.

Dans mon cas il s'agit d'un script en PHP.

Je devrais donc mettre:
Code:
#!/usr/local/bin/php -q
<?php

/* mon script */

/* rapport par mail */

?>
Le -q permet de ne pas renvoyer quelque chose, si j'ai bien compris.
En revanche, le chemin /usr/local/bin/ est bien existant, mais je n'ai pas de php à l'intérieur. C'est normal !?

Je ne passe aucune variable (normalement), je n'aurais donc pas besoin de $argc et de $argv.
Mais peut tout de même m'expliquer comment passer une variable, parce que j'avoue, ne pas avoir compris comment les utiliser.

C'est un script qui intervient sur toutes les bases de données mysql, de ce fait il possède les droits root.

.. .. .. .. ..
En revanche, sous Plesk, il y a déjà des cron d'établis, en voici un exemple:
Code:
/opt/psa/admin/bin/php /opt/psa/admin/plib/report/autoreport.php --auto monthly >/dev/null 2>&1

Dois-je également mettre le >/dev/null 2>&1 ?
A quoi cela correspond ?

Si je comprends cette tâche, par rapport à ce que tu m'as dis le début permettrait d'indiqué le chemin pour interpréter le script. (Plesk fonctionne sous PHP 5). Ensuite, la ligne d'après, le chemin du script, puis derrière, quelque chose d'autre... :?
 
WRInaute impliqué
L'option -q permet d'être en quiet mode : c'est à dire d'afficher quelque chose si tu fais un echo, mais de ne pas envoyer d'entête html.

Le /usr/local/bin/php est un emplacement qu'on retrouve souvent sur les distributions linux, mais ce n'est une règle générale. Pour savoir où se trouve ton exécutable, soit tu fais un phpinfo(), soit tu fais un whereis en ligne de commande :

Code:
 [Bourriquet@sms-gift.com] whereis php
php: /usr/local/bin/php /usr/local/lib/php /usr/local/lib/php.ini

Le /dev/null n'est pas obligatoire.

Pour ton rapport tu te l'envoie par mail, mais je te conseille tout de même de faire un petit log au cas ou y est un plantage.

Ca peut être fait très simplement comme ça :

Code:
/chemin/vers/ton/script.php >> fichier_log.txt

Pour le passage d'argument c'est simple :

Code:
/chemin/vers/ton/script.php pouet prout biloute NuNux "et plein d'autre choses possible encore"

$argv[0] contiendra : /chemin/vers/ton/script.php
$argv[1] contiendra : pouet
$argv[2] contiendra : prout
$argv[3] contiendra : biloute
$argv[4] contiendra : NuNux
$argv[5] contiendra : et plein d'autre choses possible encore

Après c'est à toi en PHP de faire des traitements différents en fonction des arguments.
 
WRInaute accro
Merci, merci, merci !!!

Concernant le fichier .txt, il sera créé je suppose à la racine tu dossier du script courant ?

Une question encore: (confirmation de ma bonne compréhension :? )
Finallement je met le #!/usr/local/bin/php -q au début de mon fichier php. Et ma tâche cron serait :
/chemin/vers/ton/script.php var1 >> fichier_log.txt

Et mon fichier php:
Code:
#!/usr/bin/php -q
<?php

/* mon script */

/* rapport par mail */

?>
Tout somplement ?

Merci beaucoup à toi ! Tu m'as été d'une grande aide sur bien des points.

note: sur plesk l'emplacement est donc là: /usr/bin/php
 
WRInaute discret
Robinson a dit:
euuuh pour ma part, je ne vois pas en quoi cela peut poserait problème.
Au contraire, tous mes crons sont dans un répertoire différent de l'arborescence du site ! Ainsi pas besoin de placer un .htaccess, ceux là ne sont pas accessibles.

Exemple :
/var/www/site1 => répertoire du site www.domaine.com
/var/www/cronsite1 => répertoire des crons
AMHA, il y a erreur, là (hum, au moins dans les hébergements mutualisés où www est le répertoire de base, mais peut-être en dédié tu peux gérer ça différemment)
en effet, au moins dans ce cas, il suffit de -http://ton-domaine.tld/cronsite1 pour avoir l'index de tous les fichiers présents dans cronsite1... et en faire à peu près ce que l'on veut 8) ... si aucun .htaccess ne vient en interdire ni l'accès ni l'indexation !
 
WRInaute impliqué
thierry8 a dit:
Concernant le fichier .txt, il sera créé je suppose à la racine tu dossier du script courant ?

Si tu donnes un chemin absolu, il sera là où tu l'auras indiqué. Si tu le mets en relatif, il sera créé à l'endroit depuis lequel le script est appellé. Lorsque tu mets une tâche en cron, ça revient à ouvrir automatiquement une console en tant que l'utilisateur qui lance le cron (tu me suis ? :)).

Donc, si tu mets que ton cron s'éxecute en tant que l'utilisateur biloute, ton log sera placé à la racine du répertoire personnel de biloute, généralement /home/biloute .

Le mieux est quand même de mettre un chemin absolu :).

thierry8 a dit:
Une question encore: (confirmation de ma bonne compréhension :? )
Finallement je met le #!/usr/local/bin/php -q au début de mon fichier php. Et ma tâche cron serait :
/chemin/vers/ton/script.php var1 >> fichier_log.txt

Et mon fichier php:
Code:
#!/usr/bin/php -q
<?php

/* mon script */

/* rapport par mail */

?>
Tout somplement ?

Mmmmmmh... (Roulement de tambours....) Oui !

thierry8 a dit:
Merci beaucoup à toi ! Tu m'as été d'une grande aide sur bien des points.

De rien ;) J'accepte les dons via PayPal mdr
 
WRInaute passionné
cardoule a dit:
Robinson a dit:
euuuh pour ma part, je ne vois pas en quoi cela peut poserait problème.
Au contraire, tous mes crons sont dans un répertoire différent de l'arborescence du site ! Ainsi pas besoin de placer un .htaccess, ceux là ne sont pas accessibles.

Exemple :
/var/www/site1 => répertoire du site www.domaine.com
/var/www/cronsite1 => répertoire des crons
AMHA, il y a erreur, là (hum, au moins dans les hébergements mutualisés où www est le répertoire de base, mais peut-être en dédié tu peux gérer ça différemment)
en effet, au moins dans ce cas, il suffit de -http://ton-domaine.tld/cronsite1 pour avoir l'index de tous les fichiers présents dans cronsite1... et en faire à peu près ce que l'on veut 8) ... si aucun .htaccess ne vient en interdire ni l'accès ni l'indexation !

Bah non il n'y a pas erreur, tout dépend de la configuration de ton httpd.conf. Oui ptet que je n'aurai pas du donner l'exemple /var/www/ qui est le répertoire par défaut.
Mais de toutes façons, je suis sur dédié et me souvient plus trop des mutualisés et de tous leurs problèmes :lol:
 
WRInaute accro
Merci Bourriquet.

Je t'aurais bien proposé de mettre des bl, mais je n'ai pas de site perso malheureusement. :? :(

Mais je penserais à toi lorsque j'en aurais un perso. ;)

Merci beaucoup de ton aide.
...ah, oh fait, je t'ais suivi ! ;)

ah une question encore! je pense que les limitations sont aussi prisent en compte dans ce genre d'interprétation ? (en autre le safe_mode à on)
 
WRInaute impliqué
La config générale de php s'applique également au mode CLI.

Néammoins, tu as aussi une version optimisée CLI sur le site www.php.net.

Mais pour un cron, ça suffit amplement ;)
 
WRInaute accro
Ben en fait non, ca ne suffit pas vraiment, car le script met plus de 30 secondes pour s'éxécuter. Or avec le safe_mode à On, on ne peut modifier cette variable avec set_time_limit().

Mais je vais voir pour désactiver le safe_mode uniquement sur ce dossier.
 
WRInaute accro
Une question quand même, parce que je fais le test, mais je n'ai pas l'impression t'avoir un max_time_limit qui me soit obligatoire.

En effet je fais une boucle au préalable de plus de 30 secondes, puis derrière je m'envois le mail. Or je reçois bien le mail....je ne suis pas stopé.

Est-ce qu'ajouter la tâche cron avec le root influence ?

Un autre truc, bon je n'ai pas eu d'erreur, mais le fichier_log.txt, est vide et s'incrément de 1ko à chaque appel, c'est normal également je suppose.

Je m'attendais à voir l'erreur max_time_limit...mais on dirait que je n'ai pas de limite de temps.

php.ini bien configuré à 30 et sur les vhost je suis bien bloqué à 30 secondes.

Peut être le fait que j'ai mis la tâche en root... :? :? :?

EDIT: j'ai provoqué volontairement une erreur et elle s'inscrit bien dans le fichier de log. En revanche il n'y à pas marqué l'heure et la date. Est-il possible d'ajouter ce genre d'information ?

Merci.
 
WRInaute impliqué
thierry8 a dit:
Une question quand même, parce que je fais le test, mais je n'ai pas l'impression t'avoir un max_time_limit qui me soit obligatoire.

En effet je fais une boucle au préalable de plus de 30 secondes, puis derrière je m'envois le mail. Or je reçois bien le mail....je ne suis pas stopé.

Est-ce qu'ajouter la tâche cron avec le root influence ?

Je ne pense pas. Disons que t'as un max time et à partir de ce max time, il essait de killer le processus, qui peut durer plus longtemps et devenir un processus zombie.

thierry8 a dit:
Un autre truc, bon je n'ai pas eu d'erreur, mais le fichier_log.txt, est vide et s'incrément de 1ko à chaque appel, c'est normal également je suppose.

Certainement que dans ton script tu as insérer une ligne par exemple comme ça :
Code:
#!/usr/local/bin/php -q
<?php

//script ....

// ... fin du script

?>

quelque chose 
<?php 

//autre morceau de script

?>

Dans ce cas là le saut de ligne est bien repris par le fichier log. Tu penses qu'il est vide, mais en fait ce sont que des saut de lignes.

Pour en être sur :
Code:
cat fichier_log.txt | od -c

Il va te montrer les caractères spéciaux ;)

thierry8 a dit:
En revanche il n'y à pas marqué l'heure et la date. Est-il possible d'ajouter ce genre d'information ?

Merci.

Ca c'est à toi de le gérer en php. Le ">>" c'est un redirecteur de sortie. Ca veut dire : au lieu de l'afficher à l'écran, l'écrire dans un fichier.

De rien ;)
 
WRInaute accro
Bourriquet a dit:
thierry8 a dit:
Une question quand même, parce que je fais le test, mais je n'ai pas l'impression t'avoir un max_time_limit qui me soit obligatoire.

En effet je fais une boucle au préalable de plus de 30 secondes, puis derrière je m'envois le mail. Or je reçois bien le mail....je ne suis pas stopé.

Est-ce qu'ajouter la tâche cron avec le root influence ?

Je ne pense pas. Disons que t'as un max time et à partir de ce max time, il essait de killer le processus, qui peut durer plus longtemps et devenir un processus zombie.
euh...j'ai pas tout compris. En clair, lorsqu'un script est éxécuté en root, le script à une durée infinie tant qu'il n'est pas finis ?

Bourriquet a dit:
thierry8 a dit:
Un autre truc, bon je n'ai pas eu d'erreur, mais le fichier_log.txt, est vide et s'incrément de 1ko à chaque appel, c'est normal également je suppose.

Certainement que dans ton script tu as insérer une ligne par exemple comme ça :
Code:
#!/usr/local/bin/php -q
<?php

//script ....

// ... fin du script

?>

quelque chose 
<?php 

//autre morceau de script

?>

Dans ce cas là le saut de ligne est bien repris par le fichier log. Tu penses qu'il est vide, mais en fait ce sont que des saut de lignes.

Pour en être sur :
Code:
cat fichier_log.txt | od -c

Il va te montrer les caractères spéciaux ;)

thierry8 a dit:
En revanche il n'y à pas marqué l'heure et la date. Est-il possible d'ajouter ce genre d'information ?

Merci.

Ca c'est à toi de le gérer en php. Le ">>" c'est un redirecteur de sortie. Ca veut dire : au lieu de l'afficher à l'écran, l'écrire dans un fichier.

De rien ;)
ah ok ! donc le echo permet d'enregistrar dedans....
Je suppose qu'il faut également gérer le fichier pour ne pas qu'il soit trop gros...
 
WRInaute impliqué
Il se peut que ton script dépasse le time_limit parce que php n'arrive pas à killer le processus.


Sous linux, tout est fichier. Tu peux lire sur une socket comme dans un fichier, une carte est considéré comme un fichier. La sortie de ton écran est considéré comme un fichier.

L'opérateur de redirection permet de rediriger un flux prévu pour arriver sur la sortie standart (généralement l'écran) vers une autre sortie.

Par exemple, le fichier /dev/null est un fichier spécial qui définit le NULL, c'est à dire rien du tout.

Si tu veux qu'un programme tourne en mode "silencieux", tu mets ça :
Code:
./ton_prog >> /dev/null
 
WRInaute accro
ok pour la redirection de la sortie "d'affichage".

Bourriquet a dit:
Il se peut que ton script dépasse le time_limit parce que php n'arrive pas à killer le processus.
Mais est-ce un comportement normal ?
Puis-je le laisser ainsi ?
 
WRInaute impliqué
Normalement, il doit le killer. Si il n'y arrive pas c'est qu'il y a un souci.

Le mieux est de bien gérer les exceptions dans ton script, et tout faire pour provoquer une sortie si problème il y a.
 
WRInaute accro
Bourriquet a dit:
Normalement, il doit le killer. Si il n'y arrive pas c'est qu'il y a un souci.
Mais ne crois tu pas simplement que le fait de mettre la tâche en cron avec le compte root et l'exécution sous le compte root empêche naturellement ce genre de limitation ?
Sinon est-il possible de vérifier s'il s'agit d'un comportement anormale ?

Bourriquet a dit:
Le mieux est de bien gérer les exceptions dans ton script, et tout faire pour provoquer une sortie si problème il y a.
ok
 
WRInaute impliqué
Déjà, je te déconseille de le mettre en root.

Si c'est pour des droits mysql, sache de le root de mysql est totalement différent du root de unix, car mysql a son propre système de gestion des utilisateurs. D'ailleurs mysql tourne normalement sous l'utilisateur mysql du groupe qui porte le même nom.

Pour ma part, le set_time_limit a toujours été efficace pour killer un script PHP en mode console. Je suppose donc que c'est un comportement anormal.
 
WRInaute accro
Bourriquet a dit:
Déjà, je te déconseille de le mettre en root.
ok..je vais voir. Mais en fait, je passe par l'interface Plesk...
Je vais voir pour mettre entrement, mais si le le fait autrement je ne peux appeller le script se trouvant dans un dossier créé par mois (hors arborescence du site). Enfin je crois. :?

Bourriquet a dit:
Si c'est pour des droits mysql, sache de le root de mysql est totalement différent du root de unix, car mysql a son propre système de gestion des utilisateurs. D'ailleurs mysql tourne normalement sous l'utilisateur mysql du groupe qui porte le même nom.
Oui, pour mysql, j'utilise bien entendue un login et mot de passe nécessaire.
root en l'occurence du fait que je travail sur toutes les tables.

Bourriquet a dit:
Pour ma part, le set_time_limit a toujours été efficace pour killer un script PHP en mode console. Je suppose donc que c'est un comportement anormal.
ok...je vais donc voir pour le premier point, soit mettre sur un autre compte.
 
WRInaute accro
Est-ce que ce message d'erreur signifie que je n'ai pas de disponible les commandes mysql etc... ?

Fatal error: Call to undefined function: mysql_connect() in /......./test.php on line 79
 
WRInaute accro
euh...

en fait Plesk tourne sous PHP 5, mais pas pour les domaines....(php 4)

Peut-être bien que les script sont employé en php 5.
:? :? :? comment faire alors pour lui dire que je veux php 4 ?
(sinon quel est l'erreur par rapport à php 5 ?)
 
WRInaute impliqué
Le problème viendrait à mon avis que ton php serait compilé avec l'extension mysqli et non pas l'extension mysql, qui correspond à une amélioration des fonctions mysql antérieures et qui ajoute des fonctionnalités, pour prendre en charge correctement mysql 4.1 et supérieur.
 
Nouveau WRInaute
Bonjour,

Question ! Je suis sous PHP 4.1.2, je cherche a être sur que je ne peux pas utiliser ma version de php comme interpreteur, en ligne commande !!?

:wink:
 
WRInaute discret
http://webdocs.math.univ-rennes1.fr/php/fr/commandline.html a dit:
Vous ne pouvez utiliser les options de ligne de commande que si vous avez installé PHP comme exécutable. Si vous avez créé un module Serveur, et que vous n'avez aucune version CGI disponible sur votre serveur, vous n'avez aucune chance de pouvoir utiliser ces options. Pour les utilisateurs Windows, les deux versions de PHP sont disponibles dans la distribution binaire, et l'exécutable s'appelle php.exe.
avec easy php.exe se trouve dans le dossier php
mais il faut au moins indiquer le chemin(pas encore testé plus)
 
WRInaute discret
En furetant un peu plus, j'ai encore trouvé ceci qui répondrait peut-être plus précisément à ta question concernant ta version de php :

-http://www.manuelphp.com/php/features.commandline.php
 
Nouveau WRInaute
Bonjour et merci pour les liens !

J'aurai besoin de quelques petites aides s'il vous plait :

Je m'occupe d'un site internet, html, php, mysql, etc ... !

J'ai mis en place quelques routines php lancer par une commande cron hors mes scripts php sont dans mon www d'apache ceux qui ne me plait pas.

* * * * * * http://www.monsite.fr/mon_script_php.php

Je souhaitetai mettre ces memes scrips dans un repertoire au-dessus d'apache, inaccesible pour un utilisateur lamba du site. Il suffirait qu'une personne lance l'url et mon script serait alors executer.

je voudrais dans ma table cron :

* * * * * * php /home/xxx/mon_script_php.php arg1 arg2

lancer tout simplement mon script comme ceci. Hors apparement cela ne fonctionne pas, j'en ai deduit que je n'avais pas d'executable pour lancer un scripts de cette maniere.

Et là !!! ba je ne sais pas quoi faire ! :?

Pourriez-vous :idea: ?!
 
WRInaute passionné
Moi j'utilise la commande /usr/sbin/php /home/xxx/monscript.php

PS : c'est quoi tes arg1 et arg2 ?
 
Nouveau WRInaute
c'est un passage d'argument en faite mais ca je peux m'en passer ! C'éte juste en plus !

Tu utilise /usr/sbin/php en faite c'est ton chemin en dur vers ton executable php mais cela veut dire que ton php est compiler pour fonctionner hors de ton serveur web si j'ai bien compris tout ce que j'ai lu.

Moi je n'ai pas cette compilation sur mon serveur et je voudrais savoir un peu si je ne me trompe pas dans mes deductions car je ne suis pas admin système et je ne voudrais pas causer de souci sur le serveur j'office.
Mon php est juste je pense utiliser en module pour apache.

Miantenant je souhaiterai le mettre en module CGI je crois :? .... j'espere ne pas faire fausse route !!
 
WRInaute impliqué
Même en mode CGI (donc pas prévu pour fonctionner en dehors du site), l'interprêteur PHP fonctionne.

Il suffit simplement d'adapter son code aux spécificités du mode CGI et d'appeller correctement l'interprêteur.
 
Nouveau WRInaute
J'ai lance whereis php sous ma console linux !

verdict --> php: /usr/local/lib/php
j'imagine qu'il s'agit de ma commande php.

Or si je tente de lancer un script php en dehors d'apache avec cette commande ... RIEN? cela ne fonctionne pas !

De ce faite je me suis laisser tenter a croire suivant mes différentes lecture a droite à gauche que php sur mon serveur avait du etre simplement compiler comme module web pour apache de ce faite inutilisable hors de mon arborescence web ! De là j'ai imaginer qu'il fallait recompiler php avec de lui creer un binaire exploitable pour lancer un script php hors d'apache, non ?!!
 
WRInaute passionné
Je viens d'installer apache, mysql...etc sur un dédié (debian).

Et de même, la commande php n'y figurait pas.

Pour cela, il faut installer le package "php4-cli".
Et php se retrouve normalement dans /usr/bin/.
 
Discussions similaires
Haut