Crédit photo : akakumo (flickr)

Il parait que le cloud est plébiscité pour ses fonctionnalités de stockage et de sauvegarde. Bon, moi, je suis toujours pas confort avec cette notion de cloud et de « je sais pas trop où sont mes données mais je sais comment y accéder ».

Ça ne m’empêche pas de l’utiliser, dropbox en tête, pour balader des documents entre mes stations de travail et mes divers appareils mobiles, c’est bien pratique. Ce sont à peu près les seuls à avoir fait un truc bien intégré à Windows en matière de dossier partagé.

Si un jour ces messieurs se décidaient à vendre leur solution soft coté client & serveur pour que les gens puissent l’installer sur leurs propres infrastructures, ce serait fort appréciable.

Reste que, même protégées par un mot de passe, voilà que mes données se baladent je ne sais pas où. Du coup, je fais très attention à ne pas stocker n’importe quoi sur cet espace. Des présentations powerpoint, des PDF que je dois lire, quelques photos, mais c’est à peu près tout.

Pour le reste, des listings de mots de passe, par exemple, j’aime assez avoir une surcouche de sécurité convenable. Deux principes pour stocker convenablement ce genre de données dans les nuages :

• Utiliser une application qui gère ce type d’information et pratique un chiffrage fort avant d’écrire le fichier, par exemple KeePass qui permet de chiffrer un trousseau de mots de passe avec une passphrase ou un fichier complet servant de clé, ou les deux (on peut ensuite se permettre d’aller écrire tout ça sur dropbox dans la foulée)
• Utiliser une application de chiffrement qui donne, ensuite, accès normalement aux fichiers déchiffrés, par exemple truecrypt qui va créer un fichier chiffré dans l’espace dropbox dans lequel on pourra mettre ce qu’on veut

Le problème, avec la seconde solution, c’est qu’on ne doit pas oublier, en quittant un poste de travail, de démonter son lecteur truecrypt pour pouvoir le ré-ouvrir de l’autre côté sans faire de collision. C’est aussi partiellement vrai avec la première solution, mais le logiciel employé pose généralement un verrou sur le fichier utilisé sur dropbox de sorte qu’une autre instance ne puisse être lancée en même temps.

Une petite mention pour une application iphone gratuite trouvée dernièrement, PlainText, qui fonctionne comme l’application de prise de note fournie par Apple mais qui a le bon goût de synchroniser les notes, en quasi temps réel, avec dropbox. Pour ceux qui, comme moi, aiment bien jeter des idées dans l’iphone à longueur de temps et les récupérer rapidement sur un poste de travail après, c’est un must. Un seul bémol, l’appli ne gère QUE l’encodage UTF8 et refusera d’ouvrir un fichier contenant autre chose. Dommage.

Tout ça, c’est bien gentil, mais ça ne sauve pas les données de tous les jours que vous avez sur l’ordinateur et c’est un peu compliqué à mettre en oeuvre en version « tout automatisé » pour faire des sauvegardes sécurisées.

Pour ma part, je préfère largement l’option petit serveur dédié. Les premiers prix du moment chez les lowcosters tournent autour de 20 euro par mois, avec 160Go d’espace disque, si vous n’êtes pas un vilain pirate pédonazi, vous devriez pouvoir stocker l’ensemble de vos documents importants sur le bébé.

Alors bien entendu, vous prendrez grand soin de chiffrer les données pendant la transmission, soit au moyen d’un VPN (c’est ce que je fais), soit en copiant vos fichiers avec ssh ou un autre mode de transmission un minimum sécurisé.

Mais une fois sur le petit serveur de l’autre côté, qui vous dit que personne n’ira fouiller dedans ? Lorsque vous allez résilier cette machine qui vous dit que le prochain utilisateur ne tombera pas fortuitement sur vos données ?

Pour éviter ça, le chiffrage est encore de mise. TrueCrypt reste manifestement la référence en la matière sous Linux, mais moi, Linux, ça me donne des boutons. Avec notre ami FreeBSD, on a un outil formidable portant le doux nom de Geli qui permet de chiffrer des partitions entières.

Le principe est simple :

• Lors de l’installation de la machine, vous mettez tout votre système dans un petit espace disque (5Go, par exemple)
• Si votre disque dur n’est pas neuf, il convient de remplir tout le restant avec de la donnée aléatoire (‘dd if=/dev/random of=/dev/ad0s1e bs=1m’ par exemple)
• Il faut ensuite créer une clé qui servira, en plus de la passphrase, pour le chiffrement : ‘dd if=/dev/random of=/root/geli.key bs=64 count=1′
• On peut ensuite initialiser la partition à chiffrer : ‘geli init -l 256 -s 4096 -K /root/geli.key /dev/ad0s1e’. C’est à ce moment que vous spécifiez la passphrase qui doit être conséquente
• Puis attacher cette partition : ‘geli attach -k /root/geli.key /dev/ad0s1e’
• Pour parfaire le tout, créez le filesystem dans la partition chiffrée : ‘newfs /dev/ad0s1e.eli’
• Il ne reste plus qu’à la monter (presque) normalement : ‘mount /dev/ad0s1e.eli /home’

Notez qu’il faudra refaire les points 5 à 7 à chaque reboot pour récupérer votre partition active. Vous pouvez l’automatiser mais ça implique, pour un serveur distant, d’avoir la main sur la console au moment du boot pour taper la passphrase, ce qui est généralement impossible et peu souhaitable pour des raisons de discrétion (vous ne voudriez pas qu’on sache que vous avez des données chiffrées dans cet espace apparemment vide, hein ? Bon, on le saura quand même, on vous a à l’oeil !).

Voilà, un petit tour d’horizon de mon usage de ce que nos amis marketteux surnomment « le cloud »

Crédit photo : Shimown

C’est le nouveau dada de la presse spécialisée en ce moment, le futur-probable-marché-noir-des-IPv4.

Remise dans le contexte pour ceux qui ne suivent pas l’actualité de près ou qui n’ont pas lu mes précédents articles sur le sujet :

Il y a moins de 4 milliards d’adresse IP version 4 qui sont utilisables en tout. Ce gros bloc est géré par un organisme mondial (IANA) qui les distribue par paquet de 16 millions à des registres régionaux (RIR, il y en a 5 dans le monde) qui eux-mêmes vont les découper en blocs de différentes tailles (le plus petit théoriquement existant sur Internet et ayant de bonnes chances de fonctionner comme il faut étant un bloc de 256 adresses) à des registres locaux (il y en a un gros paquet). Enfin, ce registre local va découper ses blocs d’adresse en petits bouts pour les distribuer aux clients.

Par exemple, un fournisseur d’accès ADSL va donner une IP à chaque client. Un hébergeur qui propose un réseau redondant bien fait occupera probablement un minimum de 8 adresses pour un client même s’il n’a qu’une seule machine.

On a donc ici une chaîne de distribution avec un minimum de 4 intermédiaires qui a son propre stock d’adresse au frais. On sait très bien combien d’adresses il reste à l’IANA, on sait beaucoup moins combien il en reste chez chaque RIR, encore moins chez les LIR, et pour ce qui concerne l’usage fait par les clients finaux, c’est carrément mission impossible.

Une chose est certaine, la source est quasiment tarie, donc on va avoir un problème. Qui dit raréfaction dit généralement marché noir. Oui, sauf que :

• On ne peut pas revendre ou même donner une IP toute seule et, dans une moindre mesure, un bout de bloc d’IP comme on revend un bouquin. Chaque bloc est associé à une entité théoriquement utilisatrice.
• Bien entendu, on peut toujours ne pas changer l’attribution théorique mais qu’en pratique ce soit quelqu’un d’autre qui utilise le bloc, mais ce sera le bloc entier et non seulement cette personne n’aura aucun droit si le titulaire original réclame la récupération de son bloc, et en plus, c’est ce titulaire original qui sera inquiété en cas d’usage déplacé des IP par leur utilisateur final (si ce sont de vilains pédonazis qui s’en servent, par exemple).
• Dans le cas (majoritaire) des blocs d’IP subdivisés par les LIR pour leurs clients ou leurs usages propres, le LIR peut changer l’attribution d’un bloc vers un nouveau client mais celui-ci ne pourra que difficilement s’en servir proprement s’il ne maintient pas de connexion physique avec le réseau du LIR d’origine qui annonce le bloc entier.
• Cet usage, appelé désagrégation, encombre d’autant la table de routage mondiale que chaque routeur BGP doit prendre en charge, c’est donc in fine une mauvaise idée.

Il y aura donc probablement un marché, mais loin d’être opaque puisque tout se sait sur le réseau, et loin d’être similaire à de la vente de drogue sous le manteau puisqu’il ne s’agit pas simplement de s’échanger des IP mais que ça a aussi un impact sur la constitution du réseau lui-même.

On risque par contre de rencontrer de plus en plus d’offres du type « une IP fournie, les autres faut payer en plus » alors que l’habitude actuelle,  sauf arnaqueurs qui font croire à leur clients que les adresses IP coûtent de l’argent, est plutôt à « autant d’IP que nécessaire fournies sur justification ».

En bref, contrairement à la culture, nous passons ici d’un marché d’abondance à un marché de rareté. Les prochaines années vont être intéressantes.

Je profite d’être en plein dans le sujet pour vous rappeler que le 8 juin prochain, ce sera le World IPv6 day, suivi par les géants du secteur. L’idée est que tous les frileux se réunissent en disant « ce jour la, on met de l’IPv6 sur nos services ». Je n’arrive toujours pas bien à saisir pourquoi c’est seulement une journée (ce blog est IPv6 tout le temps, par exemple), mais passons, l’idée est rigolotte.

Il s’agit donc de créer un grand réseau anycast en se basant sur un tas de petites machines éparpillées un peu partout. Objectifs de la chose :

• Renforcer la stabilité du DNS en général en proposant un (ou plusieurs) serveurs joignables au plus court d’un peu partout sur la planète. Par exemple pour les DNS faisant autorité pour des domaines comme wikileaks.org (mais ce n’est qu’un exemple)
• Préparer le terrain pour d’éventuelles initiatives en lien avec la liberté d’expression sur le réseau et qui pourraient avoir besoin de technologies anycast

Créé sur la base du volontariat de généreux pourvoyeurs de matériel, d’espace d’hébergement et d’interconnexion, le projet serait porté par des entités associatives qui seraient créées un peu partout dans le monde, en fonction des opportunités et surtout des bonnes volontés locales.

Système décisionnel acentré, 1 membre = 1 voix, en bref, comme internet.

Première étape, tester le concept en France. Pour démarrer, il faudrait au moins 4 ou 5 volontaires. Prérequis techniques :

• Disposer d’une machine (éventuellement virtuelle pour commencer) avec deux pattes réseau
• Avoir de quoi l’héberger en datacenter
• Etre en mesure de raccorder cette machine à un routeur BGP qui annoncera une route par défaut et acceptera une route annoncée par la machine ou, mieux, avoir la possibilité de raccorder directement cette machine à un point d’échange (ou les deux).

Les coûts sont à partager entre les intéressés, les bénéfices de l’ensemble du réseau anycast également, du coup.

Une fois que les quelques volontaires de démarrage se seront fait connaitre, il faudra :

• créer une association loi 1901
• aller mendier un AS et un /24 auprès du RIPE via un LIR
• implémenter une première version du réseau anycast en 4 points couvrant à minima le FranceIX, le Sfinx et l’EquinIX ainsi qu’une annonce globale derrière un transitaire
• valider et tester ce qui permettra de s’assurer de la cohérence des informations fournies par tous les noeuds du réseau anycast
• tester les process de prise de décision au sein de l’association et réfléchir à la mondialisation de la chose
• trouver de nouveaux participants à l’étranger et étendre le réseau

Vous voulez vous lancer dans cette aventure un peu folle ? Un wiki a été ouvert, ainsi qu’un channel IRC sur irc.geeknode.net canal #DNS. A vos claviers.

Comme je l’ai déjà expliqué dans la série qui explique comment on devient hébergeur, pour faire fonctionner un site internet, vous avez besoin d’un serveur, d’un logiciel qui sait parler le protocole HTTP, d’une adresse IP routable et, éventuellement, pour la cosmétique, d’un serveur DNS (qui peut être sur la même machine) et d’un nom de domaine.

Le problème actuel de Wikileaks se situe au niveau du serveur DNS. Ils ont utilisé un service de DNS gratuit comme on en trouve un peu partout et se sont fait jeter comme des malpropres, ce qui peut éventuellement être considéré comme normal, le service en question n’étant probablement pas prévu pour tenir la charge générée par Wikileaks en tant que tel, et donc encore moins la charge générée  par les cyberattaques des imbéciles qui s’imaginent qu’un site inaccessible ne peut plus rien faire.

En bref, Wikileaks, lorsqu’il n’est pas victime d’attaques par saturation est parfaitement fonctionnel, simplement, il n’y a plus de machine pour dire « www.wikileaks.org = 88.80.2.32″. Ceux qui savent peuvent toujours continuer à y accéder en tapant http://88.80.2.32 mais cette IP aura probablement changé dès la fin du weekend si c’est pas avant.

Pour aider les gens, vous pouvez utiliser un nom de domaine tout frais (ou un que vous avez déjà) et configurer l’alias de www sur cette adresse IP voir un sous domaine, par exemple je pourrais faire http://wikileaks.spyou.org mais la j’ai pas le temps.

Seconde possibilité, pour créer un peu de solidité, vous pouvez utiliser un nom de domaine à vous pour faire une redirection web vers la bonne IP du moment pour Wikileaks. Le résultat final sera identique au pointage DNS ci dessus mais vous ne souffrirez d’aucun délai de prise en compte lorsqu’il viendra le temps de changer d’IP puisque chaque requêtes effectuée aboutira sur votre machine qui redirigera le visiteur vers la bonne adresse.

Si vous voulez aller un peu plus loin, il faut créer un miroir du site. La, ça se corse. Outre le fait que les contenus de Wikileaks ne peuvent, à priori, pas être dupliqués à volonté sans autorisation, il y a un brin de dynamisme sur le site qui rends la création d’un miroir difficile sans arrangement avec Wikileaks lui-même.

Ceci dit, il semble, dans le cas précis du cablegate, que le gros de ce qui est interessant soit en HTML statique. Créez vous donc un espace d’hébergement quelconque et, si vous êtes sous un unix lambda, lancez un petit

wget -m -k -K -E http://wikileaks.bortzmeyer.fr

Et voila, grâce au pointage DNS de Stéphane Bortzmeyer, vous avez rapatrié le site Wikileaks chez vous. Vous pouvez à présent communiquer l’URL au monde entier et vous attirer les foudres d’Eric Besson et de la totalité du corps diplomatique mondial.

La dernière solution consiste à contacter l’équipe Wikileaks pour leur proposer un hébergement officiel .. Mais si vous envisagez la chose, vous avez probablement les compétences pour gérer l’engin.

Crédit photo : Will Pate

Je vais reprendre un sujet que j’ai brièvement abordé un peu partout sur ce blog : la redondance, ou l’art de faire que les choses marchent même quand c’est cassé.

Il est important de comprendre qu’on doit l’appréhender de manière globale, un peu comme la sécurité. Avoir deux liens réseaux sur une seule machine n’a aucun intérêt s’ils sont tous deux branchés au même switch. En matière d’internet, on peut vouloir redonder beaucoup de choses, mais l’exemple d’un site web est le plus parlant ou, en tout cas, celui qui rassemble le plus grand nombre de points auxquels il faut faire attention. Nous allons commencer par le bas de la chaîne :

Redonder le réseau

