Problème appel script bash depuis php

Gons

Nouveau WRInaute
Bonjour à tous !

J'ai un problème et malgré plusieurs heures à tourner dessus, à lire et lire sur le net, je ne comprends pas...

J'ai réalisé un script bash qui fonctionne très bien quand je le lance via ssh sur mon serveur. Je lui ai donné les droit chmod 777.
Pourtant ma page php avec exec('sh /home/le/chemin/vers/mon/script/script.sh'); ne fonctionne pas...

Si je remplace par exec('une commande a executer'), la commande est bien exécutée ?

D'où peut venir le problème ?

Merci pour votre aide !
 

DeLoVaN

Nouveau WRInaute
Ca ne fonctionne pas... Tu as un message d'erreur quelconque à nous transmettre ?
Ton script marche en console ?
Et si tu remplace sh par /bin/sh (voire /bin/bash) ?
 

Gons

Nouveau WRInaute
DeLoVaN a dit:
Ca ne fonctionne pas... Tu as un message d'erreur quelconque à nous transmettre ?
Ton script marche en console ?
Et si tu remplace sh par /bin/sh (voire /bin/bash) ?

Aucun message d'erreur. Le script ne s'exécute pas. Comment pourrais-je en connaître la cause ?
Sinon avec /bin/sh et /bin/bash ça change rien. Il fonctionne en console.
 

Gons

Nouveau WRInaute
e-kiwi a dit:
>> Comment pourrais-je en connaître la cause ?
dans les logs apache ?
voilà :

Code:
sh: Can't open /home/blabla/blabla.sh
/bin/sh: Can't open /home/blabla/blabla.sh
/bin/bash: /home/blabla/blabla.sh: Permission denied
 

passion

WRInaute accro
il semblerait que le user qui va lancer le script bash n'est pas les droits suffisants !
 

Gons

Nouveau WRInaute
passion a dit:
il semblerait que le user qui va lancer le script bash n'est pas les droits suffisants !

Après avoir changer mon script de groupe (www-data) et l'avoir mis dans /var/www/chemin/vers/mes/scripts/web
Il accède bien au script.

Cependant, certaines actions à l'intérieur de mon script ne peuvent être exécutées par manque de droits.
J'ai pourtant fait certaines démarches indiquées ici :

Code:
www-data ALL=(ALL) NOPASSWD: /var/www/chemin/vers/mes/scripts/web/script.sh

Dans /etc/sudoers avec visudo

