Aujourd’hui je vous propose une « petite » technique pour suivre sa consommation de fioul quand on dispose d’une chaudière de ce type pour chauffer son habitation. En domotique, le suivi de consommation est quand même l’un des axes principal  sur lequel se tourne rapidement les gens qui s’y mettent. Autant suivre sa consommation d’eau ou d’électricité est relativement [...]

C’est la commande Shell du jour, dans le cadre d’une migration dns  Bind, j’ai besoin de mettre à jour le numéro de série de l’ensemble des zones présentes sur le serveur. Lorsque l’on fait une recherche sur internet sur le sujet, difficile de trouver moins qu’un script shell d’une dizaine de lignes. Or il est [...]

Ces derniers temps j’ai vu passer des cahiers des charges assez loufoque niveau dimensionnement de serveur. Pour un même CMS en PHP j’ai vu des infras basées sur des serveurs à base de 1/6e de CPUs et des clusters de 4 à 6 serveurs 16 coeurs, chacun pour une audience similaire (1 à 10 millions de pages vues/mois).

En général je fais quelques produits en croix sur un coin de nappe pour voir si au moins les ordres de grandeur sont corrects. Dans les deux cas les specs techniques étaient absurdes, mais quand on veut avoir du répondant il vaut mieux aussi fournir les bons chiffres. Du coup j’ai formalisé mes calculs qui relèvent pourtant de la tambouille dans une feuille de calcul presque rationnelle que je partage ici : lamp-sizing.ods.

Exemple très rapide : 1M PV/mois sur un site actif 20 jour/mois et 8h/jour, avec 0.5sec CPU par page et 1 requête AJAX/page en moyenne donne :

• 3,5 req/sec en moyenne; besoin en CPUs: 2
• 17 req/sec avec un ratio de sécurité de 5x; besoins en CPUs: 9

L’adminsys avisé retient l’ordre de grandeur et se dit qu’il devrait pouvoir démarrer avec 2 CPUs mais qu’il a intérêt à pouvoir monter jusqu’à 8 facilement. Si c’est une migration et que le trafic est déjà soutenu, alors on ne prend aucun risque et on prend 8 CPUs, voire plus.

Tous ces calculs supposent quelques hypothèses et approximations qui sont documentées dans la seconde feuille du document LibreOffice, je les reporte sur ce blog pour qu’ils soient plus facile à retrouver et consulter.

Edit : j’ai rajouté un paragraphe mentionnant que les caches nétaient pas pris en compte et ce qu’on pouvait attendre d’eux. Personne ne se passe de cache, et la feuille de calcul ne les prend pas en compte.

---

Cette feuille de calcul permet d’obtenir des ordres de grandeur pour le dimensionnement d’une plateforme LAMP. Les résultats sont grossiers et incomplets, il est en particulier quasiment impossible d’obtenir des résultats exploitables pour la partie SQL, la nature des requêtes étant bien plus importante que leur débit. Mais elle permet d’obtenir des ordres de grandeur réalistes. Il suffit d’appliquer le facteur multiplicteur de sécurité qui convient selon son expérience et ses exigences de performance.

Le modèle considère que seules les requêtes dynamiques interviennent dans le dimensionnement (celles servies par PHP, Ruby, Python, etc). Les fichiers statiques sont en général faciles à gérer en larges volumes et débits et peuvent être facilement traités par un CDN si nécessaire (S3, Akamai, etc).

Une page vue est constituée d’une requête HTTP dynamique pour fournir la page HTML ainsi que 0, 1 ou plusieurs requêtes AJAX associées.

Le coût de rendu d’une requête HTML ou AJAX est considéré identique et principalement imputé en temps CPU (celui nécessaire pour exécuter le code de l’application). Le dimensionnement SQL relevant d’avantage de problème d’I/O et de locking, il n’est pas abordé.

Coûts constatés :

• WordPress : 0,25 à 1 seconde CPU par page, 0 à 2 requêtes AJAX par page, 10 à 100 requêtes SQL par page
• Drupal : 0,1 à 0,8 seconde CPU par page, 0 à 1 requête AJAX par page, 5 à 100 requêtes SQL par page

Les chiffres sont évaluées sur une moyenne - un trafic moyenné sur une période “active”. Plus la période active est courte, plus le trafic moyen est élevé (à trafic en PV/mois constant). Sur un intranet, on peut par exemple compter les jours ouvrés (environ 20/mois) et les heures de bureau (environ 8h/jour). Un site public a en général une période active plus large.

Le dimensionnement complet d’un serveur frontal PHP peut se baser sur le modèle suivant :

• 1GB de RAM pour 1 CPU
• 2 processus PHP par CPU avec memory_limit = 256 MB

Ceci permettant dans le cas de charge maximale un ralentissement de 50% des temps de réponse et une utilisation de la moitié de la RAM disponible (le reste étant potentiellement utile pour les caches internes - kernel - ou externes - memcached, Redis, etc). Ne sont pas pris en compte les tâches de fond dont le contexte est différent (besoin de beaucoup plus de RAM et CPU, appels ponctuels) et peuvent être résolus à part.

