FRsAG

frsag@frsag.org

15 participants
2603 discussions

Surcoût lié au passage de HTTP en HTTPS
by Artur 24 Apr '15

24 Apr '15

Salut, Quelqu'un aurait essayé/réussi de quantifier le surcoût (essentiellement en CPU, je suppose) d'un passage d'un site web en http à https ? En frais annexe, il y a bien sûr le ou les certificats, mais c'est surtout le surcoût en puissance de calcul qui m'intéresse, même à la louche. -- Cordialement, Artur.

5 5

Surveillance email de masse
by Remy Sanchez 21 Apr '15

21 Apr '15

Bonjour à tous, Sans rentrer dans le débat politique, je suis assez curieux de savoir quelles communications pourraient être interceptées si les infrastructures françaises étaient dotées de boites noires qui interceptent tout. En l'occurence, si on regarde https://www.google.com/transparencyreport/saferemail/?hl=en[1] on s'apperçoit rapidement qu'un très grand nombre des mails échangés le sont via TLS. Si on considère par exemple 2 mails échangés de Gmail à Gmail, on est sûr que de bout en bout le mail était chiffré sur "on the wire", étant donné que Google force le HTTPS/TLS partout. Est-ce qu'on peut donc considérer qu'il est bien impossible pour le gouvernement français de surveiller _massivement_ Gmail par exemple ? Merci pour vos lumières :) Rémy Sanchez -------- [1] https://www.google.com/transparencyreport/saferemail/?hl=en

7 6

MiTM Swisscom ?
by Florian Siegenthaler 16 Apr '15

16 Apr '15

Bonjour à toutes et à tous, Je ne sais pas si ce message a sa place ici, au cas où je suis preneur d'un endroit plus approprié. J'ai besoin de faire une investigation sur un faux certificat TLS, j'ai un serveur ownCloud qui a un certificat CAcert pour mon nom de domaine files.siegenthaler.mx et aujourd'hui j'ai reçu une alerte pour un faux certificat émanant de Swisscom (fournisseur d'accès national en Suisse). Aujourd'hui à deux reprises j'ai reçu ce faux certificat d'une validité de 30 ans, une fois sur l'application ownCloud (fichiers) et une fois sur Thunderbird (contacts), je souhaite savoir si c'est réellement une attaque MiTM de la part de mon fournisseur d'accès ou si c'est un faux-positif, par exemple le routeur qui fait une redirection HTTP 3XX quand il se broute et qu'il présente son propre certificat ? Le screenshot : https://files.siegenthaler.mx/public.php?service=files&t=dedf776f96b51657df… NB : l'accès est aussi disponible en clair mais les personnes utilisant le service sont clairement informées qu'elles doivent y accéder par HTTPS, cela va être modifié prochainement, tant pis pour les applications ne supportant pas SNI. Merci de vos conseils avisés. -- Florian Siegenthaler //

8 10

Baie en coloc et transit IP
by olc 15 Apr '15

15 Apr '15

Bonjour, Je suis en train de budgéter un projet, et à ce titre je cherche en région parisienne : - de la baie en coloc, ~ 4KVA (quantité : 1 ou 2, à voir) autre que DC2 car j'y ai déjà des équipements, mais avec possibilité d'une fibre (ou d'un lambda) avec DC2 - de transit IP (~1Gbps), avec une protection anti-DDoS qui fonctionne ... Si vous avez des pistes, je suis preneur. Je veux bien aussi des indications tarifaires, mais c'est sans doute mieux en privé. Merci ! :) -- Olivier

1 0

mail depuis/vers 1and1 : erreur 550
by Thomas Constans 03 Apr '15

03 Apr '15

