Yop, Je suis plus coté système que réseau, donc je vais devoir passer la main a quelqu'un d'autre ...
Mais quand on me dit duplication de VM, je pense directement aux adresses mac/IP de dupliquée, surtout si vous faites des copies a la mano. Bon ça m'étonnerai que ça soit ça pour le coup ... En tout cas, n'hésite pas à poster quand tu aura trouvé la solution :-) Bonne continuation, Cordialement -- MrJK GPG: https://jeznet.org/jez.asc Le 28 mars 2015 11:46, Christophe LE PORT <c.lep...@hotmail.fr> a écrit : > Bonjour, > > Nous investiguons toujours, c'est sur des serveurs en développement, du > coup c'est pas trop critique. > > 2 serveurs ont le même problème. > > un centos 7 qui heberge une application symphony > un centos 7 qui héberge une petite php que j'ai développé moi-même et une > appli cmdb Itop > > Comme les 2 vms ont été créer à partir d'un template vmware, nous avons > suspecté un problème au niveau du clone (réseau couche virtualisation ou > os). J'ai donc réinstallé un serveur en passant sur Centos 6.6 installé > depuis une ISO, mais le problème c'est reproduit. > > Nous nous sommes rendu compte en faisant des traces Wireshark sur un poste > client que quand le problème se produit nous avons des duplications de > trames, les trames dupliqués proviennent d'un de nos parefeu Netasq alors > que celui-ci ne sert pas de passerelle au serveurs. > Nous investiguons au niveau réseau, nous avons capturé des traces réseau > avec tcpdump sur le client et un serveur impacté ainsi sur le pare-feu d'ou > provienne les trames. > En faite on reçoit des duplications de connections tcp au niveau du client : > -> ip source "Serveur" mac source "Serveur" port source 80 Ip dest : > "client mac dest: "client" port dest 50400 SEQ:0 SYN:1 > -> ip source "Serveur" mac source "Netasq" Ip dest : "client mac dest: > "client" port dest 50400 SEQ:0 SYN:1 > > Du coup le client ne comprend pas ce que ce passe et affiche "la connection > à été reinitialisé pendant le chargement" > > Sur le serveur, aucune trame envoyé au pare-feu . > Au niveau du parefeu, on voit seulement quelques trames de la discussion > entre le client et le serveur (alors que théoriqument, il n'est pas censé > voir ces trames) et des fois il se met à répondre au client. > > C'est comme-çi le netasq interceptait la trame renvoyé par le serveur et le > retransmettait au client. > > Le question, pourquoi ce problème se pose avec ces serveurs Centos alors que > nous hébergeons au moins 20 appli web, aucune présente ce problème. > > Du coup, nous allons approfondir les recherches au niveau du netasq > (configuration particuliere liée à l'ip de ces serveurs, limite mss, proxy) > ainsi que sur la configuration des centos (paquet installé, ...) et au > niveau des switchs (problème d'adressage mac) > > Nous avons isolé le serveur Centos6.6 qui présentait le problème sur un > réseau différent pour voir si le problème se reproduit (pas encore validé) > > Mais comme c'est très aléatoire, c'est très long à débogué, nous utilisons > donc des scripts wget qui tourne toutes les 20 minutes, ça marche pas mal > pour reproduire l'erreur. Mais on peut avoir aucun soucis pendant une > mâtiné et l'après midi ça recommence. Difficile aussi de faire le lien avec > des alertes nagios. > >> Test 1: >> ######### >> Essayer de reproduire le problème depuis le localhost de ton serveur (wget >> --headers="Host:mondomaine.com" 127.0.0.1/test.php) > > Pas reussi a reproduire l'erreur en local > > Test 2: >> ######### >> Essayer de voir si c'est Apache le problème, ou plutôt le module PHP >> (mod_php ou PHP-FPM). Essayer de servir un fichier html et un fichier PHP, >> pour voir si le problème se reproduit sur le HTML > > Meme soucis > > Merci pour votre aide. > > Christophe > > > > > > > > > ________________________________ > From: mrjk...@gmail.com > Date: Fri, 27 Mar 2015 20:42:35 +0100 > Subject: Re: [FRsAG] Lot FRsAG, Vol 183, Parution 1 > To: c.lep...@hotmail.fr > CC: frsag@frsag.org > > > Et alors, tu as trouvé la source du problème? > > Cordialement > > -- > MrJK > GPG: https://jeznet.org/jez.asc > > Le 23 mars 2015 13:58, Mrjk <mrjk...@gmail.com> a écrit : > > Bah, les problèmes d'heure, ça fait souvent des effets de bords ... qui sait > ? > > Pour régler le problème: > -> Si décalage de quelques minutes: il faut installer le daemon ntpd pour > qu'il aille se synchroniser avec un serveur NTP. La machine sera à l'heure > exacte. > -> Si décalage de fuseau horaire: Il faut regarder la directive > date.timezone dans le php.ini du mod_apache (ou du FPM). Cf: > http://php.net/manual/fr/datetime.configuration.php#ini.date.timezone > > Dans tous les cas, je recommande l'installation d'un client NTP, surtout si > tu as un pool de serveur ... > > > -- > MrJK > GPG: https://jeznet.org/jez.asc > > Le 23 mars 2015 10:58, Christophe LE PORT <c.lep...@hotmail.fr> a écrit : > > Bonjour, > > merci encore pour votre aide. > Je suis sur les tests ce matin, mais comme c'est aléatoire c'est assez long > pour valider les étapes. > > En créant une page php avec >> // Start full report >> echo "<h1>SERVER: DATE</h1>"; >> echo "<pre>"; >> print_r(date("Y/m/d h:i:sa")); >> echo "</pre>"; >> echo "<h1>HTTP: REQUEST HEADER</h1>"; >> echo "<pre>"; >> print_r(getallheaders()); >> echo "</pre>"; > > Je me suis rendu compte que l'heure donnée par php ne corresponds pas avec > celle donnée par le serveur. > > Savez-vous quels impacts cela peut-il avoir ? > > Merci > > > > >> From: frsag-requ...@frsag.org >> Subject: Lot FRsAG, Vol 183, Parution 1 >> To: frsag@frsag.org >> Date: Mon, 23 Mar 2015 01:22:58 +0100 >> >> Envoyez vos messages pour la liste FRsAG à >> frsag@frsag.org >> >> Pour vous (dés)abonner par le web, consultez >> http://www.frsag.org/mailman/listinfo/frsag >> >> ou, par email, envoyez un message avec 'help' dans le corps ou dans le >> sujet à >> frsag-requ...@frsag.org >> >> Vous pouvez contacter l'administrateur de la liste à l'adresse >> frsag-ow...@frsag.org >> >> Si vous répondez, n'oubliez pas de changer l'objet du message afin >> qu'il soit plus spécifique que "Re: Contenu du digest de FRsAG..." >> >> >> Thèmes du jour : >> >> 1. Re: Apache rafraichissement page (Baptiste) >> 2. Re: Apache rafraichissement page (Emmanuel Thierry) >> 3. Re: Apache rafraichissement page (Christophe LE PORT) >> 4. Re: Apache rafraichissement page (j...@captainadmin.com) >> 5. Re: Apache rafraichissement page (Mrjk) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Sun, 22 Mar 2015 12:00:00 +0100 >> From: Baptiste <bed...@gmail.com> >> To: Christophe LE PORT <c.lep...@hotmail.fr> >> Cc: "frsag@frsag.org" <frsag@frsag.org> >> Subject: Re: [FRsAG] Apache rafraichissement page >> Message-ID: >> <caodhi7q4m+ch0pdgt2xbwb3v6wtnmoixokkzw6w3ejznkgd...@mail.gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> 2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.lep...@hotmail.fr>: >> > Bonjour, >> > >> > J'ai un soucis avec httpd 2.4.6 sur centos 7 >> > >> > Le serveur apache marche bien seulement quand j'ouvre une page sur le >> > port >> > 80 et que je rafraichis la page au bout d' un certain temps (environ >> > >5mn) , >> > ça plante (comme çi la page n'existait pas) >> > >> > Via notre reverse, il nous affiche l'erreur suivante : >> > >> > Proxy Error >> > >> > The proxy server received an invalid response from an upstream server. >> > The proxy server could not handle the request GET /test.php. >> > >> > Reason: Error reading from remote server >> > >> > >> > Au niveau des entêtes html, voici le cas d'un fonctionnement normal : >> > >> > Host: test.site15.net >> > User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101 >> > Firefox/36.0 >> > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 >> > Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3 >> > Accept-Encoding: gzip, deflate >> > Connection: keep-alive >> > >> > >> > Cache-Control: no-cache >> > Connection: Keep-Alive >> > Content-Type: text/html; charset=UTF-8 >> > Date: Sun, 22 Mar 2015 09:07:10 GMT >> > Keep-Alive: timeout=5, max=100 >> > Server: Apache/2.4.6 (CentOS) PHP/5.4.16 >> > Transfer-Encoding: chunked >> > Via: 1.1 test.site15.net >> > X-Debug-Token: 674072 >> > X-Powered-By: PHP/5.4.16 >> > >> > Voici la réponse html lors d'un plantage : >> > >> > Connection: Keep-Alive >> > Content-Length: 401 >> > Content-Type: text/html; charset=iso-8859-1 >> > Date: Sun, 22 Mar 2015 09:30:03 GMT >> > Keep-Alive: timeout=5, max=100 >> > Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips >> > >> > >> > Je me demande ce que viens faire "OpenSSL/1.0.1e-fips" alors que je fais >> > une >> > requête sur le port 80. >> > >> > Sur une analyse wireshark, on peut observer que le serveur envoi des TCP >> > RST >> > après la demande de GET du client alors qu'une connexion tcp est bien >> > établi >> > juste avant d'envoyer le GET HTTP. >> > >> > J'ai essayé de jouer avec le paramètre keepalive, sans succès ! >> > >> > Si quelqu'un à des pistes ? >> > >> > Merci, >> > >> > Christophe >> > >> >> >> Salut, >> >> Tu pourrais partager la trace réseau, même en PV? >> Ainsi que les logs Apache... >> J'ai déjà vu ce genre de comportement avec HAProxy, mais avec un >> client chrome, c'etait lié au "pre-connect" et à une mauvaise gestion >> du buffer de reception côté client. >> >> Baptiste >> >> >> ------------------------------ >> >> Message: 2 >> Date: Sun, 22 Mar 2015 12:15:44 +0100 >> From: Emmanuel Thierry <m...@sekil.fr> >> To: Christophe LE PORT <c.lep...@hotmail.fr> >> Cc: "frsag@frsag.org" <frsag@frsag.org> >> Subject: Re: [FRsAG] Apache rafraichissement page >> Message-ID: <b0a99c40-f8b1-451e-a4c5-bdedf505d...@sekil.fr> >> Content-Type: text/plain; charset=iso-8859-1 >> >> Bonjour, >> >> Le 22 mars 2015 à 11:31, Christophe LE PORT a écrit : >> >> > >> > Connection: Keep-Alive >> > Content-Length: 401 >> > Content-Type: text/html; charset=iso-8859-1 >> > Date: Sun, 22 Mar 2015 09:30:03 GMT >> > Keep-Alive: timeout=5, max=100 >> > Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips >> > >> > Je me demande ce que viens faire "OpenSSL/1.0.1e-fips" alors que je fais >> > une requête sur le port 80. >> >> Le header Server de apache est le même que tu l'utilises en HTTP ou HTTPS. >> Ça veut juste dire que ton apache a été compilé avec le support TLS. >> >> Cordialement >> Emmanuel Thierry >> >> >> >> ------------------------------ >> >> Message: 3 >> Date: Sun, 22 Mar 2015 16:30:10 +0100 >> From: Christophe LE PORT <c.lep...@hotmail.fr> >> To: Baptiste <bed...@gmail.com>, "webmas...@ajeux.com" >> <webmas...@ajeux.com> >> Cc: "frsag@frsag.org" <frsag@frsag.org> >> Subject: Re: [FRsAG] Apache rafraichissement page >> Message-ID: <dub119-w40f81e84e5d8b5e9298cffe7...@phx.gbl> >> Content-Type: text/plain; charset="iso-8859-1" >> >> Merci pour vos réponses, >> @Manu -> Le problème est identique que ce soit en direct ou en passant par >> le reverse >> >> @Baptiste et Olivier >> Il n'y aucune trace au niveau des logs httpd (passé en mode debug) sur le >> serveur apache >> Au niveau du proxy, il me retourne ces 2 lignes : >> [Sun Mar 22 16:09:41.754637 2015] [proxy_http:error] [pid 19583] >> (104)Connection reset by peer: [client 2.2.227.125:64566] AH01102: error >> reading status line from remote server 192.168.0.234:80[Sun Mar 22 >> 16:09:41.755049 2015] [proxy:error] [pid 19583] [client 2.2.227.124:64566] >> AH00898: Error reading from remote server returned by /test.php >> >> > Date: Sun, 22 Mar 2015 12:00:00 +0100 >> > Subject: Re: [FRsAG] Apache rafraichissement page >> > From: bed...@gmail.com >> > To: c.lep...@hotmail.fr >> > CC: frsag@frsag.org >> > >> > 2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.lep...@hotmail.fr>: >> > > Bonjour, >> > > >> > > J'ai un soucis avec httpd 2.4.6 sur centos 7 >> > > >> > > Le serveur apache marche bien seulement quand j'ouvre une page sur le >> > > port >> > > 80 et que je rafraichis la page au bout d' un certain temps (environ >> > > >5mn) , >> > > ça plante (comme çi la page n'existait pas) >> > > >> > > Via notre reverse, il nous affiche l'erreur suivante : >> > > >> > > Proxy Error >> > > >> > > The proxy server received an invalid response from an upstream server. >> > > The proxy server could not handle the request GET /test.php. >> > > >> > > Reason: Error reading from remote server >> > > >> > > >> > > Au niveau des entêtes html, voici le cas d'un fonctionnement normal : >> > > >> > > Host: test.site15.net >> > > User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) >> > > Gecko/20100101 >> > > Firefox/36.0 >> > > Accept: >> > > text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 >> > > Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3 >> > > Accept-Encoding: gzip, deflate >> > > Connection: keep-alive >> > > >> > > >> > > Cache-Control: no-cache >> > > Connection: Keep-Alive >> > > Content-Type: text/html; charset=UTF-8 >> > > Date: Sun, 22 Mar 2015 09:07:10 GMT >> > > Keep-Alive: timeout=5, max=100 >> > > Server: Apache/2.4.6 (CentOS) PHP/5.4.16 >> > > Transfer-Encoding: chunked >> > > Via: 1.1 test.site15.net >> > > X-Debug-Token: 674072 >> > > X-Powered-By: PHP/5.4.16 >> > > >> > > Voici la réponse html lors d'un plantage : >> > > >> > > Connection: Keep-Alive >> > > Content-Length: 401 >> > > Content-Type: text/html; charset=iso-8859-1 >> > > Date: Sun, 22 Mar 2015 09:30:03 GMT >> > > Keep-Alive: timeout=5, max=100 >> > > Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips >> > > >> > > >> > > Je me demande ce que viens faire "OpenSSL/1.0.1e-fips" alors que je >> > > fais une >> > > requête sur le port 80. >> > > >> > > Sur une analyse wireshark, on peut observer que le serveur envoi des >> > > TCP RST >> > > après la demande de GET du client alors qu'une connexion tcp est bien >> > > établi >> > > juste avant d'envoyer le GET HTTP. >> > > >> > > J'ai essayé de jouer avec le paramètre keepalive, sans succès ! >> > > >> > > Si quelqu'un à des pistes ? >> > > >> > > Merci, >> > > >> > > Christophe >> > > >> > >> > >> > Salut, >> > >> > Tu pourrais partager la trace réseau, même en PV? >> > Ainsi que les logs Apache... >> > J'ai déjà vu ce genre de comportement avec HAProxy, mais avec un >> > client chrome, c'etait lié au "pre-connect" et à une mauvaise gestion >> > du buffer de reception côté client. >> > >> > Baptiste >> >> -------------- section suivante -------------- >> Une pièce jointe HTML a été nettoyée... >> URL: >> <http://www.frsag.org/pipermail/frsag/attachments/20150322/323d5ea9/attachment-0001.html> >> >> ------------------------------ >> >> Message: 4 >> Date: Sun, 22 Mar 2015 23:28:41 +0100 >> From: j...@captainadmin.com >> To: frsag@frsag.org >> Subject: Re: [FRsAG] Apache rafraichissement page >> Message-ID: <1453bd49c0ee26948f69ae321b684...@captainadmin.com> >> Content-Type: text/plain; charset=UTF-8; format=flowed >> >> Bonsoir, >> >> Il faut vérifier si le flux arrive toujours sur le serveur final avec un >> tcpdump par exemple. >> En regardant les logs apache, a supposer que ton vhost soit correctement >> configuré, tu devrais avoir des informations dans /var/log/httpd/*.log >> qui te permettront de trouver plus facilement l'erreur. >> >> Si tu rafraichis plusieurs fois, le problème persiste ou la page ne >> s'affiche toujours pas? >> Ton test.php pourrait-être un simple >> <?php >> >> // Show all information, defaults to INFO_ALL >> phpinfo(); >> >> ?> >> >> pour être sur que ce en soit pas php qui pose problème ? >> >> Bonne soirée >> http://www.captainadmin.com >> >> >> >> >> Le 22-03-2015 16:30, Christophe LE PORT a écrit : >> > Merci pour vos réponses, >> > >> > @Manu -> Le problème est identique que ce soit en direct ou en >> > passant par le reverse >> > >> > @Baptiste et Olivier >> > >> > Il n'y aucune trace au niveau des logs httpd (passé en mode debug) >> > sur le serveur apache >> > >> > Au niveau du proxy, il me retourne ces 2 lignes : >> > >> > [Sun Mar 22 16:09:41.754637 2015] [proxy_http:error] [pid 19583] >> > (104)Connection reset by peer: [client 2.2.227.125:64566] AH01102: >> > error reading status line from remote server 192.168.0.234:80 >> > >> > [Sun Mar 22 16:09:41.755049 2015] [proxy:error] [pid 19583] [client >> > 2.2.227.124:64566] AH00898: Error reading from remote server returned >> > by /test.php >> > >> >> Date: Sun, 22 Mar 2015 12:00:00 +0100 >> >> Subject: Re: [FRsAG] Apache rafraichissement page >> >> From: bed...@gmail.com >> >> To: c.lep...@hotmail.fr >> >> CC: frsag@frsag.org >> >> >> >> 2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.lep...@hotmail.fr>: >> >> > Bonjour, >> >> > >> >> > J'ai un soucis avec httpd 2.4.6 sur centos 7 >> >> > >> >> > Le serveur apache marche bien seulement quand j'ouvre une page sur >> > le port >> >> > 80 et que je rafraichis la page au bout d' un certain temps >> > (environ >5mn) , >> >> > ça plante (comme çi la page n'existait pas) >> >> > >> >> > Via notre reverse, il nous affiche l'erreur suivante : >> >> > >> >> > Proxy Error >> >> > >> >> > The proxy server received an invalid response from an upstream >> > server. >> >> > The proxy server could not handle the request GET /test.php. >> >> > >> >> > Reason: Error reading from remote server >> >> > >> >> > >> >> > Au niveau des entêtes html, voici le cas d'un fonctionnement >> > normal : >> >> > >> >> > Host: test.site15.net >> >> > User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) >> > Gecko/20100101 >> >> > Firefox/36.0 >> >> > Accept: >> > text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 >> >> > Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3 >> >> > Accept-Encoding: gzip, deflate >> >> > Connection: keep-alive >> >> > >> >> > >> >> > Cache-Control: no-cache >> >> > Connection: Keep-Alive >> >> > Content-Type: text/html; charset=UTF-8 >> >> > Date: Sun, 22 Mar 2015 09:07:10 GMT >> >> > Keep-Alive: timeout=5, max=100 >> >> > Server: Apache/2.4.6 (CentOS) PHP/5.4.16 >> >> > Transfer-Encoding: chunked >> >> > Via: 1.1 test.site15.net >> >> > X-Debug-Token: 674072 >> >> > X-Powered-By: PHP/5.4.16 >> >> > >> >> > Voici la réponse html lors d'un plantage : >> >> > >> >> > Connection: Keep-Alive >> >> > Content-Length: 401 >> >> > Content-Type: text/html; charset=iso-8859-1 >> >> > Date: Sun, 22 Mar 2015 09:30:03 GMT >> >> > Keep-Alive: timeout=5, max=100 >> >> > Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips >> >> > >> >> > >> >> > Je me demande ce que viens faire "OpenSSL/1.0.1e-fips" alors que >> > je fais une >> >> > requête sur le port 80. >> >> > >> >> > Sur une analyse wireshark, on peut observer que le serveur envoi >> > des TCP RST >> >> > après la demande de GET du client alors qu'une connexion tcp est >> > bien établi >> >> > juste avant d'envoyer le GET HTTP. >> >> > >> >> > J'ai essayé de jouer avec le paramètre keepalive, sans succès ! >> >> > >> >> > Si quelqu'un à des pistes ? >> >> > >> >> > Merci, >> >> > >> >> > Christophe >> >> > >> >> >> >> >> >> Salut, >> >> >> >> Tu pourrais partager la trace réseau, même en PV? >> >> Ainsi que les logs Apache... >> >> J'ai déjà vu ce genre de comportement avec HAProxy, mais avec un >> >> client chrome, c'etait lié au "pre-connect" et à une mauvaise >> > gestion >> >> du buffer de reception côté client. >> >> >> >> Baptiste >> > >> > _______________________________________________ >> > Liste de diffusion du FRsAG >> > http://www.frsag.org/ >> >> >> ------------------------------ >> >> Message: 5 >> Date: Mon, 23 Mar 2015 01:22:32 +0100 >> From: Mrjk <mrjk...@gmail.com> >> To: j...@captainadmin.com >> Cc: French SysAdmin Group <frsag@frsag.org> >> Subject: Re: [FRsAG] Apache rafraichissement page >> Message-ID: >> <CAPhPNGNk2h=u9a0mcj7tvjpxtnno2dmc+8htn5qw6adsxul...@mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Bonsoir, >> >> Avec les informations que tu nous a indiquées, j'essayerai de répondre aux >> questions suivantes. >> >> Je pars du constat que: Le problème est reproduisible directement sur la >> machine (sans le HAProxy), cependant il peut toujours y avoir un problème >> de réseau. >> >> Test 1: >> ######### >> Essayer de reproduire le problème depuis le localhost de ton serveur (wget >> --headers="Host:mondomaine.com" 127.0.0.1/test.php) >> --> Si le problème se reproduit à l'identique depuis le localhost et >> depuis >> ton poaste local, le problème n'est pas au niveau du réseau, mais au >> niveau >> de la machine. >> --> Si le problème ne se reproduit pas, c'est probablement un problème de >> firewall ou de proxy (mais visiblement, ce n'est pas le cas) >> >> Test 2: >> ######### >> Essayer de voir si c'est Apache le problème, ou plutôt le module PHP >> (mod_php ou PHP-FPM). Essayer de servir un fichier html et un fichier PHP, >> pour voir si le problème se reproduit sur le HTML >> --> Si le problème existe sur les deux, le problème vient d'apache >> --> Si le problème vient seulement du code PHP, le problème vient de ... >> PHP ^^ >> >> Test 3: >> ######### >> Si c'est PHP, et en supposant que ce ne soit pas un problème de >> programmation, il faut essayer de reproduire le pb avec une page comme >> ci-dessous (à toi de le modifier pour qu'il corresponde à tes besoins). >> Après, il faut aller éplucher les logs pour voir ce qu'il se passe: >> >> Note: Faire attention si y'a du cache PHP, ça peut être interressant de le >> désactiver pendant les tests, en supposant que ce ne soit pas la source du >> problème. >> >> <?php >> >> // Disable cache >> header("Expires: on, 01 Jan 1970 00:00:00 GMT"); >> header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); >> header("Cache-Control: no-store, no-cache, must-revalidate"); >> header("Cache-Control: post-check=0, pre-check=0", false); >> header("Pragma: no-cache"); >> >> // Send a syslog message >> openlog('apache2', LOG_CONS | LOG_NDELAY | LOG_PID, LOG_USER | >> LOG_PERROR); >> syslog(LOG_NOTICE, 'Debug: Notice test message (1/3)'); >> syslog(LOG_INFO, 'Debug: Info test message (2/3)'); >> syslog(LOG_ERR, 'Debug: Error test message (3/3)'); >> closelog(); >> >> // Start full report >> echo "<h1>SERVER: DATE</h1>"; >> echo "<pre>"; >> print_r(date("Y/m/d h:i:sa")); >> echo "</pre>"; >> echo "<h1>HTTP: REQUEST HEADER</h1>"; >> echo "<pre>"; >> print_r(getallheaders()); >> echo "</pre>"; >> >> echo "<h1>HTTP: SERVER</h1>"; >> echo "<pre>"; >> print_r ($_SERVER); >> echo "</pre>"; >> >> echo "<h1>HTTP: POST DATA</h1>"; >> echo "<pre>"; >> print_r($_POST); >> echo "</pre>"; >> >> echo "<h1>PHP: PHPINFO</h1>"; >> phpinfo(); >> ?> >> >> Test 4: >> ######### >> - Penser au contexte: le problème arrive tout le temps? Quand y'a de la >> charge? Quand y'en a pas? Pendant des backups? Pendant un check de la >> supervision (omg) ? >> - Penser au cache PHP, si y'en a un ... >> - Penser à la conf de PHP et/ou Apache >> - Si tu as un pool de serveur derrière, penser à la concurrence: des >> modifications sur des fichiers lockées, des requetes mysql en attente, des >> accès concurrents, etc ... >> - Faire un strace sur le process qui sert le fichier (franchement pas >> facile avec le mod_php, mais ça se fait, l'idée est de sortir la machine >> de >> ton pool de prod, si tu en a un, pour faire tes tests) >> >> Test 5: >> ######### >> En dernier recours, essayer de voir si le problème se reproduit dans un >> environnement neuf, et essayer de faire le diff des confs. C'est long et >> pas élégant, mais c'est pour ça que c'est le test 5 et qu'il y'en a pas >> après ^^ >> >> >> Et si c'est pas dans tout ce que j'ai dit, je parie une bière que c'est un >> problème de code, ou sous-jacent :-D On sous-estime toujours les codeurs >> dans l'accomplissement de leur exploits techniques, huhu (</troll>) :D >> >> Bon courage, je serai curieux de savoir ce que c'était au final :-) >> -- >> MrJK >> GPG: https://jeznet.org/jez.asc >> >> Le 22 mars 2015 23:28, <j...@captainadmin.com> a écrit : >> >> > Bonsoir, >> > >> > Il faut vérifier si le flux arrive toujours sur le serveur final avec un >> > tcpdump par exemple. >> > En regardant les logs apache, a supposer que ton vhost soit correctement >> > configuré, tu devrais avoir des informations dans /var/log/httpd/*.log >> > qui >> > te permettront de trouver plus facilement l'erreur. >> > >> > Si tu rafraichis plusieurs fois, le problème persiste ou la page ne >> > s'affiche toujours pas? >> > Ton test.php pourrait-être un simple >> > <?php >> > >> > // Show all information, defaults to INFO_ALL >> > phpinfo(); >> > >> > ?> >> > >> > pour être sur que ce en soit pas php qui pose problème ? >> > >> > Bonne soirée >> > http://www.captainadmin.com >> > >> > >> > >> > >> > Le 22-03-2015 16:30, Christophe LE PORT a écrit : >> > >> >> Merci pour vos réponses, >> >> >> >> @Manu -> Le problème est identique que ce soit en direct ou en >> >> passant par le reverse >> >> >> >> @Baptiste et Olivier >> >> >> >> Il n'y aucune trace au niveau des logs httpd (passé en mode debug) >> >> sur le serveur apache >> >> >> >> Au niveau du proxy, il me retourne ces 2 lignes : >> >> >> >> [Sun Mar 22 16:09:41.754637 2015] [proxy_http:error] [pid 19583] >> >> (104)Connection reset by peer: [client 2.2.227.125:64566] AH01102: >> >> error reading status line from remote server 192.168.0.234:80 >> >> >> >> [Sun Mar 22 16:09:41.755049 2015] [proxy:error] [pid 19583] [client >> >> 2.2.227.124:64566] AH00898: Error reading from remote server returned >> >> by /test.php >> >> >> >> Date: Sun, 22 Mar 2015 12:00:00 +0100 >> >>> Subject: Re: [FRsAG] Apache rafraichissement page >> >>> From: bed...@gmail.com >> >>> To: c.lep...@hotmail.fr >> >>> CC: frsag@frsag.org >> >>> >> >>> 2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.lep...@hotmail.fr>: >> >>> > Bonjour, >> >>> > >> >>> > J'ai un soucis avec httpd 2.4.6 sur centos 7 >> >>> > >> >>> > Le serveur apache marche bien seulement quand j'ouvre une page sur >> >>> >> >> le port >> >> >> >>> > 80 et que je rafraichis la page au bout d' un certain temps >> >>> >> >> (environ >5mn) , >> >> >> >>> > ça plante (comme çi la page n'existait pas) >> >>> > >> >>> > Via notre reverse, il nous affiche l'erreur suivante : >> >>> > >> >>> > Proxy Error >> >>> > >> >>> > The proxy server received an invalid response from an upstream >> >>> >> >> server. >> >> >> >>> > The proxy server could not handle the request GET /test.php. >> >>> > >> >>> > Reason: Error reading from remote server >> >>> > >> >>> > >> >>> > Au niveau des entêtes html, voici le cas d'un fonctionnement >> >>> >> >> normal : >> >> >> >>> > >> >>> > Host: test.site15.net >> >>> > User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) >> >>> >> >> Gecko/20100101 >> >> >> >>> > Firefox/36.0 >> >>> > Accept: >> >>> >> >> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 >> >> >> >>> > Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3 >> >>> > Accept-Encoding: gzip, deflate >> >>> > Connection: keep-alive >> >>> > >> >>> > >> >>> > Cache-Control: no-cache >> >>> > Connection: Keep-Alive >> >>> > Content-Type: text/html; charset=UTF-8 >> >>> > Date: Sun, 22 Mar 2015 09:07:10 GMT >> >>> > Keep-Alive: timeout=5, max=100 >> >>> > Server: Apache/2.4.6 (CentOS) PHP/5.4.16 >> >>> > Transfer-Encoding: chunked >> >>> > Via: 1.1 test.site15.net >> >>> > X-Debug-Token: 674072 >> >>> > X-Powered-By: PHP/5.4.16 >> >>> > >> >>> > Voici la réponse html lors d'un plantage : >> >>> > >> >>> > Connection: Keep-Alive >> >>> > Content-Length: 401 >> >>> > Content-Type: text/html; charset=iso-8859-1 >> >>> > Date: Sun, 22 Mar 2015 09:30:03 GMT >> >>> > Keep-Alive: timeout=5, max=100 >> >>> > Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips >> >>> > >> >>> > >> >>> > Je me demande ce que viens faire "OpenSSL/1.0.1e-fips" alors que >> >>> >> >> je fais une >> >> >> >>> > requête sur le port 80. >> >>> > >> >>> > Sur une analyse wireshark, on peut observer que le serveur envoi >> >>> >> >> des TCP RST >> >> >> >>> > après la demande de GET du client alors qu'une connexion tcp est >> >>> >> >> bien établi >> >> >> >>> > juste avant d'envoyer le GET HTTP. >> >>> > >> >>> > J'ai essayé de jouer avec le paramètre keepalive, sans succès ! >> >>> > >> >>> > Si quelqu'un à des pistes ? >> >>> > >> >>> > Merci, >> >>> > >> >>> > Christophe >> >>> > >> >>> >> >>> >> >>> Salut, >> >>> >> >>> Tu pourrais partager la trace réseau, même en PV? >> >>> Ainsi que les logs Apache... >> >>> J'ai déjà vu ce genre de comportement avec HAProxy, mais avec un >> >>> client chrome, c'etait lié au "pre-connect" et à une mauvaise >> >>> >> >> gestion >> >> >> >>> du buffer de reception côté client. >> >>> >> >>> Baptiste >> >>> >> >> >> >> _______________________________________________ >> >> Liste de diffusion du FRsAG >> >> http://www.frsag.org/ >> >> >> > _______________________________________________ >> > Liste de diffusion du FRsAG >> > http://www.frsag.org/ >> > >> -------------- section suivante -------------- >> Une pièce jointe HTML a été nettoyée... >> URL: >> <http://www.frsag.org/pipermail/frsag/attachments/20150323/3a894fe7/attachment.html> >> >> ------------------------------ >> >> Subject: Pied de page des remises groupées >> >> _______________________________________________ >> FRsAG mailing list FRsAG@frsag.org >> http://www.frsag.org/mailman/listinfo/frsag >> >> ------------------------------ >> >> Fin de Lot FRsAG, Vol 183, Parution 1 >> ************************************* > > _______________________________________________ > Liste de diffusion du FRsAG > http://www.frsag.org/ > > > _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