C’est ce qui vient du plus loin, et c’est le plus facile a redonder. Enfin, facile … Si on a les équipements qui vont bien. Le maître mot de la redondance réseau, c’est la multiplicité des fournisseurs.

Une première base de redondance peut être mise en place avec un seul fournisseur. Ca permet de se protéger contre les pannes matérielles puisqu’on se connecte a son fournisseur avec deux connexions distinctes. Il faut bien faire attention à ce que les câbles utilisés empruntent des chemins physiques strictement différents et que les équipements passifs et actifs du fournisseur soient bien distincts. On ne sera par contre pas protégé, dans ce cas, des bourdes humaines qui peuvent, malgré tout l’empilement matériel possible, interrompre simultanément les deux circuits établis.

Pour éviter autant que faire se peut les erreurs humaines du fournisseur, il en faut un second et on saute tout de suite une étape décisive en matière de réseau en passant du coté obscur de la force avec notre ami BGP qui est, à l’heure actuelle, le seul protocole réellement utilisable pour se connecter à plus d’un opérateur à la fois en assurant une redondance à peu près automatique.

Ce n’est pas qu’un saut technologique majeur où il faut investir dans du matériel et acquérir des compétences. Il s’agit aussi d’une implication humaine et administrative dans le bon fonctionnement de l’ensemble du réseau mondial. On ne doit définitivement pas faire un réseau BGP de la même façon qu’on installe un switch avec deux câbles d’arrivée.

Le fait d’obtenir son indépendance technique et administrative vis à vis de ses fournisseurs ne vous assure toutefois pas un fonctionnement continu et dépourvu de coupures. D’une part parce que vous serez probablement vous-même victime d’erreurs humaines en interne, mais aussi sûrement à cause des divers problèmes de congestion ou de blackhole (volontaires ou pas) que BGP peut rencontrer tout en continuant de prétendre que tout va bien.

Redonder l’alimentation électrique

C’est rarement le métier de l’hébergeur ou du fournisseur d’accès. Pour redonder l’électricité, il faut, en premier lieu, deux circuits électriques distincts. Comme notre beau pays n’a qu’un seul réseau électrique, il convient de choisir soigneusement son emplacement géographique pour faire en sorte d’être au plus proche de deux sources d’énergies différentes (deux centrales EDF, en gros).

De la même façon que le réseau, s’il était possible de s’adresser à deux fournisseurs ayant deux réseaux physiques distincts, ce serait mieux, mais ce n’est pas le cas en France. Par contre, contrairement au transit vers Internet, il est facile de créer ou de stocker l’électricité.

Les plus petites structures choisiront sûrement le stockage temporaire d’énergie dans les batteries d’un ou plusieurs onduleurs ou dans des volants d’inertie (en résumé, c’est une grosse roue qui tourne en consommant un peu de courant pour maintenir sa rotation. Lorsque le courant est coupé, l’inertie de la roue fait qu’elle continue à tourner et restitue l’énergie de la même façon qu’une dynamo).

Les plus gros consommateur se tourneront vers les générateurs au gaz ou au fioul. L’ennui de ces appareils, c’est qu’ils sont incapables de démarrer assez rapidement pour prendre en charge l’alimentation des équipements. Il faut donc, en plus, prévoir un stockage temporaire d’énergie (avec les mêmes composantes qu’au paragraphe précédent) qui permettra de continuer à alimenter les équipements le temps que le générateur démarre et fournisse sa pleine puissance.

Ils seront également utiles par la suite, le courant produit par un générateur mécanique ayant une tension fluctuante, les onduleurs permettant de le stabiliser avant de le fournir aux serveurs.

Redonder le matériel

Pendant longtemps, la mode a penché vers la redondance matérielle à toute épreuve. On rencontre à présent souvent des ordinateurs avec des disques dur fonctionnant en RAID, autorisant ainsi la panne d’un ou plusieurs disques sans pour autant perdre les données ou devoir interrompre le fonctionnement de la machine pour réparer.

On en voit moins chez monsieur tout le monde, mais la plus part des serveurs possèdent deux alimentations. Dans l’idéal, elles sont chacune connectées à des lignes de production d’énergie distinctes (voir chapitre ci dessus).

Mais il existe aussi des serveurs qui embarquent des cartes réseaux doublées ou quadruplées, de la mémoire en réserve qui s’active automatiquement si un problème est détecté sur une barrette en fonctionnement et même, parfois, des processeurs redondants.

Ces prouesses techniques coûtent très cher pour un résultat finalement peu convainquant. De nos jours, on préfère redonder la partie logicielle en se reposant sur du matériel peu coûteux et pas fiable du tout mais en plus grand nombre. Vulgairement, au lieu de mettre une machine avec deux alimentations, deux disques durs et deux cartes réseau, on va mettre deux machines avec chacune une alimentation, un disque dur et une carte réseau.

Il est possible, avec ce genre de pratique, si on choisit bien son matériel, d’avoir, pour un coût d’acquisition identique, trois machines au lieu d’une avec, au global, plus de capacité et de puissance.

Autre avantage qui en découle, avec deux (ou plus) serveurs au lieu d’un, vous pouvez les séparer géographiquement (un à Paris et un à Tokyo par exemple) vous permettant, ainsi, de vous prémunir (ou pas) d’un conflit nucléaire local.

Redonder le logiciel

C’est le plus complexe parce qu’il faut généralement que les logiciels soient prévus spécifiquement pour pouvoir être redondants.

Quelques exemples parmi d’autres :

Redonder un serveur web :

Si votre site n’est constitué que de fichiers HTML et d’image, c’est presque facile. Il vous suffit d’avoir deux machines contenant chacune une copie à l’identique du site et de les faire se surveiller mutuellement. Si B détecte que A n’est pas très en forme (ou carrément aux abonnés absents), elle prend l’adresse IP sur lesquels les sites sont pointés et personne (ou presque) n’aura rien vu.

Redonder un serveur de bases de données :

Là, c’est un peu plus compliqué. Si votre site fait appel (par exemple) à une base MySQL, il faudra recommencer l’opération ci dessus mais en configurant les bases de données pour se synchroniser en permanence, généralement selon un mode maître/esclave. L’ennui, c’est que l’esclave ne sait généralement pas se comporter comme un maître tout seul comme un grand. Il ne pourra donc, par exemple, pas accepter les écritures.

Si votre site web ne fait que lire dans la base de données, pas de problème. C’est rarement le cas. Un contournement est possible en faisant en sorte que le serveur esclave soit vu comme un maître par l’autre et inversement. L’ennui de ce principe, c’est que si les deux maîtres enregistrent une écriture dans la base de données au même moment, il y aura collision, chaque ligne dans une base de donnée étant généralement commencée par un identifiant de ligne qui se doit d’être unique.

Là encore, une solution existe. Lorsqu’on a 2 bases de données, les identifiants écrits via le premier serveur doivent systématiquement être pairs, ceux du 2ème serveur seront systématiquement impaires.

On peut aussi faire appel à des solutions propriétaires et/ou commerciales (Oracle, MySQL Cluster, ..) mais c’est un peu moins Do It Yourself, pas vrai ?

Redonder un serveur de mail :

La, c’est carrément le cauchemar. Vous pouvez bien sur prévoir un second serveur disposant d’une configuration strictement identique au premier avec, par exemple, les informations sur vos utilisateurs stockées dans une base de donnée dupliquée en temps réel (voir ci-dessus) et une synchronisation périodique du contenu des boites (une fois par heure, par exemple).

Si votre serveur principal se casse la gueule, le second recevra le flux de nouveaux mails et les mettra en boîte. Avec un peu de malchance, vous aurez perdu au maximum une heure d’emails.

Si la panne était due, par exemple, à une coupure inopportune du réseau, les mails en question sont tout de même stocké sur le serveur principal qui, au bout d’un moment, redevient accessible. C’est bien joli, mais comment allez-vous synchroniser le contenu des deux serveurs puisqu’ils contiennent tous les deux certains emails que l’autre n’a pas en stock ?

Si vous avez de la chance, le logiciel utilisé stocke un seul email par fichier et vous pouvez lancer une synchronisation simple des deux machines. Si vous utilisez POP3 pour relever vos mails vous vous exposez probablement à des doublons, ce qui n’a jamais tué personne. Si vous utilisez IMAP, par contre, vous perdrez probablement les flags d’une partie ou de la totalité de vos mails (ce sont les indicateurs « lu », « répondu », etc.).

Si le logiciel utilisé stocke tous les mails d’une même boîte dans un seul fichier, vous pourrez peut-être créer une moulinette qui va mélanger vos fichiers tout en éliminant les doublons, mais c’est loin d’être propre.

Des solutions propriétaires existent pour palier à ce genre de problèmes, mais on n’aime pas ça, hein, les solutions propriétaires ?

Il manque sans doute quelques points à tout ça. Commentaires bienvenus ! :)

Crédit photo : @toadscroack

Mesdemoiselles, parfois, dans la vie, il faut savoir abaisser son niveau d’exigence. Vous approchez de (ou vous avez légèrement dépassé) la trentaine, vos hormones vous le crient, vous êtes prêtes à enfanter, et vous n’êtes toujours pas casée ? Il vous faut un homme.

Dans cette catégorie d’âge, remballez tout de suite vos illusions, vous avez le choix entre deux grands types de proies :

- l’abimé, qui après 7 ans de vie commune avec sa petite amie du lycée, vient de se rendre compte qu’elle le cocufiait avec son meilleur ami. Entre nous, ça pue. Il a perdu toute confiance en l’amour, et il va probablement sombrer dans le tunning ou la clystérophilie.

- le geek. Attention, quand je parle de geek, je ne vous parle pas de celui qui a un iPhone et qui déboîte à Plants vs Zombies (ça c’est un hipster niais). Je vous parle du vrai geek, avec du poil, une décoration intérieure spartiate, à base de câbles réseau et de barettes de RAM, et qui, hormis sa mère, adresse la parole à environ deux filles par mois, quand il est l’heure d’aller se ravitailler en pizzas surgelées/coca/noodles. à la supérette du coin. Le geek célibataire et pas trop laid est une ressource abondante et généralement négligée, donc GO FOR IT GAL’.

Je ne reviendrai pas sur les innombrables avantages du geek en tant que que compagnon et père de famille, ni sur les façons de dénicher ce type de bien, cela a déjà été traité en moult endroits. Je me contenterai donc de vous livrer un petit how-to infaillible pour séduire un de ces grands timides et le pousser à commettre l’inimaginable : vous draguer de façon pataude et tellement mignonne.

1. Préambule : le network pour que votre net work

Vous êtes rodée à l’exercice avec les garçons normaux, et vous ne passez plus à l’attaque sans avoir au préalable décortiqué votre cible sur facebook. Seulement voilà, le geek peut avoir un côté un peu militant (le geek est parfois libriste), et ne pas y être inscrit. Votre cible est en revanche forcément présente sur twitter, ou en possession d’un blog. Entre deux notes/liens consacrés à l’hadopi ou à sa dernière découverte sur 4chan, vous trouverez de précieuses informations sur lui, ses goûts, son « univers » comme ils diraient à La Nouvelle Star.

2. Talk to me nerdy

Vous marquerez votre premier point en lui parlant (ce qui est rare est cher). Il existe cependant des faux pas à ne pas commettre. Le geek a tendance à valoriser l’intelligence, même si elle lui fait défaut. Et il a tendance à ranger toutes les filles dans une case : « être vivant dont l’activité principale est la manucure et le shopping, la nourriture : le brocoli, l’habitat : une bonbonnière rose, la culture : Marc Lévy et Anna Gavalda ». Evitez donc soigneusement ces sujets de conversation. Pour les sujets à aborder, voir infra. N’oubliez pas d’être drôle. Les geeks ont de l’humour.

3. Maniez la culture geek

Vous êtes peut-être au courant, il existe une culture geek. Contrairement à ce que l’on pourrait croire au vu du temps que ces êtres passent devant un écran d’ordinateur, la plupart d’entre eux ont lu. Heureusement pour vous, c’était généralement au moment de leur adolescence, quand ils avaient le temps, et les ouvrages clés sont rarement hors de portée. Avoir lu le premier chapitre de Fondation(Asimov), du Guide du voyageur intergalactique (Douglas Adams, pas épais, pas cher) ou de Dune vous permettra qu’acquérir à leurs yeux le statut enviable de « personne qui a de la conversation ». Un vernis suffit, je vous rappelle que le but ici est de créer les conditions d’un rapport fécondant, pas de causer toute la nuit. Une après-midi dans votre bibliothèque de quartier devrait donc suffire. A défaut de bibliothèque, dites que vos lectures préférés à 12 ans, c’était le Livre dont tu es le héros.

4. Jouez maintenant

Vous ne l’ignorez pas, le geek est un grand enfant. Un geek de qualité joue PC, à mon avis, mais je le rappelle, c’est besoin impérieux de maternité dont il est question ici. On ne va donc pas faire la fine bouche, et on saura se contenter d’un joueur console, pour peu qu’il soit un peu sexy. Il sera donc de bon ton de se renseigner discrètement sur son équipement et d’en déduire quelques titres clef. De préférence du jeu de combat, histoire de jouer à deux. Mise en situation : « Ah bon, tu as une XBox ? Tu me botteras les fesses à Soul Calibur ? » Faites suivre par un petit rire de gorge, c’est dans la poche.

5. Surveillez votre style vestimentaire.

Je le rappelle, le geek est un être timide et sensible. D’un autre côté, il s’est habitué à l’idée de terminer sa vie vieux garçon, ou en compagnie d’une fille obèse et velue. Il vous faut donc être à la fois féminine et accessible. Choisissez entre le décolleté et la jupe, évitez le maquillage outrancier. Soyez la girl next door, fraîche et souriante. De toute façon, vous ne serez jamais aussi bonne que Seung Mina.

6. Possédez une cotte de mailles

La cotte de mailles montre deux choses. D’abord, qu’une fois, peut-être, vous avez été impliquée dans un GN (grandeur nature, sorte de rassemblement de geeks en costumes), et ensuite, que vous êtes prête à affronter une attaque zombie. Autrement dit, vous savez vous amuser ET vous êtes dotée d’un solide sens pratique. En deux mots, vous êtes la femme idéale, digne de porter son patrimoine génétique.

7. Seder pour le faire céder

Un mode de conversation incontournable avec un bon geek est le chat. Je vais vous donner ma botte secrète, imparable avec tout geek qui se respecte (et donc, qui code). Il s’agit du sed. Un jour, forcément, vous ferez une faute de frappe. Au lieu de rectifier immédiatement en retapant le mot comme le font les gens normaux, vous allez procéder comme suit :

s/[mot à remplacer]/[mot de remplacement]/

Ça n’a l’air de rien, c’est à la portée de n’importe quel élève de CP, et l’effet est faramineux. En pratique, cela donne :

>Tenfloril : J’adore les pizzas. Et toi, c’est quoi ton plat préféré ?

>Ursula78 : Je pourrais mourir pour des endives baisées

>Ursula78 : s/baisées/braisées/

>Tenfloril : MAIS

>Tenfloril : MAIS

>Tenfloril : MAIS

>Tenfloril : Épouse moi.

Ce billet était sponsorisé par le secrétariat d’État à l’économie numérique et le Ministère pour l’explosion de la démographie. Si vous avez une fille, je vous autorise à l’appeler Cécile.

Petite introduction pour deux sujets que les geeks (qui peuvent être grecs) ont à coeur : le binaire et le nombre 42.

Crédit photo : Pawel Marciniak (flickr)

