SME 7.5 en mode "Server Only" + PHP 4 = PHP intermittent

[HP77]

Bonjour,

Décidément, j'ai de la veine avec mon serveur au Campus (...)

J'accède à une i-bay de mon serveur de différentes manières depuis mon PC client comme suit :

- Si j'accède par la redirection http://MonIntranet.DynDNS.org/, j'ai bien le fruit de mes scripts PHP qui s'affiche.
- Si j'accède par http://@IP_Serveur/Intranet/ je n'ai rien que la partie HTML qui s'afiche. Pas un bout de code PHP visible dans le source HTML de la page...

Que l'adresse IP du serveur soit 192.168.0.10 (locale sur le LAN_Routeur) ou 172.aaa.bbb.250 (externe via la fonction DMZ du Routeur), c'est le même cirque.


Pour les infos techniques, c'est par ici :

- La correspondance entre l'URI et l'i-bay est réalisée par le biais du mécanisme SME permettant de faire correspondre une i-bay à un nom de domaine qui est configuré, à la fois dans le panneau de gestion des domaines et dans le panneau ddclient.

- Compte DynDNS.org (super basique...):

- Hostname: MonIntranet.dyndns.org
- Wildcard Status: Disabled
- Service Type: Host with IP address
- IP Address: 172.aaa.bbb.250
- Mail Routing: [ ] Yes, let me configure Email routing.

- Configuration réseau :

{ LAN_Campus (172.aaa.bbb.xxx/25) }---[ (172.aaa.bbb.250/25) Routeur D-Link DIR-600 ]---{ LAN_DIR-600 (192.168.0.xxx/24) }

{ LAN_DIR-600 (192.168.0.xxx/24) }---[ (192.168.0.10/24) Serveur SME 7.5 en mode "Private Server Only" ]
{ LAN_DIR-600 (192.168.0.xxx/24) }---[ (192.168.0.123/24) PC client M$-Windows XP ]

Fonction DMZ du routeur est activée et redirige tout ce qui vient du LAN du campus sur le serveur SME.

Bon, voilà ce que je n'ai pas eu le temps de poster hier soir.


Sur ce, bon weekend, j'en ai grand besoin.

Cordialement,
HP

[jpmgir]

salut

- Si j'accède par la redirection http://MonIntranet.DynDNS.org/, j'ai bien le fruit de mes scripts PHP qui s'affiche.

pour moi avec cet adresse tu arrive dans l'ibay primary.

- Si j'accède par http://@IP_Serveur/Intranet/ je n'ai rien que la partie HTML qui s'affiche.

alors que la tu arrive dans l'ibay intranet!
peu etre avec http://@IP_Serveur/ tu arriverai au même endroit (l'arbre qui porte les fruit de tes scripts).

[jibe]

Salut,

jpmgir a très probablement donné la bonne réponse. Toutefois, ce fil m'en rappelle étrangement un autre ! Je ne serais donc pas surpris qu'il y ait là deux problèmes imbriqués, le second étant commun aux deux fils...

[HP77]

Hello,

..., ce fil m'en rappelle étrangement un autre ! Je ne serais donc pas surpris qu'il y ait là deux problèmes imbriqués, le second étant commun aux deux fils...

C'était aussi un peu mon idée au départ mais depuis mes débuts avec SME 5.6 je sais que la variable globale (oui, euh, je sais que ce n'est pas bien et j'ai honte d'utiliser encore cela... ) $_SERVER[ 'DOCUMENT_ROOT' ] ne renvoit pas le même résultat lorsque l'on est dans l'i-bay Primary ou bien une autre i-bay créée pour les besoins du moment.
Pour éviter les surprises, j'utilise toujours des chemins absolus ( /home/e-smith/files/ibays/intranet/html/mon_script.inc.php ) dans mes scripts pour les accès aux fichiers et/ou inclusions.

J'aurais peut-être dû le préciser, c'est vrai que j'ai focalisé sur la différence d'accès à l'i-bay et la configuration réseau (vu que c'est ce qui me donne du fil à retordre ces temps-ci (...))

Bon, j'espère n'avoir rien oublié de mentionner cete fois-ci.

