OVH Community, votre nouvel espace communautaire.

[urgent] mon script ne fonctionne pas sur les serveurs d'OVH (il marche en local)


jwhosting
17/01/2010, 21h28
contacte le service commercial en expliquant ton problème et que tu passes sur dédié

anxious
17/01/2010, 17h53
en effet, j'aurais juste aimé avoir eu lors de ma souscription au contrat OVH de telles limites... je suis extrêmement déçu de la part d'OVH surtout que j'ai renouvelé mon contrat en décembre pour 1 an...

Toro
14/01/2010, 12h13
Si tu as besoin d'ouvrir des ports en PHP, je ne pense pas qu'un mutualisé soit la solution idéale pour toi. Toutes les offres mutualisées que j'ai eu l'occasion de tester ont des limitations sur les ports accessibles.
Diriges-toi plutôt vers un serveur "kimsufi", tu auras beaucoup plus de souplesse dans tes développements.

Sarc
14/01/2010, 11h43
Je ne suis pas sûr de ce que j'avance anxious, mais je pense que d'écrire en taille 36 et en rouge ne rendra pas les administrateurs d'OVH plus conciliants envers toi.

Et en plus, c'est désagréable pour les autres lecteurs du sujet.

Maintenant, j'espère quand même que tu pourras résoudre ton souci. Enfin, après tous les tests qui ont été faits, il semblerait que le TCP marche, mais pas l'UDP. Et si l'UDP marche pas, il semblerait que ce soit volontaire de leur part. Donc pas sûr que tu puisses arriver à tes fins avec un mutualisé OVH.

anxious
14/01/2010, 11h33
Ticket répondu au bout de 7 jours.

Bonjour,

Je vous présente nos excuses pour ce retard.
En effet, les sockets sont bloqués par défaut sur toutes
nos offres mutualisées que ce soit en UDP ou bien en TCP
pour des raisons de sécurité.

Cordialement,
Fabrice D.
.............. pour avoir ce genre de réponses, ont t'il seulement pris le temps de lire le ticket ? si effectivement comme il l'avance, les ouvertures de socket sur un serveur distant était bloqué, mon script qui utilise une ouverture de socket en TCP ne fonctionnerait pas......


Et c'est reparti pour 7 jours d'attente avant une réponse (tout ca pour un ticket en priorité maximum...)

...................

anxious
13/01/2010, 13h17
je suis toujours sans nouvelles de ovh. Le ticket date maintenant d'il y à 6 jours

anxious
06/01/2010, 21h24
ce qui confirme le problème qui vient d'OVH. Que faut t'il faire pour qu'ils corrigent ce problème au PLUS TOT ?