Commençons par la partie barbante, le binaire. Vous l’avez nécessairement entendu au moins une fois, c’est la base de l’informatique. La raison est simple, pour éviter de faire des erreurs, on est parti du principe qu’il n’y avait que deux états électriques possible : y’a du courant ou y’en a pas. En mathématique, c’est le binaire. Au lieu de compter de 0 à 9 (0 1 2 3 4 5 6 7 8 9 10 11 12…) on compte de 0 à 1 (1 10 11 100 101 110 111 1000…).

Quand on fait de l’informatique depuis un moment, on est habitué à convertir le binaire en décimal et parfois en hexadécimal (ou on compte de 0 a F … 0 1 2 3 4 5 6 7 8 9 A B C D E F 10 11 12…). On sait par exemple que 255 c’est 11111111 en binaire et FF en hexadécimal. On acquiert aussi quelques mécanismes simples : le double de 1 c’est 10, le double de 10 c’est 100 et ainsi de suite. On sait aussi qu’un 1 suivi de un plusieurs 0 peut se calculer simplement comme étant 2 puissance [le nombre de zéro], par exemple, 10000 = 2^4 = 16. Quant au chiffre 1, il vaut 1.

Nous voila donc avec 101010, pour vérifier que ça donne bien 42, il suffit de le découper en blocs avec les 1. On a donc 10, 1000 et 100000, respectivement 2^1 (2), 2^3 (8) et 2^5 (32). 32+8+2 = 42.

Vous pouvez aussi le vérifier en comptant sur vos doigts, mais c’est plus long. Chacun de vos doigt est un des chiffre qui peut être 0 ou 1 … essayez, vous verrez que c’est pas facile de suivre au bout d’un moment.

Vous savez donc maintenant comment compter jusqu’à 31 avec une seule main et jusqu’à 1023 avec les deux. Et si vous êtes souples des pieds, vous pouvez même compter jusqu’à 1048575 avec vos 20 doigts.

Certains agités du bulbe ont fait des montres en binaires (photo) ou des bougies pour gateau d’anniversaire en binaire (c’est pratique, vous êtes à peu près sur de ne jamais avoir besoin de plus de 7 bougies et il est rare d’avoir à toute les allumer)

Crédit photo : Adams Foster (flickr)

Mais pourquoi 42 ? L’origine se trouve dans l’oeuvre de Douglas Adams, « Le Guide du voyageur galactique ». Pour résumer l’histoire, une civilisation extrèmement avancée à construit un ordinateur capable de calculer la réponse à la question universelle, la grande question sur la vie, l’univers et le reste. Le bestio, Pensées Profondes de son petit nom, met quand même plus de 7 millions d’années à mouliner la question, puis, convoque les représentants de la civilisation en question pour enfin sortir une réponse qui est « 42″.

Les gens étant un poils déçus quand même, ils demandent « mais, c’est la réponse à quoi ? », sur quoi l’ordinateur répond « je ne suis pas assez puissant pour vous formuler correctement la question mais je peux fabriquer la machine qui pourra le faire », la machine en question étant la Terre telle que nous la connaissons, les souris étant les incarnations dans notre monde de cette ancienne civilisation. Ils sont la, ils nous surveillent, histoire d’avoir la question à leur réponse. Je ne vous raconte pas la fin :)

De fait, 42 est un nombre souvent utilisé en informatique, on le retrouve même parfois à des endroits inattendus.

Plus de détails (spoiler inside) sur la page wikipédia qui vous explique 42 en détail.

Le petit bonhomme juste au dessus est l’incarnation, dans le film tiré du bouquin, de Marvin, le robot dépressif car doté de la capacité de ressentir des émotions humaines.

Et pour finir, ça ne se voit pas, mais cet article à été publié à 10h10. Ça vous fera un petit exercice, ça donne combien 1010101010 de binaire en décimal ? Et dans quel système de numération ça vous fait penser à des piles ? Interdit de répondre « kamoulox ».

Crédit photo : akakumo (flickr)

C’est le fer de lance de l’industrie en ce moment. Virtualisation, cloud, petits nuages, et PAF, votre informatique se portera beaucoup mieux, vous dépenserez moins d’argent, vous aurez plus de puissance et vous serez bientôt les maîtres du monde.

Ils ont tout faux, le maître du monde, chacun sait très bien que c’est moi.

Trêve de gonflage de chevilles, de quoi s’agit-il ? Pour commencer, un mot à propos de la virtualisation. Dans les glorieux temps reculés de l’informatique nous avions déjà une bonne couche de virtualisation :

• Nous n’avions à notre disposition sur un ordinateur qu’un BIOS (Basic Input Output System) servant grosso modo à faire parler les composants matériels de l’ordinateur (carte vidéo, clavier, carte réseau, …) avec le système d’exploitation. Ce n’est pas une virtualisation parfaite dans le sens où chaque composant matériel a encore besoin d’un langage spécifique au niveau du système d’exploitation pour fonctionner, mais c’était déjà un bon début.
• Nous avions aussi un système d’exploitation appuyé sur le BIOS qui offrait tout une palette de fonctionnalités permettant aux développeurs d’applications de ne pas avoir à réinventer la roue à chaque fois (créer une fenêtre, gérer un menu déroulant, etc.). A ce niveau, par contre, il n’y a plus que de rares applications qui ont besoin d’instructions spécifiques concernant le matériel, pour toutes les autres, l’ordinateur est déjà complètement virtualisé dans le sens où vous pouvez remplacer le matériel et continuer à utiliser vos applications de la même façon.

Alors qu’y a-t-il de nouveau qui justifie de crier à la révolution ? Une nouvelle étape de virtualisation a été franchie, il est à présent possible (ça l’a toujours plus ou moins été, mais c’est à présent fiable, rodé et déployé à grande échelle) de faire fonctionner une machine dans la machine. En bref, de faire fonctionner un système d’exploitation sur une machine qui est virtuelle et complètement détachable du matériel.

Et donc, concrètement, où est la révolution ? Vous êtes sans doute habitués à l’ordinateur de base, un (ou plusieurs) processeur(s), un espace de mémoire, du stockage sur disque dur et un système d’exploitation. La virtualisation consiste à n’utiliser le système d’exploitation installé sur le matériel que pour faire fonctionner d’autres systèmes virtuels.

Je vais prendre l’exemple de VMWare ESXi qui est celui que je pratique le plus (preuve supplémentaire que je ne suis pas libriste). Il ne s’agit ni plus ni moins que d’un vulgaire système basé sur Linux mais qui ne vous offre, de prime abord, aucun moyen d’interaction si ce n’est la configuration du réseau pour pouvoir y accéder à distance. Une fois configuré, vous pouvez lancer un outil (vSphere) sur un poste distant vous permettant de prendre la main sur le VMWare.

Une fois dans cet outil, vous obtenez une vue des ressources disponibles (espace disque, mémoire, puissance de calcul, …) et vous pouvez créer une machine virtuelle, la démarrer, lui connecter un lecteur de CD bien réel, etc …

Que se passe-t-il ? Le système d’exploitation installé sur notre machine fait tourner un programme (hyperviseur) qui va se comporter comme une machine réelle en réutilisant les ressources de la machine sur laquelle il est installé. Vous pourrez par exemple lui dire « tu peux utiliser 4Go de mémoire, 80Go de disque dur et la moitié de la ressource de calcul du serveur ».

Là dessus, on démarre un système d’exploitation dans la machine virtuelle. Ce système n’a théoriquement aucun moyen de sortir du carcan établi. On peut donc, par exemple, faire tourner 3 machines virtuelles ayant chacune 1Go de mémoire sur un serveur réel qui en a 4 en tout.

Où est l’intérêt ? Souvent, lorsqu’on installe un serveur, on n’utilise à fond qu’une seule des trois ressources principales. Une machine de stockage va par exemple n’utiliser que très peu de mémoire ou de puissance de calcul mais remplir complètement son disque. La virtualisation permet de faire fonctionner, sur cette même machine réelle, une autre machine virtuelle qui, elle, n’aura besoin que de peu d’espace disque mais utilisera beaucoup de mémoire.

Et la, vous vous dites « oui, mais ça, je pouvais déjà le faire avant, il suffisait d’installer les deux applications complémentaires sur le même système d’exploitation ». Bravo, vous avez mis le doigt sur la grande esbroufe de la virtualisation. Le seul intérêt réel réside dans le fait qu’avec elle, vous pouvez installer plusieurs systèmes d’exploitation différents. Sorti de ça, pas de grand intérêt si ce n’est peut-être plus de souplesse pour l’administrateur qui peut proprement segmenter les différents usages de son matériel.

Quel rapport avec les nuages ? Le nuage dont on parle, c’est le réseau et la myriade de serveurs qui y sont connectés. C’est le second avantage de la virtualisation, le fait de pouvoir séparer les éléments matériels pour les réunir virtuellement et constituer ainsi une machine qui aura l’air d’être vraie.

Imaginez deux serveurs avec 64Go de mémoire vive, 8 gros processeurs et aucun disque dur. Faites-leur faire copain-copain avec deux NAS bourrés de disques durs qui ne savent rien faire d’autre que restituer les 80To qu’ils contiennent. Mettez un serveur et un NAS à un endroit, les deux autres à un autre, montez un joli réseau qui interconnecte tout ça, ça y est, vous avez un cloud.

Que pouvez-vous faire avec votre tout nouveau nuage ? Vous allez commencer par faire que les NAS se synchronisent entre eux, histoire d’être quasiment sûr de ne jamais perdre une seule donnée. Vous allez ensuite installer un hyperviseur sur chacun des deux serveurs et configurer 32 machines virtuelles par serveur, chacune avec 1Go de ram et 1To de disque que vous irez chercher sur le NAS.

Si un avion tombe sur le site numéro 1, que deviez-vous faire avant ? Récupérer vos backups et relancer vos services sur le site numéro 2 au prix de longues heures d’interruption du service et de travail pour restaurer les données. A présent, en 2 clics, vous aurez relancé les 32 machines virtuelles du site 1 sur le site 2, aucune donnée ne sera perdue puisque le second NAS avait une copie en temps réel des données du premier, et votre job est sauvé !

Et puis quoi, encore ? Une dernière chose amusante, une machine virtuelle utilise un quota fixé d’espace disque, de mémoire et de processeur. Vient un moment où vous avez besoin de plus, il suffit d’aller cliquer pour augmenter la mémoire… Si vous aviez bien sûr prévu le coup et installé la mémoire en question dans la machine physique. Non, la virtualisation n’invente pas de la mémoire qui n’existe pas.

Alors où est l’arnaque ? Il n’y en a pas vraiment, vous pouvez effectivement bénéficier de redondance accrue, ou en tout cas plus facile à mettre en oeuvre, de flexibilité dans l’allocation des ressources, mais vous perdez de la puissance du fait de cette virtualisation (quelques pourcents d’après les éditeurs d’hyperviseurs, donnée à vérifier) et vous vous retrouvez sur une infrastructure mutualisée entre plusieurs clients, ce qui peut entraîner pas mal de désagréments, de la surcharge ponctuelle au plantage généralisé qui mobilise tellement les équipes de l’hébergeur que vous passez en seconde position question urgence.

Rien de bien révolutionnaire pour les grosses infrastructures, donc. Ça ne fait qu’ajouter une couche de complexité à quelque chose qui l’est déjà énormément. Pour les petits usages ayant besoin de flexibilité, c’est par contre assez intéressant.

Crédit photo : Jennifer Buehrer (flickr)

Le « Libre » ? C’est quoi ? Comment le définir ?

Pourquoi donc certaines personnes se disent « Libristes » ? Pourquoi donc certaines personnes ont décidé de quitter les chemins pavés pour arpenter d’autres routes ? Pourquoi donc le « Libre » a autant d’importance pour moi (nous ?) ?

Oui, en effet, j’aime prendre des chemins légèrement détournés, j’aime rester maître de mes mouvements, mais ce que je préfère surtout, c’est avoir le choix. Quels choix me demanderez-vous ? Tout simplement celui de parler, de m’exprimer comme je le sens et quand je le souhaite et par le moyen que je choisis : le choix de pouvoir apprendre n’importe quoi de n’importe qui et n’importe où.

Cette année, j’ai parlé philosophie et économie avec un barbu d’Amiens, techniques et configuration pendant trois jours avec quelqu’un de Cahors, un peu de droit, de nouveaux modèles économiques et d’informatique sur IRC, et la liste est encore longue, très très longue. Pour vous donner une idée, j’ai appris plus de choses sur Internet  en un an en  me baladant, en parlant et en rencontrant des personnes qu’en BTS informatique (donc 2 ans), ce dont je me sers aujourd’hui vient d’Internet, et non de mes cours, à part quelques rares cas.

Le Libre, c’est un peu de philosophie : le partage est important, comme l’éducation,  les deux valeurs les plus importantes dans ce qu’on pourrait appeler « l’apprentissage de la vie ». Il faut apprendre à réfléchir par soi-même, à sortir des sentiers battus et rebattus afin de mieux prendre son envol.

Le Libre, c’est un peu croire en l’Humain, et se dire que si une chose peut nous servir, elle peut servir à une autre personne, qui pourra la modifier et l’améliorer si elle en a envie. C’est se dire que le savoir est et restera une des choses les plus importantes de notre espèce, qu’il faut diffuser le plus largement possible, sans restriction, après tout, c’est un “patrimoine commun de l’humanité”

• « Qu’est-ce qu’un logiciel libre » sur le site de l’April
• « Définition d’un logiciel libre » sur Gnu.org
• « La philosophie du libre » sur cooperation.net

Un logiciel libre est un logiciel dont l’utilisation, l’étude, la modification, la duplication et la diffusion sont universellement autorisés sans contrepartie.

On peut tout à fait héberger des contenus internet sur un PC de bureau tout ce qu’il y a de plus classique, mais lorsqu’on souhaite avoir un peu de fiabilité, on s’oriente plutôt vers des serveurs. Ils n’ont pas grand chose de différent dans leur structure mais proposent la redondance et la fiabilité de composants nécessaires à la fourniture d’un service 24h/24 et 7j/7.

Lorsqu’on les installe en datacenter (photos) ils sont généralement le plus plat possible pour occuper le moins d’espace. Lorsque l’espace n’est pas un problème, on peut se contenter de serveurs au format tour.

L’alimentation

Crédit photo : Craig Rodway (flickr)

En amont de votre matériel, il est bien entendu préférable de disposer d’au moins deux sources d’énergie (par exemple EDF et un générateur au diesel ou au gaz). On peut tout à fait pratiquer cette redondance à moindre frais de petits équipements. Un petit générateur diesel n’est par ailleurs pas hors de prix. On branche ensuite ce générateur à un équipement commun avec l’arrivée EDF qui dispose d’une batterie permettant de continuer à alimenter les équipements le temps que le générateur démarre. (voir l’article sur l’énergie en datacenter pour avoir une idée de ce que ça donne à grande échelle)

Une fois l’arrivée électrique sécurisée par un quelconque moyen, le premier composant de notre serveur sera l’alimentation. Avec les disques dur, c’est ce qui a tendance à cramer le plus vite dans une machine. On prendra donc soin d’opter pour un serveur disposant de deux alimentation. Dans un datacenter c’est très utile, les salles proposant souvent deux arrivées électriques distinctes (on branchera alors chacune des alimentation sur une arrivée). Mais même dans un endroit ne proposant qu’une arrivée, le branchement des deux alimentations sur cette unique source permet d’éviter que le serveur ne soit hors d’usage lorsque son alimentation tombe en panne.

La mémoire et les processeurs

Crédit photo : Manuel W. (flickr)

