Discussion :

[Chello]

Bonjour à tous,

J'ai un site sous serveur Linux Mandriva 2010 - Apache.

Le script "script.php" produit un script "script.R" et lance l'application qui va l'implémenter (ici : "R"). Cette application doit produire une image que je veux récupérer et mettre la page.

J'ai fait un répertoire dans /var/www/html/ "r" et lui ai donné les permissions 0777 :
drwxrwxrwx 2 root root 4096 ... r/

script.php écrit correctement "script.R"

-rw-r--r-- 1 apache apache 587 ... script.R

Mais R, par contre, n'arrive pas à écrire le fichier : permission denied.
Sauf si je lance script.R moi-même et en root.

En tant que simple utilisateur, j'ai vu que je pouvais écrire dans le répertoire r. Je pensais donc que l'application pourrait faire de même. Visiblement pas.

Comment faire pour donner les droits d'écriture à l'application R ?

Merci d'avance,

[_Mac_]

Tu l'exécutes comment, cette application "R" ?

[Chello]

Bonne question, tiens... !

J'ai une ligne de php qui doit normalement agir en mode batch :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$output = `Rscript $file 2>&1` ;

Ça marche sur mon Mac. Pb susdit avec Mandriva.

[_Mac_]

Et ce script PHP est exécuté par quel utilisateur système ? "apache" ou un autre ? Le souci peut venir des droits sur le répertoire où se trouve le fichier .R : si seul l'utilisateur apache peut écrire dedans, c'est normal d'avoir cette erreur. Il faut que les droits sur le répertoire du .R soient 777 (drwxrwxrwx)

[Chello]

Ben justement... c'est par là que j'ai commencé (cf mes premiers posts).

Je n'ai pas le serveur sous la main pour vérifier, mais pour répondre à la première question, je suppose que c'est apache qui lance le script. En tout cas, il est marqué propriétaire du fichier script.R généré dans le dossier R.
Donc il peut écrire.

Et si ce n'est pas lui qui lance le script (mais alors qui ?), dans ce cas le problème subsite, car j'ai déjà modifié les droits avec 777 (la 6ème ligne du 1er posts est le résultat de ls -l r/.

[_Mac_]

Oui, autant pour moi, j'ai lu trop vite.

Le fichier que doit générer le script doit se trouver dans quel répertoire ? Je dirais que le premier problème est effectivement d'identifier l'utilisateur système qui appelle ce .R (voir dans les crontab, peut-être). Ensuite il faut voir où est généré le fichier et si effectivement l'utilisateur qui doit lancer le programme .R peut écrire dans ce répertoire. Après, faut peut-être décortiqué le programme et mettre du debug pour voir exactement où ça plante. Tu peux déjà peut-être commencer par un simple "Hello World!" en R et voir si l'utilisateur qui doit lancer le script peut correctement exécuter du R : c'est peut-être un problème d'installation de R, pas de script.

[Chello]

Pffff, j'm'en sors pas, là.
Il y avait effectivement au passage un argument de fichier sortie à fournir. Ça évite une erreur. Mais le résultat est toujours le même.

Pb : Je ne sais pas utiliser crontab (moi = pingouin une étoile, pas plus.)

Par contre, j'ai demandé à R de produire un fichier sortie, et ça, ça marche.
Donc
1) R est bien lancé.
2) apache est le propriétaire du fichier sortie. Donc je suppose qu'il n'y a pas de doute là-dessus : c'est bien lui qui lance R. A priori, il devrait donc pouvoir écrire un fichier, puisque je le peux moi-aussi.
Ça m'énerve...

[Chello]

Ah tiens, le script ne fonctionne pas non plus quand je le lance moi-même en utilisateur... Petites vérif...

[Chello]

C'ÉTAIT UNE ERREUR DE PATH (pour info, donc, avec R SOUS LINUX, le chemin est relatif et dépend de l'endroit où se trouve le script - et non pas d'où a été envoyée la commande de lancement de l'appli
<> SOUS MAC.

Y'en a, des fois...

Enfin, merci Mac ! (non, pas Macintosh, MacGiver !)

Et depuis ce matin, j'ai le générique de MacGiver qui me trotte dans la tête.

[Chello]

Finalemnet, non, c'était pas encore ça.

Sous Linux, tout dépend du working directory (wd) défini dans R.

Bon, ça y est...