Mon Samsung r780 vient de fêter ses 4 ans. 4 ans en informatique, c'est entre 2 et 4 générations. Autant dire qu'on pourrait presque le voir comme obsolète. Pourtant, il n'a pas à rougir avec ses 4Go de RAM et son double cœur i5.

J'utilise clavier, souris et écran externe, l'intérieur est donc quasi neufs. La batterie aussi étant donné qu'elle n'est pas connectée. Néanmoins, avec le temps, il commence à chauffer énormément, en été comme en hiver provoquant des coupures de sécurité intempestives. Ce point là a été réglé avec une bombe d'air (5€-8€) : un coup à chaque entrée/sortie d'air disponible et c'est reparti ! Il faut cependant faire attention à bien garder la bombe à la verticale, sinon le gaz se liquéfie ! (obligé de passer un coup de séchoir avant la remise sous tension).

Autre point très Très TRÈS désagréable : le wifi. Sa gestion est catastrophique sous Linux. Deux murs fins suffisent pour avoir des déconnexions et un débit plus que réduit, alors que c'est à peu près correct sous Windows (et parfait via un smartphone)... Les derniers firmware de Debian (firmware-realtek dans non-free) semblent plus stables, mais le débit est toujours anémique.

Dernier goulot d'étranglement : le disque dur. À 5400tr/min, il fait pâle figure face à la dernière génération de SSD. Plusieurs options d'amélioration sont possibles :