C’est rare de croiser ce genre de configuration sur (ou sous) un bureau. Dans un serveur, on peut réserver une ou plusieurs barrettes de mémoire pour de la tolérance de panne. Lorsque la machine détecte un problème quelconque sur une barrette, elle copie immédiatement l’intégralité des données encore valables sur une barrette de secours et désactive la barrette fautive.

Le même genre de comportement peut se faire avec les processeurs physiques et nombres de composants tolèrent les pannes dans des serveurs (ventilateurs, câblage, …)

Ce genre de solution est de moins en moins utilisée, la mode étant plutôt à la multiplication des serveurs se répartissant la charge de travail qu’au fait de pousser à l’extrême la redondance interne de chaque machine.

Les disques dur

Crédit photo : osde8info (flickr)

C’est la première chose qui bénéficie de redondance. On trouve d’ailleurs de petites solutions de stockage NAS pour particuliers et petites entreprises mettant en jeu le fameux RAID (Redundancy Arrays of Inexpensive Disks). L’idée de base est de stocker les mêmes données sur plusieurs disques pour éviter leur perte lors d’une panne.

Il existe plusieurs niveau de RAID, les plus connus étant 0, 1 et 5.

• Le RAID0 n’offre aucune redondance mais permet de regrouper plusieurs disques physiques différents en un seul disque virtuel qui sera présenté au système d’exploitation du serveur. Gros problème si on perd un disque, l’ensemble du disque virtuel devient inutilisable
• Le RAID1 est une simple copie miroir, vous installez deux disques de capacité identique, chaque donnée est écrite sur chacun des deux disques. Vous disposez donc de l’espace disponible d’un seul des deux disques. Si l’un des deux claque, le second continue à fournir les informations. Le disque défaillant peut être généralement changé sans avoir à stopper le fonctionnement du serveur. L’autre avantage du RAID1 est qu’en fonctionnement optimal (2 disques fonctionnels), la lecture est deux fois plus rapide qu’avec un seul disque puisque les lectures sont réparties sur les deux disques physiques.
• Le RAID5 est une répartition d’un seul volume sur plusieurs disques avec une tolérance de panne d’un disque. Pour comprendre le mécanisme, imaginez que les disques ont une capacité d’un seul bit, le RAID5 de 3 disques donnera donc une capacité globale de deux bits. Si vous stockez 0 et 1 dans ces deux bits, une opération binaire XOR sera effectuée sur ces deux bits et le résultat (1) sera stocké sur le 3ème disque. Si vous perdez le premier disque, le système pourra retrouver la donnée perdue en comparant celle stockée dans le second et la donnée de contrôle du 3ème.

Il existe tout un tas d’autres RAID, je vous invite à aller voir la page Wikipédia consacrée pour en savoir plus.

Pour faciliter l’échange à chaud de disques dur, les serveurs présentent généralement des racks extractibles en façade. Vous passez devant, un disque clignote en rouge, vous le sortez, vous en prenez un autre dans le stock, vous le remettez en place, et le système va démarrer tout seul la resynchronisation des données pour rétablir la redondance en fonction du niveau de RAID choisi.

Le réseau

Crédit photo : DaveOnFlickr

On l’oubli souvent, certains hébergeurs ne fournissent d’ailleurs pas ce type de solution, mais la redondance du réseau peut se faire jusqu’au serveur en livrant la connectivité vers internet sur deux liens au lieu d’un seul. Les serveurs de marque sont donc tous équipés d’au moins deux cartes réseau dont le fonctionnement est généralement « maître/esclave », l’une effectuant tout le travail pendant que l’autre est laissée en standby pour n’être activée qu’en cas de besoin.

Crédit image : Alterdigue

J’ai enfin réussi à mettre la main sur l’origine d’un bug qui me pourri la vie depuis un mois. Symptôme : lorsque j’indiquais une URL de mon blog sur Facebook, leur crawler n’arrivait pas à récupérer la page correspondante, donc pas de bel affichage avec une jolie image et une mise en forme sympathique.

Le problème vient des rewrite rules établies par le plugin W3 Total Cache. Une page en parle sur le site du support wordpress. N’ayant pas réussi à faire le lien avec la mise en route du cache, j’ai mis un temps fou à trouver.

Pas de workaround bien documenté, j’ai fini par basculer le cache de pages en « basic » à la place d’enhanced et désactiver les rewrites rules du cache navigateur. Depuis, plus de problèmes !

Si des gens ont une idée plus propre ou le temps de chercher, je suis preneur.

J’ai quand même tenté l’aventure, histoire de dire au moins une fois dans ma vie « je suis early adopter ».

Alors, pour les gens qui sont pas encore au courant, Diaspora, c’est quoi ? C’est censé, à terme, être comme Facebook mais sans grosse usine à gaz centrale qui vous vole votre vie privée. Pour remplacer, il y aura donc un tas d’usines à gaz un peu partout, que chacun utilisera à sa guise. Les utilisateurs normaux seront sans doute contraint d’utiliser l’installation d’une autre personne (un de leurs amis geek, par exemple), mais chacun pourra, en tout théorie, communiquer sur le réseau Diaspora en conservant ses données personnelles dans sa machine à lui et contrôler très précisément qui peut y accéder.

Pour faire tourner tout ça, Diaspora se base sur les théories ancestrales du peer2peer. Grosso modo, sur un serveur diaspora installé, vous aurez un identifiant qui ressemble fort à une adresse email, mais qui en vérité est votre login suivi du nom de la machine ou tourne Diaspora. Dans mon cas, j’ai feinté au maximum, et mon identifiant est donc root@spyou.fr. Avec ça, je peux contacter tom@pivots.joindiaspora.com et échanger avec lui comme ça se fait sur Facebook. Enfin presque, c’est une version pré-alpha, et y’a à peu près rien qui marche pour l’instant.

Trois façons de faire tourner Diaspora :

• Par le serveur web (thin) embarqué
• Via passenger dans un apache
• Via mod_proxy d’apache pour retomber sur le thin embarqué

J’ai testé les trois. Passenger n’étant vraiment pas pour moi, j’ai vite fais l’impasse, et j’ai fini par laisser tomber aussi mod_proxy, il semble qu’il y ai quelques problèmes de communication entre les différentes instances distantes et votre installation locale de Diaspora dans ce cas.

Concentrons nous donc sur le plus simple. Le howto d’installation pour linux qu’on trouve sur le site officiel est à peu près bon, mais faisons les choses dans les règles. Pour FreeBSD, donc :

cd /usr/ports/lang/ruby18 && make install clean
cd /usr/ports/databases/mongodb && make install clean
echo « mongod_enable=’yes’\n » >> /etc/rc.conf
/usr/local/etc/rc.d/mongod start
cd /usr/ports/devel/ruby-gems && make install  clean
cd /usr/ports/devel/git && make install clean
cd /usr/ports/graphics/ImageMagic && make install clean
cd /la/ou/vous/allez/mettre/diaspora
git clone http://github.com/diaspora/diaspora.git
gem install bundler
cd diaspora
bundle install
rake db:seed:tom
bundle exec thin -a ip_a_utiliser_sur_votre_serveur -p port -D start

Bien sur, si vous n’avez qu’une seule IP et que votre port 80 est déjà utilisé, ça va être moins pratique, Diaspora ne sachant pas communiquer avec l’extérieur convenablement s’il ne fonctionne pas sur le port 80. Vous pouvez quand même voir la chose et l’utiliser en local avec, par exemple, le port 3000. Une fois thin lancé, vous pouvez aller a http://votre_ip:3000/ et jouer avec.

Bon courage ! :)

Crédit photo : __Olga__ (flickr)

Quand vous configurez un compte email, vous saisissez generalement un nom d’utilisateur, un mot de passe, et un ou deux noms de serveurs (entrant et sortant).

Lorsque vous allez envoyer votre premier email, que va-t-il se passer ? Votre machine va contacter le serveur d’émission (généralement dit « serveur SMTP ») que vous lui avez indiqué pour expédier l’email. Il ne va jamais contacter directement le serveur de courrier du (ou des) destinataires.

Votre mail, une fois arrivé sur le serveur, deux possibilités, soit le serveur en question est un simple relai, auquel cas il va se borner a renvoyer l’email a son petit copain qu’il connait de par sa configuration, soit il doit se charger lui même d’envoyer l’email aux serveurs destinataires et il va donc dupliquer l’email en autant de domaines destinataires différents. Par exemple, si vous envoyez un mail a toto@titi.pouet, tata@miaou.pouet et titi@titi.pouet, votre serveur de mail fera un premier groupe avec les deux emails @titi.pouet et un autre avec @miaou.pouet.

Une fois les tas d’emails constitués, il va rechercher à quels serveurs envoyer chaque tas d’email. Pour les trouver, on se base sur le système DNS qui contient, pour chaque domaine ou sous domaine, un champ « MX » (Mail eXchanger) indiquant le nom du ou des serveurs responsables des emails pour le domaine.

Il établi ensuite une connexion (également en SMTP, comme vous l’avez fait vous-même) à chacun de ces serveurs pour envoyer l’email à tous les destinataires qui sont joignables sur ces serveurs.

Bilan des courses, vous pouvez tout à fait, si votre FAI vous fourni du vrai internet et en cherchant vous même le nom du serveur MX d’un domaine, envoyer directement à ce serveur vos emails pour les destinataires qui sont dessus. Ça suppose de changer la configuration de votre logiciel de messagerie à chaque email que vous voulez envoyer.

Une fois arrivé sur le serveur de destination, votre mail passe dans différents filtres, probablement au moins un antispam et un antivirus puis est distribué dans une boite ou il attendra sagement que son propriétaire vienne le relever. On utilise majoritairement deux protocoles pour relever les mails :

• POP3 qui n’a aucune notion de sous dossiers et qui se borne à lister tous les emails présents dans la boite, permettant de les récupérer, puis, éventuellement, de les effacer
• IMAP4 qui, lui, conserve également une arborescence de sous dossier permettant de trier ses emails puis de retrouver cette arborescence ailleurs, à la maison, par exemple

Avant de pouvoir relever les mails, le logiciel fourni vos identifiant et mot de passe au serveur (ne serait-ce que pour qu’il sache quelle boite vous montrer, mais aussi pour qu’il puisse être sur de votre identité)

Le cas du webmail, très employé de nos jours, n’est pas différent de celui d’un logiciel de courrier comme Thunderbird ou Outlook. C’est simplement un logiciel accessible via le web qui va, lui aussi, parler avec le serveur de mail en POP3 ou en IMAP4 (a de rares exceptions près que nous ne détaillerons pas ici.

La ou ça devient drôle, si vous avez bien suivi la description ci dessus, c’est que vous pouvez envoyer des mails à peu près à n’importe qui sous n’importe quelle identité. En effet, le protocole SMTP n’a, à l’origine, aucune notion de vérification de l’émetteur. Une petite démonstration valant mieux qu’un long discours, je m’en vais de ce pas envoyer un email à notre président en me faisant passer pour Barack Obama.

Je commence par récupérer le serveur de mail traitant le courrier pour le domaine de Nicolas Sarkozy :

$ dig MX sarkozy.fr
[...]
;; ANSWER SECTION:
sarkozy.fr. 300 IN MX 10 berlioz.elysee.fr.
[...]

Je me connecte ensuite à la machine en question (berlioz.elysee.fr) sur le port 25 (celui réservé au SMTP, je ne pirate rien, c’est ce que font les logiciels de courrier) et je parle comme un logiciel de courrier qui envoie un mail, je commence par me présenter (HELO ) puis par donner les emails de l’émetteur et du destinataire (en italique) :

$ telnet berlioz.elysee.fr 25
Trying 84.233.174.57…
Connected to berlioz.elysee.fr.
Escape character is ‘^]’.
220 SMTP Welcome
helo blog.spyou.org
250
mail from: barack@whitehouse.gov
250 2.1.0 barack@whitehouse.gov… Sender ok
rcpt to: nicolas@sarkozy.fr
451 4.7.1 Greylisting in action, please come back in 00:05:00
quit
221 2.0.0 phobos.elysee.fr closing connection
Connection closed by foreign host.

Si vous avez bien lu, je me suis fais jeter comme un malpropre par un dispositif de greylisting qui me demande de revenir dans 5 minutes. C’est une technique de base de la lutte antispam qui consiste à refuser un email à la première tentative. Les serveurs de mail normalement constitués vont réessayer quelques minutes plus tard alors que le robot de spam, lui, ne réessaiera pas, prenant généralement ce refus comme un « la boite n’existe pas ». Bien sur, les spammeurs se sont adaptés depuis et réessaient autant de fois qu’il le faut. La méthode permet tout de même encore d’éviter l’arrivée de certains spams.

Je laisse donc passer les 5 minutes demandées par notre cher ami Berlioz (si vous notez bien, la machine elle même, lorsque j’ai demandé l’arrêt de la connexion, m’a dit qu’elle s’appelait Phobos … Ils ne doivent pas boire que de l’eau à l’Élysée) :

$ telnet berlioz.elysee.fr 25
Trying 84.233.174.57…
Connected to berlioz.elysee.fr.
Escape character is ‘^]’.
220 SMTP Welcome
helo blog.spyou.org
250
mail from: barack@whitehouse.gov
250 2.1.0 barack@whitehouse.gov… Sender ok
rcpt to: nicolas@sarkozy.fr
550 5.1.1 nicolas@sarkozy.fr… User unknown
quit
221 2.0.0 phobos.elysee.fr closing connection
Connection closed by foreign host.

Bon, j’ai vraiment pas de chance, cette adresse ne marche plus, il va falloir que je trouve un autre email pour joindre Nicolas.

Notez que la ligne que nous avons eu : 550 5.1.1 nicolas@sarkozy.fr… User unknown est celle qui, lorsque vous utilisez votre logiciel de courrier, va faire que le serveur de votre fournisseur d’accès vous renverra un email « Mailer Daemon » vous expliquant que votre mail n’a pas pu arriver à bon port.

Je ne trouve rien pour sauver ma démo, je vais donc être contraint de demander à un intermédiaire, le webmaster du site de l’Élysée (webmestre@elysee.fr) de transmettre mon faux mail de Barack à Nicolas. Ça tome bien, le serveur MX pour elysee.fr est le même que pour sarkozy.fr. Il faudra que je pense à revérifier ça après les prochaines élections.

Il faut bien sur attendre de nouveau 5 minutes pour le passage de la greylist, puis :

$ telnet berlioz.elysee.fr 25
Trying 84.233.174.57…
Connected to berlioz.elysee.fr.
Escape character is ‘^]’.
220 SMTP Welcome
helo blog.spyou.org
250
mail from: barack@whitehouse.gov
250 2.1.0 barack@whitehouse.gov… Sender ok
rcpt to: webmestre@elysee.fr
250 2.1.5 webmestre@elysee.fr… Recipient ok
data
354 Enter mail, end with « . » on a line by itself
subject: A l’attention de Nicolas
Un petit mail de demo pour un article sur http://blog.spyou.org/. L’expediteur est bien entendu faux :)

Merci.
.
250 2.0.0 o8BCCtp8003800 Message accepted for delivery
quit
221 2.0.0 phobos.elysee.fr closing connection
Connection closed by foreign host.

Et voila, comme une lettre à la poste, comme on dit. Il faudra que je pense à regarder les statistiques d’accès à mon blog, je pourrais éventuellement récupérer l’adresse IP depuis laquelle se connecte le webmaster du site de l’Élysée et apprendre, du coup, quel est leur fournisseur d’accès (voir mon billet sur le sujet). C’est un formidable début d’ingénierie sociale qui peut aider un vilain méchant pirate à entrer dans un système informatique.

On note au passage qu’on a obtenu un identifiant unique pour l’email envoyé (o8BCCtp8003800), ce qui est relativement pratique lorsqu’on chasse des mails qui n’arrivent pas ou mal à bon port.