et
Code:
/etc/init.d/sudo restart
pour être sûr (j'ai même redémarré apache2)

Je n'ai toutefois toujours pas les permissions pour effectuer certaines commandes de mon script :(

Voilà les erreurs (pour les fichiers qui n'existent pas, c'est normal puisque mon script devait les créer)

Code:
tar: applicationparameters.txt: Cannot open: Permission denied
tar: seasoninfo.txt: Cannot open: Permission denied
tar: levelinfo.txt: Cannot open: Permission denied
tar: playercategories.txt: Cannot open: Permission denied
tar: clubs.txt: Cannot open: Permission denied
tar: venues.txt: Cannot open: Permission denied
tar: players.txt: Cannot open: Permission denied
tar: fixtures.txt: Cannot open: Permission denied
tar: tournaments.txt: Cannot open: Permission denied
tar: matchtypes.txt: Cannot open: Permission denied
tar: calenderdates.txt: Cannot open: Permission denied
tar: Exiting with failure status due to previous errors
mv: cannot stat `players.txt': No such file or directory
rm: cannot remove `*.txt': No such file or directory
rm: cannot remove `db-20110607.tabt': Permission denied
/var/www/infoping/scripts/maj_affilies_fr.sh: 18: cannot open /var/www/infoping/scripts/affilies/players.txt: No such file
rm: cannot remove `*.txt': No such file or directory
/var/www/infoping/scripts/maj_affilies_fr.sh: 21: cannot create joueurs.csv: Permission denied
cat: joueurs2.csv: No such file or directory
rm: cannot remove `joueurs2.csv': No such file or directory
sed: can't read joueurs.csv: No such file or directory
ERROR 2 (HY000) at line 1: File '/var/www/infoping/scripts/affilies/joueurs.csv' not found (Errcode: 2)
rm: cannot remove `/var/www/infoping/scripts/affilies/*': No such file or directory
 

_Soul

WRInaute impliqué
Si ta un ../xxx dans ton script sa ne fonctionnera pas, il faut des chemins "direct".

Sinon tu dois pas éditer tes fichiers en root, fais un sudo avant, essaye en fessant exec('sudo /home/le/chemin/vers/mon/script/script.sh');

Bonne chance ;)
 

Gons

Nouveau WRInaute
_Soul a dit:
Si ta un ../xxx dans ton script sa ne fonctionnera pas, il faut des chemins "direct".

Sinon tu dois pas éditer tes fichiers en root, fais un sudo avant, essaye en fessant exec('sudo /home/le/chemin/vers/mon/script/script.sh');

Bonne chance ;)
Les chemins sont directs. Avec sudo :

Code:
sudo: no tty present and no askpass program specified
 

jcaron

WRInaute accro
Euuuuh... Tu es certain que tu n'as pas un autre moyen d'arriver à faire ce que tu veux? Lancer un script bash avec des droits root depuis un script php, ça me paraît horriblement dangereux. Tu as intérêt à très sérieusement bien vérifier tout ce que tu passe à ton script, et plutôt deux fois qu'une!

Jacques.
 

Gons

Nouveau WRInaute
_Soul a dit:
Si dans le script tu fais juste un 'touch plop' sa fonctionne?
Voilà la réponse :( :
Code:
touch: cannot touch `plop': Permission denied

jcaron a dit:
Euuuuh... Tu es certain que tu n'as pas un autre moyen d'arriver à faire ce que tu veux? Lancer un script bash avec des droits root depuis un script php, ça me paraît horriblement dangereux. Tu as intérêt à très sérieusement bien vérifier tout ce que tu passe à ton script, et plutôt deux fois qu'une!

Jacques.
Cette page php est une page d'administration accessible uniquement par moi via mot de passe. De plus mon script bash ne prend aucun paramètre. Il télécharge un fichier sur un site distant et met à jour ma BDD.
 

DeLoVaN

Nouveau WRInaute
Balance un petit chmod 777 pour vérifier. Tu es sur de passer avec le www-data ? Tu n'utilise pas suexec ou suphp par ex ?
 

Julia41

WRInaute passionné
Gons a dit:
_Soul a dit:
Si dans le script tu fais juste un 'touch plop' sa fonctionne?
Voilà la réponse :( :
Code:
touch: cannot touch `plop': Permission denied
T'as tenté avec le chemin absolu ?
/home/tonsite/www/plop ?
Car là "plop" ça sera ptete dans /usr/sbin/

jcaron a dit:
Euuuuh... Tu es certain que tu n'as pas un autre moyen d'arriver à faire ce que tu veux? Lancer un script bash avec des droits root depuis un script php, ça me paraît horriblement dangereux. Tu as intérêt à très sérieusement bien vérifier tout ce que tu passe à ton script, et plutôt deux fois qu'une!

Jacques.
Je suis un peu d'accord avec jcaron.
A mon niveau j'avais fraudé avec un :
"on écrit exactement ce qu'on veut dans un fichier .txt, un cron execute ce script (si présent)".
 

jcaron

WRInaute accro
Gons a dit:
Cette page php est une page d'administration accessible uniquement par moi via mot de passe. De plus mon script bash ne prend aucun paramètre. Il télécharge un fichier sur un site distant et met à jour ma BDD.

Ce qui m'amène les questions suivantes:
- pourquoi ne pas faire tout ça directement en php?
- quel besoin d'exécuter ça avec des droits root?

Jacques.
 

Gons

Nouveau WRInaute
jcaron a dit:
Ce qui m'amène les questions suivantes:
- pourquoi ne pas faire tout ça directement en php?
- quel besoin d'exécuter ça avec des droits root?

Jacques.

- car cela serait plus lent (du moins je pense), je dois faire un "tar xvf" sur le fichier puis récupérer un autre qui possède 18000 lignes et je fais des traitements dessus avec les commandes awk cat et sed avant d'envoyer tout ça ds ma BDD
- car /var/log/apache2/error.log il me dit que j'ai pas la permission pour effectuer ces commandes (ça fonctionne très bien si je lance mon script en ssh).

Julia41 a dit:
T'as tenté avec le chemin absolu ?
/home/tonsite/www/plop ?
Car là "plop" ça sera ptete dans /usr/sbin/

Désolé, je ne connais pas la commande "touch", je dois faire touch /le/chemin/vers/mon/site ?

En tout cas, merci de vous attarder ici et tenter de m'aider !
 

ortolojf

WRInaute accro
Bonsoir

En ce qui me concerne, j'ai été amené, à fournir à mon site partenaire de mon site de Turf, un ensemble de scripts php et en Bourne Shell, pour mettre à jour quotidiennement mes pronostics sur mon site, et rapatrier la page de ces pronostics vers mon site partenaire.

J'avais effectivement, à lancer un script en Bourne Shell, à partir d'un script php.

Voici la syntaxe, en utilisant la fonction php shell_exec() , recommandée par le site du PHP Manual, à la place de exec() :

Code:
<?php
  $output = @shell_exec("./script.sh");
?>


Ensuite, la variable $output, contient tout ce qui a été affiché ( par echo, ou bien les messages d'erreurs du script script.sh ).

Le fait que le script script.sh , se trouve dans le mếme répertoire que le script php, permet de spécifier le chemin du script script.sh simplement, en le préfixant par un point et un slash. "./script.sh" donc ).

Normalement, j'ai déjà testé avec des paramètres, et aussi avec une redirection des erreurs vers le puids sans fond 2>/dev/null, ça marche très bien, et le script en Bourne Shell prend très bien les paramètres dans les variables $1, $2, etc... comme tout bon script en Bourne Shell qui se respecte.

Il est vrai, que le serveur où ceci a été mis au poinnt, avait le "Safe Mode" désactivé, c'est-à-dire à off.

Evidemment, c'st sûr que le script en Bourne Shell, doit avoir pour première ligne, ceci :

#/bin/sh

De toute manière, l'interpréteur sh ( équivalent de bash ), est toujours dans le répertoire /bin/ ( et non pas /usr/bin/ ), dans un système Unix ou Linux.

Mais bon...

Bien à vous.

Amicalement.

Jean-François Ortolo
 

ortolojf

WRInaute accro
Rebonsoir

J'ajoute, que dans le script en Bourne Shell, j'ai pris la précaution de configurer la variable d'environnement $PATH, de cette manière :

Code:
#/bin/sh

PATH=$PATH:/usr/bin/:/usr/local/bin/:.
export $PATH

# Il ne faut pas oublier les deux-points et le point à la fin,
# pour le répertoire courant.

$repert="votre répertoire absolu courant"
cd $repert

# Pour obtenir le chemin absolu d'une commande, c'est simple :
awk=`which awk`

# La variable $awk contient maintenant le chemin absolu de la commande awk
# C'est merveilleux, c'est-ce pas ?  ;)
#

# Pour avoir le chemin absolu de l'interpréteur php, c'est plus compliqué, il peut y avoir la version cli, et la version cgi de php, qui correspodent à plusieurs programmes différents, même de noms différents.
# En général, si le php du serveur est en mode cgi :
php_cgi=`which php`
# ... contiendra le chemin de l'interpréteur cgi.

# Si le serveur est configuré par défaut en mode cli, c'est le contraire ( mode cli ).

# Etc... On fait la tâche...

exit 0


Bien à vous.

Amicalement.

Jean-François Ortolo
 

Discussions similaires

Haut