La configuration Apache, PHP, etc... tout y est tel que "out of the box"... (j'ai fais "paresseux" mais SME se doit d'être "safe" (sûre) par défaut, donc, je n'ai rien changé.

Un dernier point, je n'ai pas non plus "échapé" les retours de fonctions par "@" en cas d'erreur donc, s'il y a plantage lorsque PHP parse le code, je devrais avoir un gros "blanc" là où ça coince et pas une page HTML complète et sans code PHP visible à l'écran.

Quant-à l'affichage des messages d'erreurs de PHP, je n'ai rien changer non plus par là : jamais visibles, par défaut sur SME.

Peut-être tout bêtement un problème de PHP mais, bon, j'ai ça sous SME...


Sur ce, bonnes cogitations à vous aussi.


Cordialement,
HP

[HP77]

Bonjour,

...
peut-être qu'avec http://@IP_Serveur/ tu arriverais au même endroit (l'arbre qui porte les fruit de tes scripts).

Et bien non.
Dans ce cas, ce serait "l'i-bay" Primary. C'et pour cela que je dois rajouter le nom de l'i-bay après l'adresse IP du serveur.

Autre chose incohérente, si c'était ça mon problème, pourquoi aurais-je le bon résultat HTML à l'écran et absolument rien concernant la portion de code PHP intégrée à ce même fichier index.php, le seul fichier INDEX à la racine de cette i-bay (pas de fichier index.html qui serait lu en premier par Apache (...)).

Je colle le code source de ma page de test :

Code: Tout sélectionner

<html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<TITLE>Intranet</TITLE>
    <link href="./_inc/css/default_css.css" rel="stylesheet" type="text/css">
  </HEAD>
  <body>
    <?PHP
      echo $_SERVER[ 'REMOTE_ADDR' ] . "<br/>";
     ?>
    <p>
      Message issu du code HTML, s'affiche bien.
    </p>
  </BODY>
</HTML>