Pourquoi mon faux email a très peu de chances d’arriver à destination ? Parce que même si le protocole SMTP n’a pas de notion de comment vérifier que l’expéditeur est bien qui il prétend être et que le serveur de l’élysée a accepté mon expédition (Message accepted for delivery), on a réussi à inventer tout un tas de choses diverses et variées pour contourner le problème. Les logiciels d’antispam sont à présent très doués, trop même, au point de refuser des emails légitimes. Par exemple, si Barack vient en vacances dans mon jardin picard, il est fort peu probable qu’il puisse envoyer un email au webmaster de Nicolas avec ma connexion internet sans qu’un antispam ne mette son veto avant la distribution.

Petit exercice pratique pour finir, essayez de déterminer, sans utiliser votre logiciel de courrier, si l’adresse barack@whitehouse.gov existe vraiment ou pas.

Pour aller plus loin, j’essaierai de vous parler de quelques principes des spams et des antispam dans de futurs articles.

Crédit photo : be_khe (flickr)

La flemme galopante et le weekend très actif coté travaux manuels (à base de levé de coude et d’observation de bulles) ne m’aident pas vraiment à produire quelque chose d’intéressant pour ce joli dimanche de septembre. J’ai donc jeté mon dévolu sur un article fort intéressant publié sur Infond, oeuvre de Ludovic Tokata et de Jean Dujardin. J’ai obtenu le droit de reproduire ici même l’introduction, rien que pour vous donner l’eau à la bouche.

L’article traite, comme le dit le sujet du présent billet, des aspects juridiques du scan de port. Si vous avez suivi mon article sur TCP et UDP, vous savez déjà ce que sont les ports, l’introduction ci-dessous vous rafraîchira un peu la mémoire, voir, vous donnera un oeil neuf sur la question. Je suppose aussi que vous savez ce qu’est un porc, et je trouvais celui la trop mignon ! Bonne lecture.

La prise d’empreintes de ports informatiques, appelée aussi scan de port, est une technique consistant à balayer automatiquement, à l’aide d’un programme approprié, une série d’adresses IP spécifiques afin de déterminer les ports ouverts ou fermés sur chaque ordinateur. Un ordinateur pourrait être décrit comme un bâtiment dans lequel chaque habitant (les programmes) peut ouvrir ou fermer des portes (les ports) pour communiquer avec l’extérieur (le réseau, Internet). Scanner les ports consiste donc à venir frapper à chacune de ces portes en espérant obtenir une réponse du programme derrière.

Le scan de port peut être une action légitime : un administrateur peut vouloir scanner ses machines pour repérer des logiciels indésirables sur son réseau (anciennes versions, malwares). Cependant, le scan de port permet aussi à une personne malintentionnée d’obtenir des informations sur les applications en service dans un réseau afin d’identifier des failles ou de contourner les mesures de sécurités (firewalls, détecteurs anti intrusion). Il peut ainsi s’inscrire dans une démarche de préparation à une attaque contre un système d’information et constituer une étape préliminaire avant une intrusion.

Pour autant, le scan de ports est-t il contraire à la loi ?
Cet article apporte des éléments de réponses à cette question.

Lire la suite sur Infond

Crédit photo : etringita (flickr)

C’est dès le départ un faux titre, les IP n’appartiennent (au sens « propriété » du terme) à personne. Elles ne s’achètent pas (du moins pas à leur source, il y a un certain nombre d’entreprise qui les vendent pourtant). Il s’agit d’un bien mondial, probablement d’ailleurs l’un des premier bien mondiaux crée par l’homme (j’ai bien cherché, je trouve pas de contre exemple, help !).

On peut avoir besoin de savoir qui utilise une IP pour deux grandes questions majoritaires : techniques ou légales. Etant donné l’actualité, c’est le coté légal qui intéresse aujourd’hui le plus de monde, la question étant donc de savoir sur qui taper, soit pour identifier un utilisateur, soit pour bloquer un contenu.

La plus simple manière de le savoir, c’est bien sur de demander au dernier maillon de la chaîne qui soit publiquement identifiable, à savoir l’opérateur qui gère le bloc d’adresses qui contient celle qui nous intéresse. Je ne dit volontairement pas « fournisseur d’accès », les acteurs étant à même de fournir des IP étant une famille beaucoup plus large.

Notez que ce billet n’a que peu d’intérêt pratique pour le premier quidam venu. Le fait, pour un opérateur, de révéler à n’importe qui l’identité qui se cache derrière une IP est sévèrement puni par la loi (en France, du moins). Par contre, ça peut satisfaire un peu de curiosité.

Par ailleurs, le fournisseur d’accès ne pourra fournir que les coordonnées de son client. Contrairement à une voiture flashée en plein excès de vitesse, il sera matériellement presque impossible de prouver qui était au commande derrière l’adresse IP, même en récupérant la totalité du flux d’information transmis dans les deux sens, et en tout cas pas sans perquisition poussée avec analyse de contenus de disque dur, etc …

Bon, on sait donc a qui demander. Mais maintenant, comment savoir qui est cet opérateur ?

Les blocs d’adresse IP sont géré, au sommet, par une entité portant le doux nom d’IANA. Elle distribue les blocs à 5 entités mondiales se partageant la planète, les RIR (Regional Internet Registry). Ils sont généralement composés d’opérateurs qui se partagent donc ensuite les blocs attribués par l’IANA. ces opérateurs délèguent enfin une partie des blocs a des clients finaux ou les conservent pour leur usage propre.

Chaque assignation de bloc à un opérateur entraîne théoriquement l’ajout de l’information a un annuaire central géré par le RIR (une base « whois ») qui, entre autres informations, peut donc répondre a la question « quel opérateur gère telle adresse » et aussi, en partie « comment joindre l’opérateur en question ».

Je dis « théoriquement » parce qu’il est tout à fait possible d’utiliser un bloc d’IP sans qu’il ait été attribué ou référencé dans les bases de données, de la même façon qu’on peu tout a fait utiliser le bloc d’IP d’un petit camarade sans lui demander son avis. Nous verrons plus loin qu’il est toute fois possible de retrouver, à posteriori, l’opérateur qui a indûment utilisé un bloc.

Voyons le retour d’une demande whois auprès du RIPE (le RIR européen) concernant une adresse IP prise au hasard. On l’obtient sous n’importe quel OS équipé de la commande whois en tapant « whois -h whois.ripe.net 193.40.32.5″. Il existe aussi des accès aux serveurs whois via le web :

inetnum: 193.40.32.0 – 193.40.32.255
netname: EC-NET
descr: Eurofaculty
descr: University of Tartu
country: EE
admin-c: OT463-RIPE
tech-c: EK618-RIPE
remarks: rev-srv: kadri.ut.ee madli.ut.ee ns2.eenet.ee
status: ASSIGNED PA
mnt-by: EENET-MNT
remarks: Maintainer RIPE-NCC-NONE-MNT removed and object
remarks: LOCKED by the RIPE NCC due to
remarks: deprecation of the NONE authentication scheme.
remarks: Please visit the following URL to unlock this object
remarks: http://www.ripe.net/db/none-deprecation-042004.html
source: RIPE # Filtered
remarks: rev-srv attribute deprecated by RIPE NCC on 02/09/2009

person: Otto Teller
address: Departement of Information Technology
address: Tartu University
address: Ylikooli 18a
address: 50090 Tartu
address: Estonia
phone: +3727375438
fax-no: +3727375460
e-mail: ott[...]t.ee
nic-hdl: OT463-RIPE
source: RIPE # Filtered

person: Erkki Kukk
address: Department of Information Technology Services
address: Tartu University
address: Ylikooli 18a
address: 50090 Tartu
address: Estonia
phone: +372 7 375459
fax-no: +372 7 375460
e-mail: erk[...]t.ee
nic-hdl: EK618-RIPE
source: RIPE # Filtered

% Information related to ’193.40.0.0/16AS3221′

route: 193.40.0.0/16
descr: EENET aggregate
origin: AS3221
mnt-by: AS3221-MNT
source: RIPE # Filtered

Que nous apprend ce résultat ?

• Que l’IP sur laquelle nous avons jeté notre dévolu fait partie d’un bloc de 256 adresses qui a été attribué à l’université de Tartu en Estonie.
• Que la personne en charge des aspects administratifs de la gestion de ce bloc d’adresse porte l’identifiant OT463. Cet identifiant est détaillé plus loin avec le nom, l’adresse postale et email de la personne
• Que la personne en charge des aspects techniques est Ek618 (détaillé, de même, plus loin)
• Que les serveurs DNS à qui sont délégués la gestion des reverses des adresses du bloc sont kadri.ut.ee, madli.ut.ee et ns2.eenet.ee
• Que ce bloc à été assigné à un opérateur membre du RIR (ASSIGNED-PA)
• Suit un avertissement du RIR sans grand intérêt pour ce que nous cherchons
• Suivent les détails des deux contacts mentionnés ci-dessus (il peut y en avoir qu’un seul ou beaucoup plus)
• Et, pour clore le résultat, nous apprenons que ce bloc fait partie d’un bloc plus gros (193.40.0.0/16) qui doit théoriquement être annoncé par le système autonome 3221 qui porte pour doux nom EENET.

Il est capital de se souvenir que ces informations sont présentent dans cette base de donnée parce que les responsable des IP concernées les y ont mis. Ils ne sont soumis, en pratique, à aucun contrôle de la part de qui que ce soit. Il existe donc une probabilité non négligeable que les informations soient incomplètes, erronées, périmées, voir carrément fausses (coucou HADOPI .. Vous comptiez vous baser la dessus pour envoyer les réquisitions aux FAI ? C’est raté ! Mais lisez la suite, je vous sauve plus loin)

Une seconde requête whois sur le système autonome censé annoncer ce bloc donne ceci (j’ai fais un peu de nettoyage pour réduire la taille) :

aut-num: AS3221
as-name: UNSPECIFIED
descr: EENet Autonomous System
descr: Estonian Educational and Research Network
descr: EE
import: from AS1741
action pref=100;
accept ANY
import: from AS2380
action pref=100;
accept AS2380
import: from AS3327
action pref=100;
accept AS3327
export: to AS1741
announce AS3221
export: to AS2380
announce AS3221
export: to AS3327
announce AS3221
default: to AS1741
action pref=100;
networks ANY
admin-c: MIKK1-RIPE
tech-c: PIKK1-RIPE
mnt-by: AS3221-MNT
source: RIPE # Filtered

person: Mihkel Kraav
address: Raekoja plats 14
address: 51004 Tartu
address: Estonia
phone: +372 7 302110
fax-no: +372 7 302111
nic-hdl: MIKK1-RIPE
source: RIPE # Filtered

person: Urmas Lett
address: EENet
address: Raekoja plats 14
address: Tartu 51004
address: Estonia
phone: +372 7 302 110
fax-no: +372 7 302 111
nic-hdl: PIKK1-RIPE
source: RIPE # Filtered

Cette requête nous apprend :

• Que ce système autonome est celui du réseau de l’éducation et de la recherche de l’Estonie (EENET)
• Qu’il est interconnecté avec l’AS174 (Cogent) qui lui fourni du transit (import: accept ANY et export: AS3221)
• Qu’il est aussi interconnecté (probablement en peering) avec AS2380 et AS3327
• Que l’administrateur système qui a renseigné ces informations a fait une typo en tapant « AS1741″ au lieu de « AS174″ dans l’un des champ
• Que les responsables administratifs et techniques sont respectivement MIKK1 et PIKK1 (avec le détail des moyens pour les joindre juste après)

La encore, je souligne que ces informations sont à titre indicatif et non vérifiées (la preuve en est, il y a une typo dedans et ça ne semble émouvoir personne)

Voila donc le résumé de la situation, notre IP d’exemple est gérée (au plus haut qu’on puisse remonter pour taper sur quelqu’un) par l’équivalent en Estonie de notre Renater national, que plus précisément elle est utilisée dans l’université de Tartu et que nous avons les informations de contact d’au moins 4 personnes qui vont pouvoir nous aider si jamais l’IP en question pose un problème technique ou légal.

On peut se dire que l’information « université de Tartu » permet de circonscrire un périmètre géographique très restreint, ce n’est pas forcément vrai dans la mesure ou :

• Si l’opérateur EENET a mal fait son travail, le bloc en question peut très bien être utilisé n’importe ou ailleurs et pas par l’université de Tartu
• Quand bien même le bloc serait bien utilisé par cette université, rien n’empêcherai quelqu’un la bas d’installer un serveur VPN pour propager une ou plusieurs IP n’importe ou ailleurs sur la planète, y compris sur un terminal mobile de la taille d’un paquet de cigarette sur une île paumée au fin fond du pacifique sud.

Comment affiner un peu nos informations ? « traceroute » est notre ami. C’est un outil qui, encore une fois, n’a rien de magique. Il se contente de lister tous les routeurs qui veulent bien se faire connaitre entre la machine ou on le lance et une IP quelconque (notez que traceroute fourni également les temps de parcours jusqu’à chaque routeur mais que je les ai supprimé pour que ça prenne moins de place. Il affiche également les IP et les noms correspondants. Comme pour whois, vous trouverez des versions web de cet outil sans trop de difficultés) :

4 global-crossing-xe-level3.paris1.level3.net (4.68.127.98)
5 DANTE.TenGigabitEthernet7-3.ar1.FRA4.gblx.net (207.138.144.46)
6 so-6-0-0.rt2.cop.dk.geant2.net (62.40.112.50)
7 so-0-0-0.rt1.tal.ee.geant2.net (62.40.112.122)
8 eenet-bckp-gw.rt2.tal.ee.geant2.net (62.40.124.50)
9 trt-fe.bb.eenet.ee (193.40.133.6)
10 ut-gw1.bb.eenet.ee (193.40.133.210)
11 sein.ut.ee (193.40.12.10)
12 ak-gw.ut.ee (193.40.12.14)
13 video.ut.ee (193.40.32.5)

Qu’a-t-on appris ?

• Que l’administrateur qui a rempli la base whois du RIPE a, en plus d’avoir fait une typo, menti, ou plus probablement oublié de mettre à jour ses informations, puisque les paquets sautent directement de l’IP 62.50.124.50 appartenant à GEANT2, AS20965 (le réseau européen de la recherche) à l’IP 193.40.133.6 appartenant à EENET et que ça n’a pas été déclaré au RIPE.
• Que EENET s’alimente en transit international via le réseau GEANT2 puisque notre traceroute, parti de mon petit réseau, a traversé 3 systèmes autonomes avant d’arriver à GEANT2.
• Que les deux derniers routeurs avant notre cible sont déclarés eux aussi comme étant sous la houlette de l’université de Tartu
• Qu’étant donné le supplément de latence entre le dernier routeur et notre cible (de l’ordre de 0.2 millisecondes), il est peu probable que l’IP soit au bout d’un VPN ou alors ce bout n’est pas bien loin du dernier routeur traversé (vous n’avez pas les valeurs de temps de trajet sur mon extrait, il faudra me croire sur parole)

On peut donc valablement supposer que l’IP cible est bien sous la gestion technique de l’université de Tartu. Il conviendra quand même de vérifier en contactant les responsable du réseau EENET si on a réellement besoin de certitude avant, par exemple, de déclencher un raid massif.

Voyons à présent comment partir à la chasse d’IP fantômes qui n’existent pas dans les bases publiques. C’est un peu plus poilu que ce qui précède.