Note : les mécanismes de cache ne sont pas pris en compte. Sur des sites où le contenu est facilement cachable (ceux orientés contenu où la majorité des internautes est “anonyme”), il est raisonnable de considérer que l’on peut gagner un ordre de grandeur en besoin CPU. En d’autre termes si la feuille de calcul vous recommande 20 CPUs en moyenne, avec un cache vous devriez retomber sur un besoin équivalent à 2 CPUs environ. C’est typiquement ce qu’on peut observer sur un magazine, un blog, etc.

Le worm Ramnit a déjà volé plus de 45 000 comptes Facebook en quelques jours, ciblant généralement les utilisateurs Français et Anglais.

Ce vers utilise le réseau social pour se connecter au compte Facebook de la victime, envoyant par la suite des messages aux contacts du compte infecté, leur proposant des liens malicieux.

Un bon nombre de personnes utilisent les mêmes mots de passes pour accéder à différents services Web (Facebook, Gmail, VPN, etc...), ce qui peut donner à ce worm un accès aux réseaux d'entreprises.

Avec l'apparition il y a quelques mois du worm Zeus s'attaquant aux comptes Facebook, et maintenant du worm Ramnit, il est évident que pour permettre à aux worms de s'étendre, certains groupes abandonnent l'envoi d'e-mails contenant des liens vers des fichiers infectés, par des worms utilisant les messageries des réseaux sociaux.

- Seculert en parle sur ce lien.

- Description du virus.

- Vérifiez l'état de votre PC avec Microsoft Safety Scanner.

Tout d’abord, je vous souhaite à tous une excellente année 2012 Qu’elle vous apporte plein de petits plaisirs et de grand bonheur qui font la joie de notre vie de tout les jours Je vous propose une petite bidouille rigolote dont je me suis servie dernièrement en l’absence d’accès web sur mon serveur [...]

Quand une seule ligne vous manque, tout est dépeuplé.

Bonjour.

Comme vous le savez, j'utilise NGINX sur mes machines. Et hier soir, j'ai voulu passer la dernière machine en NGINX, sauf qu'elle héberge notament un Shinken + Thruk.

Bon, le problème arrive avec Thruk.

Il utilise son propre serveur CGI, la conf avec Apache est assez triviale et tellement documentée, que j'me suis jamais posé la question sur cette partie de la conf.

Mais avec NGINX, c'est une autre paire de manches.

Mon thruk est installé dans /opt/thruk.

Voici le morceau de configuration NGINX que j'utilise, et qui fonctionne correctement :

location /thruk {
	auth_basic            "Monitoring Access";
	auth_basic_user_file  /opt/thruk/htpasswd.users;	
	fastcgi_index index.cgi;
	fastcgi_param REMOTE_USER $remote_user;
	fastcgi_pass	unix:/tmp/thruk_fastcgi.socket;
	include fastcgi_params;
}

Surtout NE PAS OUBLIER la ligne "fastcgi_param REMOTE_USER $remote_user;", qui envoie l'utilisateur logué à Thruk, qui donc le reconnait et vous autorise à accéder à l'interface.

Grand merci à ScriptFanix du canal IRC #shinken sur Freenode de m'avoir proposé cette solution, qui fonctionne :).

Merci.

Dans ma société nous avions une doc interne qui nous permettait d’installer des LAMP selon des procédures à peu près stables et reproductibles (dans le temps et d’un admin à l’autre). C’était aux temps immémoriaux de Debian Sarge.

Puis nous avons publié une doc, et en même temps commencé à automatiser ces setups, virtualisation oblige. Depuis Etch nous maintenons cette doc et elle intègre quelques détails basés sur moults retours d’expérience. J’ai récemment mis à jour la doc pour Debian Squeeze avec quelques idées glannées depuis, c’est en ligne sur http://forge.bearstech.com/trac/wiki/DebianLamp

C’est malheureusement qu’en anglais, ce qui est ironique pour FRsAG, mais je ne désespère pas de trouver le temps d’en faire une traduction.

J’y insiste sur quelques concepts autour de PHP et FastCGI que je trouve souvent mal compris ou abordés de façon assez irationnelle. Personnellement je n’utilise mod_php que dans des cas désespérés (récupération de tas de code tombé en marche il y a 10 ans).

J’y défend aussi Apache qui souffre de mythes tenaces selon lequel il est éléphantesque et ne gère pas un grand nombre de connexions… Ca n’est simplement pas la configuration dans laquelle il est livrée sur la plupart des distros (MPM prefork), et c’est facile de la changer.

La doc a été prévue pour des gens plutôt non adminsys (genre développeurs…) ou venant d’un autre monde que Debian ou GNU/Linux et ayant des réflexes leur poussant à réinventer beaucoup de roues.

