Bonjour,
 
Je suis actuellement sur un projet pour lequel j'ai besoin d’exécuter un fichier .exe sur un serveur distant, à travers une interface web et je ne trouve pas comment faire. Telnet ? Autre ?
 
Merci de votre aide.

Précision :
Je dois m'identifier pour avoir accès à ce serveur...

ssh plutôt que telnet, je pense
 
http://www.php.net/manual/en/book.ssh2.php

En fait le serveur en question ne possède ni de service telnet, ni ssh, le seul moyen actuel de s'y connecter est via le bureau à distance.
 
Par contre, j'ai trouvé qu'avec l'outil PsExec, il est possible de lancer des commandes sur un serveur distant.
Donc en admettant que PsExec.exe se trouve sur c:\ de mon poste local et le fichier à executer sur c:\batch\fichier.bat sur le serveur 192.9.200.6 :  
lorsque je lance la commande c:\psexec \\192.9.200.6 c:\batch\fichier.bat -u login -p password --> celà fonctionne correctement
 
Par contre lorsque cette commande est lancée via ma page php avec PsExec.exe dans c:\wamp\www\monprojet\ :
$commande = "psexec \\192.9.200.6 c:\batch\fichier.bat -u login -p password";
exec($commande);
-> la page n'en fini pas de charger et le fichier n'est pas exécuté. Je ne comprend pas pourquoi...
Un peu d'aide me serait utile. Merci

J'ai ouvert y'a qq jours un topic sur le même pb observé : une ligne de commande qui passe très bien dans le cmd.com mais pas quand elle est lancée depuis shell_exec J'ai pas eu de réponse qui a résolu mon pb. A noter que je n'ai pas ce pb quand c'est sous Linux.

Malheureusement le serveur web en question est sous windows
 
Ce qui est fou c'est que si je remplace
$commande = "psexec \\192.9.200.6 c:\batch\fichier.bat -u login -p password";  
par
$commance = "mkdir toto"
-> le repertoire toto est bien crée !
Le problème vient donc de l'execution de psexec mais je ne comprend pas pourquoi.
 
Sinon il ne serait pas possible de créer une sorte "d'objet cmd" qui permettrait ensuite qu'on lui envoie des commandes à executer afin de ne pas avoir à utiliser exec(),shell_exec() ou system() ?...

Attention, un seul \, c'est pour échapper un caractère! Faut les doubler ou mettre / à la place

j'ai réessayé avec $commande = "psexec \\\\192.9.200.6 c:\\batch\\fichier.bat -u login -p password";  
mais toujours le même problème.
En tapant "php psexec" sur google, je suis tombé sur plein de topic où les gens ont le même problème mais aucune solution apportée
Si quelqu'un a une idée pour pouvoir faire ce que je souhaite sans passer par PsExec, je suis preneur...

J'ai modifier le code comme celà (PsExec.exe dans c:\):
 
exec("c:\psexec \\\\192.9.200.6 c:\batch\fichier.bat -u login -p password 2>&1",$output);
echo var_dump($output);
 
et voilà ce que j'obtiens
 
array(8) { [0]=> string(0) "" [1]=> string(41) "PsExec v1.98 - Execute processes remotely" [2]=> string(40) "Copyright (C) 2001-2010 Mark Russinovich" [3]=> string(35) "Sysinternals - www.sysinternals.com" [4]=> string(0) "" [5]=> string(22) "Descripteur non valide" [6]=> string(59) "Connecting to 192.9.200.6... Couldn't access 192.9.200.6:" [7]=> string(28) "Connecting to 192.9.200.6..." }
 
Pourtant les identifiants login et password sont ceux du compte administrateur...
Et que voudrait dire ce "Descripteur non valide" ?
Car la même commande passée dans cmd fonctionne toujours...
 
A noter que sans le 2>&1 (je ne sais pas à quoi ça sert mais j'ai vu quelqun mettre ça sur un forum), j(obtiens :
 
array(0) {}

C'est pour rediriger le descripteur 2 (stderr?) dans le 1 (stdout?). Le &, c'est pour pas rendre bloquant la fin de l'exécution de la commande.

Merci pour l'info rufo
 
Malheureusement, malgrès 5h passées sur les différents résultats de google, je n'arrive toujours pas à trouver la solution à mon problème

La vrai solution c'est de faire un peu moins de bidouille...
 
2 solutions :
- serveur proprio via socket qui attends un requête et exécute le dit programme à chaque requête (devrais être très léger même via un Service Windows)
- serveur HTTP avec un WS/une page PHP qui attends une requête et exécute le dit programme
 
Et même là c'est encore pas gégé...