#20817

Note : panne site d’hier

Plop !

La panne du site d’hier est corrigée !

C’est un module MySQL qui a planté et à provoqué une charge anormale si le site (saturation mémoire + swap, entre autre).
Même si je ne n’utilise pas du tout MySQL (uniquement SQLite), s’agissant d’un serveur en mutualisé, MySQL a dû planter sur un des sites et ce sont tous les sites qui tombent en cascade ensuite.

Le truc c’est que chaque visiteur qui arrive sur le site arrive dans une sorte de file d’attente. Si l’attente est moins longue que le temps de traitement de sa requête (généralement quelques millisecondes), tout va bien : la file n’a pas le temps de se former.

Mais il suffit qu’une requête d’une personne prenne un peu de temps pour que les personnes qui arrivent ensuite attendent et forment une file (et y un visiteur toutes les quelques secondes ici). Or la gestion de cette file coûte également chère en ressources, d’autant plus que généralement quand ça répond pas, le navigateur ou l’internaute se met à bourriner sur la toucher "recharger", aggravant le problème.

Une façon de gérer serait de déprioriser les requêtes lourdes et de laisser passer les gens avec des requêtes rapides : comme ça seulement une personne attend, mais les autres passent normalement. Alors que si on traite les requêtes par heure d’arriver, t’en as un qui bloque et agace tout le monde et la queue n’en finit pas de grandir et subsiste même une fois le client chiant servi depuis longtemps (c’est généralement ce qui se passe à LaPoste ou au supermarché).

Ce genre de gestion est utilisé sur les gros sites, où les arrivants sont triés par un serveur de tri puis renvoyé sur un autre serveur approprié pour sa requête.
Du coup les gens avec les requêtes simples sont toujours servis rapidement, mais ceux avec des requêtes compliquées vont attendre (normal, si la requête est compliquée).

Mais sur des petits sites, ça ne se passe pas comme ça. Il faut donc faire gaffe à ses scripts.
L’an dernier j’avais le problème où une requête buguée ressortait tous les articles du site (1200+) en une page HTML. Un petit malin a dû s’en apercevoir car tous les jours des dizaines de requêtes sur cette URL étaient faites très rapidement et plantant le serveur à chaque fois. Depuis, j’ai débugué le script et j’ai bloqué des IP et il n’y a plus aucun soucis. J’ai aussi banni tout un tas de robots spammeurs de requêtes.

Le bug d’hier est un plantage plus ou moins aléatoire comme ça arrive tout le temps et partout.

Mon hébergeur a pu corriger le soucis hier soir très tard, merci à eux pour l’efficacité et la correction du soucis !

https://lehollandaisvolant.net/?mode=links&id=20220218084814

#18574

ΜΔDΞRΔS sur Twitter : "Quick fix to this entire Firefox browser extension debacle, especially on Tor Browser: enter about:config and set xpinstall.signatures.required to false.This will restore your current browser extensions; at worst you may have to reinstall them."

Si vous aussi vos extensions Firefox sont toutes désactivées, c’est « Normal » : Mozilla a merdé, et toutes les extensions sont maintenant marquées comme « obsolètes » parce que leur signature n’a pas pu être vérifiée.

Pour corriger ça (au moins temporairement) :

about:config, puis « xpinstall.signatures.required » à « false ».

https://twitter.com/hackermaderas/status/1124581107415040001

#16553

[WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading

Oops, un pète dans les CPU Skylake et KabyLake d’Intel.

Il faut désactiver l’hyper-threading dans le BIOS/UEFI. Le bug peut produire des erreurs aléatoires, pertes de données, instabilités…

C’est ici sur le forum de Debian, mais ils expliquent que le soucis (matériel) peut affecter tous les OS, aussi bien Linux sur Windows.

https://lists.debian.org/debian-devel/2017/06/msg00308.html

#15199

Comment j’ai réparé l’article sur la sécurisation SSH – Le blog de Seboss666

Débugage de malade.

La dernière fois que j’ai eu à faire un truc du genre c’était un plantage complet de Linux : freeze total, même les touches magiques ne fonctionnaient plus. Et aucun log disponible : le système freezait avant que le log puisse écrire.
C’était assez difficile à débuguer : il fallait faire varier un truc et attendre que ça plante, parfois des heures après : ajouter de la ram, désactiver le casque audio, arrêter le wifi, retirer la batterie…

Finalement c’était un problème d’architecture Intel, trop récente pour la version de Kernel en cours à l’époque : http://lehollandaisvolant.net/?d=2011/11/17/12/44/48-retour-sur-un-bug-coriace-avec-mon-pc-sous-linux


Dans tous les cas, partagez votre expérience ! Toujours toujours toujours !
Ça permettra à d’autres de ne pas perdre du temps et trouver une solution en tombant sur votre article (et de ne pas se sentir seul face à un bug, ce qui est déjà énorme).
https://blog.seboss666.info/2016/04/comment-jai-repare-larticle-sur-la-securisation-ssh/

#15182

Note : webfonts et proxy

Thuban, un utilisant de Blogotext m’a remonté un problème étrange : les webfonts que j’utilise ne fonctionnent pas chez lui.

Il a ce problème sur plusieurs sites, dans plusieurs navigateurs et impossible de savoir d’où ça venait.
En plus ça n’était pas systématique.

Il se trouve que c’était le proxy, qui avait du mal à mettre les fichiers au format "woff2" en cache.


Conclusion : encore une fois, les problèmes peuvent venir de n’importe où. Si c’est pas le navigateur, c’est le système, ou le serveur, ou le VPN, ou ici, un proxy.

N’oubliez pas, si vous utilisez des polices sur votre site, il peut être nécessaire d’ajouter ceci à votre .htaccess, pour la mise en cache des formats Woff2 et Woff de polices d’écritures (qui sont des formats assez récents et non implémentés nativement comme peuvent l’être JPG ou JS) :

<IfModule mod_expires.c>
  AddType application/x-font-woff .woff
  AddType application/x-font-woff2 .woff2
  ExpiresActive On
  ExpiresByType application/x-font-woff "access plus 1 year"
  ExpiresByType application/x-font-woff2 "access plus 1 year"
</IfModule>
http://lehollandaisvolant.net/?mode=links&id=20160426165002

#14797

Note : astuce sécurité PHP

MÀJ : voir les deux ÉDIT plus bas

Utilisez ça en haut de votre script PHP :

if ($_SERVER['PHP_SELF'] !== $_SERVER['SCRIPT_NAME']) {
	header('Location: '.$_SERVER['SCRIPT_NAME']);
}


Quand je vais sur la page "/index.php" ou sur la page "/" d’un répertoire, le contenu du fichier "index.php" est exécuté en PHP. Ceci est normal.
Par contre, quand je vais sur l’URL "/index.php/" (même chose, mais avec un slash à la fin) ou "/index.php/code_ici", alors Apache considère qu’on va dans un sous-répertoire (à cause du slash). Or, l’ouverture d’un répertoire constitue l’exécution de ce dernier (sous Unix/Linux). Du coup, le contenu de "index.php" est exécuté quand même, alors que pour n’importe quel autre fichier, ça aurait fait une erreur 404.

Le code PHP fonctionnera bien, mais tous les liens relatifs seront cassés, car apache considère qu’on a franchi un nouveau niveau de profondeur dans l’arborescence des fichiers.
Pire, quand on utilise le $_SERVER['PHP_SELF'] , ça contiendra le "/" et tout ce qui suit. Utilise le PHP_SELF est donc compromettant et peut devenir une faille XSS :
/index.php/%22onmouseover=prompt(971741)%3E



Ce que fait mon code : il compare le chemin du fichier actuellement exécuté (index.php) avec le chemin du fichier (index.php/). Si les deux sont différents, il y a un problème, et on renvoie sur (index.php).


ÉDIT :
Je viens de voir que certains serveurs, selon la config, retiraient directement tout ce qui suivait le "index.php". Mon code ci-dessus ne marche donc plus.
Du coup j’ai pondu ceci, qui a l’air de faire son job :

if (basename($_SERVER['SCRIPT_NAME']) === 'index.php' and strpos(parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH), 'index.php') === FALSE ) {
	$var_request_URI = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH).'index.php';
} else {
	$var_request_URI = $_SERVER['REQUEST_URI'];
}
if (parse_url($var_request_URI, PHP_URL_PATH) !== $_SERVER['SCRIPT_NAME']) {
	header('Location: '.$_SERVER['SCRIPT_NAME']);
}


