Suite aux failles récentes "Heartbleed" et "Shellshock", largement médiatisées, une nouvelle vulnérabilité, "Poodle", a été dévoilée cette nuit par Google.
Si elle ne peut être exploitée à grande échelle, elle est jugée critique, elle concerne tous les systèmes d'exploitation, et peut être mise en œuvre dans le cas d'une attaque ciblée.
Décryptage d'une faille d'encryption ...
Niveau : intermédiaire
J'ai présenté dans un précédent article le service Memcached, qui est un outil extraordinaire pour accélérer les accès aux sites web (et aux applications tout court, puisque des librairies sont disponibles pour les langages "non web" les plus courants).
Ensuite, j'ai expliqué comment intégrer l'utilisation de Memcached à Joomla, un CMS moderne, et plus sécurisé que Wordpress.
Pour résumer Memcached, pour ceux qui ne le connaitraient pas, c'est un service qui stocke les données (clé-valeur) en mémoire vive, ce qui en fait un moyen extrêmement performant pour le cache applicatif et les valeurs temporaires (le stockage permanent doit toujours passer par un SGBD, en parallèle).
Maintenant que nous avons les bases pour l'installer et pour l'interfacer avec un framework, nous allons nous intéresser au benchmarking du service, via l'outil "Memcslap", ce qui nous donnera les connaissances pour bâtir une architecture cohérente.
Niveau : intermédiaire
Nagios n'a pas de moniteur pour mesurer les IOPS, par défaut, comme la plupart des logiciels de monitoring d'ailleurs.
Nous allons donc modifier le moniteur "Check DiskIO via SNMP" écrit par Herbert Stadler, qui correspond à peu près à nos besoins.
Niveau : débutant
Lors d'un précédent post, j'avais émis l'idée que les sites populaires étaient rapides, et que de mauvais temps de réponse (la latence) nuisaient à la fréquentation des sites web, puisqu'ils faisaient partie du "perçu" du visiteur.
Toutefois, j'en étais resté au stade de l'hypothèse, de l'opinion personnelle, étayée par un court article.
J'ai eu de bons retours, mais aussi certains doutes exprimés : en effet, optimiser coûte, si ce n'est en matériel, au minimum en temps développeur / administrateur, alors que ceux-ci pourraient être affectés à des tâches plus "productives".
Est-ce pertinent pour le management de mobiliser des ressources, d’alourdir les process, le tout pour des gains incertains ?
Surtout lorsque les budgets sont serrés, puisque tout le monde n'a pas les moyens humains et matériels de Google, de Facebook ou d'Amazon ...
Est-ce que la recherche des meilleurs temps de réponse a des bénéfices concrets et chiffrables pour l'entreprise, ou est-ce juste la marotte de quelques geeks idéalistes et bien trop pointilleux ?
"Speed [is] an undervalued and under-discussed asset on the web" - James Hamilton
Une maxime banale, mais d'une sagesse infinie, surtout lorsqu'elle s'applique à une migration ou une mise en production ;-)
Plan for success and you will have failure.
Plan for failure and you will have success.
Milosz SZOT est ingénieur systèmes & réseaux spécialisé dans Linux et l'hébergement de sites web à fort trafic.