Me revoila parti dans les truc tordus ...

WRInaute accro
Pour résoudre un pb je me pose une quetsiuon : est il possible (souhaitable) de faire executer sur un serveur web un petit bout C/C++ (ou plus generalement un executable compilé quel qu'il soit).

Je m'explique : je voudrais faire ecrire une bpoite noire "montrucenC" qui va faire un travail spécifique (en entrée il a un truc , en sortie il a fait son travail). Et ensuite je voudrais pouvoir dans une page php ecrire un truc du style :

<?php

.
.
.
je mets un truc sur le disque du serveur

j'execute montrucenC

je vais lire sur le disque du serveur le resultat du ttaf en c ..
?>

Est ce que y a des instructions en php pour faire cela (style exec($chemin);)

Hum hum je sens que ca va encore etre un truc pour mon jacques préféré :mrgreen:
 
WRInaute occasionnel
Oui tu peux l'utiliser. Il y a aussi Syst je crois ou un truc dans le style. Mais ces fonctions sont désactivées sur les hébergements mutualisés il me semble pour raison de sécurité.
 
WRInaute accro
Aaarrrgggh a dit:
Mais ces fonctions sont désactivées sur les hébergements mutualisés il me semble pour raison de sécurité.
arfff

edit : j'avais ecris "exec" au pif ... ne sachant pas que cette commande existait en php :mrgreen:
 
WRInaute accro
La première question qui me vient à l'esprit c'est "pourquoi?". J'ai une petite idée des raisons possibles, mais je suis curieux :)

Sinon, effectivement, il y a plusieurs méthodes pour appeler un programme externe, sachant que tu n'es même pas forcément obligé d'utiliser des fichiers temporaires pour communiquer avec lui, tu peux passer des arguments, et tu peux communiquer via des pipes dans les deux sens. En plus de exec, system et passthru, il y a aussi popen, proc_open, et tous leurs copains.

Maintenant, il faut faire très, très attention: la plupart de ces commandes (toutes?) passent en fait la ligne de commande à un shell, qui peut interpréter toutes sortes de choses si elles ne sont pas correctement escapées. De la même façon, il faut aussi très fortement contrôler les chemins de fichiers passés, histoire qu'un attaquant ne puisse pas accéder à des fichiers auxquels il ne devrait pas à grands coups de ".." par exemple...

Jacques.
 
WRInaute accro
jcaron a dit:
La première question qui me vient à l'esprit c'est "pourquoi?". J'ai une petite idée des raisons possibles, mais je suis curieux :)
La première raison est purement mecanique ; deporter en compilé un traitement qui frise régulièrement avec la limite des 30s en php ... alors que je sais pas experience que le meme traitement bien codé et compilé c'est un truc qui va se mesurer en millisecondes ...

Ensuite, tant qu'a explorer cette piste (je suis en pleine formation ne l'oublie pas), je vais essayer de voir dans quellemesure elle ne peut pas être plus ou moins généralisée et appliquée à tout traitement un peu long et stabilisé avec comme résultat attendu un gain en ressources consommées ...

And last but not least, rendre vraiment confidentielle une moulinette en pouvant lamettre a disposition d'autres webmaster sous forme de plug-in compilé.

Ben voui, je suis un pisseur de code depuis 30 ans, on se refait pas :mrgreen:
jcaron a dit:
Sinon, effectivement, il y a plusieurs méthodes pour appeler un programme externe, sachant que tu n'es même pas forcément obligé d'utiliser des fichiers temporaires pour communiquer avec lui, tu peux passer des arguments, et tu peux communiquer via des pipes dans les deux sens. En plus de exec, system et passthru, il y a aussi popen, proc_open, et tous leurs copains.

Maintenant, il faut faire très, très attention: la plupart de ces commandes (toutes?) passent en fait la ligne de commande à un shell, qui peut interpréter toutes sortes de choses si elles ne sont pas correctement escapées. De la même façon, il faut aussi très fortement contrôler les chemins de fichiers passés, histoire qu'un attaquant ne puisse pas accéder à des fichiers auxquels il ne devrait pas à grands coups de ".." par exemple...

Jacques.
Bon je vais creuser tout ca avec la prudence qui s'impose ...
 
WRInaute accro
C'ets quoi le repertoire CGI ? :roll:

Bon en tout cas, mon approche ne vous fait pas faire des grands sauts de cabri, donc j'en conclu que :

1 - c'est pas totalement hérétique
2 - d'autres le font déjà :wink:
 
WRInaute accro
Comme le dit jacques, les compétences impératives ici sont bien plus en sécurité et administration serveur qu'en programmation. Si tu es en mutualisé, oublies tout de suite.
 
WRInaute accro
oui oui vu le nombre de mises en garde sur les aspects securité, je vais y aller piano ... juste debroussailler pour comprendre comment faire pour le moment ... et de toute façon je n'ai que des mutus ... (ca serait peut etre l'occasion de me lancer dans mon premier dédié ...)
 
WRInaute accro
Alors si tu n'as que des mutus je doute très très fort que ce soit possible ;) Ils ne sont pas fous quand même!

Un conseil, avant de passer au dédié, prends toi un kimsufi de base pour te faire la main pendant quelques semaines/mois.
Je suis passé du mutu au dédié par obligation... je galère comme c'est pas possible.
Heureusement que notre ami Julia traine sur le forum et qu'il est très calé car dès que j'aurai fait le tour de mes souci, je le contacterai pour lui demander un peu d'infogérance : https://admin-serv.net/ ;)

Tiens d'ailleurs, pose lui la question.
 
WRInaute accro
T'inquiète, j'ai un peu de bouteille en dev et debroussaillages de tous types ... et quelques reflexés acquis au fil des ans pour pas tout péter :mrgreen: Je vais déjà debroussailler en localhost ...

D'aillerus depuis que je fais "du web", je touche du bois mais j'ai encore jamais eu a recharger une secu because "mais il a tout pété" :wink: La seule fois ou j'aurais eu besoin de recharger une secu, c'est pas moi qui les faisaient ... l'autre non plus d'ailleurs :mrgreen: (joke ...cf topic yag).
 
WRInaute occasionnel
Zecat a dit:
C'ets quoi le repertoire CGI ? :roll:

Bon en tout cas, mon approche ne vous fait pas faire des grands sauts de cabri, donc j'en conclu que :

1 - c'est pas totalement hérétique
2 - d'autres le font déjà :wink:

Salut rro minet.

3 - d'autres y pensent sérieusement devant les piètres performances du couple php/sql. :D

Mais aussi "pisseur de code" au départ ! :mrgreen:

Bonne journée, Éric.
 
WRInaute accro
ricosound a dit:
3 - d'autres y pensent sérieusement devant les piètres performances du couple php/sql. :D

Il faut penser au couple PHP/MongoDB, et utiliser du cache d'opcode (APC).

Mais c'est vrai que pour de gros traitements, un programme en C ira tjs plus vite :)

Sur Facebook, ils utilisent HipHop PHP pour transformer du code PHP en C++.
 
Discussions similaires
Haut