Vous pouvez essayer sur mon site :
http://lehollandaisvolant.net/
http://lehollandaisvolant.net/index.php
http://lehollandaisvolant.net/index.php?parametre
http://lehollandaisvolant.net/index.php/
http://lehollandaisvolant.net/index.php/?param
http://lehollandaisvolant.net/index.php/codeIci
http://lehollandaisvolant.net/index.php/codeIci/?param

J’ai vu que le problème était présent sur Shaarli aussi : allez sur votre shaarli, allez sur la page "index.php" (qui n’est habituellement pas affichée, mais qui existe quand même) et ajoutez un "/" à la fin de l’URL.

RÉ-ÉDIT : voir là : http://lehollandaisvolant.net/?mode=links&id=20160330174432
http://lehollandaisvolant.net/?mode=links&id=20160319122329

#14528

Pourquoi un faux easter egg vintage peut transformer votre iPhone en brique - Tech - Numerama

Ah oui : chez Apple, les nombres négatifs n’existe plus, c’est marqué dans les CGU.
Tim Cook veut que vous restiez positif, donc positif vous serez.
D’ailleurs, les électrons sont également interdits : leur réseau fonctionne exclusivement avec des positrons.



« Entre temps, évitez de vous connecter à un réseau public ou inconnu. Un petit malin pourrait avoir réglé la date émise par le serveur NTP (Network Time Protocol) sur le premier janvier 1970 et votre iPhone, bêta, pourrait alors se mettre automatiquement à cette heure […] »

Héhéhé.
http://www.numerama.com/tech/145906-pourquoi-un-easter-egg-vintage-peut-transformer-votre-iphone-en-brique.html

#14380

Note

Juste pour signaler que c’est "normal" que les liens récents de mon fil RSS sont publiés en double dans vos flux.
Une mise à jour du code a provoqué ça, ça n’est que temporaire.
http://lehollandaisvolant.net/?mode=links&id=20160128225738

#14367

Comment #12 : Bug #918019 : Bugs : firefox package : Ubuntu - Liens d'un Parigot-Manchot

Ah c’est donc ça…

Firefox veut toujours ouvrir tous les fichiers téléchargés avec Gedit (ou Pluma sous Mint). C’est assez chiant, quand il s’agit d’un Zip ou autre. Du coup on est obligé d’enregistrer le fichier (sur la bureau par exemple) et de double-cliquer dessus une fois que c’est fini.

(ÉDIT : murphystiquement, là je veux tester, je n’ai aucun problème…)
http://gilles.wittezaele.fr/liens/?_EZr1g

#13785

[question][css][chrome] - Couleur-Science

Sur le site Couleur-Science, y a t-il des personnes qui ont des soucis d’affichages de la police d’écriture sous Chrome/Opera (webkit/blink) ?

Est-ce que la police apparaît super fine (trop fine) comme ici : http://lehollandaisvolant.net/img/17/couleurscience_chromiumFontBug.png (ça s’affiche bien sous Presto (opera 12) et Gecko (Firefox) mais la police est manifestement trop fine sous Chromium).
http://couleur-science.eu/

#13245

Note : petit dommage collatéral avec les bloqueurs de pub

Dans Blogotext, pour éviter que les fichiers uploadés ne soient tous dans le même dossier (trop de fichiers dans un seul dossier a des répercutions sur les perfs du disque dur), j’utilise des dossiers au nom aléatoire.

J’ai ainsi le dossier "fichiers" et des sous dossiers dont le nom va de "00" à "ff" puis les fichiers à l’intérieur (rangés aléatoirement). Ainsi, avant qu’un dossier contienne 1000 fichiers (ce qui commence à être beaucoup), je dois en uploader 250 000 : j’ai donc de la marge.

Le truc, c’est que dans les noms de dossiers possibles il y a "ad", et les bloqueurs de publicité détectent ça comme de la publicité ("ad" = pub, en anglais) et bloquent les fichiers qui sont dans ce dossier.

Du coup je fais quoi ? Je dis de ne pas faire de dossier "ad" ? Dans ce cas, je devrais aussi bloquer le dossier "69" (risque de bloquage par les filtres parentaux), "66" (pour les satanistes), "75" (pour les parisiens), etc.
http://lehollandaisvolant.net/?mode=links&id=20150912133847