Commençons par le cas ou le bloc en question est toujours annoncé sur internet (par exemple, l’IP cible répond au ping). Il suffit de se rendre sur n’importe quel looking glass (accès direct aux routeurs du réseau, par exemple celui proposé par le RIPE), de taper l’IP dans un appel « show ip bgp », et on obtient, parmi les informations retournée, le numéro de système autonome qui publie, à l’instant même ou on fait la demande, cette IP sur le réseau.

Par exemple, pour l’IP de tout à l’heure (193.40.32.5), on obtient tout un tas de groupes de 4 lignes correspondant aux divers chemins que le routeur que nous avons interrogé connait pour aller joindre l’IP demandée (nous n’en décortiquerons qu’un seul) :

  2895 3058 50139 20965 3221
    193.232.244.36 from 193.232.244.36 (147.45.0.7)
      Origin IGP, localpref 100, valid, external
      Last update: Thu Sep  9

• La première est la liste des systèmes autonomes à traverser pour joindre celui (à la fin) qui annonce cette IP. Nous avons donc bien confirmation que dans la réalité technique, c’est bien l’AS d’EENET qui annonce le bloc comme indiqué au RIPE.
• La seconde donne des indications interne de la route à suivre par les paquets dans le routeur que nous avons questionné.
• La troisième nous informe que ce routeur a appris cette route depuis un autre routeur à l’intérieur du même réseau et qu’elle est externe à ce réseau.
• La dernière nous informe de la date de dernière modification de l’entrée dans la base de donnée du routeur interrogé.

Prenons maintenant un exemple d’un bloc d’IP non autorisé mais présent quand même sur le réseau. Par exemple, à l’heure ou j’écris ces lignes, le bloc 198.51.100.0/24 qui n’est pas censé exister sur internet (c’est un bloc de test) est annoncé par l’AS16953 (Ascent Media Group).

Nous n’obtiendront aucun contact administratif ou technique en demandant aux bases whois, la seule information présente étant « c’est un bloc de test ». Les seuls à pouvoir nous renseigner sont chez l’opérateur en question.

Mais si, après la publication de mon billet, l’opérateur s’aperçoit de la bourde et la corrige (fort peu probable), le bloc disparaîtra instantanément du réseau mondial et il sera impossible de remonter jusqu’à eux en questionnant les routeurs via des looking glass.

Heureusement, des personnes qui s’ennuient au RIPE ont crée un outil fort sympathique prénommé REX qui permet d’obtenir un historique de qui a annoncé quoi et quand sur le réseau sur une période assez impressionnante.

En l’occurrence, REX nous apprends qu’en 2007, un autre opérateur à commis la même bourde sur un préfixe largement plus gros (198.0.0.0/7) qui contient lui-même 198.51.100.0/24, bourde qui a immédiatement été corrigée, alors que celle d’Ascent dure depuis le 4 juin 2010. A se demander d’ailleurs si c’est réellement une bourde ou pas, d’autant qu’une IP du bloc (198.51.100.138) répond au ping.

On peut aussi, via cet outil, trouver les petits malins, par exemple ceux qui ont voulu accéder Saint Graal de tout geek qui se respecte, avoir l’IP 42.42.42.42 (qui fait partie du bloc 42/8, l’un des dernier laissé en réserve actuellement). Les gagnants sont Level3 le 25 mars 2004, Telefonica Espagne le 23 aout 2007, EuroTel Bratislava le 23 janvier 2008, le NOC du département de la défense américain le 27 février 2008 et enfin Telianet qui a fait *la* bourde en voulant annoncer la moitié d’internet en un seul morceau (0.0.0.0/1) le 15 mai 2008. Toutes ces bourdes ont été corrigées le jour même.

Vous voila armé pour briller dans votre prochain diner mondain. Et, si par malchance vous tombez dessus, vous devriez pouvoir être en mesure de trouver un contact technique chez un opérateur qui aurait du contenu que votre morale et que la loi répriment, information que vous pourrez transmettre à qui de droit.

Je me rends compte, à la relecture, que la notation des blocs d’IP (198.51.100.0/24 par exemple) va en dérouter plus d’un. Promis, je ferais vite vite un article la dessus.

On distingue trois méthodes de facturation de la bande passante :

• Au forfait, le fournisseur vous alloue un lien supportant un débit maximal et vous facture un prix fixe mensuel quel que soit la consommation faite sur le lien. C’est le cas de l’ADSL en France.
• A la consommation, le fournisseur regarde, généralement sur un mois, le nombre de bits qui ont circulé sur la liaison et vous facture un prix par bit transféré
• Au débit, le fournisseur utilisant généralement une méthode de calcul en centile.

C’est un terme assez peu connu, mais utilisé un peu partout. Dans le domaine médical par exemple, lors d’une naissance, on dit que la taille du bébé est dans le 70e centile, ce qui veut dire que sur 100 mesures effectuées à la naissance et triées dans l’ordre croissant, le bébé en question serait classé 70ème.

La plus part des fournisseurs facturent selon la méthode du 95e centile mensuel sur un échantillonnage de 5 minutes. Quelques uns ont adopté le 90e centile, plus avantageux pour le client.

Concrètement, un logiciel de mesure stock toutes les 5 minutes la différence de consommation entre l’instant T et la mesure précédente sur un port réseau. Elle obtient donc un débit en bits par tranche de 5 minutes qu’il suffit de diviser par 300 pour obtenir une moyenne de débit en Mbps sur les 5 minutes en question.

A la fin du mois, si on suppose un mois de 30 jours, on a donc obtenu 8640 valeurs de consommation moyenne sur 5 minutes. On trie ces valeurs par ordre croissant, on supprime les 5% (soit, en l’occurrence, 432 mesures) les plus hautes et on facture la valeur la plus haute restante.

De manière pratique cela revient à offrir au client les 432 tranches de 5 minutes ou il a consommé le plus (soit 36 heures pour un mois de 30 jours). C’est absolument inutile dans le cas d’un client qui consomme de la bande passante de façon purement linéaire, mais ce profil est très rare.

Pour prendre un cas concret, vous lancez un site web en grande pompe a grands renforts de pub radio/télé et de conférence de presse, votre trafic va exploser le jour du lancement puis décroitre rapidement avant de se stabiliser à sa valeur « normale » une dizaine de jours après la campagne de communication.

Pour un site s’adressant aux particuliers, les heures de pointes sont généralement entre 11h et 13h et entre 19h et 23h, soit 6 heures par jour, ce qui vous laisse donc 6 jours pendant lesquels votre consommation maximale ne sera pas comptabilisée.

On constate généralement que la facture 95e centile correspond environ a une valeur située entre 55 et 70% des pointes de consommation effectuées et entre 1.5 et 4 fois plus élevé que la consommation moyenne. Si vous aviez choisi une facturation forfaitaire à un débit limité a cette même valeur du 95e centile constatée, votre site aurait tourné au ralenti en moyenne une heure par jour, pile aux heures de pointe, ce qui n’est généralement pas acceptable.

Vous remarquerez, dans l’image ci-dessus, que la consommation maximale effectuée sur le lien (donc la taille indispensable pour que le trafic soit toujours fluide) a été, sur les 30 derniers jours, de 146Mbps, mais que le 95e centile est de 133Mbps, soit 10% d’économie sans souffrir du ralentissement.

Ceci étant, la méthode de calcul est compliquée à expliquer à un client final, elle n’est donc généralement utilisée que dans les relations contractuelles entre opérateurs qui savent déjà de quoi il retourne.

Pour générer le joli graphique ci-dessus, la première chose à faire est de faire des mesures de façon régulière. Il existe tout un tas de logiciels déjà fait pour ça (Cacti, Zabbix, MRTG …) mais je préfère toujours les choses faites à la main. Voici donc comment récupèrer les compteurs d’octets sur les interfaces d’un switch (l’OID SNMP en question est valable pour presque tous les équipements du marché) :

snmpwalk -v 1 -c .1.3.6.1.2.1.2.2.1

Attention, cette commande va vous inonder si votre switch a beaucoup de ports. Vous trouverez, dans l’ordre :

• Les numéro des interfaces (pour vous y retrouver)
• Les descriptions des interfaces (telle qu’elle a été entrée dans l’équipement)
• Le type d’interfaces
• Les MTU des l’interfaces
• Les vitesse des interfaces
• Les adresses MAC des interfaces
• Les statuts administratif des interfaces (activé ou pas)
• Les statuts logiques des interfaces (pour une interface activé, est-ce qu’une machine est allumée au bout ou pas)
• Les temps depuis lesquels les interfaces sont up (le cas échéant)
• Les compteurs d’octets entrants
• Les compteurs de paquets entrants
• Les compteurs d’erreurs entrantes
• La même chose avec le sortant

Tout ceci étant généralement suivi par un tas d’autres infos spécifiques aux équipements que je ne détaillerai pas ici.

Vous voici armé pour connaitre la quantité d’information (octets et paquets) qui circulent sur chaque port de chacun de vos switchs. Notez qu’il peut être pertinent de surveiller le reste et, par exemple, d’envoyer une alerte a qui de droit lorsqu’un port passe du statut UP à DOWN ou inversement.

Maintenant, comment les stocker. Vous pouvez tout bêtement mettre tout ça dans une jolie base SQL mais des gens ont réfléchi au problème de l’historisation du trafic réseau et ont trouvé une façon de faire plutôt sexy : round robin database. Il s’agit de créer une base de donnée d’une taille fixe qui ne bougera pas dans le temps et ou, lorsqu’on est arrivé à la remplir, les données suivantes effacent les données les plus anciennes.

Vous me direz, c’est bien joli, mais si on veut garder les infos 10 ans, il faut d’emblée prévoir l’espace disque pour 10 ans. Oui et non, RRD étant parfaitement capable de gérer une dégradation de la granularité (non, je n’insulte pas votre maman).

Explications : garder 10 ans les infos, c’est très bien, mais dans 6 ans, vous n’aurez probablement pas besoin de connaitre précisément la consommation de tel port sur une période de 5 minutes. Ce qui intéresse généralement les gens du réseau, c’est de pouvoir obtenir un graphique montrant l’évolution de la consommation sur les X dernières années. Il est donc idiot, dans ce cas, de garder 8640 valeurs de mesures mensuelles dans la base de donnée, RRD va donc faire une moyenne de ces valeurs.

Tous les calculs de moyennes sont paramétrables. On peut par exemple lui dire « conserve une mesure par tranche de 5 minutes pendant 6 mois, la moyenne sur une demi heure pendant 2 ans, sur une journée pendant 10 ans, et sur une semaine pendant 100 ans » ce qui, si vous calculez bien, vous donne 51840 + 35040 + 3650 + 5200 = 95730 points de mesure sauvegardés dans la base pour avoir la possibilité d’avoir un graphique sur 100 ans qui ait une belle gueule contre 10512000 points si vous aviez gardé l’ensemble des mesures faites toutes les 5 minutes. Biensur, si vous demandez le graphique d’une journée d’il y a 5 ans, avec ce système, vous obtiendrez un joli pâté qui vous indiquera la valeur moyenne de la bande passante consommée ce jour la.

Evidemment, pour avoir ce beau graphique, il faut encore penser a remplir son fichier RRD toutes les 5 minutes pendant 100 ans, ce qui est probablement impossible. Il faut par ailleurs prendre grand soin des déclaration de ces moyennes, car une fois que le fichier est constitué, il est relativement difficile de revenir sur ces choix.

Une autre fonction présente dès la déclaration de la base RRD, c’est la notion d’historisation des maximas, minimas et moyennes. En effet, conserver la moyenne de débit d’une journée d’il y a 4 ans, c’est bien, mais savoir quels étaient les maxima et minima de ce même jour, c’est encore mieux.

On déclare donc, lors de la création d’une base RRD, plusieurs RRA qui sont les fameux endroit ou seront stockés les données et qui calculerons automatiquement les moyennes.

Enfin, on peut inclure dans une même base plusieurs sources de données, DS

Par exemple :

« –step », « 300″,
« DS:in:COUNTER:600:0:U »,
« DS:out:COUNTER:600:0:U »,
« RRA:AVERAGE:0.5:1:46080″,
« RRA:AVERAGE:0.5:60:43800″,
« RRA:AVERAGE:0.5:360:29200″,
« RRA:MAX:0.5:1:46080″,
« RRA:MAX:0.5:60:43800″,
« RRA:MAX:0.5:360:29200″,
« RRA:MIN:0.5:1:46080″,
« RRA:MIN:0.5:60:43800″,
« RRA:MIN:0.5:360:29200″

C’est une déclaration classique de base RRD pour le trafic entrant et sortant d’un port de switch. Décortiquons :

• On indique pour commencer l’intervalle de temps entre deux mesures. Ici, 5 minutes.
• On déclare ensuite deux sources de données distinctes en leur donnant un nom (« in » et « out »). On indique ensuite que cette source est un compteur et qu’on va donc lui donner une valeur qui ne fera qu’augmenter avec le temps (sauf quand le compteur revient à 0 quand il a dépassé sa valeur maximale) et qu’il faut donc soustraire la valeur précédente à la nouvelle valeur pour trouver la différence. On indique ensuite le temps en seconde après lequel, si on n’a pas mis à jour la base RRD, elle considèrera que la valeur est inconnue et génèrera un trou dans le graphique (ici 10 minutes). Suivent les valeurs minimale et maximale possibles, soit 0 (le débit sur un lien n’est jamais négatif) et U qui signifie unknown, inconnu, et, dans le cas de RRD, illimité.
• On déclare ensuite une première granularité de RRA pour la valeur moyenne (AVERAGE), suivi du facteur XFF qui indique combien il faut de valeurs inconnues pour que, dans le calcul d’une moyenne, le résultat soit inconnu. Ici, on estime que si la moitié des valeurs sont inconnues, alors, le résultat de la moyenne sera inconnu. On indique ensuite combien de mesures sont utilisées pour faire une moyenne (la première déclaration indiquant généralement 1 pour stocker exactement les mesures prises dans le premier RRA). Enfin, on indique le nombre de points de mesure qu’on stock dans le RRA en question.

Comme vous le remarquez, il n’y a donc pas de notion de temps attachées directement au RRA, tout se joue avec le step déclaré au début. Dans mon exemple, le premier RRA stock 46080 mesures sans faire aucune moyenne puisque le nombre de valeur à prendre en compte pour une mesure est de 1. Le step étant de 300 secondes, ce RRA sera valable pour 46080*300 secondes, soit 160 jours. Je vais donc conserver mes mesures exactes à un interval de 5 minutes pendant 160 jours. Notez que rien ne vous empeche de remplir plus souvent la base RRD

Le RRA suivant indique 43800 points de mesure à stocker mais une moyenne de 60 valeurs pour constituer une mesure. Le second RRA aura donc une durée de 43800*60*300 secondes, soit 25 ans et stockera une mesure toute les 60*300 secondes, soit 5 heures. Le dernier RRA aura une durée de 29200*360*300 secondes, soit 100 ans.

Il est important de noter que les RRA ne sont pas successifs, c’est a dire que ces 3 déclarations ne donneront pas une durée de vie de 100 ans + 25 ans + 160 jours mais bien une durée globale égale à la durée du plus grand RRA.

Concrètement, lorsque vous entrez une valeur dans la base RRD, elle va dans le premier RRA et, dans le cas de notre exemple, dès qu’il y a 60 valeurs entrées dans le premier RRA, la moyenne est calculée et constitue la première valeur du second RRA. Une fois que le premier RRA a 360 valeurs disponibles, il renseigne la moyenne de ces 360 valeurs dans le 3ème RRA, et ainsi de suite. Ceci est bien sur valable pour le RRA AVERAGE. Pour le RRA « MAX », ce sera la plus grande valeur des 360 retenues qui sera stockées dans le RRA du dessus, et pour MIN ce sera le minimum.