Est-ce que M$-IE7 et FireFox ne seraient pas un peu malades à cause de ces balises HTML en capitales et non pas en minuscules comme c'est, semble-t-il devenu un standard ?
(je n'arrive plus à remettre le "clic" sur l'article que j'ai lu à ce sujet sur la toile. )

Cela dit, pourquoi y aurait-il une différence de traitement entre URI avec http://MonIntranet.DynDNS.org/ et http://@IP/MonIntranet/ ??

Bon, j'ai fait un essai en changeant les balises, minuscules ou MAJUSCULES, même "topo"...


J'aimerais bien que ça fonctionne pareil tout le temps, peut importe que ce soit DynDNS (à titre provisoire) ou une adresse IP fixe (à termes).


Bon, si quelqu'un à une idée ...


Cordialement,
HP

[jibe]

Salut,

Cela dit, pourquoi y aurait-il une différence de traitement entre URI avec http://MonIntranet.DynDNS.org/ et http://@IP/MonIntranet/ ??

Relis le post de jpmgir !

Et si tu ne comprends toujours pas, essaie :
http://MonIntranet.DynDNS.org/MonIntranet/
et
http://@IP/

Cela dit, je répète qu'il peut aussi y avoir un double problème, l'un étant les url utilisées, l'autre étant le même que celui que tu rencontres avec ta popup window. Si c'est le cas, en résoudre un seul peut très bien ne rien changer, ou pas dans le bon sens...

Bon, j'ai fait un essai en changeant les balises, minuscules ou MAJUSCULES, même "topo"...

Sauf erreur de ma part, la DTD utilisée (HTML 4.0 Transitional) n'impose pas les balises en minuscules => normal qu'il n'y ait aucune différence en changeant la casse des balises.

[HP77]

Hello,

Cela dit, pourquoi y aurait-il une différence de traitement entre URI avec http://MonIntranet.DynDNS.org/ et http://@IP/MonIntranet/ ??

Relis le post de jpmgir !

Et si tu ne comprends toujours pas, essaie :
http://MonIntranet.DynDNS.org/MonIntranet/
et
http://@IP/

Je l'ai relu et, comme pour la fin de ta reponse, Jibe, je serais d'accord si tous mes scripts etaient places dans l'i-bay Primary mais ce n'est pas le cas.
J'ai d^u m'exprimer sur ce point mais probablement dans un autre fil de discussion que celui-ci. Desole.

En m^eme temps, cela me semblait normal de ne pas esperer jouer avec des scripts PHP dans l'i-bay Primary vu les permissions tres particulieres qui lui sont affectees.

Pour moi, http://MonIntranet.DynDNS.org/ et http://@IP/MonIntranet/ devraient renvoyer le meme resultat puisqu'il existe, sous SME, dans le panneau "Domains" de Server-Manager, des reglages permettant de faire pointer http://MonIntranet.DynDNS.org/ directement sur http://127.0.0.1/MonIntranet/.
Je soupcone quelque chose ressemblant a la fonction "Referrer" fournie par PHP.

Cela dit, je répète qu'il peut aussi y avoir un double problème, l'un étant les url utilisées, l'autre étant le même que celui que tu rencontres avec ta popup window. Si c'est le cas, en résoudre un seul peut très bien ne rien changer, ou pas dans le bon sens...

Je suis tout à fait d'accord que l'autre problème rencontré (fenêtre popup imprévue/inattendu) puisse avoir une certaine incidence. Cela dit, utilisant les chemins d'accès absolus pour atteindre les fichiers requis au moment où PHP 'parse' les scripts, cela devrait toujours fonctionner ou, au pire, générer une erreur chez PHP et faire abandonner le traitement en cours du(des) script(s).
Pas d'accord ??

Bon, j'ai fait un essai en changeant les balises, minuscules ou MAJUSCULES, même "topo"...

Sauf erreur de ma part, la DTD utilisée (HTML 4.0 Transitional) n'impose pas les balises en minuscules => normal qu'il n'y ait aucune différence en changeant la casse des balises.

Deja une possibilitee d'eliminee, c'est tant mieux.


Bon, je vais voir l'autre fil de discussion...

Cordialement,
HP

[jibe]

Salut,

jdh dirait : KISS (Keep It Simple and Stupid). Je crois te l'avoir déjà dit...

Avant de faire des configurations compliquées et de partir dans de grandes théories, si tu veux résoudre ton problème et surtout une aide efficace pour cela, tu devrais :
- Faire fonctionner les choses de manière "normale",
- Faire les essais qu'on te demande de faire,
- Nous donner les détails nécessaires et éviter ceux qui sont de toute évidence inutiles,
- Bien comprendre à quoi servent les fonctionnalités et comment s'en servir avant de les utiliser, souvent à mauvais escient (comme la redéfinition des DNS de l'autre fil...)
- Avant toute réalisation, définir d'abord ton besoin, puis faire ce qui est nécessaire pour le satisfaire de la manière la plus simple possible.
- Réfléchir à quoi peut bien te servir une usine à gaz avec entre autres des DNS redéfinis de manière très bizarre et des domaines redéfinis pour appeler de manière (crois-tu) plus simple mais peu orthodoxe quelques pages web à usage apparemment interne (sinon, nous permettre de constater et donc d'étudier plus directement le problème nous ferait gagner énormément de temps !).

C'est un peu la même chose pour tous tes problèmes : j'ai l'impression d'une usine à gaz inutile et mal conçue, de laquelle je connais tous les détails sauf ceux qui me permettraient d'en comprendre le fonctionnement (à supposer qu'il soit compréhensible ) et pas moyen de savoir ce qui me permettrait de t'aider, ou alors il faut partir à la pêche éventuellement dans d'autres fils...

J'ai d^u m'exprimer sur ce point mais probablement dans un autre fil de discussion que celui-ci. Desole.

essaie :
http://MonIntranet.DynDNS.org/MonIntranet/
et
http://@IP/

Le résultat de ces essais me (et très probablement te) permettrait de comprendre tout de suite ce qui se passe ou au moins de me rendre compte si je pars sur une fausse piste.

Je suis tout à fait d'accord que l'autre problème rencontré (fenêtre popup imprévue/inattendu) puisse avoir une certaine incidence. Cela dit, utilisant les chemins d'accès absolus pour atteindre les fichiers requis au moment où PHP 'parse' les scripts, cela devrait toujours fonctionner ou, au pire, générer une erreur chez PHP et faire abandonner le traitement en cours du(des) script(s).
Pas d'accord ??

Ben non ! Sauf à n'avoir rien compris au fonctionnement de ton usine à gaz (ce qui est vraiment le cas ), je ne vois pas ce qu'une URL donnée dans la barre d'adresse d'un navigateur - en plus avec un problème de DNS - a à voir avec les adresses absolues utilisées dans les scripts. Scripts dont on ne sait d'ailleurs absolument rien, hormis qu'ils sont écrits en PHP !

Comment donc PHP pourrait-il "parser" des scripts et en tirer des adresses absolues alors que manifestement il ne trouve pas ces scripts Plus exactement, que les scripts ne sont pas trouvés, et donc que PHP n'est pas appelé...

A noter que lorsque PHP n'est pas appelé, il ne génère pas de message d'erreur