Re: [FRsAG] Lot FRsAG, Vol 183, Parution 1
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-request@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-request@frsag.org
Vous pouvez contacter l'administrateur de la liste à l'adresse frsag-owner@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 (jr@captainadmin.com) 5. Re: Apache rafraichissement page (Mrjk)
----------------------------------------------------------------------
Message: 1 Date: Sun, 22 Mar 2015 12:00:00 +0100 From: Baptiste <bedis9@gmail.com> To: Christophe LE PORT <c.leport@hotmail.fr> Cc: "frsag@frsag.org" <frsag@frsag.org> Subject: Re: [FRsAG] Apache rafraichissement page Message-ID: <CAODHi7q4m+ch0PDgT2Xbwb3v6wtnMOixoKkZw6W3ejznKGDNCQ@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1
2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.leport@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 <ml@sekil.fr> To: Christophe LE PORT <c.leport@hotmail.fr> Cc: "frsag@frsag.org" <frsag@frsag.org> Subject: Re: [FRsAG] Apache rafraichissement page Message-ID: <B0A99C40-F8B1-451E-A4C5-BDEDF505D5AC@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.leport@hotmail.fr> To: Baptiste <bedis9@gmail.com>, "webmaster@ajeux.com" <webmaster@ajeux.com> Cc: "frsag@frsag.org" <frsag@frsag.org> Subject: Re: [FRsAG] Apache rafraichissement page Message-ID: <DUB119-W40F81E84E5D8B5E9298CFFE70C0@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: bedis9@gmail.com To: c.leport@hotmail.fr CC: frsag@frsag.org
2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.leport@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: jr@captainadmin.com To: frsag@frsag.org Subject: Re: [FRsAG] Apache rafraichissement page Message-ID: <1453bd49c0ee26948f69ae321b684c30@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: bedis9@gmail.com To: c.leport@hotmail.fr CC: frsag@frsag.org
2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.leport@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.78@gmail.com> To: jr@captainadmin.com Cc: French SysAdmin Group <frsag@frsag.org> Subject: Re: [FRsAG] Apache rafraichissement page Message-ID: <CAPhPNGNk2h=U9a0mcj7tVJpXTNno2dMc+8HTN5Qw6aDSxULMOg@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, <jr@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: bedis9@gmail.com To: c.leport@hotmail.fr CC: frsag@frsag.org
2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.leport@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 *************************************
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.leport@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-request@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-request@frsag.org
Vous pouvez contacter l'administrateur de la liste à l'adresse frsag-owner@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 (jr@captainadmin.com) 5. Re: Apache rafraichissement page (Mrjk)
----------------------------------------------------------------------
Message: 1 Date: Sun, 22 Mar 2015 12:00:00 +0100 From: Baptiste <bedis9@gmail.com> To: Christophe LE PORT <c.leport@hotmail.fr> Cc: "frsag@frsag.org" <frsag@frsag.org> Subject: Re: [FRsAG] Apache rafraichissement page Message-ID: <CAODHi7q4m+ch0PDgT2Xbwb3v6wtnMOixoKkZw6W3ejznKGDNCQ@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1
2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.leport@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 <ml@sekil.fr> To: Christophe LE PORT <c.leport@hotmail.fr> Cc: "frsag@frsag.org" <frsag@frsag.org> Subject: Re: [FRsAG] Apache rafraichissement page Message-ID: <B0A99C40-F8B1-451E-A4C5-BDEDF505D5AC@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.leport@hotmail.fr> To: Baptiste <bedis9@gmail.com>, "webmaster@ajeux.com" <webmaster@ajeux.com> Cc: "frsag@frsag.org" <frsag@frsag.org> Subject: Re: [FRsAG] Apache rafraichissement page Message-ID: <DUB119-W40F81E84E5D8B5E9298CFFE70C0@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: bedis9@gmail.com To: c.leport@hotmail.fr CC: frsag@frsag.org
2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.leport@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/attachmen...
------------------------------
Message: 4 Date: Sun, 22 Mar 2015 23:28:41 +0100 From: jr@captainadmin.com To: frsag@frsag.org Subject: Re: [FRsAG] Apache rafraichissement page Message-ID: <1453bd49c0ee26948f69ae321b684c30@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: bedis9@gmail.com To: c.leport@hotmail.fr CC: frsag@frsag.org
2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.leport@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.78@gmail.com> To: jr@captainadmin.com Cc: French SysAdmin Group <frsag@frsag.org> Subject: Re: [FRsAG] Apache rafraichissement page Message-ID: <CAPhPNGNk2h=U9a0mcj7tVJpXTNno2dMc+8HTN5Qw6aDSxULMOg@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, <jr@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: bedis9@gmail.com To: c.leport@hotmail.fr CC: frsag@frsag.org
2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.leport@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/attachmen...
------------------------------
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/
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.78@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.leport@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-request@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-request@frsag.org
Vous pouvez contacter l'administrateur de la liste à l'adresse frsag-owner@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 (jr@captainadmin.com) 5. Re: Apache rafraichissement page (Mrjk)
----------------------------------------------------------------------
Message: 1 Date: Sun, 22 Mar 2015 12:00:00 +0100 From: Baptiste <bedis9@gmail.com> To: Christophe LE PORT <c.leport@hotmail.fr> Cc: "frsag@frsag.org" <frsag@frsag.org> Subject: Re: [FRsAG] Apache rafraichissement page Message-ID: <CAODHi7q4m+ch0PDgT2Xbwb3v6wtnMOixoKkZw6W3ejznKGDNCQ@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1
2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.leport@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 <ml@sekil.fr> To: Christophe LE PORT <c.leport@hotmail.fr> Cc: "frsag@frsag.org" <frsag@frsag.org> Subject: Re: [FRsAG] Apache rafraichissement page Message-ID: <B0A99C40-F8B1-451E-A4C5-BDEDF505D5AC@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.leport@hotmail.fr> To: Baptiste <bedis9@gmail.com>, "webmaster@ajeux.com" <webmaster@ajeux.com> Cc: "frsag@frsag.org" <frsag@frsag.org> Subject: Re: [FRsAG] Apache rafraichissement page Message-ID: <DUB119-W40F81E84E5D8B5E9298CFFE70C0@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: bedis9@gmail.com To: c.leport@hotmail.fr CC: frsag@frsag.org
2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.leport@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/attachmen...
------------------------------
Message: 4 Date: Sun, 22 Mar 2015 23:28:41 +0100 From: jr@captainadmin.com To: frsag@frsag.org Subject: Re: [FRsAG] Apache rafraichissement page Message-ID: <1453bd49c0ee26948f69ae321b684c30@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: bedis9@gmail.com To: c.leport@hotmail.fr CC: frsag@frsag.org
2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.leport@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.78@gmail.com> To: jr@captainadmin.com Cc: French SysAdmin Group <frsag@frsag.org> Subject: Re: [FRsAG] Apache rafraichissement page Message-ID: <CAPhPNGNk2h=U9a0mcj7tVJpXTNno2dMc+8HTN5Qw6aDSxULMOg@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, <jr@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: bedis9@gmail.com To: c.leport@hotmail.fr CC: frsag@frsag.org
2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.leport@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/attachmen...
------------------------------
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/
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.78@gmail.com Date: Fri, 27 Mar 2015 20:42:35 +0100 Subject: Re: [FRsAG] Lot FRsAG, Vol 183, Parution 1 To: c.leport@hotmail.fr CC: frsag@frsag.org Et alors, tu as trouvé la source du problème? Cordialement-- MrJKGPG: https://jeznet.org/jez.asc Le 23 mars 2015 13:58, Mrjk <mrjk.78@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 ... -- MrJKGPG: https://jeznet.org/jez.asc Le 23 mars 2015 10:58, Christophe LE PORT <c.leport@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-request@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-request@frsag.org
Vous pouvez contacter l'administrateur de la liste à l'adresse frsag-owner@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 (jr@captainadmin.com) 5. Re: Apache rafraichissement page (Mrjk)
----------------------------------------------------------------------
Message: 1 Date: Sun, 22 Mar 2015 12:00:00 +0100 From: Baptiste <bedis9@gmail.com> To: Christophe LE PORT <c.leport@hotmail.fr> Cc: "frsag@frsag.org" <frsag@frsag.org> Subject: Re: [FRsAG] Apache rafraichissement page Message-ID: <CAODHi7q4m+ch0PDgT2Xbwb3v6wtnMOixoKkZw6W3ejznKGDNCQ@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1
2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.leport@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 <ml@sekil.fr> To: Christophe LE PORT <c.leport@hotmail.fr> Cc: "frsag@frsag.org" <frsag@frsag.org> Subject: Re: [FRsAG] Apache rafraichissement page Message-ID: <B0A99C40-F8B1-451E-A4C5-BDEDF505D5AC@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.leport@hotmail.fr> To: Baptiste <bedis9@gmail.com>, "webmaster@ajeux.com" <webmaster@ajeux.com> Cc: "frsag@frsag.org" <frsag@frsag.org> Subject: Re: [FRsAG] Apache rafraichissement page Message-ID: <DUB119-W40F81E84E5D8B5E9298CFFE70C0@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: bedis9@gmail.com To: c.leport@hotmail.fr CC: frsag@frsag.org
2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.leport@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: jr@captainadmin.com To: frsag@frsag.org Subject: Re: [FRsAG] Apache rafraichissement page Message-ID: <1453bd49c0ee26948f69ae321b684c30@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: bedis9@gmail.com To: c.leport@hotmail.fr CC: frsag@frsag.org
2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.leport@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.78@gmail.com> To: jr@captainadmin.com Cc: French SysAdmin Group <frsag@frsag.org> Subject: Re: [FRsAG] Apache rafraichissement page Message-ID: <CAPhPNGNk2h=U9a0mcj7tVJpXTNno2dMc+8HTN5Qw6aDSxULMOg@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, <jr@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: bedis9@gmail.com To: c.leport@hotmail.fr CC: frsag@frsag.org
2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.leport@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/
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.leport@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.78@gmail.com Date: Fri, 27 Mar 2015 20:42:35 +0100 Subject: Re: [FRsAG] Lot FRsAG, Vol 183, Parution 1 To: c.leport@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.78@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.leport@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-request@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-request@frsag.org
Vous pouvez contacter l'administrateur de la liste à l'adresse frsag-owner@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 (jr@captainadmin.com) 5. Re: Apache rafraichissement page (Mrjk)
----------------------------------------------------------------------
Message: 1 Date: Sun, 22 Mar 2015 12:00:00 +0100 From: Baptiste <bedis9@gmail.com> To: Christophe LE PORT <c.leport@hotmail.fr> Cc: "frsag@frsag.org" <frsag@frsag.org> Subject: Re: [FRsAG] Apache rafraichissement page Message-ID: <CAODHi7q4m+ch0PDgT2Xbwb3v6wtnMOixoKkZw6W3ejznKGDNCQ@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1
2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.leport@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 <ml@sekil.fr> To: Christophe LE PORT <c.leport@hotmail.fr> Cc: "frsag@frsag.org" <frsag@frsag.org> Subject: Re: [FRsAG] Apache rafraichissement page Message-ID: <B0A99C40-F8B1-451E-A4C5-BDEDF505D5AC@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.leport@hotmail.fr> To: Baptiste <bedis9@gmail.com>, "webmaster@ajeux.com" <webmaster@ajeux.com> Cc: "frsag@frsag.org" <frsag@frsag.org> Subject: Re: [FRsAG] Apache rafraichissement page Message-ID: <DUB119-W40F81E84E5D8B5E9298CFFE70C0@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: bedis9@gmail.com To: c.leport@hotmail.fr CC: frsag@frsag.org
2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.leport@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: jr@captainadmin.com To: frsag@frsag.org Subject: Re: [FRsAG] Apache rafraichissement page Message-ID: <1453bd49c0ee26948f69ae321b684c30@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: bedis9@gmail.com To: c.leport@hotmail.fr CC: frsag@frsag.org
2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.leport@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.78@gmail.com> To: jr@captainadmin.com Cc: French SysAdmin Group <frsag@frsag.org> Subject: Re: [FRsAG] Apache rafraichissement page Message-ID: <CAPhPNGNk2h=U9a0mcj7tVJpXTNno2dMc+8HTN5Qw6aDSxULMOg@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, <jr@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: bedis9@gmail.com To: c.leport@hotmail.fr CC: frsag@frsag.org
2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.leport@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/
Hello,
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 général sur de l'ESX même à la main l'adresse MAC n'est pas dupliquée. Jamais eu le cas d'un MAC dupliquée. Après l'autre problème c'est le "nasty" udev et le fait que Linux adore mettre les adresses MAC dans les fichiers de conf. Donc tu te retrouves avec eth2... etc...
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.
Ce FW est-il en mode bridge ? (et accessoirement le TOP posting sur un digest c'est bien mais ca bouffe des octets sur les serveurs de mail des abonnés pour rien...) Xavier
Le 31/03/2015 09:31, Xavier Beaudouin a écrit :
Après l'autre problème c'est le "nasty" udev et le fait que Linux adore mettre les adresses MAC dans les fichiers de conf. Donc tu te retrouves avec eth2... etc... Pour que udev arrête de créer un nouveau ethX a chaque changement dans la conf matériel d'une VM, extrait de notre DocuWiki interne:
Il est possible de désactiver la mémorisation des interfaces réseaux. Pour cela, il faut surcharger localement le script udev qui mémorise les interfaces réseaux: créer un fichier avec le même nom dans la config locale de udev pointant vers /dev/null: sudo ln -s /dev/null/etc/udev/rules.d/75-persistent-net-generator.rules A noter que ça empêche de mémoriser, mais ça n'efface pas la mémoire déjà créé. Pour oublier, effacer le fichier//etc/udev/rules.d/70-persistent-net.rules/. Cette modification est compatible avec les mises à jour systèmes et ne sera pas supprimé par celles ci. /Source:http://askubuntu.com/questions/240632/how-to-disable-udev-net-rule-generatio..., puis des essais…;-) / Bonne journée Fabrice
participants (4)
-
Christophe LE PORT -
Fabrice Vincent -
Mrjk -
Xavier Beaudouin