Il existe tout un tas de façon de créer et de mettre à jour une base RRD. La plus simple est probablement avec les commandes shell, mais vous trouverez des librairies perl, php etc .. En Perl, ça donne, pour la base constituée dans notre exemple :

RRDs::update (« fichier.rrd », « DATE:valeur_in:valeur_out »);

La date en question est idéalement le moment précis ou la mesure à été relevée (et pas le moment ou on met à jour le fichier, ce qui permet de créer un fonctionnement asynchrone, d’un coté les relevés dument horodatés, de l’autre l’alimentation des bases RRD). La date est exprimée au format EPOCH, soit le nombre de secondes écoulées depuis le 1er janvier 1970 à minuit. Si vous ne voulez pas vous enquiquiner à gérer l’horodatage des mesures et que vous êtes certain que la base RRD sera mise à jour juste après la prise de mesure, vous pouvez remplacer la date par « N », la base RRD prendra l’heure sur la machine au moment ou vous la mettez à jour.

Notez que vous devez faire les mises à jour de façon séquentielle. Vous ne pouvez pas insérer la mesure effectuée à 10h05 après avoir inséré la mesure effectuée à 10h20.

Si votre fichier RRD dispose d’une source (une mesure de température, par exemple), vous ne mettrez bien sur qu’une seule valeur après la date lors de la mise à jour.

Je cause, je cause, mais nous n’avons pour l’instant pas généré de joli graphique. Revenons à une commande utilisable en shell :

rrdtool graph demo.gif –title= »Bande passante » –end=now –start=end-3600s \
DEF:ind=fichier.rrd:in:AVERAGE \
DEF:outd=fichier.rrd:out:AVERAGE \
AREA:ind#00FF00:Input bytes \
LINE1:outd#0000FF:Output bytes