#12989

[CSS] You Know About Display Inline Block Gap

Ceci est un comportement très chiant. Seul Opera 12.x ne l’avait pas (en même temps, ce navigateur appliquait les spec mieux que les spec elle-mêmes…).

L’espacement est dû aux espaces dans le code source : espaces, tabulations, retour à la ligne.

Si on écrit tout le code HTML sur une seule ligne, ça sera moche mais le problème disparaît. Le code DOM généré en JS n’a pas ce soucis non plus.

Une autre solution est d’utiliser un « line-height:0; » dans le parent (le ul)et de remettre un line-height/font-size dans le block (les li).

http://www.frontendevelopers.com/you-know-about-display-inline-block-gap/

#12818

Issue 131325 - chromium - dragleave event fires upon entering child element of listener - An open-source project to help move the web forward. - Google Project Hosting

Ok, donc Chrome bug avec les drag'n'drop.

Quand je fais body.ondragover, ça démarre la fonction lors du drag. Sauf que moi, je veux étendre un DIV sur toute la page (position absolute) pour recueillir les fichiers. Dès que la souris passe sur ce DIV (directement, donc, vu que son affichage est déclenché par le body.ondragover), le body.ondragover s’arrête : en effet, la souris est passé sur un autre élément que body.

Chrome a ce problème depuis 3 ans et rien ne semble être fait.

Une solution c’est d’ajouter sur le "dragleave" un if (event.pageX != 0 || event.pageY != 0) { return false;}.

Comme ça, vos fonctions à exécuter quand on sort la souris du body ne sont pas exécutés quand c’est le passage de la souris sur un élément enfant.
https://code.google.com/p/chromium/issues/detail?id=131325

#12792

Note : Firefox bug - Le Hollandais Volant

Bref retour : j’ai désactivé manuellement tous les modules dans Firefox, j’ai relancé le navigateur : le code source était de nouveau normal.

J’ai ensuite relancé les modules complémentaires et le problème reste résolu.

Je ne sais pas d’où ça vient, mais en tout cas c’est résolu…


ÉDIT : en fait non.
Pour le reproduire (dans mon cas) :
- affichez une page derrière un login qui redirige sur une page de login si vous n’êtes pas connecté
‑ affichez la source (parfois ça marche, parfois non)
- rechargez la page (l’onglet, pas la source)
‑ affichez la source : là ça ne marche pas.

Visiblement, c’est lié à un bug vieux de 10 ans dans Firefox : https://ffdevtools.uservoice.com/forums/246087-firefox-developer-tools-ideas/suggestions/5899118-fix-bug-307089-debugger-and-view-source-re-re

https://bugzilla.mozilla.org/show_bug.cgi?id=307089

Déjà, la page est rechargée quand on affiche la source, ce qui est MAL car on veut le code source de la page courante, ensuite, elle est parfois rechargée sans les cookies, ce qui est très MAL.


Ré-ÉDIT : en fait si ><.

Je suis allé dans about:config, j’ai cherché « extensions. » et j’ai réinitialisé toutes les clés des VIEUX modules. Faut savoir que Firefox conserver toutes les clés des modules, mêmes quand vous les désinstallez.
Dans mon cas, il restait des clés de modules que j’utilisais dans Firefox 3.5. Ça remonte un petit non ?

Il suffit de clic droit sur une clé, puis « réinitialiser ». Quand vous savez fait toues les clés, relacnez Firefox et les clés ont disparues.

Dans mon cas toujours, j’ai viré les clés de ABP, AB-Edge, Disconnect (j’ai des remplaçants pour eux), ainsi que Lazarus (idem), Firebug, HTML-Tidy et quelques autres.

Je n’ai pas (encore :'( ?) été en mesure de reproduire le bug maintenant.


Ré-ÉDIT : en fait non, mais si en fait :D

Je crois que j’ai trouvé : ça me bug seulement quand j’ai l’outil de développeur d’ouvert.
Il faut aller dans les paramètres de cet outil (icône de config, à droite), scroller un peu, aller dans la section « paramètres » et décocher la case « désactiver le cache lorsque la boîte à outil est ouverte ».

Je pense que c’est ça.
http://lehollandaisvolant.net/?id=20150716114144