Bonnes fêtes les adminz !

Tips & tricks en vrac pour le Kindle 3 d'Amazon :

• Utilisez le logiciel Calibre (avec son plugin Kindle Collections) pour convertir et transférer vos EBooks. Pour information, l'application officielle d'Amazon pour le Kindle est disponible ici.
• Vous pouvez mettre à jour le firmware de votre Kindle sans perdre vos ebooks ou les hacks installés (ex: écrans de veille).
• Vous pouvez changer le dictionnaire par défaut ("The New Oxford American Dictionary"par défaut sur le mien), par un dictionnaire français. Téléchargez le ici (format Mobipocket : 26,3 Mo), puis copiez le fichier .prc à la racine du dossier "documents" du Kindle. Utilisez deux fois la touche menu pour vous placer là où il faut pour choisir le dictionnaire Français.
• Si vous avez le navigateur intégré, utilisez http://m.gmail.com/ pour vérifier vos mails.
• Utilisez Evernote avec le navigateur expérimental via http://www.evernote.com/m
• Envoyez vos documents (rapports du travail, que ce soit en .doc, .pdf, ou autre...) à votre adresse@(free.)kindle.com (note : supporte les fichiers compressés en .zip) qui va convertir et ajouter ces documents à votre Kindle à condition de mettre le mot "convert" en sujet du mail.
• Vous pouvez utiliser MobiPocket pour créer vos eBook.
• Le Kindle permet d'écouter de la musique en ajoutant les .mp3 dans un dossier nommé "music", puis en utilisant le menu expérimental.

Énormément de liens et de sources sont disponibles pour le Kindle, comme ce wiki qui rassemble énormément d'informations sur : 

• Les raccourcis clavier.
• La fonctionnalité de visualisation d'images sur votre Kindle (ne rêvez pas : l'affichage se fera toujours en noir & blanc).
• Les hacks pour le Kindle, notamment de quoi gérer votre collection d'ebooks (pas le temps de toute tester, mais vos avis m'intéressent) et quelques conseils utiles.

100 "tips" de plus sont aussi disponibles ici.

Voici des liens pour vos écrans de veille (si vous avez adapté votre Kindle) :

• Kindle Wallpapers qui dispose d'une belle collection.
• KindleUnit qui propose des couvertures de livre plus "historiques" (gravures en bois).
• Kindle Screensaver qui propose de l'art classique et des BD.
• E-Reader Backgrounds propose de nombreuses catégories (Sous "Book Covers")
• Picky Wallpapers est une autre source organisée en catégories.

Vous pouvez aussi créer vos propre images en 600 x 800px, JPG ou PNG, niveaux de gris 8 bits. Placez tout ceci dans "linkss\\screensavers". Vous pouvez ajouter trois fichiers dans le dossier "linkss" : shuffle, random, et reboot. Ils permettent de créer un "shuffle" des différents écrans, un affichage au hasard, et enfin de redémarrer le Kindle quand sont port USB est débranché (nécessaire pour la mise à jour des écrans de veille).


Un bibliothèque de livre qui garde à être connue se trouve ici :
http://m.gutenberg.org/ et http://www.gutenberg.org/browse/languages/fr

Enfin, il est impossible de changer la langue du menu du Kindle (donc pas de chance, si votre Kindle est en Anglais, il restera en Anglais !).

EDIT : Pour les utilisateurs d'Instapaper, il est possible d'envoyer vos Instapaper sur votre Kindle, via USB ou Wifi si vous paramétrez votre compte. Il va sans dire qu'avec le petit bouton "Read Later" de mon navigateur, j'ai déjà ajouté sur le Kindle des dizaines d'articles ... qui donnent des astuces sur le Kindle.

EDIT 2 : Vous pouvez suivre vos flux RSS sur votre Kindle via usb avec Calibre, mais aussi via wifi avec kindlefeeder.com (qui "discute" avec InstaPapter). Pour cette dernière solution, vous pouvez adapter un système "maison" (installer Ruby, utiliser Blat...) si votre lecture de flux RSS est trop importante, comme expliqué ici.

EDIT 3 : un bloc-notes (notepad) pour le Kindle est disponible gratuitement ici (et par sécurité copié ici).
Un hack existe pour accéder à votre Kindle via SSH. Ce serait une piste pour synchroniser le Kindle avec Calibre via Wifi (Kindle USBNetwork & Rsync ?). A tester...

Si vous suivez ce blog et ses derniers billets (grand bien vous en fasse ), vous savez que je me consacre de plus en plus à la domotique (pour diverses raisons dont vous trouverez l’explication dans cet historique justement). En plus de cette passion pour la domotique, je me suis pris d’un grand intérêt [...]

La sécurité n’est pas qu’une affaire de méthodes et de certifications, c’est aussi un état d’esprit, une manière d’appréhender les choses… J’y reviendrai prochainement.