On crée ici un graph intitulé « Bande passante », basé sur la valeur moyenne des deux sources in et out définies dans notre fichier RRD. On crée pour cela des définitions de source (DEF) et on leur donne des noms (ind et outd). On dit ensuite qu’on veut dessiner une zone pleine partant du bas (AREA) avec la définition ind et en vert (#00FF00). On lui donne un nom un peu plus explicite. On fait pareil avec outd mais avec une ligne bleue.

Nous obtenons donc un graph avec nos deux valeurs qui termine à l’instant présent et qui démarre à l’instant présent moins 3600 secondes (une heure).

Mais nos amis du réseau préfèrent obtenir des graphs exprimés en megabits bits par secondes, pas en octets. On va donc introduire un peu de mathématique en notation polonaise inversée pour rire un peu. Il s’agit de passer d’o/s à Mbps, donc multiplier les octets par 8 pour obtenir des bits, puis diviser deux fois par 1024 pour passer à des Kbps puis à des Mbps. On modifie donc l’appel à graph comme ceci :

rrdtool graph demo.gif –title= »Bande passante » –end=now –start=end-3600s \
DEF:ind=fichier.rrd:in:AVERAGE \
DEF:outd=fichier.rrd:out:AVERAGE \
CDEF:inbits=ind,8,*,1000,/,1000,/ \
CDEF:outbits=outd,8,*,1000/,1000,/ \
AREA:inbits#00FF00:Input Mbps \
LINE1:outbits#0000FF:Output Mbps

Les lignes CDEF créent de nouvelles sources de données basées sur des sources existantes et précisant le fonctionnement. en l’occurence, le CDEF inbits correspond au DEF ind mutliplié par 8, divisé par 1000, et redivisé par 1000. Si vous n’avez pas eu droit à des cours de notation polonaise inversée à l’école, voyez par ici.

On n’oublie bien sur pas de modifier les directives de graph pour qu’elles dessinent des choses en se basant sur les CDEF et pas sur les DEF.

Pour finir, comment afficher sur ce même graph une ligne rouge pour indiquer le 95e centile ? RRD embarque tout ce qu’il faut pour ca, il suffit de modifier notre demande de graph comme ceci (avec affichage sur un mois) :

rrdtool graph demo.gif –title= »Bande passante » –end=now –start=end-2678400s \
DEF:ind=fichier.rrd:in:AVERAGE \
DEF:outd=fichier.rrd:out:AVERAGE \
CDEF:inbits=ind,8,*,1000,/,1000,/ \
CDEF:outbits=outd,8,*,1000,/,1000,/ \
VDEF:inpct=inbits,95,PERCENT \
VDEF:outpct=outbits,95,PERCENT \
AREA:inbits#00FF00:Input Mbps \
LINE1:outbits#0000FF:Output Mbps

HRULE:outpct#FF00FF \
HRULE:inpct#FF0000 \

La directive VDEF crée une valeur fixe sur le graph et les directives HRULE dessinent la ligne elle-même.

Voila, vous savez à peu près tout ce qu’il faut pour démarrer. RRDTool est une suite d’outils très riche, on peut faire de très jolies choses pleines de couleurs. Allez faire un tour par la pour voir certaines oeuvres. Vous pouvez aussi remonter en haut du présent billet pour voir les statistiques des vélib à Paris. Graph réalisé par mat sur son site dédié à vélib.

Jje me concentre sur FreeBSD, on change pas une équipe qui gagne, mais la théorie doit pouvoir être adaptée sur n’importe quel système d’exploitation libre, y compris sur des gestionnaires de paquets différents de celui-ci, moyennant peut être un peu de scripting supplémentaire.

On peut obtenir assez simplement, en SNMP, via l’OID HOST-RESOURCES-MIB::hrSWInstalledName (.1.3.6.1.2.1.25.6.3.1.2) le listing de l’ensemble des ports installés sur la machine.

Reste ensuite, sur la machine centrale, à communiquer avec tous ces serveurs SNMP pour récupérer les infos. Ici un exemple shell très sale :

snmpwalk -v 1 -c <communaute> <IP_de_la_machine> HOST-RESOURCES-MIB::hrSWInstalledName | awk -F  »  » ‘{ print $4 }’

On peut ensuite faire beaucoup de chose, par exemple stocker tout ça dans une base de données et :

• envoyer des alertes par email lorsqu’une modification de version est détectée
• faire un récapitulatif quotidien de toutes les versions présentes sur le parc avec une mise en évidence des versions présentant des failles de sécurité (données récupérables dans la base de portaudit)

Ceci dit, si vous commencez à jouer avec la surveillance précise des numéros de versions, vous allez vite être embêté et vous allez devoir créer un petit script qui sera lancé par SNMP sur une OID privée rien que pour vous ou vous mettrez les infos qui vous intéressent.

Ayant déjà déployé puppet (administration centralisée de parc) et nagios (monitoring) avec son fidèle compagnon nrpe (qui sert à remonter à nagios les résultats de plugins locaux sur les serveurs), je cherchais un moyen simple de centraliser les informations hardware & software de l’ensemble de mes ouailles.

Le principe adopté est un peu barbare mais a l’avantage de ne pas avoir a déployer d’autre logiciel.

Il se base sur les résultats fournis par dmidecode, qui contiennent, entre autre, le numéro de série de la machine, la composition hardware et tout un tas d’infos rigolottes.

Puppet, quant à lui, retourne déjà, via facter, pas mal d’informations sur l’OS installé. Il parle déjà avec dmidecode mais n’en extrait pas toute la quintessence.

L’idée était donc d’apprendre à facter a discuter un peu plus avec dmidecode pour qu’il retoune l’ensemble des infos que je voulais. En se basant sur les scripts existants pour facter, j’ai donc crée un dmidecode.rb dans le dossier /usr/local/lib/ruby/site_ruby/1.8/facter :

# dmidecode.rb
# Facts related to hardware
#
#

require ‘facter/util/manufacturer’

query = {
‘(Chassis Information|system enclosure or chassis)’ => [
{ 'Power Supply State:' => 'powersupply' },
{ 'Thermal State:' => 'thermalstate' },
{ 'Height:' => 'racksize' }
],
‘Processor Information’ => [
{ 'Family:' => 'CPUfamily' },
{ 'Current Speed:' => 'CPUspeed' },
{ 'Version:' => 'CPUversion' }
],
}

Facter::Manufacturer.dmi_find_system_info(query)

Vous pouvez aussi patcher directement le fichier manufacturer.rb, mais je préfère quelque chose qui ne risque pas d’être écrasé par une mise à jour ultérieure de facter.

Vous remarquez très bien, même si, comme moi, vous n’êtes pas un grand amateur de ruby, qu’on retrouve assez vite ses petits dans le script en question.

Admettons que vous vouliez, en plus, récupérer le mode de fonctionnement du cache, vous ajouteriez un ‘Cache Information’ => [ {''Operationnal Mode:' => 'CacheMode'}],

Une fois que ceci est fait, si vous lancez facter, vous y trouverez les nouvelles infos demandées, pour peu que dmidecode les retourne lui-même, en l’occurrence, pour ma part, je cherchais l’état des alimentations, de la température interne, la hauteur du châssis, le type, la version et la vitesse du CPU.

Vous me direz « fort bien, facter retourne les infos, et maintenant, comment on les centralise ? ». Si vous avez bien développé votre infrastructure puppet, il doit y avoir moyen de les récupérer directement via le puppet central. Pour ma part, je souhaitais que cet outil fonctionne même si puppet était HS, j’ai donc ajouté, dans la configuration de nrpe, une simple petite ligne :

command[facter]=/usr/local/bin/sudo /usr/local/bin/facter -y

et, pour que dmidecode puisse récupérer toutes les infos, dans le /usr/local/etc/sudoers

nagios ALL=NOPASSWD: /usr/local/bin/facter

Vous pouvez être tenté, si facter retourne beaucoup d’infos, de faire un grep dans l’appel situé dans la configuration nrpe, celui-ci limitant a je-ne-sais-combien-de-caractères la réponse qu’il fourni. Le -y force facter à faire une réponse en YAML, plus simple à parser par la suite.

Pour finir, un petit script central, sur la même machine que votre nagios, ira tour a tour questionner toutes les machines et consigner les résultats en base de données (ou générer une alerte, dans le cas d’une alim HS par exemple) via un simple appel :

/usr/local/libexec/nagios/check_nrpe -H IP_de_la_machine -c facter

Evidemment, pour que tout ça fonctionne, il faut déjà avoir une base de données avec le listing de ses machines.

Toutes ces configurations peuvent être faites directement par puppet, évitant ainsi un long et laborieux déploiement.

Comme je l’expliquai dans un billet précédent sur lequel je n’arrive plus à remettre la main, le réseau est une poupée russe géante dans laquelle un nombre assez impressionnant d’acteurs revendent les prestation de celui qui est un peu plus gros à celui qui est un peu plus petit.

Il en va de même pour l’hébergement. Pour faire de l’hébergement, matériellement, il vous faut un réseau (voir la série sur comment devenir FAI) et des machines branchées à ce réseau. Le coeur du métier de l’hébergement étant de savoir s’occuper des-dites machines pour qu’elles puissent restituer le contenu des sites webs aux visiteurs.

Mais si vous savez parfaitement administrer un serveur, vous n’êtes peut-être pas spécialiste en génie climatique, vous n’avez peut-être pas envie d’avoir un réseau à gérer, vous n’avez peut-être pas la surface financière nécessaire à l’achat ou à la location de serveurs, etc …

Vous allez donc passer par des intermédiaires. La question étant de savoir quels métiers vous souhaitez internaliser pour pouvoir être complètement indépendant et quels métiers vous pouvez confier à des prestataires :

• Le stockage du matériel
• Le réseau
• L’achat ou la location du matériel et son entretient
• La surveillance 24h/24 et 7j/7 du matériel et des fonctionnalités logicielles
• L’administration des applications (sécurité, évolution, …)

La question principale pour trancher étant « quelle est ma valeur ajoutée ? ». Le fait de tout internaliser n’est pas forcément un gage de qualité et inversement. Vous pouvez tout à fait sous traiter l’ensemble de ces 5 parties de prestation et apporter tout de même une valeur ajoutée qui serait, par exemple, le fait de prendre le client par la main de A à Z sans qu’il n’ait a se soucier de rien. Il fait créer son site, donne votre nom à la personne qui a crée le site, et c’est tout. C’est le premier échelon que je ne détaillerais pas dans cette série puisqu’il est tout simple, vous prenez une offre mutualisée chez le premier hébergeur venu, vous achetez le nom de domaine pour le client, vous envoyez le site en FTP, vous créez les comptes emails sur l’interface de l’hébergeur, et c’est fini.

Ça parait simple et ça l’est, mais il y a quand même quantité de gens qui sont content de payer pour ne pas avoir à faire ça (et surtout de payer pour qu’au moindre problème ils n’aient pas à passer 5 heures pendus au téléphone)

L’étape suivante, c’est de donner un nom à son ordinateur pour que les gens puissent le trouver. Ce sera l’objet du second volet de la série.

Mon archive d’emails approchant les 23Go et remontant à une bonne douzaine d’année pour certaines boites, je vous laisse imaginer mon état de nerf. Pour bien continuer, monsieur backups & serveurs de mail (qui se trouve être la même personne) venait de partir en vacances.

Me voila donc parti à la recherche de mes emails dans le serveur de backup. Je vous passe l’article sur l’utilisation quelque peu déroutante de Bacula (qui demeure un très bon produit quand on sait lui parler au creux de l’oreille et qu’on est patient), j’ai fini par réussir à lui faire recracher mes 23Go d’emails sur le serveur mail dans un dossier différent pour pouvoir travailler calmement dessus sans risquer de perturber le fonctionnement du serveur de mail (ben oui, je bosse un peu a coté, quand même)

La problématique étant la suivante :

• Si je recopie bêtement les emails du backup par dessus les dossiers actuels, au mieux je perd l’ensemble des statut des nouveaux emails datant d’après le backup (lu, répondu, …), au pire, je mélange tout, chaque email étant stocké avec un numéro à partir de 1 et je n’ai strictement aucune idée de si par hasard Cyrus ne se met pas a recompter à partir de 1 en cas de boite vidée (ce qui a été le cas d’une grosse quantité de boite)
• Si je met le backup dans un sous dossier de mes dossiers actuels, c’est déjà une bonne chose de faite, mais je ne les vois pas pour autant dans le logiciel de courrier

La solution est un peu alambiquée mais elle fonctionne :

• Créer un dossier « Backup » via le logiciel de courrier
• Y copier le backup de l’utilisateur en console sur le serveur mail
• Lancer la commande cyrus « reconstruct -fr user/<nom_d’utilisateur> » (reconstruct se trouve avec les autres binaires de Cyrus, chez moi /usr/local/cyrus/bin)
• Aller se prendre un café, ca peut prendre un moment
• Lancer son logiciel de courrier et s’abonner à toutes les boites IMAP nouvellement trouvées par Cyrus (Thunderbird a eu du mal a me laisser faire, j’ai du terminer sur un webmail, il y avait semble-t-il trop de boites a son gout)
• S’apercevoir qu’on a perdu tous les statuts des mails récupérés par le backup
• Réimporter une seconde fois le backup au même endroit que la première fois (pour retrouver les statuts, maintenant que Cyrus a retrouvé l’arborescence de boites)
• Déplacer les emails des boites situées  dans le dossier « Backup » vers les boites réelles qui ont été vidées avant la catastrophe (c’est finalement ça qui prends le plus de temps)

Si vous avez eu la chance d’avoir complètement perdu votre serveur mail et donc de ne pas avoir une version des boites avec des vieux mails et une version avec des anciens, c’est plus simple, vous pouvez restaurer votre backup à la racine de la boite utilisateur et vous éviter la dernière phase qui reste la plus fastidieuse, surtout si vous avez des boites avec 68000 emails comme moi.

Bilan des courses, quelques 1.161.000 emails sauvés ! Du coup, j’ai fais du ménage et j’en ai jeté pas loin de 250.000.

Dans la vrai vie, quand vous signez un document avec votre stylo, toute personne qui va voir le document avec la signature en bas va, par défaut, considérer que ce n’est pas un faux, et pour les plus paranoïaques, iront verifier dans un fichier quelconque pour comparer les deux signatures.

Dans le monde de l’informatique, une signature est une suite imbitable de chiffres et de lettres et il ne suffit pas d’enchainer des chiffres et des lettres après un message pour faire croire au destinataire que le message est signé. Pas non plus question d’utiliser toujours la même suite de caractères si on communique avec plusieurs personnes, n’importe qui pouvant la copier/coller dans un email.

On utilise donc un système né presque en même temps qu’Internet qui est constitué de clés asymétriques (voir l’article Wikipedia sur le sujet). De façon très grossière, ce que l’une des deux clés a chiffré ne pourra être déchiffré que par l’autre clé. Le proprietaire de la clé asymétrique garde la partie privée de la clé pour lui et distribue la partie publique.

Partant de la, l’utilisation première de ce système est de permettre à quiconque de chiffrer un message en utilisant la clé publique de son correspondant pour empêcher quiconque intercepterai le message en question de le lire, puisque seul le titulaire de la clé privée correspondante pourra déchiffrer le message.

Mais on peut aussi l’utiliser pour signer, si on passe un message sans sa propre clé privée, seul la clé publique pourra le déchiffrer. C’est a dire que n’importe qui pourra le faire mais cela veut aussi dire que si la personne qui le fait est certaine que la clé publique qu’elle détient viens bien de vous, elle s’assure par la même occasion que le message en question est bien de vous aussi.

Les chiffrements et signatures de messages sont très utilisées par email ou on procède généralement a des cérémonie de signature ou chacun vient avec sa pièce d’identité pour attester qu’il est bien qui il prétend être et fourni aux autres participants le moyen de retrouver a coup sur sa clé publique.

Mais c’est aussi utilisé chaque jour pour le web, le protocole https:// bien connu des boutiques en lignes et autres banques émet, au début de la connexion, la clé publique qui permettra aux visiteurs de déchiffrer les pages web et de chiffrer les réponses envoyées au serveur (cette clé étant elle-même signée par une autre clé dans laquelle le navigateur a, par défaut, confiance)

Mais on peut aussi faire des choses très rigolotes avec les signatures. Imaginez que je vous envoie un email en le signant (attention, ça fait du bruit) :

----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Oh le joli mail signé !
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla

iQEcBAEBAgAGBQJMUzq5AAoJEC1hvjYyHGwWdIIH/RwaeeORO5
7av8zSYX6kCoSpElpCZuLZRbLeOSdaKCa+likLvtF61rjXOz+1
L39/RthSf4wvUDdDsiBmmXfxHpkCsotpV873PJBikuPl3pSx+U
CQMXiDS9QO4adH6sjupfE4igV8YniY9+abZoGW92wqaNkeM6DV
ElD1ykFHUhzkO0/zX0CkFKuIiC8A38TJQx8J+hd2d0Q/U5py0f
UWbi3xzKQerh4N5KPNM6EUIWtvmlCZjCeM8HOCn6h8q0es4ffe
FaBlmuognbDcCwNCzGTrbw+V0aH7N8QV+pv2labVjILoJEYpe5
qG9wlYBHOlCMol05AIwlrdqIlDRfl61oE==0fax
-----END PGP SIGNATURE-----

et que vous souhaitez le renvoyer a votre patron en y ajoutant vous même votre propre signature. Votre patron recevra donc un texte avec deux signatures. La votre qu’il connait puisqu’il a votre clé publique et la mienne qu’il ne connait pas mais a qui il va quand même faire confiance puisqu’il a confiance en vous.

Nous y sommes, c’est le principe de fonctionnement de DNSSEC (voir mon article sur comment fonctionne le DNS si vous êtes perdus maintenant). Sur mon serveur, je vais creer une signature pour mes petits noms à moi que je vais fournir à Gandi qui s’occupe d’enregistrer mon nom de domaine et qui sait que je suis bien moi.

A partir de la, Gandi va faire en sorte que ma signature spyou.org soit signée par org qui elle-même va être signée par la signature racine, celle la même dont on parle depuis le début de la semaine et qui vient de pointer le bout de son nez le 15 juillet dernier.

Une personne qui va donc venir demander à mon serveur DNS « qui est blog.spyou.org » va pouvoir suivre la succession de signatures imbriquées les unes dans les autres jusqu’à la racine qui est le seul point de confiance que tout le monde aura ces prochaines années.

Vous me demanderez sans doute « mais avant, on faisait comment ? » ben on faisait pas, on avait bêtement et aveuglément confiance dans la réponse reçue lorsqu’on posait une question et tout un tas de gens pouvaient faire des choses pas très nettes au milieu. Qu’ils se rassurent, vu l’engouement général pour DNSSEC actuellement, ils ont encore de beaux jours devant eux.

L’autre question qu’on me pose souvent, c’est « c’est vraiment sécurisé ». La réponse se trouve dans les mathématiques, plus précisément dans les fonction à sens unique. Les clés de chiffrement asymétriques utilisent une simple factorisation de nombre premiers. Par exemple, 953 et 1409 sont deux nombre premiers et constituent votre clé privée. Votre clé publique, c’est 953*1409=1342777. Les mathématiques d’aujourd’hui ne savent pas retrouver les deux nombres premiers multipliés dans 1342777. (en vérité, c’est faisable avec deux nombres juste en tâtonnant, mais les clés utilisées en contiennent beaucoup plus)

Crédit : ShimShamB

Alors on pourrait très bien imaginer le scénario « simple » qui consiste à décider d’un jour ou on éteindra le vieux réseau IPv4 et ou on allumera l’IPv6, mais ce n’est qu’un doux rêve et on préfère depuis plusieurs années parler du nouveau réseau IPv6 qui cohabite avec l’ancien réseau IPv4.

Mais d’abord, IPv6, c’est quoi ?

• Un changement de notation des adresses IP qui passent d’un système à quatre octets, chacun des 4 nombres d’une IPv4 etant en réalité un octet, codé sur 8 bits, et pouvant donc prendre une valeur allant de 0 a 255, à un système à 16 octets noté deux par deux sous forme hexadécimale.
  Concrètement, une IPv4 est de la forme 194.117.200.10 mais pourrait aussi être noté sous la forme C2.75.C8.0A
  Pour une IPv6, étant donné la longueur, la notation décimale rallongerai encore la sauce, il à donc été décidé d’utiliser la notation hexadécimale et de remplacer les . par des :  et nous obtenons donc quelque chose du type 2A01:0563:0000:0000:0000:4D6F:0660:AB32. Pour simplifier encore la notation, on a décidé de retirer les 0 situés après les : et même de faire disparaitre tous les groupes de quatre 0 consécutifs, ce qui nous donne 2A01:563::4D6F:660:AB32 ce qui reste tout de même plus difficile à retenir que les bonnes vieilles IPv4.
• Corollaire de l’allongement de la taille des IP, le nombre d’IP disponible est sans commune mesure avec IPv4. On comptait avant le nombre d’adresse disponibles globalement en milliers de milliards. Il s’agit a présent de millions de milliards  d’adresses … par millimètres carrés de la surface terrestre. Autant dire qu’on n’en a pas vu le bout.
• On découpait les IPv4 en petits bouts pour les allouer à des réseaux physiques. Le plus petit étant un groupe de 4 adresses, les plus gros en comportant plusieurs milliers. On ne s’embête plus avec ces découpages vu le nombre d’IPv6 disponibles, il a été convenu que les 8 premiers octets définissaient le réseau et que les 8 derniers définissaient la machine dans le réseau. Conséquence immédiate, lorsque vous avez un sous réseau IPv6 chez vous, vous avez 2^8 fois plus d’adresses à votre disposition que sur le réseau IPv4 actuel dans sa globalité. Vous allez pouvoir en brancher, des équipements.
• Corollaire du colossal nombre d’adresses disponibles pour le réseau final, plus besoin de faire de la translation d’adresses avec des IP privées.
• Un tas de petites nouveautés discrètes permettrons, à l’avenir, des applications assez intéressantes en terme de sécurité et de mobilité.

Tout ce qui existe aujourd’hui sur IPv4 devra donc, pour la bonne santé du réseau, se retrouver un jour ou l’autre sur IPv6. Le présent blog est présent sur les deux réseaux, mais pas en double, non, c’est simplement le serveur sur lequel il est hébergé qui dispose d’une adresse IPv4 et d’une adresse IPv6.

Crédit : markuz

Concretement, qu’a-t-il fallu faire pour que ce blog soit disponible en IPv6 ?

1. Assurer au serveur qui l’héberge une connexion au réseau IPv6. C’est la partie la plus ardue. J’ai l’avantage d’avoir eu la bonne idée de poser cette machine sur un réseau que  je co-gère avec quelques autres personnes et nous sommes assez friands de nouveautés, le réseau a donc assez tôt supporté IPv6. Mais pour en arriver la, il a fallu s’équiper de routeur supportant IPv6, revoir les configuration des firewall et négocier les conditions d’interconnexion au réseau IPv6 avec nos fournisseurs (choses simples et peu couteuses, étant donné la taille du réseau, mais qui peut revenir très cher et durer très longtemps à l’échèle d’un gros opérateur)
2. S’assurer que les logiciels tournant sur ce serveur fonctionnaient avec IPv6, ce qui est le cas de la plus part des logiciels libres disponible en ce bas monde, mais c’est moins sur pour les logiciels commerciaux, certains devant être revus de fond en comble
3. S’assurer que le serveur DNS qui répond pour blog.spyou.org était en mesure de renvoyer une adresse IPv6 aux visiteurs en faisant la demande (la encore, le logiciel libre est un allié de poid)

Et .. C’est tout. Mais c’est relativement simple puisque le site en lui-même est simple. Lorsque vous interposez en plus un firewall, que vous avez une base de donnée distante, etc .. C’est un cauchemar. Ajoutez à cela une structure technique maitrisée par X personnes différentes et autant de sous traitants, vous n’en dormirez pas pendant des semaines, c’est garanti.

Seulement, c’est bien beau d’avoir du contenu en IPv6, encore faut-il avoir des visiteurs qui puisse y accéder.  La théorie des ensembles est drastique. On peut très bien faire rentrer tout IPv4 dans IPv6, il y a largement la place, mais pas l’inverse. Impossible donc, lorsqu’on a qu’une IPv4, d’accèder à un contenu situé sur un serveur qui n’a qu’une IPv6. Ceci nous oblige donc  aujourd’hui, et tant qu’un nombre très conséquent d’utilisateur n’auront pas d’IPv6, a adresser en double tous les serveurs. La consommation galopante d’IPv4 continue donc.

Pire encore, certains freinent des 4 fers pour ne pas qu’IPv6 arrive trop vite, arguant que si le réseau IPv6, encore trop jeune à leur gout, a un problème, leur business risque d’en pâtir. C’est par exemple le cas de Google qui propose depuis longtemps ses services en IPv6 mais uniquement à certains fournisseurs dument sélectionné et audités pour être bien certain que Google marchera toujours pour les utilisateurs de ces fournisseurs d’accès.

Nous sommes donc encore aujourd’hui dans l’ère ou IPv4 est favorisé et IPv6 est un jouet alors que ce devrait être l’inverse. Il n’y a pourtant besoin que de l’impulsion de quelques géants d’Internet pour que cet état de fait change, mais les sommes en jeu sont trop grandes, et pourtant si petite par rapport à la perte qui va arriver de façon très abrupte quand on va dire « non monsieur, désolé, il n’y a plus d’IPv4″

Le principe de Sflow, c’est quoi ? Plutôt que de faire des statistiques sur l’ensemble du trafic qui traverse un routeur (par exemple en dupliquant ce trafic pour l’envoyer vers une machine qui va l’analyser, chose impossible a faire lorsqu’il commence a y avoir des Gbps de trafic) on va s’autoriser une marge d’erreur dans notre analyse en ne traitant qu’un paquet tous les X paquets.

Nos petits routeurs vont donc envoyer, par exemple, un paquet sur 1000 à la machine chargée du traitement. Evidemment, sur un trafic faible, ça ne donne rien de bon, mais lorsqu’il est conséquent, on obtient des statistiques qui, en les multipliant par 1000, donne une idée assez fiable (a 2 ou 3% près) de ce qui se passe en réalité.

J’ai très vite laissé tomber l’idée de coder un collecteur sflow moi même. Il y en a de très bons et j’ai, pour ma part, opté pour le package pmacct dans lequel on trouve sfacct. L’idée du collecteur est de faire une zone tampon entre les flux de données reçues des routeurs et le bout de code qui va l’analyser.

pmacct permet de faire une première agrégation des données reçues dans plusieurs files (IMT) stockées directement en ram. Par exemple, dans mon cas, j’ai une file qui va agreger les informations en fonction de l’AS source ou destination, me permettant d’analyser la consommation du réseau avec mes voisins, un autre également par AS source et destination mais en séparant les adresses mac destination et source, permettant de savoir, sur un lien précis, quels sont les AS source et destination qui passent par la, et enfin, une file ou je n’agrege rien pour pouvoir avoir la granularité d’information la plus fine.

Concretement, la config donne ca :

plugins: memory[dasm], memory[sadm], memory[das], memory[sas], memory[detail]
aggregate[dasm]: dst_as, src_mac
aggregate[sadm]: src_as, dst_mac
aggregate[das]: dst_as
aggregate[sas]: src_as
aggregate[detail]: src_host, dst_host, src_as, dst_as, src_mac, dst_mac
imt_path[dasm]: /tmp/dasm.pipe
imt_path[sadm]: /tmp/sadm.pipe
imt_path[das] : /tmp/das.pipe
imt_path[sas] : /tmp/sas.pipe
imt_path[detail]: /tmp/detail.pipe
syslog: local5
pidfile: /var/run/sfacctd.pid
sfacctd_renormalize: true
sfacctd_port: 5476
plugin_pipe_size: 102400000
plugin_buffer_size: 102400
imt_mem_pools_number: 12800

Il faut bien prévoir les trois dernières valeurs : Trop haut, vous allez bouffer toute la mémoire dispo, trop bas, vous aller perdre des informations.

Ensuite, on récupère les données de chaque IMT avec /usr/local/bin/pmacct -s -e -p /tmp/dasm.pipe. Il suffit ensuite de les traiter, toutes les X minutes, pour en faire ce qu’on veut :

• des fichiers RRD
• des alertes opérationnelles (quand on dépasse un certain nombre de paquets par seconde, par exemple)
• de l’accounting client (quand par exemple un même client a plusieurs IP sur une machine et qu’il est question de facturer le trafic différemment par IP)

Pour ma part, trois scripts perl fournissent des stats sur :

• Le trafic global de chaque AS client situé derrière notre réseau
• Le trafic global a destination des 50 AS extérieurs au notre avec lequel nous effectuons le plus de trafic
• La ventilation détaillée par client de chaque lien de transit et de peering
• La ventilation par AS distant de chaque lien de peering
• Les IP/AS qui consomment le plus grand nombre de paquets par seconde pour faciliter la pose de nullroute en cas d’attaque

Solution magique trouvée a l’occasion, à base de perl, a appliquer sur les fichiers mailbox de Thunderbird :

sed -e ‘s/^From ???@???/From -/’ FICHIER_SOURCE > FICHIER_DESTINATION