• Acheter un disque 2.5" à 7200tr/min ou 10000tr/min : pas facile à trouver et consomme plus.
• Utiliser uniquement un SSD : la fiabilité d'un SSD dans le temps est encore à prouver. De plus, les gros SSD sont chers.
• Coupler un SSD (pour le système) avec un disque externe (pour les données) : ça prend de la place, une alimentation et un port USB (il n'en reste qu'un de libre), ou utiliser le port eSata.
• Coupler le disque avec un SSD en cache (intégré ou via une carte d'extension).

C'est la dernière solution que j'ai retenue. Les SSD au format ExpressCard ne sont quasiment plus fabriqués, j'ai donc opté pour la solution du SSHD (Seagate Momentus Laptop thin). Pour 60€, j'ai 500Go de disque (contre 640Go) avec un cache SSD de 8Go. Vous allez me dire : 8Go, c'est rien. Le minimum du minimum chez les SSD c'est 64Go. Certes, mais la vraie question est : est-ce que le système + les logiciels utilisés fréquemment tiennent dans ces 8Go ? Si on ne joue pas, la réponse est oui ! Bien sûr, les accès hors cache (directement depuis le disque) seront toujours aussi lent, mais 80% de mon utilisation passera par le cache SSD !

Pour préserver la licence de Windows, je choisis de faire un simple dd et là, c'est le drame : le nouveau disque est plus petit que l'ancien, donc la table des partitions a des références hors disque. Les mauvais BIOS bloqueront à cette étape. En passant par un live USB, je rétabli la table des partitions. Une fois passé cette longue copie, c'est au tour de la ré installation de GNU/Linux. La dernière fois, c'était il y a 4 ans, je ne suis donc pas forcément au fait de ce qui s'est passé depuis. Alors, quand on me parle de LVM, des VG, des PV et des LV, je suis complètement perdu !

En fait LVM (Logical Volume Manager) n'a rien de très compliqué. Il permet d'abstraire des Volumes Physiques (PV) au sein de Groupes de Volumes (VG), pour en exporter un ou des Volumes Logiques (LV). C'est une "vieille" technologie héritée des serveurs qui, eux, manipulent de multiples espaces de stockage. On ne travaille plus qu'avec des volumes virtuels auxquels on peut ajouter/retirer des volumes physiques, faire des sauvegardes, faire du RAID... Les deux points qui m'intéressent particulièrement sont de 1) Chiffrer le volume et 2) Avoir du RAID. J'aurais aussi pu utiliser BTRFS qui intègre toutes ces fonctionnalités dans son cœur, mais je trouve plus élégant d'utiliser des couches séparées (stabilité, portabilité...). Pour l'anecdote, la première implémentation pour Linux date de 1998, mais sa popularité sur les machines personnelles est toute récente.

Chiffrer le disque est surtout utile en cas de perte/vol de l'ordinateur ou si on pratique des activités illégales et qu'on s'attend à recevoir la police pour dîner (ce qui n'est pas mon cas). Le RAID, quant à lui, permettra (dans l'avenir) de monter un serveur de sauvegarde en utilisant le SheevaPlug (ou une CuBox ?) ! En effet, les NAS sont hors de prix alors qu'on peut faire du RAID logiciel qui ne requiert pas un très gros débit pour juste de la sauvegarde.

Bref, je configure un groupe de volumes de 100Go qui va exporter les volumes logiques "system" et "swap" ainsi qu'un groupe de 250Go qui exportera home. "system" sera chiffré avec un mot de passe (au démarrage), "swap" avec une clé aléatoire et "home" avec une clé dans un fichier (/etc/luks-keys/home). Fichier qui sera lui même sauvegardé dans un autre endroit (après avoir été chiffré avec GPG) afin de pouvoir récupérer les données en cas de problème avec le volume "system". Cette configuration a l'avantage de ne demander le mot de passe qu'une seule fois tout en permettant de monter "home" depuis un autre système (si on possède le fichier de clés).

/boot sera (pour la première fois) une partition à part et non chiffrée (n'ayant pas de BIOS UEFI qui supporte une table des partitions GPT...). Petite blague : le noyau a pris de l'embonpoint et il est nécessaire d'augmenter la taille de la partition (200Mo), là où 20Mo suffisaient jadis.

Pour toutes les manipulations, il y a une procédure très bien expliquée sur le wiki d'ArchLinux. J'ai quand même dû rajouter l'option "rootdelay=1" à la ligne de commande au démarrage (il faudra vraiment que je règle le problème sans passer par ce bidouillage).

Dernier point : les systèmes de fichier utilisés. Comme on a un SSD, il faut éviter de trop écrire dans le cache, donc éviter autant que possible les systèmes de fichier journalisés, surtout sur /boot et / (qui risquent fortement de se retrouver dans le cache), ajouter les options "noatime" et "nodiratime" lors du montage des partitions, utiliser un maximum de parties du système en RAM (/tmp, /var...), ainsi que mettre le swappiness à 0 ("vm.swappiness = 0" dans /etc/sysctl.conf) afin de réduire au maximum l'utilisation du swap (qui risque aussi de se retrouver rapidement dans le cache SSD).

À vue de nez, l'utilisation courante semble deux à trois fois plus rapide (pari gagné). Je pense qu'on pourrait gagner encore sans LVM ni chiffrage (le noyau implémente un algorithme AES générique : pas d'accélération/optimisation matérielle). C'est aussi l'occasion de passer à Nouveau : il est un peu plus lent que les pilotes NVIDIA, mais il fait le job. Pour mon utilisation il suffit amplement.

Conclusion : pour ~70€, j'ai retrouvé un ordinateur qui tient tout à fait la route, au moins pour quelques années !

Wireshark (previously Ethereal) is the best open source protocol dissector/analyzer. You can analyze an incredible amount of protocols, not only Internet ones, but every stream based protocols. Moreover you can add your own filters/dissectors written either in C or in Lua. Nevertheless, the documentation on the net concerning Lua dissectors is light and sparse. It's been hard for me to make something that works even if it's, at the end, not really complicated. I'll try to explain the basis of Lua dissectors.

1) Installation

You need to have a wireshark that supports Lua support (wireshark -v). After that, create or edit ~/.wireshark/init.lua. To load a new plugin, just type

dofile("mydissector.lua")

Create the new file ~/.wireshark/mydissector.lua

2) Post Dissector

There are three types of dissectors :

• Dissector : you add your own protocol
• Chained dissector : you add new fields to an existing protocol
• Post dissector : you interact after all packets has been parsed

An example for each of one can be found here. I'll describe a post dissector, but other types of dissectors has pretty the same format.

Tip 1
If you want to display someting on the console, just do

print(something)

Tip 2
If the base array is not defined, add this to ~/.wireshark/init.lua

-- Display Bases
 base = {
    ["NONE"] = 0,
    ["DEC"] = 1,
    ["HEX"] = 2,
    ["OCT"] = 3,
    ["DEC_HEX"] = 4,
    ["HEX_DEC"] = 5,
}

First, you need to define your protocol : Proto(<internal name>, <displayed name>)

p_dummyproto = Proto("dummyproto","DummyProto")

Then, define your fields : ProtoField.TYPE(<internal name>, <displayed name>, [base], [values], [mask])
TYPE are defined here

-- Simple field without value
local f_X =  ProtoField.uint16("dummyproto.f_X","Field X")
-- Simple field displayed in hex format
local f_Y =  ProtoField.uint8("dummyproto.f_Y","Field Y", base.HEX)
-- Field with precomputed values and bitfield
local VALS_ZZ    = {[0] = "Single", [1] = "Dual"}
local f_Z =  ProtoField.uint8("dummyproto.f_Z","Field Z", base.HEX, VALS_ZZ, 0x3)

Third step is to register each field

p_dummyproto.fields = {f_X, f_Y, f_Z}

After that, the big part : protocol dissection. Fields are organized as a tree. You have to parse each byte (or range of bytes) in the given buffer and append your fields. Be careful : objects returned by :add function has userdata type and cannot be directly manipulated.

function p_dummyproto.dissector(buffer,pinfo,tree)
   -- Access to another field
   local f_udp_port = Field.new("udp.port")

   -- If it exists and has the right value
   if f_udp_port and tostring(f_udp_port) == tostring(5555) then
     -- Add our protocol dissection with data in buffer[17, 17+14]
     local subtree = tree:add(p_dummyproto, buffer(17,14))

     -- Add a subtree to our root for the first two bytes
     local t = subtree:add(f_X, buffer(17, 2))

     -- Add a sub subtree
     local t2 = t:add(f_Y, buffer(17, 1))

     -- Parse sub data
     parse_data(t, buffer, 18)
   end
end

function parse_data(tree, buffer, start)
     -- Wireshark integrate bitop from luajit http://bitop.luajit.org/
     field_1 = buffer(start, 1):uint()
     field_1 = bit.band(field_1, 0x3)

     -- You can also append free text information to current field
     if field_1 < 16 then
         tree:append_text(" field information")
     end
end

Finally register your post dissector

register_postdissector(p_dummyproto)

A complete example can be found here. It's a full reimplementation of ARP protocol dissector in Lua.

Dans deux semaines se déroule LE rassemblement du logiciel libre en PACA. Les JM2L (Journées Méditerranéennes des Logiciels Libres) reviennent encore une fois sur le campus de Sophia Antipolis. Au menu : conférences, stands et ateliers pour faire découvrir à tous et à toutes le monde du logiciel libre dans la joie et la bonne humeur. L'entrée est libre et gratuite les deux jours de l'événement (29 et 30 novembre 2013) !

Depuis le début de l'informatique, la façon la plus courante d'accéder à une ressource (compte) est d'utiliser le couple nom d'utilisateur/mot de passe. Pour l'anecdote, Richard Stallman ne mettait (volontairement) pas de mot de passe à son compte UNIX. Pour chaque service, il faut donc rentrer ce couple afin d'être authentifié. Le problème, c'est qu'il y a de plus en plus de services que nous utilisons quotidiennement. Il faut donc inlassablement répéter toujours les mêmes actions même si, la plupart du temps, on se facilite la tâche avec une connexion automatique gérée par le navigateur.

Pour tous ces services il faudrait, en théorie, avoir un mot de passe fort (compliqué) et différent. Mais en tant que bon fainéants, on utilise juste un sous ensemble récurrent. Problème : si le mot de passe est trop simple et/ou que le site se fait voler sa base de données, un hacker pourra (après déchiffrage) se connecter sur tous vos comptes.

Afin de répondre à cette problématique, j'ai développé gPass (global Password). Il s'agit d'un serveur de mot de passe. Quand on veut se connecter à un service, il faudra rentrer une clé maître qui va permettre de récupérer le mot de passe associé au couple site/nom d'utilisateur. Mot de passe qui sera évidemment complexe (il y a un générateur intégré) et unique par service (du moins ceux que l'on aura configurés). Concernant la sécurité, la base de données ne contient que des valeurs chiffrées (AES 256). Chiffrement qui s'effectue sur le client (sauf lors de l'insertion dans la base). la clé de chiffrement est une dérivation (PKBDF2) de la clé maître. De plus, les mots de passes sont salés. Donc, si on a une clé maître forte, il est quasiment impossible de déchiffrer la base.

En fait, il s'agit d'un concurrent plus ou moins proche de lastPass. Ses avantages sont qu'il est open source (c'est l'origine du projet), auto hébergable, que l'on peut gérer plusieurs comptes, avoir plusieurs clés maître. L'inconvénient c'est qu'il n'y a qu'un seul plugin disponible pour firefox. Pour ceux qui connaissent, on peut rapprocher cette solution d'un SSO (Single Sign On) pour les sites qui ne le proposent pas. C'est à dire que l'on s'authentifie une seule fois via un service unique pour accéder à un panel d'autres services.

Lors de l'hébergement d'un serveur, il est important de garantir la disponibilité de ce dernier (s'il n'y a plus de connexion, plus de mot de passe...). Néanmoins, si on n'a pas le plugin installé (changement de PC), on peut toujours aller consulter les mots de passe directement en ligne. Attention cependant à ne pas perdre la base de données ou la clé maître, il serait impossible de retrouver la valeur des mots de passe (sauf système de récupération propre à chaque service) !

Un serveur de démonstration est disponible ici (c'est celui configuré par défaut par le plugin), vous noterez les couleurs chatoyantes utilisées (j'ai participé au design d'iOS7). Le client (extension firefox) est disponible ici. Le code source est là. Il s'agit de la version 0.1, donc il est possible qu'elle ne fonctionne pas pour tous les sites et/ou qu'il y ait des évolutions à l'avenir.

Dans les cafés voisins
Nous étions quelques-uns
Qui attendions la gloire
Et bien que miséreux
Avec le ventre creux
Nous ne cessions d'y croire
Et quand quelque bistro
Contre un bon repas chaud
Nous prenait une toile
Nous récitions des vers
Groupés autour du poêle
En oubliant l'hiver

Nostalgie (encore). Promis, je ne le fais pas exprès ! En lisant cet article qui mentionne le changement de nom du Site du Zéro (qui devient OpenClassrooms), je me suis dit "tiens, si j'allais voir ce qu'est devenu codes-sources.com". Je n'avais plus de nouvelles depuis longtemps, et pour cause, le site est passé sous la bannière de comment ça marche. Horreur !! Si le style graphique a été plutôt bien rafraîchi, la publicité le rend complètement inutilisable... En cherchant le blog du fondateur (Nix), je m'aperçois que ça fait déjà un an que CS est sous la houlette de CCM. Les noms de domaines ont été racheté récemment et l'esprit semble plus machine à fric qu'entraide communautaire... C'est aussi le cas pour la plupart des sites rachetés par Benchmark Group (Linternaute.com, JournalDuNet.com, CopainsDavant.com, JournalDesFemmes.com etc...).

Tout cela me rapelle forcément mes début en informatique. De mon premier tableau excel à la fin du collège, au TI Basic de la TI-89, un peu de C et beaucoup de Visual Basic jusqu'à l'IUT. Le tout sur Windows XP ! Étant autodidacte à cette époque et ne parlant pas Anglais, vbfrance.com puis codes-sources.com m'a énormément aidé. Bien sûr, quand je regarde ce que j'ai pu produire à cette époque, j'ai carrément honte et je pourrais faire dix fois mieux aujourd'hui (et peut être dix fois mieux dans dix ans). Mais il faut rendre à César ce qui est à César et je remercie codes-sources pour m'avoir épaulé pendant ces années.

Finalement CodeS-SourceS a connu un destin classique. Le site était en déclin depuis plusieurs années malgrès les efforts des modérateurs. Les sources intéressantes étaient devenus trop rares (du moins sur vbfrance). Les gens ne commentaient plus. Chaque année on avait droit aux listes chaînées, matrices et Sudoku... CodeS-SourceS, c'était les années 2000, maintenant tout est sur GitHub. CodeS-SourceS est mort, vive CodeS-SourceS !

La bohème, la bohème
Ça voulait dire tu es jolie
La bohème, la bohème
Et nous avions tous du génie

...

La Bohème, Charles Aznavour et Jacques Plante, 1965