perso moi je peux pas en ouvrir j'en ai deja un en cours... je suis vert...
mon activité ne repose que sur ce script.... (enfin le controle qu'il fait)

merci Nowwhat d'avoir pris du temps pour tester

Nowwhat
06/01/2010, 20h35
J'ai testé quelques exemples présent sur le net.

J'ai trouvé ceci : http://www.kloth.net/software/timesrv1.php



Code PHP:
# PHP V4

function query_time_server ($timeserver$socket) {
/* Query a time server
   (C) 1999-09-29, Ralf D. Kloth (QRQ.software)  */

  
$fp fsockopen($timeserver,$socket,$err,$errstr,5);
        
# parameters: server, socket, error code, error text, timeout
  
if ($fp) {
    
fputs($fp,"\n");
    
$timevalue fread($fp,49);
    
fclose($fp); # close the connection
  
}
  else {
    
$timevalue " ";
  }

  
$ret = array();
  
$ret[] = $timevalue;
  
$ret[] = $err;     # error code
  
$ret[] = $errstr;  # error text
  
return($ret);

# function query_time_server 


/* Query a time server
   (C) 1999-09-29, Ralf D. Kloth (QRQ.software)  */
$timeserver "tcp://time-C.timefreq.bldrdoc.gov";
$timercvd query_time_server($timeserver,13);
if (!
$timercvd[1]) { # if no error from query_time_server
  
$timevalue $timercvd[0];
  echo 
"Time check from time server ",$timeserver," : [",$timevalue,"].
\n"
;
#if (!$timercvd)
else {
  echo 
"Unfortunately, the time server $timeserver could not be reached at this time. ";
  echo 
"$timercvd[1] $timercvd[2].
\n"
;
# else

?>
Le serveur time-C.timefreq.bldrdoc.gov écoute sur TCP et UDP.

Avec tcp://time-C.timefreq.bldrdoc.gov j'ai
Time check from time server tcp://time-C.timefreq.bldrdoc.gov : [ 55202 10-01-06 19:37:15 00 0 0 467.9 UTC(NIST) *].
Avec udp://time-C.timefreq.bldrdoc.gov j'ai
... nada

anxious
06/01/2010, 20h19
Non toujours rien, et ca se comprends,
A aucun moment le script ne test ici la connexion au socket, il devrait normalement pas y avoir de problème avec le problème de fiabilité du retour socket en UDP.

anxious
06/01/2010, 20h13
ok alors je vais virer le test de vérification de l'établissement de la connexion avec le socket et je vous dit si y'a du changement (merci de l'info nowwhat, je l'avais vu sur la doc php, mais pas tenu compte)

Nowwhat
06/01/2010, 20h10
Je edit en haut ....

anxious
06/01/2010, 19h53
Je rappelle qu'en local tout fonctionnne correctement, je viens de refaire le test, donc le problème est forcément ailleur que dans le code......

je ne peux meme pas ouvrir un ticket, vu que j'ai un ticket dit 'urgent' qui traine et qui est toujours ouvert....

si vous avez d'autres idées je suis preneur. Merci

anxious
06/01/2010, 19h30
Négatif, quand j'enlève le @ rien ne se produit.

j'ai juste une erreur SOCKET preuve qu'il ne peux pas être ouvert ?

Code PHP:
 //Not connected error
    
if(!$status)
    {
    
// echo '0'
        
echo 'ERREUR SOCKET';
    exit();
    } 
Oui mon script est compatible avec les "lois" d'OVH puisque le socket est ouvert sur le serveur distant et non sur le serveur mutualisé

Nowwhat
06/01/2010, 19h14
Un recherche sur ce forum (en totalité - mais restons sur le Mutus) avec le mot fsockopen donne entre autre ceci : http://forum.ovh.com/showthread.php?t=4555

A voir si ce que tu souhaite de faire est compatible avec les "lois" d'OVH.

edit : suivant http://forum.ovh.com/showthread.php?...ight=fsockopen
"Les sockets UDP semblent quelques fois avoir été ouvertes sans erreur, même si l'hôte distant n'est pas accessible. L'erreur apparaît alors uniquement lorsque vous tentez de lire/écrire sur la socket. La raison de cela est que UDP est un protocole "connectionless", ce qui signifie que le système ne tentera pas d'établir un lien pour la socket tant qu'il ne doit pas recevoir/envoyer de données."

Donc le retour d'un fsockopen() en UDP n'est pas 'fiable'.

sfk
06/01/2010, 19h05
Non, je ne suis pas sur : Enlève le caractère '@' devant le fsockopen pour t'assurer qu'il n'y pas pas une erreur générée ; affiche le contenu de $errno et $errstr.

anxious
06/01/2010, 18h15
Es tu sûr que l'ouverture de socket est interdit ?

car j'ai un autre script (pour un autre jeu) qui lui fonctionne correctement

Script qui fonctionne sur les serv OVH (avec ouverture de socket)
Code PHP:
  function rcon_command($ip$port$password)
        {
            
$socket = @fsockopen ('tcp://'.$ip$port$errno$errstr15);
          ..... } 
Script qui ne fonctionne pas sur OVH (avec ouverture de socket):
Code PHP:
//Open socket to gameserver
  
function Connect($server_ip$server_port$server_password "")
  {
    
$fp = @fsockopen("udp://".$ip$port$errno$errstr15);
....} 

Cela serait bien de faire savoir, si cela est vrai, que l'ouverture de socket est interdit vers un serveurs tiers. Car mon activité est basé sur le contrôle que je fais ! Sans ce contrôle, mon site n'à plus lieu d'être...
La seule différence pour la méthode d'ouverture ces deux scripts est que l'un fait appel à la méthode TCP et l'autre UDP.


(merci pour le exit(); )

sfk
06/01/2010, 18h02
Pour des raisons de sécurité, les serveurs mutualisés OVH n'autorisent pas d'ouvrir une socket vers un serveur tiers.

Le code qui pose probleme est celui-ci.
Code:
$fp = @fsockopen("udp://".$this->server_ip, $this->server_port, $errno, $errstr, 5);
Par ailleurs, dans le fichier validerRcon.php, il faut ajouter un exit()

Code:
//get server info
  $status = $server->ServerInfo();

  //Not connected error
  if(!$status)
  {
  echo '0';
  exit();
  }

anxious
06/01/2010, 17h54
le truc c'est que quand je met en local PHP 5.2.11 (comme sur OVH), mon script fonctionne TOUJOURS en local, et JAMAIS sur le web

jwhosting
06/01/2010, 17h53
5.2 et 5.3 sont très différents, il y a eu énormément de changements entre les deux versions

essaye de mettre le error_reporting à E_ALL

anxious
06/01/2010, 17h48
Bonjour,

tout beau, tout fier, je finis le coding d'un script PHP qui vérifie qu'un utilisateur est réelement le possésseur d'un serveur. Tout marche correctement sans générations d'erreures (PHP 5.3.0 en local et 5.2.0 sur le serveur OVH mutualisé PRO)

je l'upload sur le site, fais la promotion du nouveau service qui viens d'ouvrir, et pouf, je me rends compte sans aucune raison valable que le script ne fonctionne pas sous OVH. Il n'y à aucun message d'erreur.

La preuve en concret :

Mon script en version locale qui fonctionne :

http://www.gamer-certified.fr/testlocal/testlocal.zip

Structure des fichiers :
1. index.php = là ou vous devez rentrer l'adresse IP, le Port et le mot de passe

2. verificationAjoutServeur.js = Vérification Ajax du couple IP + Port + Mot de passe RCON

3. Rcon_hl_net : Classe PHP qui permet d'interroger le serveur, savoir si le mot de passe RCON est bon. [les parties principales à regarder sont entre autre l'ouverture du socket ligne 53 et les lignes suivantes (fonction AUTH).]

4. validerRcon.php = Les informations AJAX sont postés dans se fichier qui fait appel à la classe rcon_hl_net pour savoir si c'est le bon mdp RCON. 1 est retourné qd tout est OK. 0 est retourné quand le mot de passe n'est pas le bon, ou que la connection au serveur n'a pas pu être établie.
ok, maintenant on passe à la version en ligne :
http://www.gamer-certified.fr/testlocal/

Ici rien ne va plus, alors que tout fonctionne parfaitement en local, la réponse renvoyé est toujours '01' au lieu de '0' ou '1' et donc quelque soit le mot de passe, il indique que tout est OK

La version hébergé est la même que vous venez de télécharger.

D'où ce problème TRES génant peut t'il venir ? Les modifications sont live sur le site et du coup ca génère des bugs. Le pire dans tout ca c'est que je ne peux plus revenir en arrière.

Merci

EDIT: Après des tests menés par Nowwat et moi même, il semblerait que le problème vienne bel et bien de chez vous (OVH), en effet, les requêtes pour ouvrir un socket en TCP fonctionnent, mais pas pour l'UDP