Bonsoir, Je sèche sur le problème ci-dessous: Un client (qui utilise les smtp de 1and1 chez qui il a son domaine) m'informe que lorsqu'il m'envoie un mail, il obtient le message d'erreur suivant: "thomas(a)opendoor.fr": no valid MX hosts found Je viens de m'apercevoir que quand je tente un envoi, je reçois la même chose: host mx00.1and1.fr[212.227.15.41] said: 550-Requested action not taken: mailbox unavailable 550 invalid DNS MX or A/AAAA resource record (in reply to MAIL FROM command) Or, cela-marchait-"avant"(tm) J'ai vérifié la config dns du domaine client, rien ne me semble clocher (http://www.dnsinspect.com/polepik.com/1428012027#mail) Le seul truc qu'il me paraît notable de préciser c'est que je suis en mode auto-hébergé, et que depuis mon passage à la fibre chez free, je n'ai plus de reverse Une idée ?Hello, The specifications for your laptop as follow: brand: Lenovo Operating System: if possible Windows 7 professional, if not, windows 8 pro Keyboard Layout: qwerty OS language: english CPU: at least intel core i3 RAM: at least 4Go HardDrive: at least 250 Go For example, the LEnovo thinkpad S440 is a good balance between cost, hardware and form-factor (size/weight/battery life) Feel free to get back to me for more information, if needed -- Thomas Constans Services en informatique libre T: 33(0)6 23 37 87 85 @: http://opendoor.fr #: https://twitter.com/ThomasConstans gpg: 0xBA19745F80410541

9 16

Gestion des sites SSL à petite échelle
by Artur 01 Apr '15

01 Apr '15

Bonjour les gens, J'aurais à gérer un nombre un peu plus important de sites SSL qu'actuellement mais de façon assez modeste, disons quelques dizaines. Chaque site aura son propre certificat SSL. Il n'y a pas de gros volume, ni un trafic très important, mais je ne dispose pas non plus de serveurs ultra puissants. Ça sera certainement installé sur un serveur virtualisé. La question porte sur la mise en oeuvre de tout ça. Peut-on raisonnablement envisager une gestion des serveurs web virtuels dans une telle config ? Ou au contraire prévoir systématiquement une IP par serveur web ssl (ça fait riche !) ? Plutôt utiliser Apache2 avec des modules PHP ou au contraire un Nginx avec fpm ? Vos remarques, suggestions, retours d’expérience sont les bienvenues ! Merci par avance. -- Cordialement, Artur.

10 12

Re: [FRsAG] Lot FRsAG, Vol 184, Parution 2
by Christophe LE PORT 31 Mar '15

31 Mar '15

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 ? oui il est en mode bridge. Cela expliquerait-il active t-il une sorte de promiscious mode ?

3 2

Re: [FRsAG] Lot FRsAG, Vol 183, Parution 1
by Christophe LE PORT 31 Mar '15

31 Mar '15

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(a)frsag.org > Subject: Lot FRsAG, Vol 183, Parution 1 > To: frsag(a)frsag.org > Date: Mon, 23 Mar 2015 01:22:58 +0100 > > Envoyez vos messages pour la liste FRsAG à > frsag(a)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(a)frsag.org > > Vous pouvez contacter l'administrateur de la liste à l'adresse > frsag-owner(a)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(a)captainadmin.com) > 5. Re: Apache rafraichissement page (Mrjk) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 22 Mar 2015 12:00:00 +0100 > From: Baptiste <bedis9(a)gmail.com> > To: Christophe LE PORT <c.leport(a)hotmail.fr> > Cc: "frsag(a)frsag.org" <frsag(a)frsag.org> > Subject: Re: [FRsAG] Apache rafraichissement page > Message-ID: > <CAODHi7q4m+ch0PDgT2Xbwb3v6wtnMOixoKkZw6W3ejznKGDNCQ(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > 2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.leport(a)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(a)sekil.fr> > To: Christophe LE PORT <c.leport(a)hotmail.fr> > Cc: "frsag(a)frsag.org" <frsag(a)frsag.org> > Subject: Re: [FRsAG] Apache rafraichissement page > Message-ID: <B0A99C40-F8B1-451E-A4C5-BDEDF505D5AC(a)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(a)hotmail.fr> > To: Baptiste <bedis9(a)gmail.com>, "webmaster(a)ajeux.com" > <webmaster(a)ajeux.com> > Cc: "frsag(a)frsag.org" <frsag(a)frsag.org> > Subject: Re: [FRsAG] Apache rafraichissement page > Message-ID: <DUB119-W40F81E84E5D8B5E9298CFFE70C0(a)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(a)gmail.com > > To: c.leport(a)hotmail.fr > > CC: frsag(a)frsag.org > > > > 2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.leport(a)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/attachme…> > > ------------------------------ > > Message: 4 > Date: Sun, 22 Mar 2015 23:28:41 +0100 > From: jr(a)captainadmin.com > To: frsag(a)frsag.org > Subject: Re: [FRsAG] Apache rafraichissement page > Message-ID: <1453bd49c0ee26948f69ae321b684c30(a)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(a)gmail.com > >> To: c.leport(a)hotmail.fr > >> CC: frsag(a)frsag.org > >> > >> 2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.leport(a)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(a)gmail.com> > To: jr(a)captainadmin.com > Cc: French SysAdmin Group <frsag(a)frsag.org> > Subject: Re: [FRsAG] Apache rafraichissement page > Message-ID: > <CAPhPNGNk2h=U9a0mcj7tVJpXTNno2dMc+8HTN5Qw6aDSxULMOg(a)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(a)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(a)gmail.com > >>> To: c.leport(a)hotmail.fr > >>> CC: frsag(a)frsag.org > >>> > >>> 2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.leport(a)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/attachme…> > > ------------------------------ > > Subject: Pied de page des remises groupées > > _______________________________________________ > FRsAG mailing list FRsAG(a)frsag.org > http://www.frsag.org/mailman/listinfo/frsag > > ------------------------------ > > Fin de Lot FRsAG, Vol 183, Parution 1 > *************************************

4 6

connexion RDP impossible sur Windows 7 pro
by Edouard BAUDIER - FCNET 27 Mar '15

27 Mar '15

Bonjour la liste, Je suis devant un problème dont je ne trouve pas la solution, et pourtant comme ça cela semble simple... Je souhaite me connecter en RDP à un poste de travail en Windows 7 pro SP1 (à jour) depuis un autre poste de travail en Windows et cela ne fonctionne pas. J'ai vérifié tous les paramètres possibles : · Bureau à distance autorisé, ça c'est le minimum... · Firewall désactivé · Antivirus (Sophos) désactivé, on sait jamais... · Redémarrer le poste de travail · Redémarrer les services « bureau à distance » · Changer la carte réseau · Changer le port d'écoute de 3389 à 3390 · Aucun événement dans les journaux Windows. La commande « netstat -a -o » montre que le port 3389 n'est pas en écoute. Donc là j'ai plus d'idées, si vous avez déjà été confronté à ce cas de figure je suis pas contre un retour :) Merci d'avance pour vos réponses ! Edouard

9 11

LVM crashé bouteille a la mer
by Christophe 27 Mar '15

27 Mar '15

Bonjour, j'ai un LVM crashé, même après restauration du partitionnement LVM de la veille, toutes les partitions détectées sont inmontables faute de superblock. On est en train de remonter les backups qui datent de cette nuit sur le serveur clone donc ce n'est pas gravissime à long terme, mais vu la taille des backups c'est très très long, j'aimerais bien activer un peu les choses en relançant simplement mon LVM. Vu qu'aucune des quelques dizaines de partitions ne peut être montée je ne crois pas trop à la corruption individuelles des partitions, il doit y avoir un problème commun qu'il suffirait de régler pour pouvoir tout remonter tout de suite ? L'un d'entre vous serait ou connaîtrait un gourou LVM par hasard ? Merci pour votre aide, -- Christophe

6 10

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

FRsAG